Warum Transformationsprogramme viel Aktivität, aber wenig Veränderung erzeugen

Ein Transformationsprogramm kann auf dem Papier hervorragend beschäftigt aussehen: ein Steering Committee tagt, mehrere Teams liefern Statusfolien, Pilotprojekte laufen und die Ampeln stehen überwiegend auf Grün. Trotzdem bleiben Durchlaufzeiten gleich, Entscheidungen werden weiter eskaliert und die Organisation arbeitet neben den neuen Abläufen noch mit ihren alten Listen und Kontrollen.

Die Ursache liegt selten in zu wenig Projektmanagement. Veränderung entsteht erst, wenn die Geschäftsleitung drei Dinge entscheidet: Welche Arbeit hört verbindlich auf? Welche knappen Ressourcen sind tatsächlich verfügbar? Welches neue Verhalten wird im Betrieb zur Pflicht? Ohne diese Entscheidungen addiert ein Programm Aktivitäten, statt Kapazität und Verantwortung neu zu ordnen.

Das gilt besonders für AI. AI ist keine Toolliste. Sie verändert Arbeit, Daten, Entscheidungen, Evaluation, Zugriffe und Governance sowie die Befähigung der Menschen, die damit arbeiten. Das Portfolio muss deshalb nicht nur nach Projektfortschritt, sondern nach Geschäftswert, Abhängigkeiten und Betriebsfähigkeit geführt werden.

Der BCG Applied AI Index 2026 berichtet eine konkrete Messpraxis: 95 % der als „future-built“ klassifizierten Unternehmen nutzen Geschäfts-KPIs oder messen AI-Wert direkt in der Gewinn- und Verlustrechnung.1 Die Anbieterbefragung umfasst mehr als 1.300 CxOs und Senior Leaders aus über 20 Sektoren. Der Wert betrifft nur die reifste Gruppe, nicht die Gesamtstichprobe; er beweist auch nicht, dass Tracking Wert verursacht. Es ist aber ein sinnvoller Maßstab für die Managementfrage: Wo und wann wollen wir Wert, Qualität und Risiko tatsächlich nachweisen?

Die erste Entscheidung lautet nicht: Welches Projekt startet als Nächstes? Sie lautet: Welche Initiativen stoppen wir, welche Grundlagen schützen wir, was testen wir unter kontrollierten Bedingungen und was darf nach einem Beleg skaliert werden?

Ein Programm erzeugt schnell sichtbare Spuren. Es gibt Roadmaps, Workshops, Backlogs, Abstimmungen mit IT und Fachbereichen. Der CEO erhält eine Projektampel. Diese Informationen sind nicht wertlos. Sie beantworten jedoch vor allem, ob vereinbarte Aktivitäten stattfinden. Sie beantworten nicht, ob eine alte Arbeitsschleife verschwunden ist, ob ein Entscheidungsrecht verlagert wurde oder ob ein neues Vorgehen auch am Monatsende noch gilt.

Der Unterschied wird in konkreten Situationen sichtbar. Ein Vertriebsteam hat einen AI-gestützten Ablauf für die Angebotserstellung eingeführt. Informationen werden aus CRM, Produktdaten und früheren Angeboten zusammengetragen. Dennoch prüfen drei Personen jede Fassung wie bisher, weil weder Qualitätskriterien noch Freigabegrenzen angepasst wurden. Zusätzlich führt der Bereich noch eine alte Excel-Liste, um den Status abzusichern. Die Bearbeitung wird nicht einfach schneller. Sie erhält eine weitere Übergabe, einen neuen Prüfpunkt und zwei konkurrierende Wahrheiten.

Das ist kein Kundenfall, sondern ein illustriertes Beispiel. Es zeigt eine typische Managementfrage: Welcher alte Kontrollschritt entfällt, welcher bleibt und wer entscheidet bei Abweichungen? Solange darauf keine verbindliche Antwort existiert, bleibt AI eine Zusatzschicht auf der bisherigen Arbeitsweise.

Der wirtschaftliche Schaden entsteht nicht nur durch Lizenzkosten. Teams binden dieselben Fachpersonen gleichzeitig an Tagesgeschäft, Datenbereinigung, Piloten und Entscheidungsrunden. Die besten Mitarbeitenden wechseln zwischen dringenden Kundenfällen, Projektterminen und Nacharbeiten aus unklaren Übergaben. Ein Vorhaben ist dann nicht deshalb verspätet, weil ein Team langsam arbeitet, sondern weil die Organisation seine Zeit mehrfach verplant hat.

Zuerst würde ich nicht nach weiteren Ideen fragen. Ich würde diese Entscheidungen im Führungsteam verbindlich klären.

Erstens: Welche Arbeit endet? Jede neue Arbeitsweise braucht Platz. Wenn ein neuer Datenfluss entsteht, muss klar sein, welche Schattenreportings nicht mehr aktualisiert werden. Wenn ein AI-System einen ersten Entwurf erstellt, braucht es eine Entscheidung darüber, wann die frühere vollständige manuelle Erstellung entfällt und wann menschliche Prüfung zwingend bleibt. Ein Programm ohne Arbeitsabbau ist häufig ein Programm mit Mehrarbeit.

Zweitens: Welche Ressourcen sind wirklich reserviert? Ein Owner ohne geschützte Zeit ist eine Rollenbezeichnung, keine Verantwortung. Das Führungsteam muss nicht jede Stunde zentral verteilen. Es muss aber entscheiden, welche Termine Vorrang haben, welche Fachleute für welche Dauer verfügbar sind und welche anderen Vorhaben dafür warten. Ein Workstream, dessen Datenverantwortliche nur zwischen Monatsabschluss und Eskalationen Zeit findet, hat kein belastbares Mandat.

Drittens: Welches Verhalten wird bindend? Das neue Verfahren darf nicht nur als Empfehlung im Intranet stehen. Ein Sales Lead muss wissen, ab wann ein bestimmter Angebotsprozess genutzt wird. Eine Führungskraft muss wissen, wann sie eine AI-Empfehlung prüfen, dokumentieren oder zurückweisen muss. Der Betrieb braucht Eskalationswege und Rückfallabläufe. Genau dort wird aus einem Projekt eine Arbeitsweise.

Diese Entscheidungen haben Zielkonflikte. Ein zu früher Stopp kann eine sinnvolle Fähigkeit beschädigen. Ein zu langer Pilot kann knappe Kapazität blockieren. Eine verbindliche Regel kann in einer Übergangsphase mehr Reibung erzeugen. Die Alternative ist jedoch nicht Neutralität. Wer den Konflikt nicht entscheidet, überlässt ihn dem Alltag, in dem das Tagesgeschäft fast immer gewinnt.

Projektampeln zeigen Termine, Budget oder technische Risiken. Für ein Transformationsportfolio reichen sie nicht. Die Geschäftsleitung braucht eine gemeinsame Sicht darauf, welchen Geschäftsprozess eine Initiative verändert, welche Abhängigkeiten vorher gelöst sein müssen, welche Arbeit abgebaut wird und welcher Beleg zur nächsten Entscheidung führt.

Nicht jede Initiative braucht kurzfristig einen direkt zurechenbaren ROI. Ein Zugriffsmodell, ein Dateninventar, ein gemeinsames Qualitätsverfahren oder eine sichere Außerdienststellung können Grundlagen sein, ohne in wenigen Wochen eigene Erträge auszuweisen. NIST AI RMF 1.0 verortet diese Aufgaben konkret in GOVERN 1.5 für laufende Überwachung und Review, 1.6 für ein risikobasiertes Systeminventar, 1.7 für sichere Außerdienststellung, 2.1 für klare Verantwortlichkeiten und 2.3 für Executive-Verantwortung.3 Der freiwillige Rahmen ist keine Zertifizierungszusage. Er verdeutlicht aber, warum AI-Betrieb nicht bei der Einführung einer Anwendung endet.

Für solche Basisarbeit braucht es eine Schutzfrist: einen bewusst vereinbarten Zeitraum, in dem das Team an einer notwendigen Grundlage arbeitet und nicht bei jedem Statusgespräch den unmittelbaren Umsatznachweis liefern muss. Eine Schutzfrist ist kein Freipass. Sie hat einen Owner, einen klaren Liefergegenstand, Zugriffsrechte, Qualitätskriterien und einen Review-Termin. Sie schützt vor hektischer Umpriorisierung, ohne die Initiative vor Nachweis zu immunisieren.

Diese vier Optionen machen sichtbar, dass „weiterführen“ keine Managemententscheidung ist. Eine Initiative bekommt eine Funktion im Portfolio oder sie bindet nur Aufmerksamkeit.

Bei AI wird die Lücke zwischen Projektfortschritt und Betriebsveränderung besonders deutlich. Ein funktionierender Prototyp beantwortet noch nicht, ob die zugrunde liegenden Daten verlässlich sind, wer Ergebnisse bewertet, wer Zugriff erhält, wie Fehler entdeckt werden oder wie Mitarbeitende bei Ausnahmefällen handeln.

Das AI Operating System ist hierfür eine methodische Struktur, keine zusätzliche Software. Es verbindet sechs Ebenen: Strategy & Value, Processes & Decisions, Data & Knowledge, Technology & Integration, Governance & Evaluation sowie People & Operating Model. Für die Portfolioentscheidung müssen nicht alle Ebenen gleich tief diskutiert werden. Wichtig ist ihre Verbindung.

Ein Beispiel: Eine Initiative zur Angebotsunterstützung kann wirtschaftlich sinnvoll sein. Sie scheitert dennoch im Betrieb, wenn Produktwissen veraltet ist, sensible Kundeninformationen unkontrolliert zugänglich werden oder Vertrieb und Legal unterschiedliche Regeln für die Freigabe anwenden. Dann ist die passende Entscheidung möglicherweise Foundation, nicht Scale. Der nächste Schritt besteht nicht darin, noch einen Prompt zu verbessern, sondern Wissen, Zugriff und Qualitätsprüfung verbindlich zu machen.

Diese Sicht verhindert zwei verbreitete Fehler. Der erste lautet, ein Tool mit Transformation zu verwechseln. Der zweite lautet, Governance als nachgelagerte Prüfung zu behandeln. Governance und Evaluation definieren, wer verantwortlich ist, wie Qualität und Risiko beobachtet werden, welche Grenzen gelten und wie ein Prozess kontrolliert zurückfällt. Befähigung bedeutet wiederum nicht nur Schulung. Sie bedeutet, dass Führungskräfte und Teams die neue Entscheidungslogik im Alltag anwenden können.

Die Versuchung ist groß, aus einer niedrigen Erfolgsquote eine pauschale Scheitererzählung zu machen. Das wäre ungenau. In einer internationalen McKinsey-Onlinebefragung von 2021 mit 1.034 Befragten stuften 31 % die berichtete Transformation als erfolgreich ein.2 Erfolg bedeutete eine sehr oder vollständig erfolgreiche Leistungsverbesserung und die entsprechende Befähigung der Organisation, die Veränderung zu verstetigen. Der Durchschnitt umfasst die berichteten Transformationen unabhängig von der Zahl eingesetzter Maßnahmen. Die Befragung fand vom 18. Mai bis 29. Juni 2021 statt und erfasste unterschiedliche Unternehmensgrößen und Branchen.

Der Wert ist ein historischer Selbstbericht, keine universelle Scheiterquote, kein Kausalbeweis und keine Messung heutiger AI-Projekte. Seine nützliche Frage lautet deshalb nicht: Gehören wir zu den 31 Prozent? Sie lautet: Haben wir Leistung und Verstetigung beide als Kriterien definiert? Viele Programme messen den ersten Teil unvollständig und den zweiten gar nicht. Eine termingerecht gelieferte Lösung ist noch keine veränderte Organisation.