Steuerungsarchitekturen, die Transformationen tragen

Was mit „Steuerungsarchitektur“ nicht gemeint ist

Es gibt eine Frage, die in fast jedem S/4HANA-Projekt irgendwann auftaucht – meistens zu spät und meistens im falschen Raum: „Wer entscheidet das eigentlich?“ Nicht als rhetorische Frage. Sondern als echte Ratlosigkeit darüber, welche Person, welche Ebene, welches Gremium für eine bestimmte Klasse von Entscheidungen zuständig ist.

Diese Ratlosigkeit kostet. Sie kostet Zeit, weil Entscheidungen kreisen statt zu fallen. Sie kostet Qualität, weil unter Zeitdruck schließlich irgendjemand entscheidet – nicht unbedingt der Richtige. Und sie kostet Vertrauen, weil Teams, die zu oft auf Richtungsentscheidungen warten, aufhören zu glauben, dass das Projekt wirklich geführt wird.

Steuerungsarchitekturen sind das Gegenmittel. Aber nicht in der Form, in der sie meistens verstanden werden.

Wenn Beraterhäuser über Governance sprechen, entstehen in den Köpfen von Führungskräften oft ähnliche Bilder: RACI-Matrizen, Projekthandbücher, Gremienlandschaften mit vielen Kästchen und Pfeilen. Dokumente, die zu Projektbeginn mit Sorgfalt erstellt und danach konsequent ignoriert werden.

Das ist nicht gemeint.

Eine funktionierende Steuerungsarchitektur ist keine Dokumentationsdisziplin. Sie ist eine Verhaltenserwartung: Wer trifft welche Entscheidungen, auf welcher Basis, in welcher Zeit – und was passiert, wenn das nicht funktioniert? Diese Erwartung muss explizit formuliert sein, aktiv gelebt werden und Konsequenzen haben, wenn sie verletzt wird.

Der Unterschied klingt subtil. Er ist es nicht. Ein Unternehmen, das seine Steuerungsstruktur in einem 80-seitigen Governance-Dokument beschreibt, aber im Steuerkreis keine Entscheidungen trifft, hat keine Governance. Es hat Papier.

Der strukturelle Fehler: Zu viele Personen, zu wenig Klarheit

Die häufigste Schwäche in S/4-Projektgremien ist nicht Desinteresse des Managements. Es ist Unklarheit darüber, welche Entscheidungen wohin gehören.

In der Praxis sieht das so aus: Ein Workstream-Team stößt auf eine Grundsatzfrage im Prozessdesign – zum Beispiel, ob der Auftragsabwicklungsprozess global standardisiert oder regional differenziert werden soll. Die Frage geht an den Projektlenkungsausschuss. Dort sitzen zwölf Personen, von denen vier betroffen sind und acht zuhören. Nach 40 Minuten Diskussion endet das Meeting mit dem Auftrag, „das noch einmal fachlich zu klären“. Vier Wochen später taucht die Frage im nächsten Steuerkreis wieder auf.

Dieses Muster ist nicht die Ausnahme. Es ist die Regel. Und es hat eine strukturelle Ursache: Das Gremium ist nicht für diese Klasse von Entscheidungen gebaut. Es ist zu groß, zu selten und zu allgemein zusammengesetzt, um operative Designfragen zu lösen.

Was stattdessen funktioniert, ist eine gestufte Entscheidungsarchitektur – drei Ebenen, klar voneinander getrennt:

Ebene 1: Das operative Projektteam entscheidet über alles, was innerhalb der vereinbarten Design-Prinzipien liegt. Keine Eskalation, keine Rückfrage – aber auch keine Abweichung von definierten Leitlinien ohne Eskalation.

Ebene 2: Ein kleines Design Authority Board – drei bis fünf Personen, darunter der interne Projektleiter, ein Vertreter des betroffenen Fachbereichs und ein Mitglied des Executive-Kreises – entscheidet über Fragen, die Prozessgrenzen überschreiten oder von vereinbarten Standards abweichen. Dieses Gremium trifft sich wöchentlich, nicht monatlich.

Ebene 3: Der Executive Steuerkreis entscheidet über strategische Weichenstellungen, Budget-Abweichungen über einem definierten Schwellenwert und Konflikte, die auf Ebene 2 nicht gelöst werden konnten.

Die Trennlinien zwischen diesen Ebenen müssen präzise sein. Nicht als abstrakte Definition, sondern als Liste konkreter Entscheidungstypen. Wer das einmal sauber aufschreibt, stellt fest, dass 80 Prozent aller Projektentscheidungen auf Ebene 1 oder 2 gelöst werden können – ohne dass der Steuerkreis überhaupt involviert sein muss.

Rollen, die wirklich funktionieren müssen

Hinter jeder Governance-Struktur stehen Menschen. Und die entscheidende Frage ist nicht, ob jemand eine Rolle trägt – sondern ob er sie auch ausfüllt.

Drei Rollen sind in S/4-Projekten besonders kritisch und werden besonders häufig falsch besetzt oder falsch verstanden.

Der Executive Sponsor. Diese Rolle wird oft mit dem Projektsponsor verwechselt, der Sitzungen moderiert und Ressourcen freigibt. Der Executive Sponsor hat eine andere Aufgabe: Er ist die organisatorische Autorität, die Konflikte zwischen Bereichen entscheiden kann – und die das auch tut. Er braucht keine technische S/4-Expertise. Er braucht den Rückhalt des CEO oder des Vorstands und die Bereitschaft, unpopuläre Entscheidungen zu treffen und sie danach nicht wieder zu revidieren.

Ein Chemieunternehmen hat diese Rolle bewusst mit dem COO besetzt – nicht mit dem CIO, der naheliegend gewesen wäre. Begründung: Wenn der Konflikt zwischen Supply Chain und Finance über die Abbildung von Lagerkosten eskaliert, braucht es jemanden, der über beide Bereiche Entscheidungshoheit hat. Diese Besetzungsentscheidung hat das Projekt in zwei konkreten Situationen vor mehrwöchigen Blockaden bewahrt.

Der interne Projektleiter. Nicht der Berater, nicht der IT-Projektmanager – sondern eine Führungspersönlichkeit aus dem Business, die das nötige Standing hat, um mit dem Implementierungspartner auf Augenhöhe zu verhandeln und intern Entscheidungen voranzutreiben. Wer diese Rolle mit jemandem besetzt, der primär koordiniert, bekommt ein gut geführtes Protokoll – aber keine Projektsteuerung.

Die Prozesseigentümer. In vielen Projekten sind das nominelle Rollen ohne reale Entscheidungsmacht. Das ist fatal. Der Prozesseigentümer für den Purchase-to-Pay-Prozess muss tatsächlich entscheiden können, wie dieser Prozess gestaltet wird – auch wenn das einzelnen Einkaufsorganisationen nicht gefällt. Ohne diese Entscheidungsmacht werden Prozesseigentümer zu Durchlaufstationen. Entscheidungen treffen dann die, die am lautesten sind – oder die, die am längsten dabei sind.

Entscheidungslogiken, die im Alltag funktionieren

Gremien und Rollen allein genügen nicht. Sie brauchen eine Entscheidungslogik – eine geteilte Vorstellung darüber, wie Entscheidungen getroffen werden, wenn kein Konsens besteht.

Das ist der Teil, der in Governance-Diskussionen meistens ausgelassen wird. Und er ist der schwierigste, weil er Machtfragen berührt.

Eine einfache, aber wirksame Logik, die in mehreren Projekten gut funktioniert hat: „Consult, then decide.“ Bevor eine Entscheidung auf einer bestimmten Ebene getroffen wird, werden die relevanten Stakeholder konsultiert – nicht um Konsens herzustellen, sondern um relevante Informationen zu sichern. Danach entscheidet die zuständige Person oder das zuständige Gremium. Die Entscheidung gilt. Sie kann revidiert werden, wenn neue, wesentliche Informationen auftauchen – nicht weil jemandem das Ergebnis nicht gefällt.

Diese Logik hat eine wichtige Nebenwirkung: Sie gibt dem Prozess Legitimität, auch wenn das Ergebnis nicht allen passt. Wer konsultiert wurde und dann übergangen wird, ist unzufrieden. Wer nicht konsultiert wurde, ist es auch. Wer konsultiert wurde und versteht, warum die Entscheidung trotzdem anders gefallen ist, kann damit meistens leben.

Ein Retailunternehmen mit neun Ländergesellschaften hat zu Projektbeginn eine halbe Seite verfasst, die genau diese Logik beschreibt: Wer konsultiert wird, wer entscheidet, welche Informationen eine Entscheidung braucht, und wie lange eine Entscheidung offen bleiben darf, bevor sie eskaliert. Diese halbe Seite wurde in jedem Steuerkreis als erstes Dokument gezeigt. Sie hat mehr zur Entscheidungskultur des Projekts beigetragen als das gesamte Governance-Handbuch.

Was Steuerungsarchitekturen mit Projektgeschwindigkeit zu tun haben

Die Verbindung ist direkter als sie auf den ersten Blick erscheint. Projekte verlieren Tempo fast nie durch technische Komplexität allein. Sie verlieren Tempo durch Entscheidungsstau.

Wenn das Testteam eine kritische Lücke im Prozessdesign findet und drei Wochen auf eine Entscheidung wartet, verliert nicht nur dieser eine Workstream Zeit. Abhängige Workstreams verschieben sich mit. Testpläne werden angepasst. Ressourcen werden umgeplant. Die echten Kosten eines ungeklärten Entscheidungsbedarfs liegen fast immer höher als sichtbar.

Umgekehrt: Ein Projekt, in dem Entscheidungen auf der richtigen Ebene in zwei bis drei Tagen getroffen werden, ist ein anderes Projekt. Nicht weil die Probleme kleiner sind. Sondern weil die Organisation bewiesen hat, dass sie handlungsfähig ist. Das verändert die Energie im Team – und damit die Bereitschaft, auch schwierige Fragen offen anzusprechen statt zu umschiffen.

Steuerungsarchitektur ist deshalb kein Verwaltungsthema. Sie ist ein Produktivitätsfaktor.

Drei Dinge, die Executives jetzt tun können

Erstens: Prüfen Sie, ob in Ihrem Projekt heute klar ist, welche Entscheidungen auf welcher Ebene getroffen werden. Nicht als Organigramm – sondern als konkrete Liste von Entscheidungstypen mit zugeordneten Instanzen. Wenn diese Liste nicht existiert oder nicht gelebt wird, ist das der erste Hebel.

Zweitens: Schauen Sie sich die letzten drei Steuerkreis-Protokolle an. Wie viele Entscheidungen wurden im Raum getroffen – und wie viele wurden vertagt? Wenn die Vertag-Quote über 50 Prozent liegt, ist Ihr Steuerkreis kein Steuerungsgremium. Er ist ein Reporting-Format.

Drittens: Überprüfen Sie die Besetzung der Schlüsselrollen – nicht auf dem Papier, sondern in der Praxis. Wer trifft tatsächlich Entscheidungen? Wer koordiniert nur? Wer wartet auf Erlaubnis, die nie explizit erteilt wird? Diese Fragen, offen gestellt, produzieren meistens sehr klare Antworten.