Artikel
Warum die Meisten Digitalen Transformationen Scheitern
Und wie das dreistufige Transformationsmodell das Ergebnis verändert
Dieser Artikel ist Teil der XPRT. Magazin Nr. 21
Vor einigen Jahren arbeitete ich mit einem mittelständischen Versicherungsunternehmen in Deutschland zusammen. Dessen CTO war scharfsinnig, engagiert und verfügte über ein Budget. Sie setzten das gesamte Spielbuch um: SAFe-Einführung, Cloud-Migration zu Azure, ein brandneues DevOps-Team, sogar ein „Transformation Office“ mit wöchentlichen Lenkungsausschusssitzungen.
Nach achtzehn Monaten nahm ich an einer Besprechung zur Release-Planung teil, bei der ein Team vier separate Freigaben benötigte, um eine Änderung an einer PDF-Vorlage zu implementieren. Vier. Für ein PDF.
Die Umstrukturierung war nicht spektakulär gescheitert. Niemand wurde entlassen, kein Projekt wurde gestrichen. Sie war einfach … ins Stocken geraten. Die Teams waren erschöpft. Der Rückstau an „Quick Wins“ wuchs immer weiter an. Die Mitarbeiter glaubten nicht mehr daran, dass die nächste Initiative anders verlaufen würde.
Dies ist das Muster, das sich in Organisationen überall abzeichnet. Nicht, weil sich die Menschen gegen Veränderungen wehren, und auch nicht, weil es den Führungskräften an Ehrgeiz mangelt – sondern weil bei den meisten Transformationsprozessen versucht wird, das Offensichtliche zu beheben, während strukturelle Probleme außer Acht gelassen werden.
Der grundlegende Fehler: Das falsche Problem lösen
Wenn die Leistung nachlässt, reagieren Führungskräfte vorhersehbar:
- Langsame Bereitstellung → Verbesserung der technischen Arbeitsabläufe
- Steigendes Risiko → zusätzliche Kontrollmaßnahmen und Genehmigungen einführen
- Innovationsrückstand → Einrichtung eines Innovationslabors
- Resistenz → Durchführung eines Kulturprogramms
Jede Reaktion ist für sich genommen rational. Zusammen bilden sie jedoch ein System, das aktiv gegen sich selbst wirkt.
Die Umsetzung war nicht das Problem. Es handelte sich um kluge Menschen, die hart arbeiteten. Das Problem bestand darin, dass die Organisationsstruktur all ihren Bemühungen im Wege stand.
Vorstellung des dreistufigen Transformationsmodells
Das dreistufige Transformationsmodell erläutert, wie sich Wert in modernen Organisationen tatsächlich bewegt – und welche Faktoren sich gemeinsam weiterentwickeln müssen, damit die Transformation gelingen kann.
Die drei Ebenen
Diese Ebenen sind voneinander abhängig. Die Verbesserung einer Ebene bei gleichzeitiger Vernachlässigung der anderen führt zu Hemmnissen, Frustration und letztendlich zu Rückschritten.
Ebene 1: Ablauf – Hier entscheidet sich über Erfolg oder Misserfolg
Die Flow-Ebene ist das operative Herzstück des Unternehmens. Sie umfasst alles, was erforderlich ist, um Wert von der Idee bis zum Kunden zu transportieren:
- Entdeckung → Umsetzung → Rückmeldung
- Bereitstellungspipelines
- Reaktion auf Vorfälle und Wiederherstellung
- Automatisierung und Beobachtbarkeit
- Verantwortung und Lernkreisläufe
So sieht ein gesunder Fluss aus
- Kurze Vorlaufzeiten von der Entscheidung bis zur Wertschöpfung
- Häufige Veröffentlichungen mit geringem Risiko
- Schnelle Wiederherstellung nach einem Ausfall
- Klare Zuständigkeiten in unmittelbarer Nähe zum Arbeitsprozess
- Kontinuierliche Verbesserung
Wenn der „Flow“ unterbrochen wird, spüren dies die Kunden sofort.
Ebene 2: Befähigung – Den richtigen Weg zum einfachen Weg machen
Die meisten Kontrollinstanzen glauben, ihre Aufgabe bestehe darin, „Nein“ zu sagen. „Enablement“ kehrt dies um: Man richtet die Leitplanken einmal ein, damit die Teams tausendmal „Ja“ sagen können, ohne nachfragen zu müssen.
Diese Ebene stellt die gemeinsamen Systeme bereit, die es den Teams ermöglichen, zügig voranzukommen, ohne dabei Abstriche bei der Sicherheit zu machen:
- Plattformentwicklung
- Self-Service-Infrastruktur
- Compliance-as-Code
- Sicherheitsautomatisierung
- Referenzarchitekturen
- Standardisierte Muster
Hier ist ein Test: Kann ein Entwickler noch vor der Mittagspause eine konforme Produktionsumgebung einrichten? Wenn die Antwort mit Tickets, Besprechungen oder dem Warten auf „das Infrastrukturteam“ zu tun hat, haben Sie ein Problem mit der Unterstützung.
Ohne eine gute Unterstützung werden Teams entweder langsamer oder umgehen das System (in der Regel durch Schatten-IT, die Ihrem Sicherheitsteam Alpträume bereitet).
Ebene 3: Führung – Die unsichtbare Einschränkung
Das ist die unangenehme Frage.
Ich habe erlebt, wie hervorragende Plattformteams eine Self-Service-Infrastruktur aufgebaut haben, die niemand nutzt – weil die Führungskräfte nach wie vor verlangen, jede Bereitstellung zu prüfen. Ich habe CI/CD-Pipelines gesehen, die innerhalb von Minuten bereitgestellt werden könnten, auf die jedoch dreitägige Sitzungen des „Change Advisory Board“ folgten.
Die Führung schafft die Rahmenbedingungen. Wenn Führungskräfte Sicherheit gegenüber dem Lernen bevorzugen, wenn sie eher fragen: „Wer hat das genehmigt?“, als: „Was haben wir daraus gelernt?“ – dann passen sich die Teams an. Sie suchen nach Erlaubnis statt nach Eigenverantwortung. Plattformen werden zu Genehmigungsinstanzen. Innovation verwandelt sich in eine Show.
Ich bezeichne dies als „aufgelaufene Führungsschuld“, die für die Führungskräfte, die sie verursachen, oft nicht erkennbar ist.
Gesunde Führungsqualitäten
- Die Tendenz, lieber zu handeln als um Erlaubnis zu bitten
- Psychologische Sicherheit
- Transparenz in Bezug auf Risiken
- Führungskräfte beseitigen Hindernisse, anstatt den Status zu verfolgen
- Anreize belohnen das Lernen und die erzielten Ergebnisse
Die meisten ins Stocken geratenen Veränderungsprozesse scheitern an dieser Stelle – selbst wenn die Führungskräfte die besten Absichten haben.
Warum die meisten Transformationsprozesse ins Stocken geraten
Häufiges Fehlermuster:
- Maßnahmen zur Prozessoptimierung stehen im Widerspruch zur Unternehmensführung
- Die Voraussetzungen sind gegeben, doch die Führungskräfte vertrauen ihnen nicht
- Autonomie wird versprochen, aber bestraft
Teams werden nicht langsamer, weil sie faul oder inkompetent sind – sie werden langsamer, weil schnelles Handeln beruflich gefährlich geworden ist.
Bewertung: Analyse Ihrer Organisation
Eine einfache Bewertung zeigt auf, wo der Wandel blockiert wird. Bewerten Sie jede Aussage auf einer Skala von 1 bis 5.
Durchflussbewertung
- Die Teams werden innerhalb eines Tages nach Fertigstellung eingesetzt
- Störungen werden innerhalb von Stunden und nicht erst nach Tagen behoben
- Die Verantwortung erstreckt sich über den gesamten Prozess
Bewertung der Umsetzungsvoraussetzungen
- Umgebungen werden im Self-Service bereitgestellt
- Sicherheit und Compliance werden automatisiert
- Plattformen verringern die kognitive Belastung
Führungskräftebewertung
- Entscheidungen werden zügig getroffen
- Aus Fehlern lernt man, statt Schuld zuzuweisen
- Die Teams verfügen über echte Entscheidungsbefugnisse
Die Ebene mit der niedrigsten Punktzahl stellt Ihre Einschränkung dar.
Eine Verbesserung anderer Ebenen wird dies nicht ausgleichen.
Visuelle Diagnose: Wo stecken Sie fest?
Die meisten Organisationen stellen fest, dass sie über alle drei verfügen – doch eine davon dominiert.
Warum dies gerade jetzt von Bedeutung ist
Vielleicht denken Sie jetzt: „Das klingt wie jedes andere Transformations-Framework.“ Das ist verständlich. Doch hier sind die Unterschiede.
Unternehmen setzen derzeit KI in allen Bereichen ein. Und KI ist gnadenlos ehrlich, was die Funktionsstörungen in Ihrem Unternehmen angeht. Sie wartet nicht höflich auf Genehmigungen. Wenn Ihre Daten in Silos gespeichert sind, ist Ihre KI nutzlos. Wenn Ihr Bereitstellungsprozess Wochen dauert, veralten Ihre KI-Experimente, bevor sie die Kunden erreichen. Wenn Ihre Teams nicht durchgängig die Verantwortung für die Ergebnisse übernehmen können, automatisiert die KI lediglich die falschen Dinge – und das noch schneller.
Ich habe beobachtet, wie Unternehmen Millionen für ML-Plattformen ausgegeben haben, die Modelle hervorbringen, die niemand einsetzen kann. Der Engpass lag dabei nie im Algorithmus.
Wie man beginnt
Wenn die Führung das Hindernis ist
- Anreize ändern – Belohnen Sie nicht länger Vorhersehbarkeit statt Lernen. Messen Sie Ergebnisse, nicht den Output. Nutzen Sie OKRs, um Autonomie mit der Strategie in Einklang zu bringen.1
- Vorbildliche Verletzlichkeit – Führungskräfte müssen sichtbar scheitern, daraus lernen und ihre Erfahrungen weitergeben. Dies vermittelt mehr psychologische Sicherheit als jede Richtlinie.2
- Schützen Sie frühe Experimente – stellen Sie Zeit und Budget gezielt zur Verfügung. Schaffen Sie ausdrücklich die Sicherheit, Dinge auszuprobieren, die möglicherweise nicht funktionieren.
- Zeitrahmen: Rechnen Sie mit 6 bis 12 Monaten, bis sich kulturelle Veränderungen bemerkbar machen. Dies ist der Bereich, in dem Veränderungen am langsamsten voranschreiten.
Wenn die Befähigung die Einschränkung darstellt
- Finanzieren Sie Plattformteams – Behandeln Sie interne Plattformen als Produkte mit eigenen Teams und nicht als Projekte. Wenden Sie die Prinzipien der „Team Topologies“ an.3
- Automatisieren Sie zunächst die Compliance – „Compliance-as-Code“ beseitigt die Ausrede für manuelle Kontrollpunkte. Sicherheit wird zu einer Funktion und nicht mehr zu einem Hindernis.
- Messen Sie die Produktivität der Entwickler – Nutzen Sie das SPACE-Framework, um zu verstehen, was die Teams tatsächlich ausbremst.4
- Zeitplan: Rechnen Sie mit 3–6 Monaten für die ersten Plattformfunktionen; 12–18 Monate für die vollständige Einführung.
Wenn der Durchfluss die Einschränkung darstellt
- Investieren Sie in CI/CD – automatisieren Sie den Weg in die Produktion. Richten Sie sich an den DORA-Kennzahlen aus: Bereitstellungshäufigkeit, Durchlaufzeit, Fehlerquote bei Änderungen und mittlere Wiederherstellungszeit.5
- Reduzieren Sie die Losgrößen – kleinere Losgrößen bedeuten schnelleres Feedback. Teilen Sie die Arbeit in Abschnitte auf, die unabhängig voneinander ausgeliefert werden können.
- Das Lernen aus Vorfällen verbessern – Schuldfreie Nachbesprechungen stärken die Kompetenz. Jeder Vorfall ist eine Lernerfahrung.
- Zeitplan: Bei gezielten Investitionen ist innerhalb von 1 bis 3 Monaten mit messbaren Verbesserungen zu rechnen.
Warnzeichen dafür, dass Sie die falsche Ebene ausgewählt haben
- Sie verbessern den Durchlauf, doch die Durchlaufzeiten bleiben unverändert → überprüfen Sie die Prozessunterstützung (Genehmigungsstufen)
- Sie entwickeln Plattformen, aber niemand nutzt sie → prüfen Sie die Führung (Vertrauen und Anreize)
- Sie schulen Führungskräfte, aber es ändert sich nichts → prüfen Sie den „Flow“ (das Problem ist noch nicht deutlich genug erkennbar)
Befassen Sie sich stets zuerst mit der bindenden Einschränkung. Die Optimierung von Nicht-Einschränkungen ist Energieverschwendung und kann die Situation sogar verschlimmern.
Verwandte Frameworks
Das dreistufige Modell ergänzt etablierte Ansätze und baut auf diesen auf:
Framework | Zusammenhang mit dem Dreischichtenmodell
DORA-Metriken5 | Flussschicht – misst die Anzeichen einer gesunden Wertschöpfung
Teamtopologien3 | Befähigungsschicht – stromorientierte und plattformbasierte Teammuster
WestrumsOrganisationskultur6 | Führungsschicht – eine generative Kultur ermöglicht Lernen
DevOps/CALMS | Querschnittsthemen – Kultur, Automatisierung, Lean, Messung, Austausch – übergreifende Zuordnungen über alle Ebenen hinweg
Theory ofConstraints7 | Kernprinzip – Identifizieren und Beheben Sie die einschränkende Stelle, bevor Sie an anderer Stelle optimieren
Drei wichtige Erkenntnisse
- Stellen Sie zunächst eine Diagnose, bevor Sie ein Rezept ausstellen. Nutzen Sie die dreistufige Bewertung, um Ihren limitierenden Faktor zu ermitteln. Die Stufe mit der niedrigsten Punktzahl bestimmt Ihre Obergrenze – eine Verbesserung der anderen Stufen kann dies nicht ausgleichen.
- Planen Sie Ihre Investition schrittweise. Führungsdefizite behindern die Befähigung; Lücken in der Befähigung behindern den Arbeitsfluss. Gehen Sie rückwärts vor: von der Stelle, an der das Problem spürbar ist, bis hin zu dessen Ursache.
- Messen Sie das, worauf es ankommt. Verwenden Sie DORA-Kennzahlen zur Erfassung des „Flow“, die Plattformakzeptanz zur Erfassung der „Enablement“ und Kulturumfragen (Westrum-Modell) zur Erfassung der „Leadership“. Was man nicht messen kann, kann man auch nicht verbessern.
Zusammenfassung
Sehen Sie, auch ich habe mich schon dabei ertappt, diese Dinge zu kompliziert zu machen. Hier also die einfache Version:
In Ihrem Unternehmen gibt es drei Aspekte, die miteinander harmonieren müssen: die Art und Weise, wie Sie Mehrwert schaffen (Ablauf), die Systeme, die diese Wertschöpfung sicher und einfach gestalten (Unterstützung), und die Frage, ob Ihre Führungskräfte den Mitarbeitern tatsächlich gestatten, diese Systeme zu nutzen (Führung).
Die meisten Fehlschläge bei Transformationsprozessen sind darauf zurückzuführen, dass jemand eine Ebene optimiert, während eine andere Ebene dem aktiv entgegenwirkt. Finden Sie den eigentlichen Engpass – meist liegt er nicht dort, wo Sie vermuten – und beheben Sie diesen zuerst.
Die Unternehmen, die dies erkennen, liefern nicht nur schneller. Sie werden auch immer besser darin, sich weiter zu verbessern. Und dieser Effekt verstärkt sich.
Über den Autor
Michael Kaufmann ist Geschäftsführer Deutschland bei Xebia, Unternehmensberater und Autor mit den Schwerpunkten digitale Transformation und DevOps. Er ist Autor des Buches „Accelerate DevOps with GitHub“ (Packt, 2022) und unterstützt Unternehmen in ganz Europa dabei, eine Engineering-Kultur aufzubauen, die nachhaltige Geschwindigkeit und Innovation gewährleistet. Michael ist Microsoft Regional Director, Microsoft MVP und regelmäßiger Referent auf internationalen Konferenzen.
Vernetzen Sie sich mit Michael auf LinkedIn oder GitHub: @wulfland
Referenzen
Fußnoten
[1]: Forsgren, N., Humble, J. und Kim, G. (2018). Accelerate: Die Wissenschaft hinter Lean Software und DevOps. IT Revolution Press.
[2]: Doerr, J. (2018). „Measure What Matters: OKRs: Die einfache Idee, die ein 10-faches Wachstum vorantreibt“. Portfolio Penguin.
[3]: Edmondson, A. C. (2018). Die furchtlose Organisation: Psychologische Sicherheit am Arbeitsplatz für Lernen, Innovation und Wachstum schaffen. Wiley.
[4]: Skelton, M., & Pais, M. (2019). Team Topologies: Organisation von Geschäfts- und Technologieteams für einen schnellen Arbeitsfluss. IT Revolution Press.
[5]: Forsgren, N. u. a. (2021). „The SPACE of Developer Productivity.“ ACM Queue, 19(1).
[6]: Westrum, R. (2004). „Eine Typologie der Organisationskulturen.“ BMJ Quality & Safety, 13(Beilage 2), ii22–ii27.
[7]: Goldratt, E. M. (1984). Das Ziel: Ein Prozess der kontinuierlichen Verbesserung. North River Press.
Verfasst von
Contact