SAP-Risikobewertung: die praxistaugliche Version

Eine SAP-Projektrisikobewertung listet auf, was das Programm aus der Bahn werfen könnte, und bewertet jedes Risiko nach Wahrscheinlichkeit und Auswirkung. Jedes Risiko bekommt genau einen benannten Verantwortlichen und eine Reaktion, die vor dem Eintritt vereinbart wird, und die Liste wird jede Woche überprüft. Die Risiken, an denen SAP-Programme scheitern, sind selten Überraschungen: Datenmigration, Integration, Verfügbarkeit von Mitarbeitern, schleichende Ausweitung des Umfangs und Akzeptanz. Dieser Leitfaden richtet sich an Programmmanager und Sponsoren, die ein Risikoregister wollen, das Entscheidungen verändert, statt in einem Ordner zu liegen. Er liefert Ihnen eine bewertete Matrix, eine Registervorlage, drei öffentlich bekannte Fehlschläge als Praxisbeispiele und die Risiken, die RISE with SAP und Clean Core hinzufügen. Beginnen Sie damit, jedem Risiko, das Sie schon haben, einen benannten Verantwortlichen zuzuordnen.

Die meisten SAP-Risikobewertungen werden vor dem ersten Lenkungsausschuss erstellt, einmal geprüft und nie wieder angefasst. Das ist kein Risikomanagement. Das ist ein Dokument.

Ich habe erlebt, wie Risiken ignoriert wurden, weil es zu unangenehm war, sie früh anzusprechen. Dieses Schweigen kostet fast immer später mehr. Was als kleines Integrationsproblem in der Materialwirtschaft (MM) beginnt, blockiert plötzlich das Finanzwesen. Ein Bericht, der im Test gut aussah, bricht nach einem Systemupdate. Das habe ich mehr als einmal erlebt.

Die Risiken waren keine Überraschungen. Sie waren dokumentiert. Niemand handelte danach.

Umfang. Das Projekt startet mit Standardmodulen. Dann fügt jemand „nur noch einen Bericht“ hinzu, dann ein Dashboard, dann ein paar Erweiterungen. Gefährlich sind Änderungen des Umfangs, die informell in Workshops, E-Mails und Flurgesprächen entstehen und von denen der Projektleiter erst erfährt, wenn die Konfiguration abgeschlossen ist. Mein Leitfaden zum Vermeiden von Scope Creep behandelt die Kontrollen.

Ressourcen. Der Architekt wird für ein Produktionsproblem abgezogen. Ein wichtiger Entwickler geht. Fachanwender verpassen Testzyklen, weil ihr Tagesgeschäft nicht stehen bleibt. Lassen Sie sich Verfügbarkeiten schriftlich geben. Mündliche Zusagen verdunsten unter Personaldruck.

Technik. Feldzuordnungen, die nie gegen die Zielstruktur validiert wurden. Schnittstellen, die den Modultest bestehen und bei echtem Transaktionsvolumen brechen. Eigencode, der bis zur Produktivlast gut aussieht. Das ist vorhersehbar, wenn man weiß, wo man hinschauen muss.

Zeitplan. Ein verspäteter Blueprint drückt auf die Tests, aber der Go-live-Termin bleibt fest. UAT, Schulung und Datenvorbereitung werden gehetzt. Dasselbe Muster zeigt sich bei fast jedem Programm, das ein Phase-Gate verpasst und den nachgelagerten Plan nicht verschiebt.

Akzeptanz. Menschen lehnen ab, was sie nicht verstehen. Schwache oder späte Schulung erzeugt Behelfslösungen, Behelfslösungen verschlechtern die Daten, und dem System wird ein Versagen des Change-Managements angelastet.

Diese Fälle sind öffentlich und gut dokumentiert. Die Muster wiederholen sich in jeder Größenordnung.

Lidl: rund 500 Millionen Euro in sieben Jahren

Lidl startete sein Projekt eLWIS auf SAP for Retail 2011, ging in einigen kleineren Ländern live und stoppte es 2018 bei gemeldeten Kosten von rund 500 Millionen Euro. Eine breit berichtete Ursache: Lidl bewertete Bestände zu Einkaufspreisen, während das SAP-Standardmodell für den Handel Verkaufspreise verwendet. Lidl passte das System an, statt die Praxis zu ändern, und erklärte, die ursprünglichen Ziele ließen sich mit vertretbarem Aufwand nicht erreichen.

Lehre: Eine Abweichung zwischen Ihrem Datenmodell und dem SAP-Standard ist ein Risiko der ersten Woche, keine Entdeckung im fünften Jahr.

HP: rund 400 Millionen US-Dollar entgangener Umsatz

2004 migrierte HP einen Teil seines Servergeschäfts auf ein konsolidiertes SAP-basiertes Auftrags- und Lieferkettensystem. Aufträge fielen zwischen dem alten Frontend und SAP durch und erforderten Handarbeit, und der Auftragsrückstand verdoppelte sich. HPs CEO sagte, die Probleme hätten die Server- und Speichersparte rund 400 Millionen US-Dollar Umsatz und 275 Millionen US-Dollar operativen Gewinn gekostet, bei einem Rückstand von 120 Millionen US-Dollar. HPs CIO sagte später, das Team habe mit drei Wochen Störung geplant und hätte Reserven für vier bis sechs Wochen gebraucht.

Lehre: Dimensionieren Sie die Reserve für einen schlechten Cutover, nicht für einen durchschnittlichen, und bauen Sie Bestands- oder Vertriebskanalpuffer auf, bevor Sie umschalten.

Nike: mehr als 100 Millionen US-Dollar entgangener Umsatz

2000 ging Nike vor seinem SAP-ERP-Programm mit der Demand-Planning-Software von i2 live. Die Software war stark an die Altsysteme von Nike angepasst, lief langsam und stürzte unter dem Produktvolumen ab. Sie bestellte von manchen Schuhen zu viele und von anderen zu wenige. Nike verlor mehr als 100 Millionen US-Dollar Umsatz, und der Aktienkurs fiel um etwa 20 %. Später verlagerte Nike die kurz- und mittelfristige Planung in SAP.

Lehre: Nehmen Sie nie an, dass eine Integration funktioniert, bevor sie mit Produktionsvolumen und echten Daten gelaufen ist.

Eine auf Annahmen gebaute Bewertung ist schlechter als keine, weil sie falsche Sicherheit erzeugt. Sechs Eingaben zählen:

1. Umfangsdokumentation: Projektcharta, freigegebener Umfang und unterzeichnete Anforderungen. Fehlen sie, ist das Umfangsrisiko bereits hoch.
2. Ressourcenzusagen: schriftliche Zusagen der Abteilungsleiter, eine Skill-Matrix für kritische Rollen und eine benannte Vertretung für jede Schlüsselposition.
3. Budget und Zeitplan: genehmigtes Budget mit Reserve und ein Zeitplan, der mit vergleichbaren Programmen abgeglichen wurde. Sechs Monate und minimale Mittel für einen vollständigen Rollout sind ein Risiko, das Sie jetzt benennen sollten.
4. Zusagen der Anbieter: Verträge mit Service-Levels und Vertragsstrafen. Bei RISE die Pflichten von SAP und der Eskalationsweg.
5. Technische Landschaft: Kompatibilität mit Altsystemen, Komplexität der Datenmigration, Bereitstellungsmodell und ein Clean-Core-Plan für alle Eigenentwicklungen.
6. Protokolle früherer Projekte: Risikoregister, Issue-Logs und Post-Mortems früherer SAP- oder ERP-Programme. Die meisten Risiken sind nicht neu.

Bewerten Sie jedes Risiko nach Wahrscheinlichkeit und Auswirkung von 1 bis 5 und multiplizieren Sie. Das Beispiel unten ist ein typischer Ausgangspunkt für ein S/4HANA-Programm; Ihre Werte werden abweichen.

Risiko	Wahrscheinlichkeit (1 bis 5)	Auswirkung (1 bis 5)	Wert	Priorität
Scheitern der Datenmigration	4	5	20	Hoch
Verzögerungen bei der Integration	4	4	16	Hoch
Ressourcenengpässe	4	4	16	Hoch
Budgetüberschreitung	3	5	15	Mittel
Eigencode im Core blockiert Upgrades	3	5	15	Mittel
Scope Creep	4	3	12	Mittel
Lücken in der Testabdeckung	3	4	12	Mittel
Performance bei Spitzenlast	3	4	12	Mittel
Compliance-Lücken	2	5	10	Mittel
Kein Eskalationsweg zu SAP (RISE)	2	5	10	Mittel
Geringe Nutzerakzeptanz	3	3	9	Mittel
Kostenrisiko durch Abonnement oder Lizenz	2	4	8	Mittel
KPIs werden nicht verfolgt	3	2	6	Niedrig

Werte ab 16 brauchen einen benannten Verantwortlichen und sofortiges Handeln. Werte von 8 bis 15 brauchen Beobachtung mit einem definierten Eskalationsauslöser. Unter 8 bleibt das Risiko im Register, ohne dass Sie vorrangig Zeit darauf verwenden. Werte sind ein Ausgangspunkt, kein Urteil: Eine Compliance-Lücke mit dem Wert 10 kann in einer regulierten Branche zu 25 werden.

Ein Wert allein ändert nichts. Jedes Risiko braucht diese Felder, ausgefüllt.

Feld	Was eingetragen wird	Beispiel
Risiko	Das Ereignis in einem Satz	Die Lieferantenstammdaten sind vor Mock-Load 2 nicht bereinigt
Verantwortlicher	Eine benannte Person	Leiter Kreditorenbuchhaltung
Wert	Wahrscheinlichkeit × Auswirkung	4 × 5 = 20
Auslöser	Der messbare Punkt, an dem Sie handeln	Dublettenquote über 5 % im Extrakt von Mock-Load 1
Reaktion	Vermeiden, mindern, übertragen oder akzeptieren, mit der Maßnahme	Mindern: zwei Kreditorenbuchhalter drei Wochen lang für die Bereinigung
Nächste Überprüfung	Datum	Risikoreview am kommenden Montag
Status	Offen, in Bearbeitung, geschlossen	In Bearbeitung

Beziffern Sie die Kosten, wo Sie können. „Hohes Risiko“ ist vage. „Eine einwöchige Verzögerung beim UAT kostet rund sechsstellig an Teamzeit und kann den Go-live um drei Wochen verschieben“ erregt Aufmerksamkeit.

Eigencode ist eine eigene Risikokategorie. In S/4HANA Cloud Public Edition ist Eigencode im Core nicht möglich. Erweiterungen laufen über SAP BTP, freigegebene APIs oder Key-User-Tools. In der Private Cloud und On-Premise können Sie den Core weiterhin verändern, und Partner, die das gewohnt sind, werden es tun. Diese technische Schuld tritt beim ersten großen Upgrade zutage. Verfolgen Sie, für wie viele identifizierte Anpassungen es einen vereinbarten Clean-Core-Ansatz gibt, prüfen Sie die BTP-Erweiterungserfahrung des Partners und richten Sie bis zum Ende von Explore ein Review-Gremium ein.

RISE ändert, wer die Verfügbarkeit verantwortet. SAP betreibt die Infrastruktur, das Risiko verschiebt sich also von „unser Team verantwortet die Verfügbarkeit“ zu „SAP verantwortet sie, und wir brauchen einen schnellen Weg zu SAP, wenn etwas ausfällt“. Halten Sie die benannten Ansprechpartner bei SAP, den Eskalationsweg und die Service-Levels fest, dazu einen vor dem Go-live vereinbarten Incident-Plan. Ohne sie bleiben Probleme, die zu SAP gehören, zu lange im Projektteam hängen.

KI hilft bei der Schreibarbeit, nicht beim Urteilen. Joule-basierte Assistenten in SAP Cloud ALM und Werkzeuge wie Microsoft Copilot können Registereinträge und Unterlagen für den Lenkungsausschuss aus Statusberichten, Fehlerlisten und Protokollen entwerfen. Das beschleunigt die Pflege des Registers in Programmen mit sauberen Quelldaten. Es findet Risiken, die in den Daten schon sichtbar sind. Es entscheidet nicht, welche Risiken Handeln verdienen, bringt Verantwortliche nicht zum Handeln und eskaliert nicht die Risiken, die die Führung lieber ignoriert.

1. Risiken über alle fünf Kategorien identifizieren. Führen Sie Workshops mit IT, Fachbereich und Anbietern durch; jeder sieht andere Risiken. Beziehen Sie bei RISE die Ansprechpartner von SAP in mindestens einen ein. Die Risiken, die Teams meist übersehen: IT und Fachbereich erwarten Unterschiedliches, schlecht definierte externe Integrationen, UAT-Verantwortliche, die nicht verfügbar sind, und informelle Umfangsänderungen.
2. Jedes Risiko bewerten nach Wahrscheinlichkeit und Auswirkung, wo möglich mit echten Zahlen.
3. Jedem Risiko einen Verantwortlichen zuordnen. Eine Person, kein Team. Ohne Verantwortlichen keine Verfolgung, keine Lösung.
4. Die Reaktion festlegen, bevor das Risiko eintritt. Vermeiden, mindern, übertragen oder akzeptieren. „Beobachten und reagieren“ ist kein Plan. Es ist eine aufgeschobene Entscheidung.
5. Wöchentlich überprüfen. Offene Risiken prüfen, neue aufnehmen, neu bewerten, wo sich Bedingungen geändert haben, und alles eskalieren, was seinem Auslöser nahekommt. Bringen Sie die wichtigsten Risiken mit einem Entscheidungsvorschlag statt einer Ampelfarbe in den Lenkungsausschuss.

1. 01IdentifizierenAlle fünf Kategorien
2. 02BewertenWahrscheinlichkeit × Auswirkung, 1 bis 5
3. 03Verantwortlichen zuordnenEine Person, kein Team
4. 04Reaktion festlegenVermeiden, mindern, übertragen oder akzeptieren
5. 05Wöchentlich überprüfenNeu bewerten, nahe am Auslöser eskalieren

16 oder mehr: ein benannter Verantwortlicher und Maßnahmen noch diese Woche

Was ist eine Risikobewertung in einem SAP-Projekt?

Das ist der Prozess, in dem man identifiziert, was schiefgehen könnte, jedes Risiko nach Wahrscheinlichkeit und Auswirkung bewertet, jedem einen Verantwortlichen gibt und eine Reaktion vereinbart, bevor es eintritt. SAP-Programme führen mehrere Module, Integrationen, eine Datenmigration, ein Veränderungsprogramm und einen festen Go-live gleichzeitig, informelles Risikomanagement trägt deshalb nicht. Eine kurze Liste echter Risiken mit Verantwortlichen schlägt ein langes Dokument, das niemand liest.

Wie baut man eine Risikomatrix für ein SAP-Projekt?

Listen Sie die Risiken über Umfang, Ressourcen, Technik, Zeitplan und Akzeptanz auf, dazu Clean Core und die Eskalation zu SAP bei RISE. Bewerten Sie jedes nach Wahrscheinlichkeit und Auswirkung von 1 bis 5 und multiplizieren Sie. Behandeln Sie 16 und mehr als hoch, 8 bis 15 als mittel und unter 8 als niedrig. Geben Sie jedem mittleren und hohen Risiko einen Verantwortlichen und einen messbaren Auslöser, etwa „liegt der UAT-Abschluss in Woche 16 unter 80 %, wird der Go-live-Termin überprüft“. Bewerten Sie wöchentlich und an jedem Phase-Gate neu.

Was sind die häufigsten Risiken bei SAP-Einführungen?

Das Scheitern der Datenmigration, weil Altdaten fast immer unsauberer sind als geschätzt. Verzögerungen bei der Integration, besonders bei undokumentierten Altschnittstellen und Drittanbietern. Scope Creep, der Tests und Schulungen zusammendrückt. Ressourcenengpässe, etwa abgezogene Schlüsselpersonen oder Anwender, die beim UAT zum Monatsabschluss nicht verfügbar sind. Geringe Akzeptanz durch Schulungen, die Bildschirme zeigen, statt die Arbeit zu simulieren. Bei RISE kommen Eigencode im Core und der fehlende Eskalationsweg zu SAP hinzu.

Wann sollte in einem SAP-Projekt eine Risikobewertung erfolgen?

Vor dem Projektstart, wenn sich strukturelle Risiken wie Abweichungen im Datenmodell oder unrealistische Zeitpläne am günstigsten beheben lassen. Vor jedem Phase-Gate von SAP Activate, denn jede Phase verändert das Risikoprofil. Wann immer sich Umfang, Budget oder Ressourcen ändern. Und wenn ein Risiko zum Problem wird, um zu prüfen, was es sonst noch betrifft. Dazwischen wöchentlich überprüfen.

Wer sollte in einem SAP-Programm die Risiken verantworten?

Die Person, die darauf reagieren kann. Der Datenverantwortliche verantwortet das Risiko der Datenmigration, der technische Architekt das Integrationsrisiko, der Change-Verantwortliche das Akzeptanzrisiko und der Lösungsarchitekt das Clean-Core-Risiko. Bei RISE verantwortet der CIO oder Programmleiter den Eskalationsweg zu SAP. Der Programmmanager verfolgt den Zustand des Registers, verantwortet aber nicht jedes Risiko.

Was passiert, wenn die Risikobewertung bei ERP-Projekten ausgelassen wird?

Im großen Maßstab entstehen Fälle wie Lidl, das sein SAP-Retail-Projekt 2018 nach rund 500 Millionen Euro aufgab. Oder HP, dessen Migration auf das SAP-Auftragssystem 2004 die Server-Sparte rund 400 Millionen US-Dollar Umsatz kostete. Im kleineren Maßstab ist der Mechanismus derselbe: spät entdeckte Abweichungen im Datenmodell, Integrationen, die bei Produktionsvolumen versagen, und Akzeptanzprobleme durch schwache Schulung. Die Risiken ließen sich erkennen, bevor sie zu Problemen wurden.