Strukturelle versus technische Ursachen für das Scheitern der digitalen Transformation

Dr. Darren W. Pulsipher
Reihe: Warum digitale Transformation scheitert – und warum O-DXA existiert

Die digitale Transformation steht seit mehr als zwei Jahrzehnten auf den Agenden der Führungsetagen.
In dieser Zeit haben Organisationen verschiedene Generationen von Technologien durchlaufen: On-Premise-ERP, serviceorientierte Architekturen, Cloud-Plattformen, Automatisierung, Analytik, KI.

Mit jeder Welle werden die Werkzeuge besser.
Trotzdem sehen die Ergebnisse der Transformation seltsam vertraut aus.

• Projekte gehen live.
• Pilotprojekte haben Erfolg.
• Dashboards leuchten auf.

Und dann – drei bis fünf Jahre später – stellt die Organisation fest, dass sie eine neue „Transformations“-Initiative ins Leben ruft, um viele der gleichen Probleme anzugehen, die die letzte Initiative hätte lösen sollen.

Dies ist keine isolierte Geschichte.
Es ist ein Muster.

Vorlesung 1 in dieser Reihe hat dieses Muster als anhaltend und systemisch beschrieben: Scheitern, das über Sektoren, Technologien und Führungswechsel hinweg wiederkehrt.
In diesem Abschnitt gehen wir einen Schritt weiter:
Wir untersuchen, warum technologiezentrierte Erklärungen nicht ausreichen und warum die primären Ursachen für das Scheitern strukturell und architektonisch sind, nicht technisch.

Unser Ziel ist es, strukturelle Ursachen von technischen Symptomen zu unterscheiden und aufzuzeigen, wie Fehlanpassungen zwischen Strategie, Ausführung und Governance die Ergebnisse der digitalen Transformation festhalten – egal, welche Werkzeuge Sie kaufen.

Wenn bessere Werkzeuge das Muster nicht beheben

Wenn Transformationsbemühungen ins Stocken geraten, klingt die Nachbesprechung oft vertraut:

• „Wir haben die falsche Plattform gewählt.“
• „Der Anbieter hat nicht geliefert.“
• „Die Methodik passte nicht zu unserer Kultur.“
• „Das Team hatte nicht die richtigen Fähigkeiten.“

Das sind keine fiktiven Beschwerden.
Sie beschreiben reale Probleme, die ein Projekt gefährden können.

Das Problem ist nicht, dass diese Erklärungen falsch sind.
Das Problem ist, dass sie allein genommen zu klein sind, um das Muster zu erklären.

Betrachten wir, wie Misserfolge bei der digitalen Transformation sich wiederholen:

• Über verschiedene Technologiegenerationen hinweg
  (monolithisches ERP zu SOA zu Microservices zu Cloud zu KI).
• Mit verschiedenen Anbietern und Partnern
  (Anbieterwechsel, Beratungsunternehmen oder Plattformen in jeder neuen Welle).
• Unter verschiedenen Führungsteams
  (CIOs, Chief Digital Officers oder Programm-Sponsoren kommen und gehen).

Wenn die ursächliche Quelle „die falsche Plattform“ oder „der falsche Partner“ wäre,
würde man erwarten, dass die Ergebnisse anders aussehen, sobald diese Entscheidungen korrigiert wurden.
Stattdessen erleben Organisationen oft:

• Die gleichen Verzögerungen bei der Entscheidungsfindung.
• Die gleichen Schwierigkeiten, über Pilotprojekte hinaus zu skalieren.
• Den gleichen Spannungsbogen zwischen lokaler Optimierung und Unternehmensausgaben.

Anders ausgedrückt:
Das beobachtbare Muster ist nicht an einen Anbieter und nicht an ein Werkzeug gebunden.

Technische Erklärungen – Konfigurationsfehler, unreife Werkzeuge, schlechte Testabdeckung, schwache DevOps-Praktiken – sind real.
Sie können ein einzelnes Projekt zum Scheitern bringen.

Aber sie können nicht für sich allein erklären, warum materiell ähnliche Misserfolge über mehrere Generationen von Technologien hinweg, in mehreren Organisationen, über Jahrzehnte auftreten.

Wenn unterschiedliche Werkzeuge die gleichen strukturellen Ergebnisse erzeugen, muss die Struktur untersucht werden.

Warum technische Nachbesprechungen den Punkt immer wieder verfehlen

Technische Nachbesprechungen sind attraktiv, weil sie konkret wirken:

• Man kann auf ein falsch konfiguriertes System zeigen.
• Man kann einen Ausfall auf eine bestimmte Designentscheidung zurückverfolgen.
• Man kann Überschreitungen auf unterschätzte Komplexität zurückführen.

Diese Erzählungen sind wichtig für das Lernen und die Verbesserung.
Aber sie haben zwei eingebaute blinde Flecken.

1. Sie konzentrieren sich auf lokale Bedingungen

Technische Analysen fokussieren auf die lokale Umgebung eines Projekts oder Systems:

• Der spezifische Stack, die Infrastruktur oder Architektur.
• Das spezifische Team und seine Praktiken.
• Der spezifische Lieferlebenszyklus und die Einschränkungen.

Selten wird gefragt:
Was im umgebenden System machte dieses Ergebnis wahrscheinlich?

Zum Beispiel:

• Warum lagen die Entscheidungsrechte dort, wo sie lagen?
• Warum waren die Genehmigungen zur Finanzierung so strukturiert, wie sie waren?
• Warum verstärkten Governance-Foren siloartiges Verhalten anstelle von bereichsübergreifenden Ergebnissen?

Ohne diese Fragen wird jeder Misserfolg als lokalisierte Anomalie betrachtet,
anstatt als Beweis für ein gemeinsames strukturelles Muster.

2. Sie setzen mit jeder neuen Technologiewelle zurück

Technische Nachbesprechungen sind oft „versionsgebunden“ an einen bestimmten Stack:

• „Wir haben gelernt, Monolithen nicht so zu entwerfen.“
• „Wir werden diesen Fehler bei unserer nächsten Cloud-Migration nicht wieder machen.“
• „Unser nächstes KI-Projekt wird von Anfang an MLOps beinhalten.“

Aber dann schlägt eine neue Welle zu.
Neue Muster, neue Schlagworte, neue Einschränkungen.

Die Organisation „setzt“ ihr Lernen um den neuen Stack zurück,
während viele der gleichen strukturellen Einschränkungen fortbestehen:

• Die gleiche fragmentierte Governance.
• Die gleichen siloartigen Finanzierungsmodelle.
• Die gleichen fehlenden Anreize.

Die Technologie ändert sich.
Die Struktur nicht.
Und so bleibt das Ergebnis — auf Unternehmensebene — dasselbe.

Was „Struktur“ in der digitalen Transformation wirklich bedeutet

Um strukturelle Ursachen für Misserfolge zu verstehen,
müssen wir genau definieren, was Struktur in diesem Kontext bedeutet.

Struktur ist kein Metapher.
Es ist die Gesamtheit der dauerhaften Vereinbarungen, die prägen, wie Arbeit tatsächlich erledigt wird.

Mindestens umfasst diese Struktur:

• Entscheidungsrechte
  Wer kann was, auf welcher Ebene und in welchem Zeitrahmen entscheiden? Zum Beispiel:

  • Kann ein bereichsübergreifendes Team einen kritischen Prozess ändern, oder muss es an ein Lenkungskomitee weiter eskalieren?
  • Wer besitzt Entscheidungen, die mehrere Geschäftseinheiten betreffen?

• Finanzierungsmodelle
  Wie werden Investitionen vorgeschlagen, genehmigt und erneuert?
  Folgen Budgets:

  • Projekten, Abteilungen, Plattformen oder Wertströmen?
  • Unterstützen sie kontinuierliche Anpassungen oder nur große, episodische Programme?

• Governance-Foren
  Wo werden ressortübergreifende Fragen geklärt?

  • Gibt es Mechanismen, um lokale Autonomie mit unternehmerischer Kohärenz in Einklang zu bringen?
  • Integrieren Risiko- und Compliance-Gremien mit der digitalen Lieferung oder existieren sie als serielle Tore?

• Wert- und Arbeitsflüsse
  Wie bewegt sich die Arbeit über Grenzen hinweg?

  • Sind Prozesse um Kundenreisen und missionale Ergebnisse herum gestaltet oder um Organigramme?
  • Wo erzeugen Übergaben Reibung oder Fehlerquellen?

Diese Elemente der Struktur wirken sowohl oberhalb als auch um jeden bestimmten Technologie-Stack.
Sie prägen:

• Welche Projekte finanziert werden.
• Welche Abwägungen akzeptabel sind.
• Wie schnell strategische Absichten in umsetzbare Entscheidungen übergehen können.

Wenn wir sagen, dass das Scheitern von Transformation strukturell ist, meinen wir:

Die Anordnungen der Entscheidungsrechte, der Finanzierung, der Governance und der Wertflüsse ziehen die Ausführung systematisch von der erklärten Strategie ab – selbst wenn einzelne Projekte technisch erfolgreich sind.

Strukturelle Fehlanpassung: Strategie, Ausführung, Governance

Eine Möglichkeit, strukturelle Ursachen klarer zu erkennen, besteht darin, zu beobachten, wie
Strategie, Ausführung und Governance auseinanderdriften.

• Strategie – die Absichtserklärungen und Richtungen:

  • „Wir werden eine datengestützte Organisation sein.“
  • „Wir werden nahtlose End-to-End-Digitaldienste anbieten.“
  • „Wir werden die Teams, die nah am Auftrag arbeiten, ermächtigen.“

• Ausführung – die tatsächliche Arbeit:

  • Programme, Projekte und Produkte.
  • Prozesse und Workflows im Alltag.
  • Wie Teams besetzt und gemessen werden.

• Governance – die Regeln und Aufsichtsmechanismen:

  • Risiko- und Compliance-Politiken.
  • Budgetierungs- und Portfolioprozesse.
  • Standards und Genehmigungsgates.

Wenn Transformationsbemühungen ins Stocken geraten, sieht man oft Muster wie:

• Die Strategie verspricht bereichsübergreifende, benutzerzentrierte Dienstleistungen.
  Die Ausführung ist immer noch um Abteilungsprojekte organisiert.
  Die Governance prüft Vorschläge Abteilung für Abteilung.

• Die Strategie fordert ermächtigte, agile Teams.
  Die Ausführungsteams übernehmen agile Terminologie.
  Die Governance erfordert weiterhin mehrmonatige Genehmigungszyklen für grundlegende Änderungen.

• Die Strategie betont datengestützte Entscheidungen.
  Die Ausführungsteams erstellen Analytik-Dashboards.
  Die Governance-Prozesse verlassen sich weiterhin auf statische Berichte und manuelle Genehmigungen.

In jedem Fall:

• Die Technologie kann modern sein.
• Die Lieferpraktiken können aktuell sein.

Aber die strukturelle Beziehung zwischen Strategie, Ausführung und Governance ist fehlangepasst.
Und diese Fehlanpassung ist es, was letztendlich eine nachhaltige Transformation blockiert.

Wenn Strukturen fehlangepasst sind:

• Können Ausführungsteams effizient und fähig sein – während sie auf die falschen Dinge optimieren.
• Können Governance-Foren gewissenhaft sein – während sie Silos verstärken und systemische Veränderungen verlangsamen.
• Können Strategiedokumente überzeugend sein – während sie wenig Einfluss auf das tägliche Verhalten haben.

Das Ergebnis ist vertraut:

• Lokale Erfolge.
• Unternehmensstagnation.
• Ein weiteres Transformationsprogramm ein paar Jahre später.

Wie Fehlanpassungen sich mit neuer Technologie verstärken

Hier entsteht eine kontraintuitive Realität:

Wenn strukturelle Fehlanpassungen bestehen, kann bessere Technologie das Problem verschlimmern.

Warum?

Weil moderne Werkzeuge:

• Die Kosten für Experimente senken.
• Die Geschwindigkeit lokaler Entscheidungen erhöhen.
• Es einfacher machen, dass einzelne Teams oder Abteilungen eigenständig voranschreiten.

Wenn die umgebende Struktur nicht ausgerichtet ist:

• Bewegen sich Teams schnell in verschiedene Richtungen.
• Vermehren sich lokale Optimierungen.
• Nehmen Integrations- und Governance-Herausforderungen zu.

Anstelle einer synchronisierten Transformation erhalten Sie:

• Mehrere „strategische Plattformen“ mit überschneidenden Fähigkeiten.
• Inkonsistente Implementierungen ähnlicher Richtlinien (z.B. Sicherheit, Datenschutz).
• Parallele Lösungen für dasselbe Problem, von denen keine unternehmensweit skaliert.

Die Technologie ist nicht „schlecht“.
Sie verstärkt einfach die Struktur, die sie vorfindet.

Wenn Entscheidungsrechte, Finanzierungsmodelle und Governance-Mechanismen fragmentiert sind,
werden moderne digitale Werkzeuge die Fragmentierung beschleunigen.

Architektur als strukturelle Disziplin, nicht als Dokumentation

Hier kommt Architektur ins Spiel – nicht als eine Sammlung von Diagrammen,
sondern als strukturelle Disziplin.

In vielen Organisationen wird Architektur als:

• Das Team, das Referenzmodelle und Standardspeicher pflegt.
• Die Gruppe, die an Entwurfsprüfungen teilnimmt und spät im Prozess „nein“ sagt.
• Eine Dokumentationsfunktion betrachtet, die im Rückstand zu realen Veränderungen ist.

In einem strukturellen Rahmen ist das nicht genug.

Architektur, strukturell verstanden, geht darum:

• Strategische Absichten in operationale Einschränkungen und Muster einzuordnen,
  sodass lokale Entscheidungen zu unternehmensweiten Ergebnissen führen.

• Entscheidungspfade zu gestalten,
  sodass, wenn eine neue Initiative erscheint, sie durch konsistente Prinzipien fließt und nicht durch ad hoc Verhandlungen.

• Strategie, Ausführung und Governance zu überbrücken, indem man:

  • Informiert, wie Portfolios strukturiert werden.
  • Beeinflusst, wie Finanzierungsmodelle Kohärenz verstärken.
  • Geteilte Prinzipien bereitstellt, die Governance-Gremien anwenden können.

Anders ausgedrückt: Architektur ist nicht primär das Artefakt; sie ist das steuernde System, das
Menschen, Prozesse, Richtlinien und Technologie im Laufe der Zeit in Einklang bringt.

Ohne diese architektonische Schicht, die als strukturelle Disziplin fungiert:

• Wird Transformation als eine Sequenz von voneinander losgelösten Projekten ausgeführt.
• Muss jedes Projekt seine eigene Ausrichtung aushandeln.
• Fehlen Governance-Gremien ein gemeinsames Rahmenwerk, um bereichsübergreifende Entscheidungen zu treffen.

Die Ergebnisse sehen aus wie „technisches Scheitern“, aber das tiefere Problem ist:

• Es existiert kein struktureller Mechanismus, um die Ausführung an die Strategie zu binden, wenn sich die Bedingungen ändern.

Warum strukturelle Probleme als technische Probleme zu behandeln, scheitert

Wenn Organisationen strukturelle Probleme fälschlicherweise als technische Probleme diagnostizieren,
tendenzieren sie dazu, in vorhersehbaren Weisen zu reagieren:

• Eine große Neugestaltung der Plattform starten, um langsame Lieferung zu „beheben“.
• Ein Anbietersystem gegen ein anderes austauschen, um die Landschaft zu „vereinfachen“.
• Eine neue Methodik oder ein neues Betriebsmodell als das Wundermittel einführen.

Diese Reaktionen können in begrenztem Sinne wertvoll sein.
Sie können bestimmte Aspekte der Umgebung verbessern.

Aber wenn die zugrunde liegenden Strukturen der Entscheidungsrechte, der Finanzierung und der Governance unverändert bleiben:

• Erbt die neue Plattform die gleichen Genehmigungsengpässe und fehlangepassten Anreize.
• Begegnet der neue Anbieter den gleichen bereichsübergreifenden Konflikten wie der vorherige.
• Wird die neue Methodik an alte Governance- und Budgetierungsrhythmen angepasst.

Die Organisation investiert erheblich in Veränderungen – und entdeckt dann, dass ihre Trajektorie weitgehend dieselbe ist.

Zwei spezifische Kosten der Fehldiagnose stechen hervor:

1. Kumulative Komplexität
   Jeder Zyklus fügt hinzu:

   • Neue Plattformen und Integrationen.
   • Zusätzliche Governance-Prozesse.
   • Mehr überschneidende Fähigkeiten.
     Die Komplexität wächst.
     Die strukturelle Ausrichtung nicht.

2. Reduzierte Fähigkeit zu echten strukturellen Veränderungen
   Nach ein paar Zyklen werden Stakeholder skeptisch:

   • „Wir haben bereits drei Transformationsprogramme gemacht.“
   • „Wir haben Agile / Cloud / Analytik ausprobiert; es hat das Problem nicht behoben.“
     Der Appetit auf tiefere strukturelle Veränderungen sinkt,
     selbst wenn der Bedarf an ihnen steigt.

Auf dem Weg zu einer integrierten architektonischen Antwort (Vorschau)

Diese Vorlesung und ihr Blog-Gegenstück haben absichtlich fokussiert auf:

• Die anhaltenden Misserfolge als systemische Ursachen über einzelne Werkzeuge und Projekte hinaus zu zeigen.
• Darauf hinzuweisen, dass die strukturelle Fehlanpassung zwischen Strategie, Ausführung und Governance eine der primären Ursachen für diese Misserfolge ist.
• Architektur als strukturelle Disziplin zu repositionieren, die in der Lage ist, diese Fehlanpassung anzugehen – nicht als nachträgliche Dokumentationsübung.

Wir haben noch kein spezifisches Lösungsframework oder Betriebsmodell beschrieben.
Das folgt später in der Reihe.

Bevor wir einen bestimmten Ansatz einführen, müssen wir ein klares, gemeinsames Verständnis davon haben:

• Wie Fehlanpassungen über Menschen, Prozesse, Richtlinien und Technologie sichtbar werden.
• Wie Governance-Fragmentierung und Entscheidungsrechte Muster vorhersagbare Fehlerquellen schaffen.
• Was es bedeuten würde, wenn Architektur als echtes steuerndes System fungieren könnte.

Der nächste Abschnitt wird tiefer in diese strukturellen Muster eintauchen:
Er wird aufzeigen, wie wiederkehrende Misserfolge aus der aktuellen Architektur von Organisationen hervorgehen
und welche Art von integriertem architektonischen Modell erforderlich ist, um die digitale Transformation über Zeit hinweg auszurichten.

Für den Moment ist die zentrale Erkenntnis einfach:

Wenn wiederkehrende Transformationsfehler unabhängig von Werkzeugen, Anbietern und Technologiewellen gleich aussehen, ist das Problem nicht primär technischer Natur.
Es ist strukturell – und Architektur, die als strukturelle Disziplin behandelt wird, ist der Bereich, in dem die Arbeit beginnen muss.