Warum die erfolgreichsten Transformationsprogramme 2026 kleiner werden, nicht größer
Letzte Woche saß ich mit einem CIO in Hamburg zusammen. Sein Unternehmen — ein mittelgroßer Versicherer — hatte gerade grünes Licht für ein großes IT-Modernisierungsprogramm bekommen. Budget: achtstellig. Laufzeit: drei Jahre. Umfang: Ablösung von fünf Legacy-Systemen, Einführung von drei neuen Plattformen, Migration von zwei Rechenzentren.
Vor fünf Jahren hätte ich gesagt: „Das ist ein ambitioniertes, aber machbares Programm.“ Heute habe ich etwas anderes gesagt:
„Streichen Sie zwei Drittel davon.“
Er hat mich angeschaut, als hätte ich gerade sein Budget gekürzt. Aber ich meinte es ernst. Und nach zwei Stunden Diskussion hat er verstanden, warum.
Das Programm, das er beschrieben hatte, folgte der Logik der letzten 15 Jahre: Modernisierung bedeutet Wachstum. Mehr Systeme. Mehr Funktionen. Mehr Möglichkeiten.
Aber 2026 funktioniert diese Logik nicht mehr.
Ich führe seit Monaten Gespräche mit Entscheidern in Konzernen und mittelständischen Unternehmen — in regulierten Branchen, in IT-Dienstleistung, im Handel. Und ich beobachte ein Muster, das vor zwei Jahren noch die Ausnahme war und heute die Regel wird:
Die erfolgreichsten Programme sind nicht mehr die, die am meisten hinzufügen. Es sind die, die am klügsten weglassen.
Ich nenne das „Kontrollierten Rückbau“ — und er ist das Gegenteil von dem, was die meisten Transformationsprogramme der letzten Jahre ausgemacht hat.
Kontrollierter Rückbau bedeutet nicht Sparprogramm. Er bedeutet: bewusst entscheiden, welche Komplexität man abbaut, welche Systeme man ablöst, welche Prozesse man vereinfacht — bevor man auch nur ein neues Tool einführt.
Das klingt trivial. Ist es aber nicht. Denn es erfordert eine fundamentale Änderung der Fragestellung.
Nicht mehr: „Was müssen wir aufbauen, um wettbewerbsfähig zu bleiben?“
Sondern: „Was müssen wir abbauen, um handlungsfähig zu bleiben?“
In den letzten zwölf Monaten habe ich drei konkrete Muster beobachtet, die sich in fast jedem Gespräch wiederholen:
Muster 1: Legacy-Ablösung vor neuen Tools
Ein Finanzdienstleister wollte ein neues CRM-System einführen. Budget war da, Business Case war klar, Management war überzeugt. Aber dann haben wir eine einfache Frage gestellt: „Welche Systeme laufen aktuell parallel zum geplanten CRM — und was passiert mit denen?“
Die Antwort: drei verschiedene Altsysteme mit teilweise überlappenden Funktionen. Keines davon sollte abgelöst werden. Das neue CRM sollte parallel laufen.
Das ist das klassische Muster: Man fügt hinzu, aber man nimmt nichts weg. Die Komplexität wächst. Die Betriebskosten steigen. Die Wartungsaufwände multiplizieren sich.
Wir haben das Programm umgedreht: Erst die drei Altsysteme konsolidieren und ablösen. Dann — und nur dann — über ein neues CRM nachdenken. Das Programm wurde um ein Jahr verkürzt, und die Betriebskosten sanken, bevor auch nur ein Euro in neue Software investiert wurde.
Die klügste Investition ist oft die, die man nicht tätigt — weil man stattdessen etwas Bestehendes ablöst.
Muster 2: Governance-Reduktion statt -Aufbau
Ein IT-Dienstleister im GKV-Umfeld wollte seine Programm-Governance „professionalisieren“. Das bedeutete: mehr Gremien, klarere Rollen, strukturiertere Freigabeprozesse. Auf dem Papier vernünftig. In der Praxis: jede Entscheidung hätte drei Wochen länger gebraucht.
Wir haben stattdessen das Gegenteil gemacht: die bestehende Governance analysiert und ein Drittel der Gremien gestrichen. Die übrig gebliebenen Gremien bekamen klarere Entscheidungsbefugnisse — nicht mehr Konsens, sondern definierte Entscheider.
Das Ergebnis: Entscheidungen wurden schneller, nicht langsamer. Das Programm hat an Geschwindigkeit gewonnen, nicht verloren.
Mehr Governance ist nicht besser. Klarere Governance ist besser. Und manchmal bedeutet das: weniger Strukturen, nicht mehr.
Muster 3: Prozess-Konsolidierung vor Automatisierung
Ein Handelsunternehmen wollte seine Logistikprozesse automatisieren. KI-gestützte Prognosen, automatisierte Bestellsysteme, intelligente Routenplanung. Alles technisch machbar.
Aber als wir uns die bestehenden Prozesse angeschaut haben, haben wir fünf verschiedene Varianten desselben Prozesses gefunden. Jede Region hatte ihre eigene Logik entwickelt. Keine davon war dokumentiert.
Das Problem: Wenn man einen chaotischen Prozess automatisiert, bekommt man automatisiertes Chaos. Also haben wir das Programm gestoppt: erst die fünf Varianten auf eine konsolidieren, dokumentieren — dann automatisieren. Das hat sechs Monate länger gedauert als geplant. Aber das Ergebnis war ein Prozess, der tatsächlich funktioniert.
Automatisierung ist wertvoll — aber nur, wenn der Prozess darunter klar ist. Sonst automatisiert man nur Komplexität.
Diese Muster sind nicht neu. Gute Programmleiter haben schon immer gewusst, dass man aufräumen muss, bevor man baut. Aber 2026 ist das nicht mehr eine Empfehlung. Es ist eine Notwendigkeit.
Drei strukturelle Gründe treiben diese Verschiebung:
Erstens: Die wirtschaftliche Lage. Budgets sind knapper. Investitionen müssen schneller ROI liefern. Ein Programm, das neue Kosten erzeugt, bevor es alte Kosten senkt, wird nicht genehmigt.
Zweitens: Die technologische Komplexität. Die meisten Unternehmen tragen inzwischen eine Schuld an Legacy-Systemen, parallelen Strukturen und ungeklärten Abhängigkeiten mit sich herum, die sie lähmt. Jedes neue System, das hinzukommt, verschärft das Problem.
Drittens: Die regulatorische Landschaft. In regulierten Branchen wird Compliance immer anspruchsvoller. Jedes System, das man betreibt, ist eine potenzielle Haftungsfläche. Weniger Systeme bedeutet weniger Risiko.
Diese drei Faktoren zusammen erzeugen einen Druck, der nicht mehr zu ignorieren ist: Unternehmen müssen einfacher werden, bevor sie komplexer werden können.
Wenn Sie gerade ein Transformationsprogramm planen — oder eines steuern, das nicht so läuft wie erwartet — dann lohnt sich eine einfache Frage:
„Was nehmen wir weg, bevor wir etwas hinzufügen?“
Konkret bedeutet das:
Wenn Sie ein neues System einführen wollen: Welches alte System können Sie gleichzeitig ablösen? Wenn die Antwort „Keines“ ist — überdenken Sie das Programm.
Wenn Sie Ihre Governance professionalisieren wollen: Welche Gremien können Sie streichen? Wenn die Antwort „Keine“ ist — bauen Sie nur Bürokratie auf.
Wenn Sie Prozesse automatisieren wollen: Sind diese Prozesse überhaupt standardisiert? Oder automatisieren Sie fünf verschiedene Varianten desselben Problems?
Kontrollierter Rückbau ist keine Sparpolitik. Er ist eine strategische Entscheidung: Komplexität abbauen, bevor man neue Fähigkeiten aufbaut.
Die Unternehmen, die das verstehen, werden 2026 erfolgreicher sein als die, die weiter nach dem alten Muster operieren.
Der CIO aus Hamburg hat sein Programm umgestellt. Statt fünf Legacy-Systeme abzulösen und drei neue Plattformen einzuführen, konzentriert er sich jetzt auf zwei Ablösungen — und eine Konsolidierung.
Das Programm ist kleiner geworden. Das Budget ist niedriger. Die Laufzeit ist kürzer.
Aber die Erfolgswahrscheinlichkeit ist höher.
Denn er hat verstanden, was die besten Programmleiter 2026 verstehen: Der Wert liegt nicht darin, wie viel man hinzufügt. Er liegt darin, wie klug man weglässt.
Über den Autor
Rainer V. Hiller ist Senior Program Manager mit 25 Jahren Erfahrung in der Steuerung komplexer Transformationsprogramme — spezialisiert auf regulierte Umfelder, Organisationsrückbau und Compliance-konforme Cloud-Transformation.
Er ist ab sofort verfügbar für Interim-Mandate.
Kontakt: rainer.hiller@dxb-41.consulting
