Einen wirksamen SAP-Lenkungsausschuss aufbauen

Ein SAP-Lenkungsausschuss ist die kleine Gruppe von Führungskräften, die die Entscheidungen trifft, die das Projektteam nicht treffen kann: Budget, Änderungen am Umfang, abteilungsübergreifende Konflikte und die abschließende Go/No-go-Entscheidung. Er funktioniert, wenn die Mitglieder echte Entscheidungsbefugnis haben, oft genug tagen, um in der Sitzung zu entscheiden, und die Einsatzbereitschaft anhand von Belegen beurteilen statt anhand des Kalenders. Dieser Leitfaden richtet sich an Sponsoren und Programmleiter, die einen Ausschuss aufsetzen oder einen reparieren wollen, der zum Publikum für Statusberichte geworden ist. Er behandelt, was der Ausschuss entscheiden muss, die Besetzung nach Projektgröße, wie Entscheidungen laufen sollten, eine Go/No-go-Checkliste und was RISE with SAP und KI-Tools verändern.

Ich habe noch nie ein SAP-Projekt mit einem schwachen Lenkungsausschuss gelingen sehen. Im Ausschuss fallen die schwierigen Entscheidungen. Entweder in Echtzeit, oder sie stauen sich, bis sie beim Cutover explodieren.

Bei einem SAP-Rollout tagte der Ausschuss einmal im Monat. Das Projektteam meldete kaputte Genehmigungsworkflows, unvollständige Tests und fehlende Schulungen. Die Leitung sagte, sie werde es „prüfen“. Das geschah nie. Das Projekt ging live, und die Finanzabteilung räumte danach sechs Monate lang auf.

Bei einem anderen Unternehmen tagte der Ausschuss wöchentlich und traf echte Entscheidungen. Als die Tests Lücken offenlegten, wies er Ressourcen neu zu. Wenn ein Prozess nicht funktionierte, brachte er ihn in Ordnung. Dieses Projekt ging reibungslos live.

Ein Ausschuss hat geführt. Der andere hat in Meetings gesessen.

Wenn der Ausschuss nur Statusberichte entgegennimmt, scheitert er bereits. Die Tabelle zeigt den Unterschied in der Praxis.

Funktion	So sieht gut aus	So sieht schwach aus
Grundsatzentscheidungen	Prüft den Fall und entscheidet auf der Stelle	„Das besprechen wir offline“; das Thema kommt nächsten Monat wieder
Blockaden	HR verzögert die Tests? Der Vorsitzende ruft den Abteilungsleiter direkt an	Nimmt das Problem zur Kenntnis und protokolliert es
Umfang	Wägt jeden Änderungsantrag gegen den Plan ab	Winkt durch, was am lautesten eskaliert wird
Risiko	Sieht einen Lieferanten kämpfen und organisiert Ersatz, bevor Verzögerungen eintreten	Wartet ab, ob sich das von selbst löst
Budget	Genehmigt zusätzliche 2 Mio. US-Dollar für drei Monate Verlängerung, weil die Störung mehr kosten würde	Schiebt es auf den nächsten Monat
Go/No-go	Verschiebt den Go-live um sechs Wochen, weil die Tests nicht abgeschlossen sind, und bleibt dabei	Genehmigt den Go-live, weil der Termin im Kalender steht

Die letzte Zeile ist die wichtigste. Ich habe erlebt, dass Ausschüsse Go-lives verschoben haben, auch wenn die Teams vorpreschen wollten. Der Ausschuss eines Pharmakunden verschob den Go-live um sechs Wochen, weil die Tests nicht abgeschlossen waren. Eine harte Entscheidung, aber sie bewahrte das Unternehmen vor einem Desaster.

Bei zu vielen Mitgliedern kann der Ausschuss nicht entscheiden. Bei zu wenigen fehlen wichtige Stimmen.

Projektgröße	Budget und Umfang	Mitglieder	Wer im Raum sein muss
Klein	Unter 0,5 Mio. US-Dollar, eine Abteilung, unter 6 Monate	3 bis 5	Abteilungsleiter, IT-Leiter, Vertreter der Finanzabteilung
Mittelstand	0,5 bis 5 Mio. US-Dollar, mehrere Abteilungen, 6 bis 18 Monate	5 bis 8	Fachbereichsleiter der betroffenen Abteilungen, IT-Leitung, Finanzen
Konzern	Über 5 Mio. US-Dollar, unternehmensweit, 18 Monate oder mehr	8 bis 12	C-Level aus Finanzen, HR, Betrieb und IT; Programmmanager; Change-Verantwortlicher

Die Regel, die ich anwende: Nehmen Sie Leute mit echter Entscheidungsbefugnis auf. Ich habe Ausschüsse scheitern sehen, weil Mitglieder mit hohen Titeln nichts genehmigen konnten, ohne bei jemand anderem nachzufragen. Wenn der CFO nicht teilnehmen kann, schicken Sie jemanden mit einem echten Mandat zu entscheiden, nicht zurückzumelden.

Den Vorsitz sollte der Projektsponsor führen, in der Regel eine Führungskraft auf C-Level, die andere Führungskräfte zur Rechenschaft ziehen kann. Eine Führungskraft der mittleren Ebene im Vorsitz kann einen CFO nicht überstimmen, und diese Autorität zählt, wenn Konflikte um Umfang oder Budget auftreten.

Auf Basis von Belegen. Ich habe mit einem Fertigungskunden gearbeitet, dessen IT-Team sagte, eine Prozessänderung würde drei Monate zusätzlich kosten. Das Business bestand darauf, sie sei „einfach“. Der Ausschuss weigerte sich zu entscheiden, bevor er Aufwandsschätzungen, Abhängigkeitsanalyse und Kapazitätsplanung gesehen hatte. Die IT hatte recht. Der Ausschuss lag richtig, weil er Belege verlangte, statt sich auf die Seite der lautesten Stimme zu schlagen.

Schnell. Ich habe einen Kunden erlebt, dessen Ausschuss alle zwei Wochen tagte, aber immer mit „Das besprechen wir offline“ endete. Die Themen stauten sich, bis das Projekt sechs Monate im Rückstand war. Der Ausschuss eines anderen Kunden traf seine Entscheidungen im Raum, und sein Projekt wurde früher und unter Budget fertig. Langsame Ausschüsse erzeugen verspätete Projekte.

Mit ausdrücklicher Befugnis. Wirksame Ausschüsse können Abteilungsleiter überstimmen, ungeplantes Budget genehmigen und Umfangserweiterungen mitten im Projekt ablehnen. Sind diese Befugnisse nicht schriftlich festgehalten und verstanden, wird der Ausschuss zum Beratungsgremium, und Beratungsgremien liefern keine SAP-Projekte.

Beim Umfang selektiv. Bei einem meiner Kunden forderte eine Abteilung plötzlich 20 zusätzliche Berichte. Der Ausschuss fragte, ob jeder einzelne jetzt gebraucht wird und ob er den Zeitplan sprengt. Er genehmigte fünf kritische Berichte und verschob den Rest auf die Zeit nach dem Go-live. Diese Entscheidung hat wahrscheinlich den Go-live-Termin gerettet.

Halten Sie die Sitzungen bei 60 bis 90 Minuten. Top-Risiken, die konkret nötigen Entscheidungen und Maßnahmen mit Verantwortlichen und Terminen. Keine technischen Updates, die man vorher lesen kann. Taucht dasselbe Thema dreimal hintereinander ohne Lösung auf, haben Sie ein Governance-Problem, kein Komplexitätsproblem.

Nutzen Sie Daten statt Foliensätzen. Ich habe mit einem Energiekunden gearbeitet, der ein Dashboard aus Testausführung, Fehlerbehebung, Schulungsfortschritt und Budgetverbrauch aufgebaut hat. In den Sitzungen ging es nicht mehr darum zu verstehen, wo man steht, sondern darum, Probleme zu lösen.

Zeigen Sie dem Ausschuss das System. Der Ausschuss eines Pharmakunden ging ein „Tag im Leben“-Szenario durch. Er stellte fest, dass das genehmigte Design die Mitarbeitenden bei einem gängigen Prozess fünf verschiedene Bildschirme nutzen ließe. Er ordnete sofort eine Überarbeitung an.

Planen Sie die Politik ein. Der häufigste Fehler ist nicht Inkompetenz. Es sind Abteilungen, die ihr Revier verteidigen, und Teams, die Tests wegen der Jahresendarbeiten verschieben. In einem Projekt verschob HR die Payroll-Tests immer wieder, weil es mit Jahresendaufgaben ausgelastet war. Der Ausschuss priorisierte die Arbeit neu und stellte Ersatztester ab, und das Projekt blieb im Plan, statt monatelang zu rutschen.

Setzen Sie an großen Gates unabhängige Prüfungen ein. Ein Fertigungskunde ließ seine Einsatzbereitschaft von externen Prüfern bewerten, bevor er den Go-live freigab. Die Prüfung fand mehrere gravierende Probleme, die das Projektteam übersehen oder heruntergespielt hatte. Mein Leitfaden zu SAP Quality Gates zeigt, wie Sie diese Kontrollpunkte aufbauen.

Kalenderdruck ist die falsche Grundlage, um den Go-live zu genehmigen. Vor der Abstimmung sollte der Ausschuss zu jedem dieser Punkte Belege sehen:

1. Integrations- und Benutzerabnahmetests abgeschlossen, ohne offene kritische Fehler
2. Letzte Probemigration der Daten abgestimmt und von der Finanzabteilung abgezeichnet
3. Cutover-Probelauf innerhalb des geplanten Zeitfensters abgeschlossen
4. Key User geschult, Unterstützung vor Ort und Arbeitshilfen bereit
5. Geschäftliche Einsatzbereitschaft von jedem Prozessverantwortlichen schriftlich bestätigt
6. Rollback-Plan getestet und vereinbart
7. Hypercare-Team, Eskalationsweg und Unterstützung für den ersten Abschluss stehen

Ist auch nur ein Punkt rot, sagt ein starker Ausschuss Nein. Eine Verzögerung von sechs Wochen lässt sich aufholen. Ein gescheiterter Go-live, der den Betrieb oder den Finanzabschluss stört, kann Monate brauchen, bis sich alles stabilisiert. Ich habe zu viele Go-lives aufgeräumt, die genehmigt wurden, weil sich der Termin unverrückbar anfühlte. Speisen Sie die Agenda des Ausschusses aus einem lebenden Risikoregister, damit diese Punkte früh sichtbar werden.

RISE holt SAP in das Governance-Modell. Bei RISE with SAP betreibt SAP die Infrastruktur und den technischen Betrieb. Laut dem SAP-Dokument zu Rollen und Verantwortlichkeiten bei RISE arbeiten Kunden mit einem SAP Cloud Architect Advisor, einem Client Delivery Manager oder dem Private-Cloud-Kundencenter von SAP. Bei Plattformthemen wie Performance, Verfügbarkeit oder Service Levels braucht der Ausschuss einen Weg zu diesen Ansprechpartnern, der nicht über den Implementierungspartner läuft. Laden Sie sie zu den relevanten Agendapunkten ein, statt sie zu ständigen Mitgliedern zu machen.

Ein Clean-Core-Gremium gehört unter den Ausschuss. Richten Sie in RISE-Programmen eine Design Authority ein, die Anpassungsanforderungen anhand der Clean-Core-Prinzipien genehmigt oder ablehnt. Sie eskaliert nur dann an den Ausschuss, wenn eine geschäftskritische Anforderung blockiert wird. Ohne diese Ebene wird jede Anpassung zum Streit im Ausschuss. On-Premise gilt weiterhin das traditionelle Modell, und SAP ist ein Anbieter, kein Beteiligter.

1. LenkungsausschussVorsitz beim Sponsor. Budget, Umfang, Konflikte, Go/No-go
   SAP-Delivery-AnsprechpartnerEingeladen für Plattformthemen, nicht über den Partner geleitet

• ProgrammmanagementbüroTägliche Umsetzung, Risikolog, Koordination
• Clean-Core-Design-AuthorityEntscheidet über Anpassungen, eskaliert nur blockierte kritische Anforderungen

KI spart Zeit beim Papierkram. Microsoft 365 Copilot entwirft Protokolle aus der aufgezeichneten Sitzung. Die Arbeit besteht dann darin, einen Entwurf zu prüfen, statt von null zu schreiben, und die Entscheidungen stammen aus dem Transkript. Atlassians Rovo kann Besprechungsnotizen in strukturierte Einträge für das Entscheidungslog verwandeln, sobald die Vorlage steht. Joule-basierte Assistenten in SAP Cloud ALM können eine erste Auswirkungsanalyse für einen Umfangsantrag entwerfen, sodass der Ausschuss in der Sitzung entscheiden kann, statt zu vertagen.

Sentiment-Analyse lassen Sie vorerst aus. Einige Anbieter bewerben die Sentiment-Analyse der Programmkommunikation als Input für den Ausschuss. In den meisten Programmen ist sie Theater: Das Signal ist schwach, Fehlalarme sind häufig, und es hat einen politischen Preis, wenn bekannt ist, dass man Stimmungen überwacht. Nur in sehr großen Programmen kann sie frühzeitig Gruppen erkennen, die sich abkoppeln. Für die meisten Ausschüsse ist es nicht die Stelle, an der man das KI-Budget ausgeben sollte.

Welche Rolle hat ein Lenkungsausschuss in einem SAP-Projekt?

Er trifft die Entscheidungen, die das Projektteam nicht treffen kann: Budgetfreigaben, Änderungen am Umfang, Ressourceneskalation und die abschließende Go/No-go-Entscheidung. Er löst abteilungsübergreifende Konflikte und nimmt Abteilungsleiter bei ihren Zusagen zu Tests und Schulungen in die Pflicht. Wenn er nur Statusupdates entgegennimmt, erfüllt er seine Aufgabe nicht. Der Wert liegt in den getroffenen Entscheidungen, nicht in den besuchten Sitzungen.

Wie viele Personen sollten in einem SAP-Lenkungsausschuss sitzen?

Drei bis fünf bei einem kleinen Projekt mit nur einer Abteilung, fünf bis acht im Mittelstand, acht bis zwölf bei einem Konzernprogramm. Der übliche Fehler sind zu viele Personen: Ein Ausschuss mit 20 Mitgliedern wird zum Präsentationspublikum. Jedes Mitglied sollte über etwas echte Entscheidungsbefugnis haben. Holen Sie bei RISE die Delivery-Ansprechpartner von SAP für Plattformthemen dazu, statt sie zu ständigen Mitgliedern zu machen.

Wie verändert RISE with SAP den Lenkungsausschuss?

SAP wird für Infrastruktur und technischen Betrieb zum Beteiligten an der Lieferung. Der Ausschuss braucht deshalb einen direkten Weg zu den zugewiesenen Ansprechpartnern von SAP, der nicht über den Implementierungspartner läuft. Darunter braucht er außerdem eine Clean-Core-Design-Authority für Anpassungsanforderungen, an den Ausschuss eskaliert nur, was geschäftskritisch und blockiert ist. On-Premise bleibt SAP ein Anbieter.

Worin unterscheiden sich Lenkungsausschuss und PMO?

Das Projektmanagementbüro steuert die tägliche Umsetzung: Aufgaben, Risikologs und Koordination über die Workstreams hinweg. Der Lenkungsausschuss trifft die Entscheidungen, die das PMO nicht treffen kann: Budgetverschiebungen, Änderungen am Umfang und Go/No-go. In größeren Organisationen sitzt über mehreren Projekten ein Gremium auf Portfolioebene, das Ressourcen zwischen ihnen verteilt.

Was gehört auf die Agenda eines Lenkungsausschusses?

Entscheidungen, nicht Updates. Beginnen Sie mit den drei bis fünf größten Risiken, dann den konkreten Entscheidungen, die eine Freigabe brauchen, dann den abteilungsübergreifenden Themen, die zu lösen sind, dann den Maßnahmen aus der letzten Sitzung mit Verantwortlichen und Terminen. Taucht ein Punkt dreimal ohne Lösung auf, eskalieren Sie, wie damit umgegangen wird, statt ihn erneut zu besprechen.

Wann sollte der Lenkungsausschuss den Go-live verschieben?

Wenn die Tests nicht abgeschlossen sind, Key User nicht geschult sind, die Datenmigration nicht abgestimmt ist, eine kritische Schnittstelle instabil läuft oder der Rollback-Plan ungetestet ist. Eine Verschiebung ist fast immer günstiger als das Aufräumen nach dem Go-live. Eine Verzögerung von sechs Wochen lässt sich aufholen; ein gescheiterter Go-live, der die Lieferkette oder den Finanzabschluss stört, kann Monate brauchen, bis sich alles stabilisiert.