Sieben Beratungs-Frameworks für die SAP- und KI-Umsetzung

Wenn ein SAP- oder KI-Programm ins Stocken gerät, liegt die Ursache meist in der Struktur, und sieben einfache Frameworks machen sie sichtbar. Erfassen Sie den Ist-Zustand. Legen Sie mit einer RACI-Matrix fest, wer was entscheidet. Verknüpfen Sie die Arbeit mit Geschäftsfähigkeiten. Finden Sie Ursachen mit der Fünf-Warum-Methode. Priorisieren Sie Anforderungen mit MoSCoW. Ordnen Sie Risiken danach, was das Programm tatsächlich stoppen kann. Führen Sie nach jeder Phase ein echtes Post-Mortem durch. Dieser Leitfaden richtet sich an Programmmanager, Berater und Sponsoren in der SAP- und KI-Umsetzung. Beginnen Sie mit der Tabelle unten: Suchen Sie Ihr Symptom und wenden Sie zuerst das passende Framework an.

Ein mittelgroßes Medienunternehmen in Katar führte SAP in mehreren Regionen ein. Finanzwesen und Beschaffung sollten in Phase eins live gehen. Zusätzlich wollte es KI-Prognosemodelle in seinem Reporting.

In Woche sechs schlichen sich Verzögerungen ein. Die Fachanwender sagten, sie hätten die Anforderungen abgenommen, wüssten aber immer noch nicht genau, was sie bekommen. KI-Anwendungsfälle waren vorgeschlagen worden, doch niemand konnte sagen, wem die Daten gehörten oder wie das Ergebnis genutzt werden sollte. Man kam zu spät zu Terminen oder gar nicht.

Es war diese Zwischenphase. Zu früh, um von Scheitern zu sprechen. Zu spät, um zu hoffen, dass sich alles von selbst richtet.

Wir wendeten die Frameworks Schritt für Schritt an. Nicht alles war anfangs willkommen. Manche Sitzungen verliefen schweigsam, andere liefen aus dem Ruder. Doch die Struktur machte die Arbeit leichter: Das Team hörte auf, sich im Kreis zu drehen, der Backlog wurde beherrschbar und die KI-Anwendungsfälle bekamen echte Verantwortliche. Das Projekt ging acht Wochen später live als geplant. Nicht perfekt. Aber es landete, und Phase zwei startete auf besserem Boden, mit weniger Unbekannten.

Versionen aller sieben habe ich in 23 Jahren Projektarbeit bei SAP-, Oracle- und KI-Programmen am Golf, in Europa und darüber hinaus eingesetzt. Keines ist exotisch. Alle funktionieren, wenn man sie mit Disziplin anwendet und nicht als Dokumentationsübung.

Ordnen Sie dem Symptom das Framework zu:

Beobachtetes Symptom	Framework	Ergebnis	Üblicher Aufwand
Anwender haben Anforderungen abgenommen, sind aber weiterhin verwirrt	1. Ist-Analyse	Eine gemeinsame Karte, wie die Arbeit heute tatsächlich abläuft	3 bis 5 Tage Workshops
Entscheidungen wandern von Termin zu Termin	2. RACI für kritische Entscheidungen	Benannte Entscheidungsverantwortliche für die 20 bis 30 wichtigen Weichenstellungen	Ein Workshop, danach Durchsetzung
Sponsoren haben sich vom „IT-Projekt“ abgewandt	3. Capability-Mapping	Fortschritt wird als Geschäftsfähigkeiten berichtet	In die Fit-to-Standard-Workshops eingebaut
Derselbe Fehlertyp kehrt immer wieder	4. Fünf Warum	Eine Ursache, die Sie ändern können	Eine moderierte Sitzung pro Problem
Alles ist als hoch priorisiert markiert	5. MoSCoW	Ein priorisierter Umfang mit realistischer Must-Have-Liste	Eine gemeinsame Sitzung von Fachbereich und IT
Das Risikoregister sieht gut aus, doch das Team ist angespannt	6. Risikopriorisierung	Getrennte Listen für programmgefährdende und lästige Risiken	Wöchentlicher 30-Minuten-Review
Dieselben Fehler wiederholen sich von Phase zu Phase	7. Post-Mortem	Drei bis fünf Änderungen mit Verantwortlichen	Ein halber Tag nach jeder Phase

Der häufigste Fehler zu Beginn eines Programms: Man springt zur Lösung, bevor dokumentiert ist, was es gibt. Die Prozessdokumentation ist meist veraltet. Menschen beschreiben, wie etwas laufen soll, nicht wie es läuft. In der Lücke dazwischen sitzen die Probleme der Einführung.

Eine brauchbare Ist-Prozesslandkarte entsteht in drei bis fünf Tagen Workshops mit den Menschen, die die Arbeit tun, nicht mit denen, die sie leiten. Sie umfasst die Prozessschritte in ihrer Reihenfolge, die Systeme je Schritt, manuelle Eingriffe und Workarounds sowie die Datenflüsse zwischen den Abteilungen.

Achten Sie auf die manuellen Schritte, die niemand erwähnt, weil sie unsichtbar geworden sind, auf Workarounds, die so lange laufen, dass sie inzwischen als Standardprozess gelten, und auf Datenqualitätsprobleme, die jeder kennt und niemand behoben hat.

In Katar entstand die Ist-Prozesslandkarte aus Workshops mit den Anwendern, nicht aus Dokumentation. Dort begann sich die Verwirrung um die abgenommenen Anforderungen zu lichten.

Richtig gemacht, dauert eine Ist-Prozesslandkarte Tage. Als Dokumentensammlung angelegt, dauert sie Monate und liefert etwas, dem niemand traut.

Entscheidungsrechte sind das strukturelle Element, das in SAP- und KI-Projekten am häufigsten fehlt. Jeder hat eine Meinung. Niemand weiß, wer das letzte Wort hat. Entscheidungen wandern in den nächsten Termin, der an den Lenkungsausschuss verweist, der sie an die Arbeitsgruppe zurückgibt.

Eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) gibt jeder Entscheidung und jedem Liefergegenstand einen klaren Owner. Eine Person ist Accountable und kann zugleich Responsible sein oder diese Rolle delegieren. Consulted-Personen liefern Input. Informed-Personen erfahren das Ergebnis.

Die praktische Variante: Listen Sie die zwanzig bis dreißig kritischsten Entscheidungen der aktuellen Phase auf und führen Sie einen RACI-Workshop mit den anwesenden Entscheidern durch. Wo eine Zuordnung umstritten ist, haben Sie etwas gelernt: Entweder ist die Governance unklar, oder es gibt einen politischen Streit um Befugnisse. In beiden Fällen gehört das in Woche zwei auf den Tisch, nicht in Woche vierzehn.

RACI ohne Durchsetzung ist Dekoration. Die Namen müssen zu den Personen mit echter Entscheidungsgewalt passen. Wer die Verantwortung einer Rollenbezeichnung statt einer namentlich benannten Person zuweist, weicht dem Gespräch darüber aus, wer das Risiko trägt.

SAP- und KI-Programme erzeugen viel technische Aktivität, die der Fachbereich nicht sieht. Der Bezug zwischen dem, was gebaut wird, und dem Ergebnis, das es liefern soll, wird abstrakt. Sponsoren ziehen sich zurück, und dem „IT-Projekt“ werden Verzögerungen angelastet, die in Wahrheit Fachentscheidungen sind.

Capability-Mapping verbindet Systemfunktion mit Geschäftsfähigkeit: dem, was die Organisation können muss. Statt zu verfolgen, ob der Bestell-Workflow konfiguriert ist, verfolgen Sie, ob die Organisation Lieferantenrechnungen binnen drei Tagen nach Eingang verarbeiten kann. Die Konfiguration ist das Mittel. Die Fähigkeit ist das Ergebnis.

In SAP Activate entspricht das den Fit-to-Standard-Workshops in der Phase Explore. Jeder Prozess im Umfang ist eine Fähigkeit, und jede Lücke zwischen SAP-Standard und der geforderten Fähigkeit ist eine Entscheidung: den Standard übernehmen, eine Variante konfigurieren oder erweitern. Hält man das Gespräch auf Fähigkeitsebene, bleibt die Aufmerksamkeit des Fachbereichs während der Umsetzung erhalten, und es kommen Fähigkeiten ans Licht, die alle im Umfang vermuteten, die aber niemand bestätigt hatte.

Wenn dieselbe Art von Problem über Sprints oder Phasen hinweg immer wieder auftaucht, hilft es nicht, jeden Einzelfall zu flicken. Die Ursache liegt weiter vorn.

Die Fünf-Warum-Methode ist das einfachste Werkzeug zur Ursachenanalyse. Fragen Sie, warum das Problem aufgetreten ist, dann, warum das passiert ist, bis Sie etwas erreichen, das Sie ändern können. Fünf Runden führen meist zur eigentlichen Ursache. Zwei Runden enden meist beim Symptom.

Ein Beispiel aus der Datenmigration. Die Testmigration enthält Datenqualitätsfehler: Das ist das Symptom. Warum? Der Quellextrakt hatte falsche Feldzuordnungen. Warum? Die Mapping-Spezifikation wurde nie vom fachlichen Data Owner geprüft. Warum? Der Data Owner wurde erst benannt, nachdem das Mapping fertig war. Warum? Der Plan machte die Einbindung des Data Owners nicht zur Abhängigkeit für das Mapping. Das ist die Ursache, und die Lösung ist eine Governance-Entscheidung, keine Datenkorrektur. Mein Beitrag über die Gründe, warum SAP-Datenmigrationen scheitern, zeigt, wie oft genau diese Kette vorkommt.

1. 01Fehler in der TestmigrationDas Symptom
2. 02Falsche FeldzuordnungenWarum ist die Migration fehlgeschlagen?
3. 03Spezifikation nie geprüftWarum waren die Zuordnungen falsch?
4. 04Data Owner zu spät benanntWarum wurde die Spezifikation nicht geprüft?
5. 05Abhängigkeit im Plan übersehenWarum kam der Owner so spät?

Die Ursache ist eine Governance-Entscheidung, keine Datenkorrektur

Ursachenanalyse in einem Raum ohne Schuldzuweisungen liefert ehrliche Antworten. In einem Raum, in dem Schuld verteilt wird, liefert sie Abwehr. Die Aufgabe der Moderation ist es, das Gespräch beim Prozess zu halten, nicht bei Personen. Mein Leitfaden zu strukturiertem Denken und Problemlösen zeigt, wie Sie ein unübersichtliches Problem zerlegen, bevor Sie mit dem Fragen nach dem Warum beginnen.

Jede Umfangsdiskussion in SAP- und KI-Programmen hat eine Konsensfalle. Niemand will Abstriche machen, also wird alles hoch priorisiert. Ist alles hoch priorisiert, ist nichts mehr wichtig, und das Umsetzungsteam versucht, alles zu bauen.

MoSCoW (Must have, Should have, Could have, Won't have this time) erzwingt die Entscheidung. Must Have ist das Minimum für den Go-live. Should Have ist wichtig, aber kein Blocker. Could Have ist wünschenswert, wenn Zeit und Budget es zulassen. Won't Have wird ausdrücklich zurückgestellt.

Die Disziplin entscheidet sich an der Must-Have-Linie. Im ersten Durchgang landet fast immer viel zu viel bei Must Have. Die DSDM-Leitlinien des Agile Business Consortium, aus denen MoSCoW stammt, setzen eine Obergrenze von 60 % des Aufwands für Must Haves und warnen, dass ein höherer Anteil die Lieferung gefährdet. Der Unterschied zwischen erstem Durchgang und realistischer Liste besteht größtenteils aus ungeprüften Annahmen.

Führen Sie MoSCoW mit Fachbereich und Technik im selben Raum durch. Getrennt durchgeführt, erweisen sich die Must-Have-Liste der IT und die des Fachbereichs als unvereinbar, und niemand gleicht sie ab, bis die Konfiguration begonnen hat.

Die meisten Risikoregister sind lange Listen, nach Eintrittswahrscheinlichkeit und Auswirkung bewertet, monatlich geprüft, mit RAG-Status, die sich kaum bewegen. Sie erfassen Risiko, ohne Handeln auszulösen.

Trennen Sie Risiken, die das Programm stoppen können, von Risiken, die es nur erschweren. Die erste Gruppe braucht Verantwortliche, Gegenmaßnahmenpläne und wöchentliche Sichtbarkeit. Die zweite braucht Beobachtung.

In Katar sah das Risikoregister auf dem Papier gut aus, aber alle waren angespannt. Eine schnelle Risiko-Auswirkungs-Matrix, wöchentlich statt monatlich geprüft, brachte die wahren Sorgen ans Licht.

Ein Register, das gut aussieht, während das Team angespannt ist, verbirgt fast immer etwas. Das Register ist nicht die Wahrheit, die Gespräche darum herum sind es. Ein wöchentlicher Review, der fragt: „Was hat Sie letzte Nacht wach gehalten?“, fördert mehr zutage als „Wie ist der Status von Punkt 14?“. Meine SAP-Risikobewertungsmatrix liefert eine Vorlage für Bewertung und Zuständigkeiten.

Post-Mortems nach einer Phase oder dem Go-live verhindern, dass sich dieselben Fehler in der nächsten Phase wiederholen. Sie sind auch das Erste, was gestrichen wird, wenn der Terminplan unter Druck steht.

Ein brauchbares Post-Mortem stellt vier Fragen. Was wollten wir erreichen, und was haben wir erreicht? Was lief gut und sollte wiederholt werden? Was lief schlecht, und was war die Ursache? Was würden wir anders machen? Es sollte mit drei bis fünf konkreten Maßnahmen samt Verantwortlichen enden, nicht mit einem Dokument, das zusammenfasst, was passiert ist.

Der übliche Fehler ist eine Rechtfertigungsübung, bei der Teams Entscheidungen verteidigen, statt sie zu untersuchen. Halten Sie den Blick nach vorn. Die Frage lautet nicht, wer die Verzögerungen in Woche sechs verursacht hat, sondern welche strukturelle Änderung sie in der nächsten Phase verhindert.

In Katar fand das Post-Mortem direkt nach dem Go-live statt und konzentrierte sich auf Maßnahmen, nicht auf Schuld. Das ist ein großer Teil des Grundes, warum Phase zwei auf besserem Boden startete.

Die Frameworks haben sich nicht verändert. Wie man sie anwendet, hat sich verändert, und zwar in dreierlei Hinsicht.

Das Entwerfen wurde schneller, das Zuhören nicht. KI-Werkzeuge machen aus Workshop-Transkripten und Prozessdokumenten in Minuten eine erste Landkarte, und SAP Cloud ALM kann Anforderungen aus Fit-to-Standard-Transkripten entwerfen. Die Workshops selbst dauern so lange wie immer, denn das Zuhören ist der Kern. Die beim Entwerfen gesparte Zeit sollte in die Diskussion der Landkarte mit den Menschen fließen.

RACI-Entwürfe liegen sofort vor, und der schwierige Teil bleibt. Ein allgemeiner KI-Assistent erstellt aus einer Projektcharta und einer Liste von Arbeitspaketen in einer Minute eine RACI-Matrix. Die Disziplin verlagert sich auf die Verhandlung: Jede Zelle braucht ein echtes Gespräch über Befugnis und Eskalation. Die beim Erstellen des Entwurfs gesparte Zeit sollte in diese schwierigen Gespräche fließen.

MoSCoW wird mit KI im Raum schwieriger. Eine KI-Rangfolge von Anforderungen ist plausibel, geschliffen und liegt bei den lokalen Machtverhältnissen oft daneben. Berater, die sie ungeprüft übernehmen, erstellen schlechtere Prioritätenlisten als Berater, die mit einem leeren Blatt beginnen. Behandeln Sie den KI-Entwurf als Ausgangspunkt, nie als Antwort.

Das Urteilsvermögen, das über diesen Frameworks liegt, ist heute mehr wert, nicht weniger. Wenn Sie diese Fähigkeiten als Berater aufbauen, zeigen die Karrierepfade von SAPopedia, welche davon in welcher Phase einer SAP-Laufbahn wichtig sind.

Was sind Beratungs-Frameworks und warum nutzen SAP-Projekte sie?

Es sind strukturierte Vorgehensweisen für Analyse, Entscheidungen und Problemlösung. In SAP- und KI-Programmen geben sie Fachverantwortlichen, Architekten, Projektleitern, Integratoren und Sponsoren eine gemeinsame Methode.

Ohne eine solche Methode greift jede Gruppe auf ihr eigenes Denkmodell zurück: Prozessergebnisse, Architektur oder Termine und Ressourcen. Frameworks wie Ist-Analyse, RACI und MoSCoW machen Meinungsverschiedenheiten explizit und lösbar. SAP Activate ist selbst ein Framework für Phasen, Gates und Liefergegenstände; diese sieben wirken innerhalb davon und adressieren die strukturellen und menschlichen Fragen, die eine Methodik allein nicht löst.

Wie funktioniert die Ist-Analyse bei einer SAP-Einführung?

Sie dokumentiert, wie Prozesse tatsächlich laufen, bevor die Konfiguration beginnt, im Gegensatz dazu, wie die vorhandene Dokumentation sagt, dass sie laufen sollen. Erarbeiten Sie sie in Workshops mit den Menschen, die die Prozesse betreiben: Schritte, Systeme, Übergaben, manuelle Eingriffe und Workarounds.

Sie speist die Fit-to-Standard-Workshops in der Explore-Phase von SAP Activate, in der der Ist-Zustand zur Baseline für den Vergleich mit den SAP-Standardprozessen wird. Schließen Sie sie ab, bevor diese Workshops beginnen, sonst beruht Ihre Gap-Analyse auf Annahmen.

Was ist MoSCoW-Priorisierung und wann kommt sie in SAP-Programmen zum Einsatz?

MoSCoW sortiert Anforderungen in Must have, Should have, Could have und Won't have this time. Must Haves sind das Minimum für den Go-live; Won't Haves werden ausdrücklich ausgeschlossen, damit sie sich nicht wieder einschleichen.

Am nützlichsten ist es in Explore, wenn Fit-Gap-Ergebnisse Entscheidungen über Erweiterungen bestimmen, und in Realize, wenn Fehler und Erweiterungen um Umsetzungszeit konkurrieren. Das übliche Problem sind zu viele Must Haves im ersten Durchgang. DSDM empfiehlt, nicht mehr als 60 % des Aufwands auf Must Haves zu verwenden; eine Moderation, die jeden einzelnen hinterfragt, mit Fachbereich und IT in derselben Sitzung, bringt Sie dorthin.

Wie führt man einen wirksamen Risiko-Review in einem SAP-Projekt durch?

Als Gespräch, nicht als Statusbericht. Beginnen Sie mit offenen Fragen wie „Was ist Ihre größte Sorge diese Woche, die nicht im Register steht?“, bevor Sie das Register durchgehen.

Fragen Sie bei jedem hoch priorisierten Risiko, was sich geändert hat, welche Maßnahme ergriffen wurde, ob sich der Trend bessert und ob der Gegenmaßnahmenplan noch passt. Risiken, die wochenlang ohne Maßnahme auf derselben Bewertung stehen, sind oft zu niedrig eingeschätzt. Prüfen Sie in aktiven Phasen wöchentlich und zeigen Sie dem Lenkungsausschuss die fünf wichtigsten mit Status und nächster Maßnahme, nicht das gesamte Register.

Was macht ein brauchbares Post-Mortem nach einem SAP-Go-live aus?

Konkrete, umsetzbare Änderungen für die nächste Phase. Eine Zusammenfassung dessen, was passiert ist, ist ein Protokoll, kein Post-Mortem.

Behandeln Sie, was Sie erreichen wollten, was Sie erreicht haben, was funktioniert hat und was nicht. Gehen Sie tiefer als Erklärungen an der Oberfläche wie „Wir hatten zu wenig Ressourcen“: War die Ressourcenplanung falsch, der Umfang falsch oder der Eskalationsweg unterbrochen? Enden Sie mit drei bis fünf Änderungen, jeweils mit Verantwortlichem und Datum.

Wie helfen Beratungs-Frameworks bei der KI-Einführung in SAP-Umgebungen?

KI-Projekte scheitern aus denselben strukturellen Gründen wie SAP-Projekte, dazu kommen ein paar eigene: Daten ohne Verantwortlichen, undefinierte Erfolgsmaße und kein vereinbarter Prozess, wie mit dem Ergebnis umzugehen ist.

Die Ist-Analyse zeigt, wem die Daten gehören, die ein Modell braucht, und wie gut sie sind. RACI beantwortet, wer das Ergebnis validiert, wer entscheidet, danach zu handeln, und wer Accountable ist, wenn es falsch ist. MoSCoW trennt unverzichtbare Anwendungsfälle von interessanten. Beginnen Sie mit zwei oder drei unverzichtbaren Anwendungsfällen mit klaren Verantwortlichen und Erfolgsmaßen, nicht mit fünfzehn auf einmal.