Den Knoten durchschlagen

Hinweis: Sie lesen eine gekürzte Version des vollständigen Leitartikels. Die vollständige Fassung enthält zusätzliche Beispiele, Entscheidungsmuster und konkrete Handlungsempfehlungen für Executive‑Teams in Transformationsprogrammen. Für einen vertiefenden Austausch steht Ihnen Michael Kozlowski, CFO/CEO Advisor, AXIOM Informationsmanagement GmbH, jederzeit persönlich zur Verfügung.

Ich habe in den vergangenen Jahren viele Gespräche mit Führungskräften geführt, die alle irgendwann an denselben Punkt kamen. Nicht an den Punkt der Entscheidung – das wäre einfach. Sondern an den Punkt, an dem klar wurde, dass die Entscheidung komplizierter ist, als sie zunächst aussah. Zu viele Variablen. Zu viele Meinungen. Zu viele Risiken, die sich schwer einschätzen lassen. Und im Hintergrund immer die leise, aber hartnäckige Frage: Sind wir wirklich bereit dafür?

Dieser Zustand – nennen wir ihn ruhig, was er ist: eine Art qualifizierter Lähmung – ist keine Schwäche. Er ist das vernünftige Ergebnis einer ehrlichen Auseinandersetzung mit einem komplexen Vorhaben. S/4HANA‑Transformationen sind tatsächlich komplex. Sie dauern lange. Sie kosten viel. Und sie haben, wenn man ehrlich ist, eine nicht unerhebliche Ausfallrate, was die prognostizierten Ergebnisse betrifft.

Wer das weiß und trotzdem einfach anfängt, handelt nicht mutig. Er handelt unvorbereitet.

Wer das weiß und deswegen gar nicht anfängt, handelt nicht vorsichtig. Er zahlt einen anderen Preis – einen, der in keiner Projektrechnung auftaucht, aber in jedem Wettbewerbsvergleich.

Der Ausweg aus dieser Zwickmühle ist nicht mehr Analyse. Er ist eine andere Art von Klarheit: über das, was an diesem Vorhaben tatsächlich komplex ist, hinsichtlich dessen, was nur kompliziert wirkt. Über die Entscheidungen, die wirklich schwer sind – und jene, die sich schwer anfühlen, aber es nicht sind. Und über das, was Führung in diesem Kontext konkret bedeutet.

Darum geht es in diesem Artikel.

Teil I: Was an S/4HANA‑Transformationen wirklich komplex ist – und was nicht

Es lohnt sich, hier zu beginnen. Denn ein erheblicher Teil der Lähmung, die Führungsteams vor diesem Vorhaben erleben, entsteht aus einer undifferenzierten Wahrnehmung der Komplexität. Alles erscheint gleich schwer. Alles erscheint gleich riskant. Das Ergebnis: Handlungsunfähigkeit, die sich wie Vorsicht anfühlt.

Tatsächlich gibt es in jeder S/4‑Transformation mindestens zwei Kategorien von Herausforderungen, die völlig getrennt betrachtet werden müssen.

Die erste Kategorie: komplizierte Probleme. Das sind Probleme, die viele Variablen aufweisen und methodisch anspruchsvoll sind – aber lösbar, wenn man die richtigen Leute mit dem erforderlichen Wissen einsetzt. Technische Datenmigration gehört dazu. Systemkonfiguration. Testmanagement. Schnittstellenarchitektur.

Die zweite Kategorie: echte Komplexität. Das sind Probleme, bei denen die Lösung nicht aus Expertise allein entsteht – weil die Antwort von Faktoren abhängt, die sich während des Lösungsprozesses selbst verändern.

Diese Unterscheidung ist nicht akademisch. Sie ist praktisch entscheidend. Denn sie definiert, wo Expertise hilft – und wo Führung gefragt ist.

Das Ergebnis ist eine charakteristische Fehlverteilung: Executive‑Management, das sich in technischen Details verliert. Und operative Fragen von strategischer Tragweite, die niemand entscheidet, weil niemand zuständig ist.

Was die Komplexität konkret treibt – und was sie reduziert

Nicht alle S/4‑Projekte sind gleich komplex. Die Komplexität eines konkreten Vorhabens hängt von vier Faktoren ab, die vor dem Programmstart eingeschätzt werden können – und die das Führungsteam informieren.

Faktor 1: Organisationsstruktur. Ein Unternehmen mit drei Gesellschaften, einem Kernmarkt und einheitlicher Währung ist strukturell anders aufgestellt als eines mit zwölf Ländergesellschaften.

Faktor 2: Systemlandschaft. Wie viele Altsysteme gibt es? Wie viel Eigenentwicklung steckt im SAP‑System? Wie viele Schnittstellen existieren?

Faktor 3: Datenqualität. Je schlechter der Zustand der Stammdaten, desto höher Aufwand und Risiko der Migration.

Faktor 4: Entscheidungskultur. Wie schnell trifft das Unternehmen Entscheidungen? Wie hoch ist die Konsenserfordernis?

Teil II: Die sechs Entscheidungen, die wirklich zählen

In einem S/4‑Programm werden zahlreiche Entscheidungen getroffen. Konfigurationsentscheidungen. Prozessentscheidungen. Ressourcenentscheidungen. Eskalationsentscheidungen.

Tatsächlich gibt es eine überschaubare Anzahl von Entscheidungen, die den Charakter und den Ausgang des gesamten Programms prägen.

Entscheidung 1: Scope und Standardisierungstiefe

Wie viel globale Standardisierung ist das strategische Ziel? Welche lokalen Abweichungen sind wettbewerbsrelevant – und welche sind historisch gewachsene Komplexität ohne echten Mehrwert?

Der Preis des Offenlassens: Patchwork statt Standard.

Entscheidung 2: Implementierungspartner

Die Auswahl des Partners entscheidet über Seniorität, Kulturpassung und Ehrlichkeit im Projekt.

Entscheidung 3: Interne Ressourcen

Für jeden kritischen Workstream braucht es eine interne Führungspersönlichkeit mit fachlicher Tiefe und organisatorischer Durchsetzungskraft.

Entscheidung 4: Governance‑Design

Governance ist eine Führungsaufgabe – nicht die des Implementierungspartners.

Entscheidung 5: Go‑Live‑Strategie

Big Bang oder schrittweise? Entscheidend ist die Organisationsreife.

Entscheidung 6: Was passiert nach dem Go‑Live

Ohne Betriebsmodell wird aus der Transformation ein Upgrade.

Teil III: Der praktische Leitfaden – was Executives in den vier Phasen konkret tun müssen

Phase 1: Vor dem Programm

Systemlandschafts‑Analyse. Alignment‑Workshop. Reife‑Einschätzung. Partnerauswahl.

Phase 2: Im Programm

Informationsarchitektur. Entscheidungsgeschwindigkeit. Unabhängige QA. Kritische Designentscheidungen. Sichtbarkeit.

Phase 3: Go‑Live und Stabilisierungsphase

Readiness‑Bewertung. Hypercare. Momentum nutzen.

Phase 4: Nach dem Go‑Live

Nutzenrealisierung. Systemkompetenz. Kontinuierliche Verbesserung.

Teil IV: Häufige Fehler – und was sie über das Führungsteam sagen

Fehler 1: Start ohne Einigkeit

Konflikte wandern in den Projektraum.

Fehler 2: Partner wird nicht gefordert

Optimistische Berichte verdecken Risiken.

Fehler 3: Schlüsselpersonen gehen

Wissensverlust und Verzögerungen.

Fehler 4: Business Case wird nie wieder geöffnet

Nutzen bleibt ungehoben.

Fehler 5: System veraltet nach drei Jahren

Kein Betriebsmodell, keine Weiterentwicklung.