SAP-Stakeholder-Management: Konflikte verhindern, bevor sie entstehen

Stakeholder-Management in SAP entscheidet darüber, ob ein Programm pünktlich endet oder sein letztes Quartal im Streit verbringt. Es läuft auf vier Gewohnheiten hinaus. Erfassen Sie, wer zählt und was jede Gruppe beschäftigt. Schreiben Sie auf, wer was entscheiden darf. Führen Sie einen Kommunikationsrhythmus, der zur SAP-Activate-Phase passt. Halten Sie jede wesentliche Entscheidung samt Alternativen fest. Dieser Leitfaden richtet sich an Programmleiter, PMOs und Sponsoren in S/4HANA-Programmen. Nutzen Sie die Rollentabelle und den phasenweisen Rhythmus unten, um Ihren Einbindungsplan vor dem ersten Workshop aufzusetzen.

Ich habe einmal an einem SAP-Rollout gearbeitet, bei dem die IT strikte Systemkontrollen wollte und der Finanzbereich mehr Flexibilität brauchte. Als wir dazukamen, sprachen die beiden Teams nicht mehr miteinander. Der Finanzbereich war frustriert. Die IT ging in Abwehrhaltung. Die Leitung wollte wissen, warum niemand miteinander kommunizierte.

Wir erstellten eine Rollenlandkarte, führten regelmäßige Abstimmungsrunden ein und schufen eine zentrale Quelle der Wahrheit für Entscheidungen. Hätte man diese Grundlagen von Anfang an gelegt, hätten wir uns Monate des Streits erspart.

Das Muster gilt weit über dieses Programm hinaus. Die Technik scheitert selten von allein. Programme scheitern, wenn Entscheidungen nicht getroffen und Erwartungen nie gesetzt wurden. Sie scheitern, wenn Kommunikation von persönlichen Beziehungen statt von einem Rhythmus abhängt und wenn Konflikte, die auf die Arbeitsebene gehörten, Wochen zu spät bei der Leitung ankommen.

Nicht jeder in einem SAP-Programm hat dieselben Anliegen oder denselben Einfluss. Behandeln Sie alle als ein Publikum, und Sie versenden irrelevante Updates und übersehen die echten Risiken.

Rolle	Was sie beschäftigt	Wie Sie sie einbinden
Executive Sponsor (CEO, COO, Konzern-CFO)	Rendite, Geschäftsrisiko, Glaubwürdigkeit des Programms	Direkt, regelmäßig, kurz
Lenkungsausschuss (CIO, CFO, Leiter der Geschäftsbereiche)	Termin, Budget, Scope	Strukturierte Lenkungsausschuss-Reviews mit Entscheidungen
Finanzleitung (CFO, Controller)	Umsatzrealisierung, Integrität der Berichterstattung, Kontrollen	Frühe Einbindung in das Design; Freigabe des FI/CO-Scopes
Operations und Fachbereichsleiter	Prozesskontinuität, Schulung, Benutzerfreundlichkeit	Design-Workshops; Verantwortung für den Benutzerabnahmetest (UAT)
IT-Leitung (CIO, Leiter Architektur)	Architektur, Sicherheit, Integration, Support	Freigabe des technischen Designs
Prozessverantwortliche (Business Process Owner)	Prozessgenauigkeit, Ausnahmen, Sonderfälle	Leiten Design-Workshops; geben die Konfiguration frei
Endanwender	Lernkurve, tägliche Arbeit, Veränderungen der eigenen Aufgaben	Schulung und Change Management
Systemintegrator (SI)	Leistungsumfang, Change Requests, Ressourcenbesetzung	Formale Governance und Scope-Dokumente
HR und Change Management	Auswirkungen auf Mitarbeitende, Rollenänderungen, Kommunikation	Ein zum Projekt paralleler Workstream

Die Macht-Interessen-Matrix zeigt Ihnen, wo Sie Aufwand investieren sollten. CIO, CFO und Sponsor liegen bei beiden Achsen hoch: Sie genehmigen Änderungen, verschieben das Go-live und teilen Personal zu, und wenn sie sich zurückziehen, verliert das Programm seinen Rückhalt. Prozessverantwortliche, Controller und Architekten haben hohes Interesse und weniger formale Macht, aber ihr Wissen darüber, wie das Geschäft wirklich läuft, macht sie im Design unverzichtbar. Mitglieder des Boards und Führungskräfte außerhalb des Programms brauchen Briefings zu Meilensteinen, keine wöchentlichen Updates. Endanwender haben wenig Einfluss und die größte Betroffenheit: Ihre Akzeptanz beim Go-live entscheidet, ob das System in der Praxis funktioniert.

Einfluss auf das ErgebnisHochMittelNiedrig

• Board, Führungskräfte außerhalb des Programms

• Sponsor, CFO, CIO

• Prozessverantwortliche
• Controller, Architekten

• Endanwender

NiedrigMittelHochWie stark das Programm sie betrifft

Die wirksamste Einbindung findet statt, bevor sich jemand beschwert. Legen Sie zum Kick-off drei Dinge fest.

Entscheidungsrechte

Wer darf eine Scope-Änderung genehmigen? Wer gibt den UAT frei? Wer darf eine Verschiebung des Go-live in den Lenkungsausschuss bringen? Schreiben Sie es auf, lassen Sie es unterzeichnen und nehmen Sie es in die Projekt-Charter auf. Wird mitten im Projekt eine Entscheidung angefochten, verweisen Sie auf dieses Dokument.

Ohne es gewinnt bei strittigen Entscheidungen, wer am lautesten ist oder das Ohr des Sponsors hat. Beides ist keine Governance, und beides sät Groll. Mein Leitfaden zum Erstellen einer SAP-Projekt-Charter beschreibt, was der Abschnitt zu den Entscheidungsrechten enthalten sollte.

Kommunikationsrhythmus

Legen Sie zum Kick-off fest, wie oft das Programm kommuniziert, über welchen Kanal und mit welchem Inhalt. Lenkungsausschuss alle zwei Wochen. Workstream-Leiter wöchentlich. Endanwender zu Meilensteinen, mit Hinweisen auf Schulungen. Wenn Menschen nur dann vom Programm hören, wenn etwas schiefläuft, nehmen sie an, dass es immer in Schwierigkeiten steckt.

Scope-Baseline

Schreiben Sie auf, was im Scope liegt und was ausdrücklich nicht. Ausschlüsse sind so wichtig wie Einschlüsse, denn jede ungeklärte Grenze ist ein künftiger Konflikt. Nehmen Sie eine Person aus der Finanzleitung, die davon ausgeht, dass das Spesenmanagement im Scope liegt, und in Realize erfährt, dass es nicht so ist. Diese Person wird für den Rest des Programms schwierig sein, nicht weil sie von Natur aus schwierig ist, sondern weil das Programm ein stillschweigendes Versprechen gebrochen hat.

Die Anforderungen an die Einbindung ändern sich, während das Programm durch die SAP-Activate-Phasen läuft. Was in Explore funktioniert, funktioniert in Deploy nicht. Nutzen Sie diese Tabelle als Rückgrat Ihres Einbindungsplans:

Phase	Schwerpunkt der Einbindung	Rhythmus	Wer führt
Discover und Prepare	Rollenlandkarte, Governance-Struktur, Sponsor-Briefings, erste Abstimmungstermine mit Finanzwesen, Operations und IT	Sponsor-Briefing zu Beginn; Lenkungsausschuss wird eingerichtet	Programmleiter
Explore	Fit-to-Standard-Workshops mit Fachbereichsleitern und Prozessverantwortlichen; Fit-Gap-Entscheidungen werden vor der Freigabe geprüft	Wöchentliche Arbeitssitzungen; Lenkungsausschuss zum Phasenabschluss	Solution Architect und Prozessverantwortliche
Realize	UAT-Vorbereitung; Zeit der Fachbereichsleiter für Tests schützen; Status zu Fehlern und Datenmigration	Lenkungsausschuss alle zwei Wochen; Workstream-Leiter wöchentlich	Programmmanager
Deploy	Cutover-Bereitschaft, Go/No-go-Kriterien vor Cutover-Start vereinbart	Tägliche Cutover-Stand-ups; Go/No-go-Briefing für die Geschäftsleitung	Leiter Geschäftsbetrieb, unterstützt von IT und SI
Run	Hypercare-Kommunikation, Meldekanäle für Störungen, Stabilisierungs-Reviews	Zwei Wochen täglich, danach wöchentlich; Reviews nach 30, 60 und 90 Tagen	Support-Leiter und Prozessverantwortliche

Zwei Phasen machen die meisten Probleme. In Explore führen die falschen Leute im Raum dazu, dass Entscheidungen in Realize wieder aufgemacht werden, nachdem die Konfiguration begonnen hat. In Realize ist ein häufiges Muster, dass die UAT-Verantwortlichen nicht verfügbar oder nicht vorbereitet sind. Beheben Sie das im Plan während Explore, nicht zwei Wochen vor Testbeginn.

Das traditionelle Modell hatte drei Parteien: den Kunden, den SI und die Sponsoren. Bei RISE with SAP kommt SAP als Beteiligter an der Umsetzung hinzu. SAP betreibt Infrastruktur und technischen Betrieb, und das Customer-Success-Team verfolgt Nutzung und Wertbeitrag. Daraus folgen drei Änderungen an der Governance.

1. Ein Forum für die Prüfung von Erweiterungen. Jede Lücke braucht eine Entscheidung: konfigurieren, über freigegebene APIs erweitern (On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP) oder ablehnen. In S/4HANA Cloud Public Edition ist eine Modifikation des Kerns nicht möglich. In der Private Edition schon, aber jede Modifikation bringt zusätzlichen Aufwand bei Upgrades. Ein kleines Forum unterhalb des Lenkungsausschusses, in dem ein Architekt entscheidungsbefugt ist, verhindert, dass jede Diskussion über Kundenanpassungen im Lenkungsausschuss landet. Wer darauf verzichtet, sieht die technischen Schulden beim ersten größeren Upgrade.
2. Ein Customer-Success-Rhythmus mit SAP. Das Team von SAP kümmert sich um Nutzung, BTP-Verbrauch und Roadmap. Dieser Rhythmus läuft parallel zur Governance der Einführung und geht nach dem Go-live weiter. Binden Sie ihn in Ihre Governance ein, statt ihn getrennt zu führen.
3. Ein Eskalationsweg zu SAP. Wenn auf Plattformebene etwas ausfällt, muss der CIO wissen, wen er bei SAP anrufen kann, nicht nur beim Partner. Klären Sie Ansprechpartner und Service Levels, bevor Sie unterschreiben.

GROW-with-SAP-Programme auf der Public Edition brauchen dieselben drei Elemente in leichterer Form: weniger Entscheidungen zu Erweiterungen, weil es weniger Spielraum zum Erweitern gibt, einen stärker standardisierten Success-Rhythmus und eine Eskalation, die meist zuerst über den Partner läuft. On-Premise-Programme behalten das traditionelle Modell, mit SAP als Anbieter statt als Beteiligtem.

KI-Werkzeuge helfen beim Papierkram der Einbindung, nicht bei den Beziehungen.

Meeting-Zusammenfassungen sind der klarste Gewinn. Microsoft Copilot macht aus einer aufgezeichneten Lenkungsausschuss-Sitzung einen Protokollentwurf, der eine kurze Durchsicht statt einer langen Ausarbeitung braucht. Die erfassten Entscheidungen stimmen meist, weil das Werkzeug mit dem Transkript arbeitet statt mit der Erinnerung.

Entscheidungsprotokolle kommen an zweiter Stelle. Die KI-Funktionen von Confluence, die jetzt unter der Marke Rovo von Atlassian laufen, können Besprechungsnotizen in strukturierte Einträge im Entscheidungsprotokoll verwandeln, sobald Sie eine Vorlage aufgebaut haben.

Das Entwerfen von Anforderungen hilft in Explore. SAP Cloud ALM kann Anforderungen aus Transkripten von Fit-to-Standard-Workshops entwerfen. Jede Zeile muss weiterhin von einer Person validiert werden.

Stimmungsanalyse ist in Programmen mit weniger als 100 Personen meist Theater. Das Signal ist schwach, Fehlalarme sind häufig, und der Eindruck, Stimmungen zu überwachen, hat einen echten politischen Preis. In sehr großen Programmen kann sie Gruppen, die sich zurückziehen, früh erkennen. Für die meisten Programme geben Sie das KI-Budget besser anderswo aus.

Widerstand gegen SAP hat fast immer einen nachvollziehbaren Grund. Wer sich sperrt, schützt meist etwas: einen Workaround, der eine Lücke im Altsystem schließt, eine manuelle Kontrolle, die der Standardprozess nicht zeigt, oder die Sorge, ob das eigene Team die Veränderung verkraften kann. Finden Sie diesen Grund, bevor Sie reagieren. Gehen Sie auf das zugrunde liegende Anliegen ein, und der Widerstand verschwindet meist ohne Konfrontation.

„Wir brauchen diese Anpassung“

Meist schützt das einen Prozess, der heute funktioniert und dem die Person nicht zutraut, dass Standard-SAP ihn abbildet. Gehen Sie den Standardprozess durch und fragen Sie, wo genau er versagt. Oft ist das Anliegen ein Sonderfall, den die Konfiguration abdecken kann. Manchmal ist es berechtigt. Sie finden es nur im Gespräch heraus, und unter Clean Core steht mehr auf dem Spiel, denn die Antwort entscheidet, ob Sie eine Erweiterung bauen und pflegen.

„Wir sind nicht bereit für das Go-live“

Nehmen Sie das ernst. Sagt die Fachbereichsleitung, sie sei nicht bereit, hat sie meist einen Grund: Datenqualität, unvollständige Schulung, ein ungetesteter Prozess. Finden Sie das konkrete Anliegen. Ist es berechtigt, sollte es das Go-live verschieben. Ist es Angst statt Evidenz, beantworten Sie sie mit gezielter Vorbereitung, nicht mit einem neuen Termin.

Die häufigste Variante: Der UAT hat Probleme aufgedeckt, die nicht behoben sind. Wer trotzdem weitermacht, verlagert das Problem vom UAT in den Produktivbetrieb. Eine Verzögerung von zwei Wochen kostet meist weit weniger als eine Hypercare-Phase, die mit Problemen verbracht wird, die schon vor dem Go-live bekannt waren.

„Niemand hat uns über diese Änderung informiert“

Das ist ein Kommunikationsversagen. Die Person stand auf dem Verteiler, war aber nicht in der Design-Sitzung, oder die Änderung stand in einem Dokument, das sie nie gelesen hat. Streiten Sie nicht darüber, wer was kommuniziert hat. Entschuldigen Sie sich, gehen Sie die Änderung gemeinsam durch, nehmen Sie die Person in künftige Design-Reviews ihres Bereichs auf und schließen Sie die Lücke im Einbindungsplan.

Wächst ein Konflikt über die Arbeitsebene hinaus, zählen drei Dinge.

Halten Sie ihn innerhalb der Governance. Ein Streit zwischen Finanzbereich und IT über Systemzugriff gehört in den Lenkungsausschuss und wird nicht informell von dem gelöst, der hartnäckiger ist. Die informelle Lösung struktureller Konflikte erzeugt Groll und wieder aufgemachte Entscheidungen.

Rahmen Sie ihn in geschäftlichen Begriffen. Wenn Finanzbereich und IT über Zugriffskontrolle streiten, ist das Politik. Wenn Finanzbereich und IT das Sicherheitsrisiko gegen die operativen Kosten darstellen, ist es eine geschäftliche Entscheidung, die der Lenkungsausschuss treffen kann. Das eine in das andere zu übersetzen, ist die Aufgabe des Programmmanagers oder des SI-Leiters, je nach Vertrag.

Halten Sie jede wesentliche Entscheidung fest. Was wurde entschieden, von wem, wann und welche Alternativen wurden erwogen. In sechs Monaten sagt jemand: „Dem haben wir nie zugestimmt.“ Wenn der Lenkungsausschuss fragt, warum eine Konfiguration gewählt wurde, oder ein Neuling eine frühere Entscheidung infrage stellt, brauchen Sie das Protokoll und keine Rekonstruktion aus dem Gedächtnis. Ein gemeinsames Entscheidungsprotokoll, wöchentlich aktualisiert und im Lenkungsausschuss geprüft, kostet fast nichts und spart sehr viel.

Wenn das Postfach des Programmmanagers voller dringender Eskalationen ist, funktioniert der Plan nicht. Gesunde Programme laufen über strukturierte Entscheidungen, nicht über tägliches Feuerlöschen.

Gesunde Signale: Lenkungsausschuss-Sitzungen bringen Entscheidungen statt Vertagungen; Fachbereichsleiter nehmen an Workshops und UAT teil, ohne dass man ihnen hinterherlaufen muss; Scope-Änderungen kommen über den Änderungsprozess; Probleme nach dem Go-live kommen über definierte Kanäle; das Entscheidungsprotokoll ist aktuell und wird im Lenkungsausschuss herangezogen.

Warnsignale: Menschen wenden sich außerhalb der Governance-Struktur an den Programmmanager; Fachbereichsleiter geben Liefergegenstände frei, ohne sie zu lesen, und fechten sie später an; der Sponsor ist zwischen den Sitzungen des Lenkungsausschusses nicht erreichbar; Personen, die das Design ausgelassen haben, stellen den Change Freeze infrage; derselbe Konflikt taucht in drei Lenkungsausschuss-Sitzungen hintereinander auf.

Treten Warnsignale auf, drücken Sie nicht stärker auf den bestehenden Plan. Finden Sie heraus, welches Element versagt (Rhythmus, Entscheidungsbefugnis, Kommunikation oder Dokumentation), und beheben Sie genau dieses. Mehr E-Mails und mehr Meetings machen es schlimmer. Zum Lenkungsausschuss selbst finden Sie meinen Leitfaden zum Aufbau eines wirksamen SAP-Lenkungsausschusses, und zur menschlichen Seite des Go-live meine Hinweise zum SAP-Change-Management.

Was ist Stakeholder-Management in einer SAP-Einführung?

Es ist die strukturierte Arbeit, zu erkennen, wer Einfluss auf das Programm hat oder daran interessiert ist, ihre Anliegen zu verstehen, Kommunikation und Entscheidungsfindung aufzusetzen und alle vom Kick-off bis zur Hypercare eingebunden zu halten.

SAP berührt Finanzwesen, HR, Einkauf, Operations und IT zugleich, und jeder Bereich hat andere Prioritäten und anderen Einfluss. Wer sie als ein Publikum behandelt, erzeugt generische Updates und übersieht die Anliegen, die Widerstand auslösen. SAP Activate verankert das in jeder Phase: Workshops in Explore, UAT-Verantwortung in Realize und Bereitschafts-Reviews in Deploy hängen alle von vorbereiteten Beteiligten aus den Fachbereichen ab.

Wie erstellen Sie eine Rollenlandkarte für ein SAP-Projekt?

Tragen Sie jede Person oder Gruppe auf zwei Achsen ein: Einfluss auf das Ergebnis und Grad der Betroffenheit durch das Programm. Sponsor, CFO und CIO liegen bei beiden hoch und brauchen direkten, regelmäßigen Kontakt. Controller, Prozessverantwortliche und Architekten haben hohes Interesse und müssen im Design dabei sein. Führungskräfte außerhalb des Programms brauchen Briefings zu Meilensteinen. Endanwender brauchen gezielte Kommunikation darüber, was sich für sie ändert, wann geschult wird und wo sie Hilfe bekommen.

Halten Sie die Landkarte aktuell. Menschen wechseln Rollen, Einfluss verschiebt sich, wenn das Programm sichtbar wird, und neue Beteiligte kommen hinzu, wenn der Scope wächst.

Was gehört in einen SAP-Einbindungsplan?

Ein Rollenregister (Name, Funktion, Einfluss, Interesse, Hauptanliegen), ein Kommunikationsplan (Kanal, Häufigkeit und Inhalt je Gruppe), Entscheidungsrechte für Scope-Änderungen, Designentscheidungen und Go-live-Bereitschaft, Aktivitäten für jede Activate-Phase, ein Eskalationsweg für strittige Entscheidungen und eine Möglichkeit, Bedenken formal vorzubringen.

Aktualisieren Sie ihn an jedem Phasen-Gate. Dokumentieren Sie ihn so gut, dass das Team ihn betreiben kann, ohne dass der Programmmanager jede Interaktion persönlich führt, denn das skaliert nicht über dreißig namentlich geführte Beteiligte hinaus.

Wie gehen Sie mit Widerstand von Fachbereichsleitern gegen SAP um?

Finden Sie zuerst die Quelle. Häufig sind es die Sorge, dass der neue Prozess einen wichtigen Sonderfall übersieht, die Angst vor Produktivitätsverlust und das Gefühl, bei Entscheidungen außen vor zu sein. Prozessbedenken gehören in eine Design-Sitzung. Produktivitätsängste brauchen realistische Schulung und klare Hypercare-Unterstützung. Ausgrenzung ist ein Kommunikationsversagen, das Sie beheben, nicht ausdiskutieren.

Widerstand ohne nachvollziehbaren Grund ist schwieriger. Der Hebel ist meist der Sponsor, der deutlich machen muss, dass die Leitung hinter dem Programm steht. Durchdrücken, ohne den Widerstand anzugehen, ist die schlechteste Option: Die Bedenken kehren im UAT zurück.

Wie gehen Sie mit Konflikten zwischen Finanzbereich und IT in einem SAP-Programm um?

Die meisten laufen auf eine von drei Spannungen hinaus: Zugriff gegenüber Funktionstrennung, Flexibilität im Reporting gegenüber Data Governance oder Tempo der Integration gegenüber Sicherheitsprüfung.

Benennen Sie die Spannung präzise. „Der Finanzbereich will, dass Controller Lesezugriff auf Fertigungsaufträge im Produktivsystem für das Reporting haben, und die IT sieht darin eine Verletzung der Funktionstrennung“ lässt sich lösen; „Der Finanzbereich will Flexibilität“ nicht. Bringen Sie es mit den Optionen und ihren Risiken in den Lenkungsausschuss. Halten Sie dann die Entscheidung und die Alternativen fest, denn diese Streitfälle kehren zurück, wenn sich Personen ändern. Kann der Lenkungsausschuss es nicht lösen, geht es an den Sponsor. Das ist Governance, die wie vorgesehen funktioniert.

Wie verändert RISE with SAP das Stakeholder-Management?

SAP wird vom bloßen Anbieter zum Beteiligten. Sie brauchen ein Forum für die Prüfung von Erweiterungen, das entscheidet, wie jede Lücke unter Clean Core behandelt wird, einen Platz in Ihrer Governance für den Customer-Success-Rhythmus von SAP und einen dokumentierten Eskalationsweg zu SAP für Plattformprobleme, der nicht vom Partner abhängt. Klären Sie Ansprechpartner und Service Levels vor der Unterschrift.