Softwareumstellung erfolgreich durchführen - Alle an Bord

„Warum eine neue Software, wenn die alte funktioniert?“ Diese Frage stellen viele Mitarbeitende, wenn eine Softwareumstellung bevorsteht. Oft werden Veränderungen als Bedrohung wahrgenommen und nicht als Chance zur Verbesserung betrachtet. Dabei sind gerade solche Neuerungen entscheidend, um die Effizienz zu steigern und Kosten zu senken. Ein kluges Change-Management kann nicht nur den Bedenken der Mitarbeitenden professionell begegnen, sondern auch ihre Motivation positiv beeinflussen und so den Wandel erfolgreich gestalten.

Markus Kawollek, Geschäftsführer der nuboworkers GmbH, verrät im Interview, wie der Prozess der Softwareumstellung erfolgreich gestaltet werden kann. Als Cloudworker und Change-Manager unterstützt er mit seinem Team Unternehmen bei der effizienten Umsetzung von Digitalisierungsprojekten im Bereich Microsoft 365.

Markus, wie viele Digitalisierungsprojekte habt ihr schon betreut?

Mittlerweile betreuen wir zwischen 30 und 40 Digitalisierungsprojekte pro Jahr. nuboworkers gibt es seit 2017, seitdem haben wir insgesamt rund 200 Projekte abgeschlossen. Wenn man auch kleinere Anwendungen und Workflows einbezieht, kommen wir sicherlich auf rund 250 Digitalisierungsprojekte.

Ist ein solches Projekt immer einem einzelnen Kunden zuzuordnen oder gibt es auch Kunden, die mehrere Projekte mit euch realisieren?

Es gibt unterschiedliche Konstellationen. Kleinere Kunden haben oft nur ein Digitalisierungsprojekt, wie beispielsweise die Umstellung vom Schwarzen Brett auf ein Intranet. Wir betreuen zum Beispiel ein relativ kleines Hausbauunternehmen mit 30 Mitarbeitenden, in dem nun alle in der Produktion ein Smartphone haben. Dort wird das Schwarze Brett durch ein Intranet auf SharePoint-Online-Basis ersetzt.

Bei größeren Kunden geht es oft um mehrere Projekte, zum Beispiel ein Unfallmeldeformular, das als App abgebildet werden soll, oder ein digitaler Freigabezyklus, der früher in Papierform durch das Unternehmen ging und dies jetzt digital tut. Das Ergebnis ist ein Protokoll, das in der SharePoint-Bibliothek gespeichert wird. Für solche Kunden führen wir manchmal acht oder neun Projekte durch.

Wie lange dauert ein Digitalisierungsprojekt?

Bei kleineren Prozessen wie der Einführung einer einzelnen Anwendung oder eines digitalisierten Umlaufs lässt sich der zeitliche Rahmen in der Regel recht gut einschätzen. Abhängig von der Größe der Anwendung oder des Prozesses kann dies mit Abstimmungen, Aufbau und Test relativ schnell, etwa in zwei bis zwölf Wochen, durchgeführt werden. Wichtig ist, dass wir in dieser Zeit nicht kontinuierlich am Thema arbeiten, da gerade Feedback und Selbsttests seitens des Kunden Zeit benötigen. Man entwickelt etwas, stimmt es ab und setzt es um. Hinzu kommt noch ein wenig Betreuung und dann ist der Prozess abgeschlossen.

Bei großen Projekten wie der Einführung von Microsoft Teams sieht die Situation anders aus. Ein derartiges Projekt beeinflusst im Grunde alles, was im Unternehmen geschieht. Wie arbeiten wir zusammen? Wie managen wir Aufgaben? Wie und wo kommunizieren wir? Welche Geräte verwenden wir dafür? Bei solchen Projekten wird auch deutlich, wie offen die Kommunikationskultur im Unternehmen ist.

Die Veränderung braucht Zeit. Sie kann nicht auf ein oder zwei Jahre begrenzt werden, vor allem aufgrund der ständigen Updates von Microsoft. Am Anfang ist viel Kommunikation, Training und Wissenstransfer erforderlich. Auch danach ist ein kontinuierliches Change-Management notwendig, selbst wenn die Betreuung mit der Zeit weniger wird. Darüber sollte sich der Kunde vor Projektbeginn im Klaren sein.

»Das Hauptziel ist immer eine Effizienzsteigerung oder eine Vereinfachung der Anwendung.«

Welche Hauptziele verfolgen eure Kunden mit der Einführung oder Umstellung von Software?

Das Hauptziel ist immer eine Effizienzsteigerung oder eine Vereinfachung der Anwendung. Vor allem die Effizienz ist dabei das zentrale Element, sei es durch Prozesse, die die Anwendung vereinfachen, die Rücklaufquote erhöhen oder die Zuverlässigkeit verbessern. Beschäftigte auf der Baustelle laufen nicht jeden Tag am Schwarzen Brett vorbei, sondern benötigen eine Push-Benachrichtigung auf ihrem Smartphone, um neue Beiträge zu erhalten.

Kosteneinsparungen und das volle Ausschöpfen von Lizenzen sind ebenfalls wichtige Themen. Wenn man zum Beispiel Microsoft 365 lizenziert hat, hat man in der Regel auch ein Paket, das Power Apps, Power Automate und SharePoint Online beinhaltet. Dieses Paket bietet bereits eine solide Basis, die beispielsweise für ein Intranet verwendet werden kann. Diese Möglichkeit sollte man nutzen.

Es geht bei solchen Projekten also nicht in erster Linie um die Digitalisierung um der Digitalisierung willen?

Nicht unbedingt, meistens liegt ein konkretes Problem oder eine Herausforderung vor. Kürzlich haben wir zum Beispiel einen Genehmigungszyklus für Budgetanträge digitalisiert. Der bisherige Papierprozess war sehr fehleranfällig. Es waren sechs bis sieben Genehmigungen erforderlich, die über verschiedene Stufen eingeholt werden mussten. Dies erfolgte mithilfe eines Papierformulars, das durch das Haus getragen wurde. Wir verfolgten den Prozess über vier Monate, um zu sehen, wie lange er dauerte. Das Ergebnis: durchschnittlich 21 bis 24 Tage. Außerdem bestätigte sich, dass der Antrag am Ende erschreckend oft nicht im Planungsbüro oder in der Planungsabteilung ankam. Durch die Digitalisierung des Prozesses geht nichts mehr verloren und die Durchlaufzeit konnte auf drei Tage verkürzt werden. Das senkt automatisch auch die Kosten, weil weniger Opportunitätskosten entstehen.

Wie und wann sollte man Stakeholder über das bevorstehende Projekt informieren und einbeziehen?

Am besten so früh wie möglich, zumindest mit der Ankündigung, dass Änderungen bevorstehen. Im Idealfall – und je nach Konstellation – lässt man die Stakeholder mitreden. Es ist wenig sinnvoll, wenn allein die IT entscheidet, einen Prozess zu digitalisieren. Das muss abgestimmt werden. So werden Funktionalitäten häufiger kritisch hinterfragt: Ist eine Funktion zwingend erforderlich oder eher „nice to have“?

Das Hinterfragen von Funktionalitäten ist auch dann wichtig, wenn bereits digitalisierte Prozesse vorhanden sind und diese durch ein anderes Tool ersetzt oder auf eine einheitliche Plattform gebracht werden sollen. Auch in solchen Fällen kann es sein, dass es nicht sinnvoll ist, einen Prozess eins zu eins zu übernehmen, da er möglicherweise nicht gut funktioniert oder das Nutzerfeedback zeigt, dass die Oberfläche zu kompliziert ist. Dies lässt sich nur herausfinden, wenn man möglichst früh mit den Stakeholdern spricht.

Gibt es einen festen Prozess, der bei diesen Projekten eingehalten werden sollte?

Unserer Meinung nach sollte man auf jeden Fall iterativ vorgehen. Wir beginnen immer mit einer Analyse, bei der wir den Ist-Zustand untersuchen und anschließend Ideen und Anforderungen festhalten. Das ist zunächst Arbeit, spart jedoch enorm viel Zeit bei der eigentlichen Umsetzung. So gewinnen wir ein klares Verständnis dafür, was der Kunde tatsächlich benötigt. Am besten dokumentiert man nicht nur den eigentlichen Prozess, sondern auch, wer daran beteiligt ist und welche Berechtigungen vorhanden sind. Wo gehen E-Mails oder ganz allgemein Benachrichtigungen hin? Wer arbeitet mit wem zusammen? Wer darf was sehen? Wer gibt welche Informationen weiter? Dadurch entsteht ein gewisser Dokumentationscharakter. Das bedeutet nicht zwangsläufig, dass am Ende ein 80-seitiges Dokument entsteht. Vielmehr geht es darum, eine Basis und ein gemeinsames Verständnis zu schaffen.

Bevor mit der Umsetzung begonnen wird, sollte ein Dialog mit den Anwendern stattfinden und gegebenenfalls ein Test durchgeführt werden. Unsere Erfahrung zeigt, dass sich während der Umsetzung oft noch einige Änderungen ergeben. Deswegen ist es wichtig, frühzeitig mit den Anwendern in den Dialog zu treten und Tests durchzuführen. Wenn die Umsetzung ohne Tests zu 100 % durchgezogen wird, treten am Ende oft viele Aspekte auf, die sich die Anwender anders vorgestellt haben.

Oberflächen können beispielsweise mit Mock-ups getestet werden, was relativ schnell geht. Intranet-Strukturen kann man mit Card Sorting erarbeiten und testen. Die konkrete Testmethode hängt von der Größe der Zielgruppe ab. Wenn die Zielgruppe für ein Intranet zum Beispiel 18.000 Mitarbeitende umfasst, wird es schwierig, alle zu Wort kommen zu lassen. Eine Umfrage könnte hierbei hilfreich sein. Am besten wählt man eine kleine Gruppe aus, bestehend aus Anwendern, Multiplikatoren (Champions, Power Usern, Key Usern) und Redakteuren, mischt diese ein bisschen durch und bittet um Feedback.

»Die größte Herausforderung bei der Planung und Einführung von Software ist der Mensch, denn er definiert die Anforderungen. «

Welche Rolle spielt das Management bei einer Umstellung oder Einführung von Software?

Zum einen wird das Management benötigt, um Entscheidungen zu treffen, zum anderen, um managementspezifische Anforderungen an die Software oder den Prozess zu erfüllen. Ohne Bewusstsein und Unterstützung des Managements ist der Rest nutzlos. Wenn wir einen Prozess für eine Abteilung digitalisieren sollen, der Bereichsleiter jedoch dagegen ist und die Lösung nicht freigibt, kommen wir an dieser Stelle nicht voran.

Das Management spielt zudem eine Vorreiterrolle. Wenn man zum Beispiel Plattformen wie Viva Engage einführt, sollte das Management von Anfang an aktiv dort posten und sich als Best Practice präsentieren. Man muss mit einer Mehrwertkommunikation an die Führungskräfte herantreten. Je nachdem, wie groß der Change ist, empfiehlt es sich, eigene Formate für Manager anzubieten, um ihre Anwendungsfälle abzubilden. Ein Beispiel: Wenn ein Teams-Rollout geplant ist, sollte den Führungskräften aufgezeigt werden, wie sie konkret davon profitieren. Dabei können ganz andere Anforderungen auftreten als bei der Belegschaft, zum Beispiel: Wie können die Tools meine Führungsmethodik unterstützen oder verändern?

Welche Herausforderungen können bei der Implementierung neuer Software auftreten und welche Maßnahmen empfiehlst du, um diese zu bewältigen?

Die größte Herausforderung bei der Planung und Einführung von Software ist der Mensch. Ein Klassiker, den wir immer wieder zu hören bekommen, lautet: „Warum? Das haben wir schon immer so gemacht.“ Diese Aussage stammt tatsächlich nicht nur von älteren Mitarbeitenden, wie man zunächst vermuten könnte. Wir hören sie auch sehr oft von jüngeren Mitarbeitenden, teilweise sogar schon von Auszubildenden oder Studierenden.

Um dieser Herausforderung zu begegnen, müssen die Mitarbeitenden einbezogen werden. Die Lern- und Kommunikationstypen sind sehr unterschiedlich. Dies muss berücksichtigt werden, um die Mitarbeitenden dort abzuholen, wo sie stehen. Inhalte müssen so aufbereitet werden, dass Mitarbeitende sie verstehen und nutzen möchten. Manche Personen sind eher visuell orientiert und lesen Inhalte im Intranet oder auf einer Hilfeplattform. Andere sind eher auditiv und nutzen das Intranet so gut wie nie. In solchen Fällen muss man verschiedene Kanäle bedienen, was einen gewissen Schulungsaufwand mit sich bringt. Dieser muss jedoch angemessen sein. Wenn ich eine bestimmte Anwendung einführe, die von vier Personen genutzt wird, muss ich nicht fünf verschiedene Schulungsmethoden zur Erklärung verwenden.

»Change-Management ist kein Sprint, sondern ein Marathon. Deshalb sollte man keine Energie in eine Gruppe investieren, die keine Lust auf Veränderung hat.«

Die größte Herausforderung ist also der Faktor Mensch und nicht die technische Umsetzung?

Ja, die technische Umsetzung ist letztlich eine Frage des Budgets. Hier ist so gut wie alles machbar. Die Herausforderung ist der Mensch, denn er definiert die Anforderungen. Das verdeutlicht das Beispiel von Microsoft To Do. Zu Beginn hatte die Anwendung nur einen begrenzten Funktionsumfang. Durch das Feedback der Nutzer hat sich die Anwendung weiterentwickelt. Was für viele Menschen positiv ist, bläht für andere die Anwendung unnötig mit Funktionen auf. Man darf bei der Entwicklung der Lösung den Menschen nie aus den Augen verlieren. Die meisten von uns nutzen vermutlich nie mehr als 10 % der Excel-Funktionen, nur ein sehr kleiner Teil profitiert in vollem Umfang von Excel. Daher ist beispielsweise eine Gestaltung mit erweiterten Menüs und ähnlichen Funktionen sehr hilfreich, statt alle Funktionen direkt zu präsentieren und damit die Anwender zu überlasten bzw. den Eindruck eines komplizierten Tools zu vermitteln.

Wie lassen sich Widerstände gegen die Veränderung frühzeitig erkennen? Wie äußern sie sich?

Da sind wir wieder bei meiner Lieblingsaussage: „Das haben wir schon immer so gemacht.“ Doch so offensichtlich ist es nicht immer. Manchmal gibt es auch Personen, die darauf bestehen, dass bestimmte Funktionen weiterhin verfügbar sein müssen, dass Dinge früher mit einem Klick weniger funktioniert haben oder dass die Oberfläche früher schöner war. Solche Erkenntnisse erlangt man nur im Austausch – wie genau, hängt wiederum von der Größe der Zielgruppe ab. Man kann zum Beispiel eine Umfrage durchführen, in der man die Pain Points oder die Anforderungen abfragt. Wenn bei den Anforderungen sehr viele Punkte genannt werden oder Punkte, die spezifisch mit der aktuellen Software zusammenhängen, dann weiß man, dass die Ablösung kein Spaziergang wird.

Besteht die Gefahr, dass eine solche Gruppe das gesamte Projekt gefährdet oder Zweifel bei anderen Teammitgliedern sät?

Das hängt von der Größe der Gruppe ab. Wir haben die Erfahrung gemacht, dass die Gruppe oft versucht, das intern zu klären, was meistens sehr hilfreich ist. Es hängt auch davon ab, wie die Gruppe zusammengesetzt ist. Wenn sie aus C-Level, Top-Management und mittlerem Management besteht, wird das Projekt scheitern. Wie bereits erwähnt, ist ein Change nicht ohne die Unterstützung des Managements umsetzbar. Wenn jedoch nur wenige Anwender dagegen sind, kann das Projekt trotzdem erfolgreich sein.

Wie sollte man mit Widerständen umgehen und welche Strategien zur Überwindung gibt es?

Kommunikation ist das A und O. Man muss die Leute abholen und ihnen konkrete Mehrwerte aufzeigen. Das funktioniert jedoch nicht bei allen. Im Change-Management besagt eine Regel, dass 10 bis 20 Prozent der Beteiligten „Gegner“ sind. Diese Gruppe muss man ignorieren und sich auf diejenigen konzentrieren, die Lust auf Veränderung haben. Man darf sich nicht mit den Randgruppen aufhalten. Bei einem Teams-Rollout wird es immer Personen geben, die gar nicht zu Teams wechseln möchten und so lange wie möglich auf der alten Plattform bleiben. Die Erfahrung zeigt jedoch, dass die meisten von ihnen irgendwann mitkommen.

Generell gilt: Change-Management ist kein Sprint, sondern ein Marathon. Deshalb sollte man keine Energie in eine Gruppe investieren, die keine Lust auf Veränderung hat.

Gibt es Warnzeichen, die darauf hinweisen, dass man die Einführung oder Umstellung einer Software unterlassen sollte?

In dieser Hinsicht hat sich mein Bauchgefühl in der Vergangenheit als sehr zuverlässiger Indikator erwiesen. Wenn wir bereits im Erstgespräch feststellen, dass die Prozesse und Entscheidungen im Unternehmen sehr schwerfällig sind und wenig Fortschritt erkennbar ist, dann verlaufen in der Regel auch die Projekte nicht gut. Im schlimmsten Fall kommen wir zu dem Schluss, dass das Unternehmen noch nicht für so ein Projekt bereit ist. Ein weiteres Warnzeichen besteht darin, dass die Beteiligten uns nicht klar sagen können, wie eine Verbesserung bzw. der Zielprozess aussehen soll. In solchen Fällen entwickelt sich das Projekt oft zu einer Never-ending-Story.

Was sind die Gründe für fehlende Motivation bei Projektverantwortlichen?

Ein möglicher Grund ist, dass Projekte von oben nach unten entschieden und delegiert werden. Mangelnde Motivation kann auch darauf zurückzuführen sein, dass jemand einfach keine Lust auf das Projekt hat. Das muss nicht unbedingt etwas mit dem Projekt an sich zu tun haben. Es kann auch daran liegen, dass die Person einfach schon in sehr viele Projekte eingebunden ist und keine Ressourcen oder Kapazitäten mehr übrig hat. Es kann auch sein, dass den Projektbeteiligten der Mehrwert nicht klar ist. Hier sind wir wieder bei der Kommunikation. Es muss klar sein, warum etwas gemacht wird – und zwar bevor das Projekt beginnt. Sonst wird es holprig.

Wie kann man Mitarbeitende am besten motivieren, sich auf die Veränderungen einzulassen? Welche Schulungs- und Unterstützungsmaßnahmen sollten zur Verfügung gestellt werden?

Das hängt vom Kontext ab. Häufig arbeiten wir mit sogenannten Champions, Key Usern oder Multiplikatoren. Diese erhalten eine besondere Betreuung in Form von speziellen Updates, Neuheiten oder auch Pilottests, an denen sie teilnehmen können. Im Gegenzug übernehmen diese Personen jedoch auch Pflichten, zum Beispiel im Bereich des Wissenstransfers. Sie fungieren oft als Botschafter.

Je nach Kunde gibt es für diese Gruppe auch Incentives in Form von Champions-Veranstaltungen, bei denen neben dem Wissenstransfer auch Socializing stattfindet, beispielsweise bei einem gemeinsamen Essen. Diese Praxis hat sich sehr bewährt, dennoch gibt es auch andere Arten von Incentives.

Welche Incentives sind das?

Eine Methode, die derzeit in aller Munde ist, ist Gamification – die Wissensvermittlung auf spielerische Art und Weise. Die Umsetzung muss nicht kompliziert oder aufwendig sein. Betrachten wir das Thema IT-Sicherheit: Oft genügt es, in einem Intranet-Artikel eine Frage dazu zu stellen und die ersten 20 Personen, die diese Frage richtig kommentieren, können etwas gewinnen. Dann bereiten wir kleine Geschenke vor, die mit dem Thema zu tun haben, zum Beispiel einen Schlüsselanhänger mit einer kleinen Taschenlampe oder eine Rettungsdecke. Es geht nicht darum, große Sachen zu machen.

Eine weitere Möglichkeit, die sich bei der Einführung eines neuen Tools bietet, ist eine Challenge. Dabei müssen die Mitarbeitenden ähnlich wie bei einer Stempelkarte Punkte sammeln, sei es durch das Einstellen eines Profilbildes, das Posten eines eigenen Beitrags oder das Liken eines Beitrags eines Kollegen. Diese Punkte kann man dann einlösen und wieder eine Kleinigkeit gewinnen. Das motiviert die Mitarbeitenden und macht sie gleichzeitig mit dem Tool vertraut. Wir haben bei solchen Aktionen immer ein sehr positives Feedback erhalten.

Wie messt ihr den Erfolg von Softwareeinführungen oder Digitalisierungsprojekten?

Sehr gute Frage! Darüber könnten wir stundenlang diskutieren. Zum einen bietet Microsoft ein Dashboard, das direkte Auswertungen in Form von Nutzungsstatistiken der Microsoft-365-Umgebung zur Verfügung stellt. Damit kann man den Erfolg aus einer technischen Perspektive betrachten. Zum anderen gibt es Power BI, das Reports erstellt, die man einfach herunterladen kann. Dafür benötigt man allerdings eine Power-BI-Pro-Lizenz. Diese „trockenen“ Daten zeigen beispielsweise auf, wie viele Chats geführt, wie viele E-Mails verschickt oder wie viele Telefonate und Meetings in Teams durchgeführt wurden oder wie viel Speicherplatz belegt ist. Solche Zahlen geben jedoch nur bedingt Aufschluss über die tatsächliche Nutzung der Tools. Um herauszufinden, woran es den Nutzenden mangelt, führt kein Weg an einer Befragung vorbei. Dabei wird eine Nullmessung vorgenommen, indem vor dem Rollout eines neuen Tools eine Befragung durchgeführt wird. Diese wird regelmäßig wiederholt, um den Fortschritt oder die Veränderung zu messen. Die Fragen werden je nach Tool oder Prozess geclustert, abhängig davon, was eingeführt wird. Bei einem Zeithorizont von zwei Jahren sollte man mindestens drei oder vier Umfragen durchführen, um die Nullmessung zu validieren. Auf diese Weise kann festgestellt werden, ob die Nutzenden mit dem Tool zurechtkommen und wissen, wo sie Funktionen und Inhalte finden.

Welche Kennzahl oder welcher KPI ist für euch am wichtigsten?

Ich finde Nutzerstatistiken sehr interessant, sie sind für mich jedoch nicht die wichtigsten Zahlen. Diese Statistiken können manchmal auch irreführend sein. Wenn ich sehe, dass das Datenvolumen steigt, gehe ich zunächst davon aus, dass alles funktioniert. Tatsächlich kann es jedoch sein, dass immer mehr Dateien mit Version 1, Version 2, Version 3 usw. abgelegt werden, anstatt die Versionierung in SharePoint Online oder OneDrive zu nutzen.

Für mich ist der sichere Umgang mit dem jeweiligen Tool am wichtigsten. Dies lässt sich nur herausfinden, indem man den Nutzenden detaillierte Fragen stellt. So lässt sich überprüfen, ob der Nutzen bzw. der Use Case hinter dem Tool tatsächlich verstanden wurde. Bei einem Teams-Rollout erleben wir oft, dass Kunden sagen, alles habe einwandfrei funktioniert, und dass alle das Tool nutzen. Wenn wir dann genauer nachfragen, heißt es oft: „Wir chatten und telefonieren damit.“ Das alleine ist nicht aussagekräftig. Wenn jemand chattet, statt eine E-Mail mit zwei Sätzen zu schreiben, hat er zwar die Transferleistung erbracht, aber nicht zwingend die Funktionalitäten von Teams verstanden. Es werden zum Beispiel oft Dokumente in Teams abgelegt, das Co-Authoring oder das automatische Speichern hingegen wird nicht genutzt.

Welche Bedeutung hat die Unternehmenskultur für eure Projekte und wie kann sie berücksichtigt werden?

Die Feedbackkultur ist entscheidend. Selbst wenn wir das Projekt aktiv kommunikativ starten, erhalten wir bei Befragungen nur 12 bis 20 Prozent Rücklauf, wenn keine aktiv gelebte Feedbackkultur vorhanden ist. Dann müssen wir darüber nachdenken, wie wir die Situation ändern können, um an das benötigte Feedback zu kommen.

Was ist mit Unternehmen, die bisher hauptsächlich analog gearbeitet haben und/oder viele ältere Mitarbeitende beschäftigten?

Wenn in einem Unternehmen bisher überwiegend analog gearbeitet wurde, jedoch eine aktive Kommunikationskultur besteht, sind in der Regel keine besonderen Anstrengungen notwendig. Die Mitarbeitenden sind es gewohnt zu kommunizieren und müssen lediglich das Tool wechseln.

Wenn in einem Unternehmen jedoch wenig kommuniziert und nicht abteilungsübergreifend gearbeitet wird, können übergreifende Projekte schwierig sein. Für die Einführung eines Intranets müssen zum Beispiel die IT- und die Kommunikationsabteilung zusammenarbeiten. Zwar haben diese Abteilungen schon vor der Umstellung miteinander kommuniziert, jedoch müssen sie nun aktiv in den Austausch und Dialog treten. Dadurch entsteht eine viel transparentere Kommunikation, die jedoch erst wachsen muss.

Hast du einen letzten Tipp für alle, die ein Veränderungsprojekt planen und umsetzen müssen?

Es gibt ein Zitat, das ich sehr gerne verwende: „Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.” Das Wichtigste bei einem Projekt ist, einfach anzufangen. Natürlich braucht man einen Plan und Strukturen. Man muss sich Gedanken machen über die Zielgruppe, über Prozesse, über die beteiligten Personen. Doch vor allem muss man anfangen. Denn Collaboration beginnt im Kopf und nicht mit Technik.

»Es gibt ein Zitat, das ich sehr gerne verwende: „Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.” Das Wichtigste bei einem Projekt ist, einfach anzufangen.«