Der Moment der Wahrheit in der digitalen Transformation offenbart sich meist sechs Monate nach dem Go-Live. Das System ist eingeführt, das Projektteam aufgelöst und die Dokumentation auf dem SharePoint abgelegt.

Zu diesem Zeitpunkt stellt die Geschäftsleitung (GL) oft fest, dass die avisierte Leistungssteigerung ausbleibt. Die Ursache ist kein technischer Fehler, sondern ein Designfehler der Governance: Das Unternehmen hat Technologie beschafft, aber die dauerhafte fachliche Ergebnisverantwortung für die neue Fähigkeit im organisatorischen Niemandsland hinterlassen.

Der strukturelle Klippensturz

In den meisten Organisationen endet das strategische Mandat am Tag der Einführung. Während Projekte durch Start, Ende und Scope definiert sind, fehlt ihnen die Dimension der Beherrschung. Mit der Auflösung des Projekts entsteht ein Vakuum. Es gibt auf der Empfängerseite keine Instanz, die den Auftrag zur kontinuierlichen Weiterentwicklung der Fähigkeit besitzt.

Die Konsequenz ist ein Rückfall in die alte Silo-Logik, in der jede Seite vollkommen rational agiert:

• Die IT-Sicht: Das System wird zum technischen „Asset“. Es muss stabil und kostengünstig laufen. Jede inhaltliche Weiterentwicklung wird primär als Risiko für die Stabilität und als Kostenfaktor bewertet.
• Die Fachbereichs-Sicht: Die operative Linie betrachtet das System als externe Restriktion. Passt das Tool nicht perfekt zum Alltag, investiert man keine Energie in dessen Verbesserung, sondern baut Schattenprozesse in Excel auf.

Ohne eine Instanz, die über das Projektende hinaus die Hand auf dem Prozess-Design und dem Budget hat, verkümmert die Investition.

Das Muster der Problemverschiebung

Wenn die Stagnation sichtbar wird, greifen GL-Reflexe, die das strukturelle Problem nicht lösen, sondern lediglich Zeit kaufen:

1. Blame-Game: Man kritisiert die IT für mangelnde Qualität oder den Fachbereich für fehlende Akzeptanz.
2. Reparatur-Projekte: Man versucht, das Fehlen einer dauerhaften Verantwortung durch temporäre „Taskforces“ oder eine „Phase 2“ zu heilen. Hier wird versucht, das fehlende organisationale Lernen durch teure Technik-Initiativen zu ersetzen.
3. Die RFP-Flucht: Die GL akzeptiert die Ineffizienz als „technisch bedingt“ und flüchtet in die nächste Ausschreibung. Ein neues Tool soll die internen Organisationsmängel heilen.

Fazit

Priorisierung auf GL-Ebene bleibt eine reine Absichtserklärung, solange keine dauerhafte fachliche Verantwortung in der Linie existiert, die den strategischen Nutzen verteidigt und weiterentwickelt. Wahre Transformation erfordert ein Betriebsmodell, das über Projektlaufzeiten hinausgeht.

Die harte Realität: Die Organisation besitzt heute zwar die Technologie, aber niemand besitzt deren evolutionäre Wirksamkeit.

---

Zusammenhang verstehen Dieser Artikel vertieft den Cluster „priorisierung-macht“ und schliesst den Bogen von der strategischen Absicht zur strukturellen Verankerung. Während wir in Teil 4 etabliert haben, dass Priorisierung eine schmerzhafte Weglass-Entscheidung der Führungsebene erfordert, und in Teil 11 den fundamentalen Wechsel der Steuerungseinheit von Projekten hin zu Fähigkeiten (Capabilities) vollzogen haben, zeigt dieser Beitrag die machtpolitische Konsequenz im Betrieb auf: Ohne ein angepasstes Betriebsmodell (Operating Model) erodiert jede noch so präzise Priorisierungsentscheidung am Tag des Go-Live.

Fokus: Priorisierung & Macht

• Teil 4: Priorisierung, Desinvestition, Weglassen: Die eigentliche Führungsaufgabe
• Teil 11: Vom Projektportfolio zur Fähigkeitsarchitektur
• Teil 12: Das Ownership-Vakuum (Aktuell)