Warum digitale Transformation nach 12 Monaten stockt und wie Sie wieder Tempo aufbauen

Fünf Digitalprojekte sind gestartet, neue Software ist eingeführt, Schulungen haben stattgefunden. Trotzdem dauern die wichtigsten Geschäftsprozesse beinahe so lange wie zuvor. Nach zwölf Monaten steht die Geschäftsleitung vor einer unangenehmen Frage: Warum entsteht aus den Investitionen noch keine erkennbare Verbesserung?

Häufig liegt das Problem nicht bei einer einzelnen Technologie. Projekte konkurrieren um dieselben Fachpersonen, Entscheidungen bleiben liegen und Mitarbeitende wechseln zwischen neuen Anwendungen und alten Arbeitsweisen. Ein funktionierendes System ist noch kein veränderter Geschäftsprozess.

Um wieder Tempo aufzubauen, braucht die digitale Transformation deshalb eine andere Steuerung: ein gemeinsames Veränderungsprogramm mit begrenzter Parallelität, verbindlichen Verantwortlichkeiten und messbaren Ergebnissen. Für Schweizer KMU mit schlanken IT-Teams ist diese Unterscheidung besonders wichtig.

Ein wirksamer Neustart beginnt nicht mit dem nächsten Tool. Er beginnt mit einer ehrlichen Bestandsaufnahme: Welche Initiativen schaffen bereits Nutzen, welche blockieren sich gegenseitig und welche müssen vorübergehend zurückgestellt werden?

Warum Ihre digitale Transformation stoppt, sobald 5 Projekte parallel laufen?

Fünf parallele Digitalprojekte können eine Transformation zum Stillstand bringen, wenn sie dieselben internen Schlüsselpersonen benötigen. Nicht die Projektanzahl allein ist entscheidend, sondern die gemeinsam beanspruchte Kapazität von Fachbereichen, IT und Geschäftsleitung. Werden diese Engpässe nicht berücksichtigt, verlängern sich selbst gut finanzierte Vorhaben gegenseitig.

Der Mechanismus heisst Überverpflichtung: Jedes Projekt plant mit einer bestimmten Verfügbarkeit seiner Fachpersonen. In der Gesamtplanung taucht dieselbe Person jedoch mehrfach auf. Der IT-Verantwortliche soll beispielsweise eine ERP-Schnittstelle prüfen, ein CRM-Projekt begleiten und gleichzeitig Anwenderfragen zur neuen Dokumentenverwaltung beantworten.

Auf dem Papier verfügt jedes Projekt über die benötigte Unterstützung. In der Arbeitswoche reicht die verfügbare Zeit jedoch nicht aus. Entscheidungen stauen sich, Tests werden verschoben und Mitarbeitende springen zwischen Aufgaben, ohne eine davon vollständig abzuschliessen.

Das Schweizer KMU-Portal des SECO zu den notwendigen Ressourcen der digitalen Wende betont die Bedeutung personeller Kapazitäten, technischer Kompetenzen und Weiterbildung. Gerade kleinere Unternehmen verfügen häufig über weniger spezialisierte Ressourcen als Grossunternehmen.

Eine Kapazitätsdiagnose sollte deshalb vor dem nächsten Projektentscheid stattfinden. Erfassen Sie für jede Initiative die benötigten Schlüsselpersonen, deren Aufgaben und ihre tatsächlich verfügbare Wochenkapazität.

Ein ausdrücklich hypothetisches Beispiel: Eine IT-Fachperson kann neben dem Tagesgeschäft zwölf Stunden pro Woche für Veränderungen einsetzen. Drei laufende Projekte benötigen zusammen zwanzig Stunden. Die fehlenden acht Stunden verschwinden nicht durch eine höhere Priorität in der Projektpräsentation.

Die Konsequenz reicht über Terminverschiebungen hinaus. Werden Initiativen wiederholt angekündigt, unterbrochen und erneut gestartet, kann das Vertrauen in weitere Veränderungen sinken. Mitarbeitende erleben dann zusätzliche Arbeit, ohne die versprochene Entlastung zu erhalten.

Erst wenn sichtbar ist, welche Personen tatsächlich den Durchsatz begrenzen, lässt sich entscheiden, welche Vorhaben gleichzeitig sinnvoll sind. Die übrigen Projekte benötigen eine verbindliche Reihenfolge.

Wie planen Sie Transformation in 3 Wellen, ohne sich zu verzetteln?

Planen Sie digitale Transformation in drei Wellen, indem Sie zuerst technische und organisatorische Voraussetzungen schaffen, anschliessend entlastende Prozessverbesserungen umsetzen und zuletzt komplexe, bereichsübergreifende Veränderungen angehen. Entscheidend ist nicht ein fixer Kalender, sondern ob jede Welle genügend Nutzen und freie Kapazität für die nächste erzeugt.

Ein Wellenmodell funktioniert nur, wenn die Reihenfolge aus tatsächlichen Abhängigkeiten entsteht. Die lauteste Fachabteilung oder das attraktivste Softwareangebot darf nicht automatisch den Start bestimmen.

Eine praktikable Einteilung sieht folgendermassen aus:

Bewerten Sie jedes Vorhaben vor der Zuordnung anhand derselben Kriterien: Welche Systeme müssen zuerst funktionieren? Wie viele Prozesse sind betroffen? Sind die benötigten Key User verfügbar? Welche regulatorischen oder vertraglichen Anforderungen beeinflussen die Reihenfolge?

Ein scheinbar einfacher Quick Win kann ungeeignet für die erste Welle sein, wenn er auf Daten einer noch ausstehenden Migration angewiesen ist. Umgekehrt kann eine unspektakuläre Bereinigung von Stammdaten mehrere spätere Projekte gleichzeitig erleichtern.

Eine wissenschaftliche Studie zur Ressourcensteuerung in Projektportfolios von Browning und Yassine aus dem Jahr 2015 untersucht unter anderem Abhängigkeiten, Ressourcenkonkurrenz und Priorisierungsregeln. Sie behandelt Produktentwicklungsportfolios, nicht speziell Schweizer Transformationsprogramme. Ihr methodischer Beitrag liegt darin, dass unterschiedliche Portfolioeigenschaften unterschiedliche Priorisierungsentscheidungen erfordern.

Zwischen den Wellen braucht es bewusst eingeplante Kapazität, um offene Fehler zu beheben, Dokumentation zu aktualisieren und Verantwortlichkeiten in den Regelbetrieb zu übergeben. Ein starrer Übergang nach einem Kalendermonat kann diesen Bedarf übergehen.

Ein kleiner Pilot für die zweite Welle darf dennoch parallel stattfinden, sofern er keine kritischen Ressourcen der ersten Welle bindet und klare Abbruchbedingungen besitzt. Das Wellenmodell ist keine Vorschrift, dass immer nur ein einziges Projekt laufen darf.

Für die Freigabe der nächsten Welle sollte die Programmleitung nachweisen können, dass vereinbarte Prozessziele erreicht oder begründete Abweichungen akzeptiert wurden, offene Risiken beherrschbar sind und die benötigten Personen tatsächlich zur Verfügung stehen.

Die Länge jeder Welle richtet sich nach ihrem Umfang und der Fähigkeit des Unternehmens, Veränderungen aufzunehmen. Entscheidend bleibt, dass nicht nur technische Lieferobjekte, sondern auch die versprochene Wirkung erreicht wird.

Adoption oder ROI: Welche Kennzahl ist für Transformation bei 200 Mitarbeitenden wichtiger?

Bei einem Unternehmen mit 200 Mitarbeitenden ist in der frühen Transformation die tatsächliche Nutzung neuer Arbeitsweisen meist aussagekräftiger als eine unsichere ROI-Prognose. Langfristig genügt Adoption jedoch nicht. Die Geschäftsleitung muss nachweisen können, dass veränderte Prozesse Zeit sparen, Fehler reduzieren oder einen anderen messbaren Unternehmensbeitrag liefern.

Adoption beschreibt Nutzung, ROI beschreibt wirtschaftlichen Rückfluss. Beide Kennzahlen beantworten unterschiedliche Fragen. Eine Anwendung kann rege genutzt werden, während Mitarbeitende weiterhin Informationen doppelt erfassen oder Genehmigungen ausserhalb des Systems per E-Mail einholen.

Eine hohe Login-Quote ist deshalb kein ausreichender Erfolgsnachweis. Aussagekräftiger ist, welcher Anteil relevanter Geschäftsvorgänge vollständig über den vorgesehenen neuen Prozess abgewickelt wird.

Für die Programmsteuerung bietet sich eine gestaffelte Messlogik an:

Erheben Sie die Ausgangswerte möglichst vor dem Projektstart. Fehlt eine Baseline, muss die spätere Erfolgsmessung mit einer nachvollziehbaren Einschränkung arbeiten. Eine Verbesserung darf nicht automatisch dem neuen Tool zugeschrieben werden, wenn gleichzeitig Personal, Mengen oder Prozessregeln verändert wurden.

Bei 200 Mitarbeitenden ist eine detaillierte ROI-Modellierung häufig mit erheblichen Schätzunsicherheiten verbunden, insbesondere wenn verschiedene Projekte dieselben Prozesse beeinflussen. Zwei oder drei belastbare Kennzahlen sind für operative Entscheide oft hilfreicher als eine umfangreiche Berechnung mit unsicheren Annahmen.

Die Gewichtung hängt vom Transformationstyp ab. Bei einer sicherheitsrelevanten Umstellung können zunächst vollständige Abdeckung und zuverlässige Nutzung wichtiger sein. Bei einer Prozessautomatisierung stehen später Bearbeitungszeit, Qualität und Kosten im Vordergrund.

Kann die Programmleitung nach einem Jahr keine zwei oder drei nachvollziehbaren Wirkungskennzahlen vorlegen, ist das ein Anlass, die bisherige Steuerungslogik zu überprüfen. Häufig beginnt genau dort die notwendige Verschiebung vom Tool-Projekt zum Veränderungsprogramm.

Der Change-Fehler, der Key User verbrennt und die Einführung um Monate verzögert

Ein besonders folgenreicher Change-Fehler besteht darin, Key User gleichzeitig als Tester, Schulende, Veränderungsbotschafter und erste Supportstelle einzuplanen, ohne sie von regulären Aufgaben zu entlasten. Dadurch entsteht ein personeller Engpass. Wenn diese Personen ausfallen oder überlastet sind, können sich Schulung, Fehlerbehebung und produktive Einführung über Monate verzögern.

Key User verbinden Fachwissen mit dem neuen System. Sie kennen Ausnahmen im Geschäftsprozess, erkennen unpraktische Abläufe und übersetzen technische Änderungen in den Arbeitsalltag ihrer Kolleginnen und Kollegen.

Genau deshalb werden sie häufig für immer mehr Aufgaben eingesetzt. Zusätzlich zum Testen sollen sie Schulungsunterlagen verfassen, Fragen beantworten, Fehler dokumentieren und das Projekt in Teammeetings vertreten. Ihre ursprünglichen Fachaufgaben bleiben bestehen.

Eine longitudinale wissenschaftliche Studie zu Digitalisierung und Arbeitsbelastung von Zacher und Rudolph untersuchte 1’661 Beschäftigte in Deutschland über 33 Erhebungswellen zwischen April 2020 und Dezember 2022. Sie fand wechselseitige Zusammenhänge zwischen Digitalisierung und Arbeitsbelastung. Die Studie untersucht keine spezifischen Key-User-Rollen und belegt keine feste Verzögerungsdauer; sie unterstreicht jedoch, warum Arbeitsbelastung in Veränderungsprogrammen bewusst beobachtet werden sollte.

Die Gegenmassnahme ist eine verbindliche Rollengestaltung. Legen Sie für jede Key-User-Funktion fest, welches Zeitbudget zur Verfügung steht, welche Aufgaben in der Linie entfallen und wer bei Abwesenheit übernimmt. Das ist eine Führungsentscheidung, keine informelle Bitte an besonders engagierte Mitarbeitende.

Definieren Sie ausserdem, wann Key User Störungen unmittelbar eskalieren dürfen. Eine produktionskritische Blockade sollte nicht erst durch mehrere Abstimmungsrunden gehen müssen. Die erbrachte Veränderungsarbeit gehört sichtbar in die Zielvereinbarung beziehungsweise Leistungsbeurteilung.

In einem Schweizer KMU kann eine kurze, direkte Rollenvereinbarung zwischen Linienführung, Key User und Programmleitung wirksamer sein als ein umfangreiches Rollenhandbuch, sofern Aufgaben, Kapazität und Eskalationswege eindeutig dokumentiert sind.

Achten Sie auf Frühwarnzeichen: Supportfragen werden regelmässig ausserhalb der Arbeitszeit beantwortet, die Warteschlange wächst, oder die zuständige Fachführung nimmt nicht mehr an wichtigen Abstimmungen teil. Solche Beobachtungen sollten zu einer sofortigen Kapazitätsprüfung führen.

Eine technisch funktionierende Lösung kann trotzdem scheitern, wenn niemand mehr Zeit hat, sie im Alltag zu verankern. Deshalb muss die Programmleitung personelle Belastung genauso ernst nehmen wie technische Risiken.

Wie entkoppeln Sie 4 Digitalprojekte, damit eins nicht alle blockiert?

Vier Digitalprojekte lassen sich entkoppeln, indem Sie technische, personelle und entscheidungsbezogene Abhängigkeiten getrennt analysieren. Fixieren Sie gemeinsame Schnittstellen frühzeitig, regeln Sie Stammdaten zentral und schaffen Sie eigenständige Entscheidungswege. Vollständige Unabhängigkeit ist selten erreichbar; das Ziel besteht darin, vermeidbare Blockaden zu beseitigen und unvermeidbare Kopplungen bewusst zu steuern.

Eine häufige Fehlannahme lautet: Wenn Projekt A verspätet ist, muss Projekt B ebenfalls warten. Das stimmt nur, wenn B tatsächlich auf ein Ergebnis von A angewiesen ist.

Unterscheiden Sie deshalb drei Arten von Abhängigkeiten:

• Technische Abhängigkeiten: Mehrere Vorhaben verwenden dieselben Schnittstellen, Stammdaten oder Systemkomponenten.
• Personelle Abhängigkeiten: Projekte benötigen dieselben Fachpersonen, Entwickler oder Key User.
• Entscheider-Abhängigkeiten: Mehrere Teams warten auf dieselben Freigaben oder Managemententscheidungen.

Jede Kategorie erfordert eine eigene Lösung. Eine gemeinsam vereinbarte Schnittstellenspezifikation kann technische Unsicherheit reduzieren. Eine zentrale Datenverantwortung verhindert widersprüchliche Definitionen. Verbindlich reservierte Kapazitäten reduzieren Personenkonflikte. Regelmässige, projektbezogene Entscheidungsfenster verhindern, dass jede Freigabe bis zur nächsten grossen Steuerungssitzung warten muss.

Auch getrennte Testumgebungen können helfen, sofern gemeinsame Ressourcen und Datenflüsse kontrolliert bleiben. Eine isolierte Pilotumgebung ersetzt allerdings keine Prüfung der späteren Produktivintegration.

Ein einfacher Test macht überflüssige Abhängigkeiten sichtbar: Könnte Projekt B in einer begrenzten Form starten, ohne dass Projekt A vollständig abgeschlossen ist? Falls ja, prüfen Sie, ob mit Testdaten, einer stabilen Schnittstellenvereinbarung oder einem engeren Pilotumfang begonnen werden kann.

Bleibt B dagegen beispielsweise auf die verbindliche Kundennummer aus einer zentralen Stammdatenmigration angewiesen, handelt es sich um eine echte Abhängigkeit. Diese muss im Plan stehen und mit einem verantwortlichen Liefertermin geführt werden.

Vermeiden Sie Scheinentkopplung. Zwei Projekte können in unterschiedlichen Gantt-Diagrammen unabhängig aussehen und trotzdem dieselbe einzige IT-Fachperson beanspruchen. Ebenso wenig genügt eine technische Trennung, wenn alle wesentlichen Freigaben bei einer überlasteten Führungsperson liegen.

Dokumentieren Sie daher pro Abhängigkeit einen Eigentümer, die benötigte Vorleistung, den spätesten Entscheidungspunkt und eine mögliche Ausweichlösung. Diese Angaben gehören in die laufende Programmsteuerung.

Entkopplung bedeutet nicht, jedes Projekt eigenständig zu optimieren. Gemeinsame Standards und gezielte Kopplungen bleiben notwendig. Entscheidend ist, dass sie bewusst gewählt statt unbemerkt zum Hindernis werden.

Wie kartieren Sie Ihre Systemlandschaft in 14 Tagen ohne Spezialsoftware?

Kartieren Sie Ihre Systemlandschaft mit einer einfachen Matrix aus Geschäftsprozessen und verwendeten Anwendungen. Interviews mit Fachbereichen, eine Erfassung der Datenflüsse und eine gemeinsame Validierung reichen für eine erste Entscheidungsgrundlage häufig aus. Ein Zeitraum von 14 Arbeitstagen ist dafür ein möglicher Planungsrahmen, sofern Umfang und Komplexität überschaubar bleiben.

Das Ziel ist keine technisch vollständige Architekturaufnahme. Die Karte soll zeigen, welche Systeme für welche Prozesse erforderlich sind, wer sie verantwortet und welche Abhängigkeiten spätere Digitalprojekte beeinflussen.

Ein kleines Team aus Programmleitung, IT und Fachvertretungen kann die Erhebung koordinieren. Legen Sie Prozesse als Zeilen und Anwendungen als Spalten an. Markieren Sie, welche Systeme einen Prozess unterstützen und wo Informationen zwischen ihnen übertragen werden.

Erfassen Sie neben den offiziellen Anwendungen auch Excel-Listen, manuelle Dateiübertragungen und E-Mail-Freigaben. Gerade solche Lösungen ausserhalb der zentralen Systeme bleiben in klassischen IT-Inventaren leicht unsichtbar. Bei einer neuen Einführung können sie jedoch entscheidende Prozessschritte enthalten.

Zu jedem System gehören mindestens die fachlich verantwortliche Person, die wesentlichen Nutzergruppen, die ungefähre Zahl aktiver Anwender und die relevanten Datenflüsse. Technische Details sollten nur so weit aufgenommen werden, wie sie für konkrete Projektentscheidungen notwendig sind.

Für einen überschaubaren Unternehmensbereich kann die Erhebung in zwei Phasen organisiert werden: In den ersten sieben Arbeitstagen sammeln Sie Informationen aus Kurzinterviews und bestehenden Unterlagen. In den folgenden sieben Arbeitstagen konsolidieren Sie die Ergebnisse, prüfen Widersprüche und validieren die wichtigsten Abhängigkeiten mit den Fachverantwortlichen.

Diese Vorgehensweise ist eine pragmatische Arbeitsmethode, keine allgemein nachgewiesene 14-Tage-Garantie. Bei zahlreichen Tochtergesellschaften, komplexen Integrationen oder schlecht dokumentierten Altsystemen braucht die Erhebung möglicherweise mehr Zeit oder zusätzliche technische Analysen.

Der Nutzen entsteht erst, wenn die Karte bei Projektentscheidungen weiterverwendet und bei relevanten Änderungen aktualisiert wird. Als einmalige Dokumentation ohne operative Verwendung verliert sie rasch ihren Wert.

Wie erstellen Sie einen Change-Plan mit 5 Zielgruppen, ohne Agentur?

Erstellen Sie einen Change-Plan, indem Sie fünf betroffene Zielgruppen unterscheiden und für jede Gruppe die konkreten Veränderungen, benötigten Fähigkeiten und Unterstützungsangebote festlegen. Ein gemeinsames Tabellenblatt mit Botschaft, Kommunikationskanal, Frequenz, verantwortlicher Person und Rückkanal genügt als Ausgangspunkt. Entscheidend ist die kontinuierliche Umsetzung durch die Linienführung.

Für ein Unternehmen mit rund 200 Mitarbeitenden bietet sich eine überschaubare Zielgruppenstruktur an. Dabei sollte nicht jede Person dieselben allgemeinen Aussagen über Digitalisierung erhalten. Vielmehr braucht jede Gruppe Antworten auf drei Fragen: Was ändert sich für mich? Was muss ich wann können? Wer unterstützt mich?

Ein möglicher Change-Plan kann so aussehen:

Die genannten Frequenzen sind Gestaltungsvorschläge. Sie müssen zur tatsächlichen Veränderungsgeschwindigkeit passen. Eine kleine Anpassung benötigt weniger Begleitung als ein neuer Kernprozess, der die tägliche Arbeit mehrerer Abteilungen verändert.

Die Linienführung ist der entscheidende Übersetzer zwischen Programm und Arbeitsalltag. Sie kann Aufgaben neu verteilen, Schulungszeit ermöglichen und darauf achten, dass alte Prozesse nicht dauerhaft parallel weiterlaufen.

Ebenso wichtig ist ein funktionierender Rückkanal. Erfassen Sie nicht nur, wie viele Mitarbeitende eine Mitteilung erhalten haben, sondern welche Fragen offenbleiben und welche konkreten Hindernisse wiederholt auftreten. Ordnen Sie jedem relevanten Einwand eine zuständige Person und einen nächsten Bearbeitungsschritt zu.

Ein Change-Plan ohne Verantwortliche wird schnell zur Kommunikationssammlung. Ein Plan ohne Rückmeldungen wird zur Einwegkommunikation. Beides verhindert, dass die Programmleitung früh erkennt, warum die Einführung im Alltag ins Stocken gerät.

Die Tabelle ist dabei nur das Steuerungsinstrument. Ihre Wirksamkeit zeigt sich in den Teamgesprächen, den bearbeiteten Rückmeldungen und den tatsächlich veränderten Arbeitsabläufen.

Wie gestalten Sie Change-Management-Prozesse, wenn 30% der Mitarbeitenden skeptisch sind?

Wenn 30 Prozent der Mitarbeitenden einer digitalen Veränderung skeptisch gegenüberstehen, sollten Sie die Ursachen der Skepsis systematisch unterscheiden, statt pauschal mehr Überzeugungsarbeit zu leisten. Berechtigte fachliche Kritik, Veränderungsmüdigkeit und Unsicherheit über neue Anforderungen brauchen unterschiedliche Antworten. Ziel ist eine konstruktive Beteiligung am Veränderungsprozess, nicht die Zustimmung aller.

Bei einem hypothetischen Unternehmen mit 200 Mitarbeitenden entsprechen 30 Prozent genau 60 Personen. Dieser Wert dient hier als Planungsszenario und ist keine statistisch belegte Skepsisquote für Schweizer Unternehmen.

Eine historisch referenzierte Schweizer Untersuchung nennt geringe Veränderungsbereitschaft als wahrgenommene Transformationsbarriere. Solche Ergebnisse dürfen jedoch nicht mit dem Anteil skeptischer Beschäftigter gleichgesetzt werden.

Für die operative Arbeit hilft eine Unterscheidung in drei Gruppen von Einwänden:

• Berechtigte Lösungskritik: Mitarbeitende erkennen fachliche Probleme, unvollständige Daten oder unnötige Arbeitsschritte. Hier braucht es fachliche Prüfung und gegebenenfalls eine Anpassung der Lösung.
• Veränderungsmüdigkeit: Frühere Initiativen haben zusätzliche Arbeit verursacht, ohne den angekündigten Nutzen zu liefern. Hier helfen verlässliche Umsetzung, realistische Zusagen und sichtbare Verbesserungen.
• Unsicherheit über Kompetenzen: Mitarbeitende befürchten, neue Anforderungen nicht zu beherrschen oder bisheriges Fachwissen zu verlieren. Hier sind praktische Schulungen, erreichbare Unterstützung und ausreichend Lernzeit erforderlich.

Die drei Ursachen können gleichzeitig auftreten. Wer Kritik sofort als Widerstand einstuft, übersieht möglicherweise Hinweise auf tatsächliche Mängel. Fachlich begründete Einwände können für die Programmleitung besonders wertvoll sein.

Für die Linienführung empfiehlt sich ein kurzer, wiederkehrender Austausch in bestehenden Teammeetings. Fragen Sie konkret, welche Arbeitsschritte seit der Einführung schwieriger geworden sind, wo alte Hilfsmittel weiter benötigt werden und welche Unterstützung fehlt.

Dokumentieren Sie wesentliche Einwände, treffen Sie nachvollziehbare Entscheidungen und melden Sie deren Bearbeitungsstand zurück. Nicht jede Forderung muss umgesetzt werden. Entscheidend ist, dass Mitarbeitende erkennen können, wie mit ihren Rückmeldungen umgegangen wird.

Verfolgen Sie parallel die tatsächliche Nutzung: Werden Vorgänge vollständig im neuen System abgewickelt? Entstehen zusätzliche Excel-Listen? Werden Daten doppelt gepflegt? Solche Signale können auf ungelöste Prozessprobleme oder mangelnde Akzeptanz hinweisen, ohne deren Ursache bereits eindeutig zu beweisen.

Der realistische Zielzustand ist keine vollständige Begeisterung. Mitarbeitende dürfen kritisch bleiben, solange sie ihre Fragen offen einbringen, die vereinbarten Arbeitsprozesse mittragen und auf notwendige Unterstützung zugreifen können.

Beginnen Sie den Neustart Ihres Transformationsprogramms mit einer gemeinsamen Sitzung von Geschäftsleitung, Programmleitung und Linienverantwortlichen. Prüfen Sie Kapazitäten, priorisieren Sie die nächsten Ergebnisse und legen Sie wenige messbare Prozessziele fest. Anschliessend vereinbaren Sie, wie Rückmeldungen der Mitarbeitenden in die laufenden Entscheidungen einfliessen. So wird digitale Transformation wieder als steuerbares Veränderungsprogramm geführt – und nicht als Sammlung bereits eingekaufter Werkzeuge.