SAP Quality Gates: So richten Sie sie ein und woran sie scheitern

Ein Quality Gate ist ein formaler Kontrollpunkt zwischen Projektphasen. Bevor das Team weitergeht, muss es nachweisen, dass vereinbarte Kriterien erfüllt sind. Bestanden: Sie gehen weiter. Nicht bestanden: Sie beheben zuerst die Probleme. In einem SAP-Programm liegen die Gates an den Phasenübergängen von SAP Activate, jedes mit einem namentlich benannten Verantwortlichen, der befugt ist zu sagen: „Nicht bereit.“

Ein großes Konsumgüterunternehmen in Singapur führte SAP weltweit ein. Das Team hetzte durch die Tests, um Termine zu halten. Ich habe dieses Desaster aus der Nähe erlebt. Anwendertests fanden kaum statt, doch die Führungskräfte drängten trotzdem auf den Start. Binnen Tagen zeigten sich die Probleme: fehlende Einstellungen, kaputte Workflows, völlig falsche Daten. Die Wochen des Chaos nach dem Start gingen auf Probleme zurück, die schon vor dem Go-live sichtbar gewesen waren. Niemand hielt an, um nachzuprüfen.

Ich überspringe nie eine Quality-Gate-Prüfung. Keine Abkürzungen, kein Durchwinken. Das kostet vorab mehr Zeit und erspart später Monate an Aufräumarbeit.

Ein Gate ist ein Entscheidungspunkt mit einem schriftlichen Maßstab, dokumentierter Freigabe und echter Befugnis, das Projekt zu verzögern. Es ist keine Fortschrittsprüfung und kein Status-Update im Lenkungsausschuss.

Ohne diese Befugnis werden Prüfungen zu Abnickrunden. Und Gates, die nur abgenickt werden, sind schlimmer als gar keine, weil sie falsche Sicherheit erzeugen. Ein Handelskunde veranstaltete „Reviews“, die im Grunde Abnickrunden waren. Sechs Monate später lag er hoffnungslos hinter dem Plan, weil sich niemand um die Probleme gekümmert hatte, die diese Reviews hätten aufdecken müssen.

SAP Activate hat sechs Phasen: Discover, Prepare, Explore, Realize, Deploy und Run. Jeder Übergang ist ein natürliches Gate. Das erwarte ich als Prüfumfang jedes Gates.

Phasen-Gate	Qualitätsfokus	Nachweise	Bestanden, wenn
Discover	Business Case, Abstimmung auf Führungsebene	Business Case, Roadmap auf hoher Ebene	Business Case unterzeichnet, Sponsor verpflichtet
Prepare	Governance, Team, Risiken	Charta, Governance-Modell, Risikoregister	Charta genehmigt, Risikoverantwortliche benannt, Team eingearbeitet
Explore	Fit-to-Standard, Design, Integrationsansatz	Fit-Gap-Entscheidungen, Prozessdesigns, Integrationsarchitektur	Prozessverantwortliche haben abgenommen; jede Lücke hat eine Entscheidung
Realize	Konfiguration, Integrationstests	Berichte zur Testausführung, Defect-Log	Testschwellenwerte erreicht, kritische Defects geschlossen
Deploy	Daten, Schulung, Cutover-Bereitschaft	Migrationsabstimmung, Schulungsnachweise, Cutover-Plan	Generalprobe abgeschlossen, Rollback-Plan vereinbart
Run	Stabilisierung und Übergabe	Incident-Log, Performance-Berichte	Incidents innerhalb der vereinbarten Grenzen, Support-Übergabe unterzeichnet

In der Praxis tragen Explore, Realize und Deploy das größte Risiko. Ein Problem, das eines dieser drei Gates passiert, kostet am meisten, wenn es nach dem Go-live auftaucht.

1. 01DiscoverBusiness Case unterzeichnet, Sponsor verpflichtet
2. 02PrepareCharta genehmigt, Risikoverantwortliche benannt
3. 03ExploreJede Lücke hat eine Entscheidung
4. 04RealizeTestschwellenwerte erreicht, kritische Defects geschlossen
5. 05DeployGeneralprobe abgeschlossen, Rollback vereinbart
6. 06RunIncidents innerhalb der Grenzen, Übergabe unterzeichnet

Jedes Gate unterzeichnet von einem Verantwortlichen mit der Befugnis zu sagen: nicht bereit

Schreiben Sie Eingangs- und Ausgangskriterien für jedes Gate in die Projektcharta, bevor die Konfiguration beginnt. Kriterien, die unter Termindruck entstehen, beschreiben, was das Team aktuell vorzeigen kann, nicht, was das Projekt braucht. Ich hatte einen Kunden, der Phasen zusammenlegen wollte, um „Zeit zu sparen“. Er musste am Ende Wochen an Arbeit wiederholen.

Kriterien, die ein Ja oder Nein ergeben

„Tests abgeschlossen“ ist kein Kriterium. Es löst Streit aus. Ich habe mit einem Handelskunden gearbeitet, dessen Gate schlicht „UAT abgeschlossen“ lautete. Die eine Hälfte des Teams las das als alle Tests ausgeführt, die andere als alle Defects behoben.

„95 % der Testfälle ausgeführt, alle Defects der Priorität 1 behoben, keine offenen Defects der Priorität 2, die älter als fünf Tage sind“ ist ein Kriterium. Es liefert eine Antwort.

Bei einem Fertigungskunden scheiterten die Gates, weil die Kriterien zu vage waren. Niemand wusste, ob sie tatsächlich bestanden waren. Als die Kriterien zu messbaren Schwellenwerten wurden, hörten die Streitereien an den Phasenübergängen auf.

Ein Verantwortlicher mit Befugnis zur Verschiebung

Jedes Gate braucht einen namentlich benannten Verantwortlichen, der das Projekt verzögern darf. Eine Person, kein Gremium. Ich habe ein Projekt scheitern sehen, weil niemand die Macht hatte, die nächste Phase zu verschieben, obwohl das Team nicht bereit war.

Das Gegenteil funktioniert. Ein Handelskunde ernannte einen Senior Director zum Gate-Verantwortlichen. Wenn er sagte: „Nicht bereit“, hörten alle zu. Schreiben Sie diese Befugnis in die Charta.

Rückhalt der Führung, bevor der Druck kommt

Führungskräfte lieben Quality Gates, bis ein Gate einen Termin gefährdet. Ein CIO setzte sich über ein nicht bestandenes Gate hinweg, um ein Quartalsziel zu erreichen. Die Folgeprobleme kosteten doppelt so viel wie die Verzögerung. Ich habe dieses Muster oft erlebt, deshalb verlange ich inzwischen die Freigabe der Führungsebene für das Gate-Rahmenwerk, bevor das Projekt startet.

Nachweise aus dem führenden System

Gate-Entscheidungen brauchen Nachweise: Berichte zur Testausführung, Defect-Logs, Prozessabnahmen, Migrationsabstimmungen. Ziehen Sie sie aus dem Tool, nicht aus dem, was Leute als erledigt melden. Einer meiner Kunden entdeckte über Solution-Manager-Berichte, dass 40 % seiner „abgeschlossenen“ Testfälle nie ausgeführt worden waren. Er bemerkte es vor dem Gate, nicht danach.

1. Ordnen Sie Gates den Phasenübergängen zu. Bei SAP Activate mindestens nach Prepare, Explore, Realize und Deploy. Ein Energiekunde legte dazwischen willkürliche Kontrollpunkte an und endete im Durcheinander.
2. Definieren Sie Eingangs- und Ausgangskriterien, bevor die Konfiguration beginnt. Vereinbaren Sie Testabdeckung, Defect-Schwellenwerte und die Prozessverantwortlichen, die unterzeichnen müssen. Schreiben Sie sie in die Charta und lassen Sie sich die Unterschrift des Sponsors geben.
3. Planen Sie Gates mit Puffer ein. Tragen Sie jedes Gate als Aktivität in den Kalender ein, nicht nur als Meilenstein. Einer meiner Handelskunden reservierte vor jedem Gate eine volle Woche allein für Aufräumarbeiten.
4. Wählen Sie Prüfer, die entscheiden können. Fachbereichsleiter nehmen Prozesse ab. Technische Leiter nehmen Konfiguration und Integration ab. Berater unterschreiben niemals für den Fachbereich.
5. Halten Sie die Nachweise an einem Ort. Sechs Monate später wird ein Prüfer fragen, wer die Datenmigration abgenommen hat. Die Antwort sollte in Minuten zu finden sein.
6. Machen Sie die Ergebnisse sichtbar. Ein Kunde hängte sein Gate-Dashboard an die Wand des Projektraums. Man konnte es nicht ignorieren.

Beispielhafte Exit-Kriterien für die zwei wichtigsten Gates

Realize-Gate:

1. Testausführung auf oder über dem vereinbarten Schwellenwert, mit Ergebnissen im Test-Tool.
2. Keine offenen Defects der Priorität 1, Defects der Priorität 2 innerhalb der vereinbarten Altersgrenze.
3. Jeder kritische Prozess von seinem namentlich benannten Prozessverantwortlichen abgenommen.
4. Integrationstests über vollständige Prozessketten durchgeführt, mit dokumentierten Ergebnissen.
5. Jede kundeneigene Entwicklung gegen die Clean-Core-Regeln des Programms freigegeben.

Deploy-Gate:

1. Generalprobe der Datenmigration abgeschlossen und Abstimmung vom Datenverantwortlichen unterzeichnet.
2. Schulungsabschluss nach Rolle auf oder über dem vereinbarten Schwellenwert.
3. Cutover-Plan geprobt, mit Zeitplänen und Go/No-go-Entscheidungspunkten.
4. Rollback-Plan dokumentiert und getestet.
5. Hypercare-Team benannt, mit Eskalationswegen und vereinbarten Schweregraddefinitionen.

Zeigt das Deploy-Gate ungeklärte Abstimmungsabweichungen oder ungeschulte Anwender und der Fachbereich will trotzdem weitermachen, machen Sie daraus eine dokumentierte Entscheidung mit einem namentlich benannten Unterzeichner. Nicht als Standard, nur weil niemand Nein sagen wollte.

Zwei Dinge haben verändert, wie ich Gates in aktuellen Programmen gestalte.

Clean Core ist jetzt ein Gate-Kriterium. SAP klassifiziert Erweiterungen von Level A (nur freigegebene Schnittstellen) bis Level D (Modifikationen und direkte Tabellenschreibzugriffe). Beim Explore-Gate sollte jede Lücke eine Entscheidung haben: konfigurieren, als Erweiterung über freigegebene APIs bauen oder ablehnen. Beim Realize-Gate prüfen Sie, dass keine neuen Level-D-Objekte eingeschlichen sind. Die Public Edition erzwingt das technisch. Private Edition und On-Premise tun das nicht, also ist das Gate das, was es durchsetzt.

SAP Cloud ALM ist das Standard-Tool. Es ist in SAP-Cloud-Abonnements mit Enterprise Support, cloud edition, und in SAP Enterprise Support für On-Premise-Kunden enthalten (SAP Support). Es deckt Fit-to-Standard, Aufgabenzuweisung, Testorchestrierung und Nachverfolgbarkeit ab. Die Mainstream-Wartung von SAP Solution Manager 7.2 endet Ende 2027, und SAP empfiehlt, bis dahin auf Cloud ALM zu wechseln (SAP Support). Sind Sie mitten in einem Programm auf Solution Manager, bringen Sie es dort zu Ende. Planen Sie neue Programme rund um Cloud ALM.

Tools für die Gate-Steuerung

Das Tool zählt weniger als die Disziplin. Ein Handelskunde baute einen sauberen Gate-Prozess in SharePoint, der für eine mittelgroße Einführung hervorragend funktionierte. Ich habe auch Gates auf einem vollständigen Solution-Manager-Setup scheitern sehen, weil das Team parallele Tabellenkalkulationen führte.

Tool	Rolle in der Gate-Steuerung	Am besten für
SAP Cloud ALM	Fit-to-Standard, Aufgaben, Tests, Nachverfolgbarkeit	Neue S/4HANA-Programme, Cloud oder On-Premise
SAP Solution Manager 7.2	Projektverfolgung, Test- und Defect-Management	Programme, die bereits darauf laufen
Jira und Confluence	Aufgaben, Defects, Gate-Kriterien und Nachweise	Teams, die bereits Atlassian-Tools nutzen
Tricentis Tosca	Testautomatisierung und Reporting zur Testabdeckung	Programme mit starker Testautomatisierung
ServiceNow	Freigabe-Workflows und Audit-Trail	Unternehmen, die bereits ServiceNow betreiben

Welches Sie auch wählen: Es muss die einzige maßgebliche Quelle sein. Eine parallele Tabellenkalkulation zeigt immer die Version, die das Team zeigen will. Mein Vergleich der Tools für SAP-Tests und -Validierung geht auf der Testseite tiefer.

Unter Termindruck übersprungen. Wenn Projekte rutschen, werden Gates als Erstes gestrichen. In einem Projekt wurden die Reviews zu Abnickrunden, und der Go-live wurde zum Albtraum: Systeme stürzten ab, Aufträge blieben hängen, und man musste komplett zurückrollen. Die drei Wochen, die man „gespart“ hatte, kosteten drei Monate Wiederherstellung.

Vage Kriterien. Oben behandelt. Wenn ein Kriterium Interpretation braucht, ist es ein Gesprächsanlass.

Prüfer ohne Zeit. Sind die wichtigsten Prüfer auf mehrere Projekte verteilt, wird aus Reviews Kästchenabhaken. Ein Realize-Gate-Review in einem mittelgroßen Programm sollte mindestens einen halben Tag dauern, mit vorab gelesenen Nachweisen.

Kultur. Teams, die es gewohnt sind, Meilensteine hastig abzuhaken, suchen Wege um Gates herum. Das ändert sich, wenn eine Führungskraft beim Kickoff sagt, dass Gates verpflichtend sind, und es dann beweist, indem sie sich weigert, das erste Gate zu übergehen, das eine Verzögerung verursacht.

Drei Kennzahlen, die zeigen, ob Gates wirken

Verfolgen Sie diese, um zu sehen, ob Gates das Projekt schützen oder nur so aussehen.

1. Defect Leakage: der Anteil der Defects, die nach einem Gate gefunden werden und die das Gate hätte erkennen müssen.
2. Bestehensquote beim ersten Versuch: Wenn jedes Gate beim ersten Mal bestanden wird, haben die Kriterien vermutlich keinen Biss.
3. Incidents nach dem Go-live: Incidents hoher Priorität in den ersten 30 Tagen sind ein direktes Urteil über das Deploy-Gate.

Gates gehören vom ersten Tag an in die Charta. Mein Leitfaden zur Projektcharta zeigt, wo sie hineinpassen, und der Leitfaden zum Lenkungsausschuss behandelt, wer die Befugnis haben sollte, sie durchzusetzen.

Was ist ein Quality Gate in SAP-Projekten?

Ein formaler Kontrollpunkt zwischen Projektphasen. Das Team muss nachweisen, dass bestimmte, messbare Kriterien erfüllt sind, bevor es weitergeht. Jedes Gate hat einen namentlich benannten Verantwortlichen, der das Projekt verzögern darf. In SAP Activate liegen die Gates an den Phasenübergängen, besonders nach Explore, Realize und Deploy.

Welche Quality Gates gibt es in SAP Activate?

SAP Activate hat sechs Phasen (Discover, Prepare, Explore, Realize, Deploy und Run), und jeder Übergang ist ein Gate. Discover prüft den Business Case. Prepare prüft Governance und Charta. Explore prüft Design-Abnahme und Lückenentscheidungen. Realize prüft Testergebnisse und Defects. Deploy prüft Daten, Schulung und Cutover-Bereitschaft. Run prüft Stabilisierung und Übergabe.

Was sollten die Kriterien eines SAP Quality Gates enthalten?

Kriterien, die ein Ja oder Nein ergeben. Für Realize: Schwellenwerte der Testausführung, offene Defects nach Priorität, Abnahmen der Prozessverantwortlichen und Ergebnisse der Integrationstests. Für Deploy: Migrationsabstimmung, Schulungsabschluss nach Rolle, ein geprobter Cutover-Plan, ein getesteter Rollback-Plan und ein besetztes Hypercare-Team. Jedes Kriterium braucht einen Verantwortlichen, der den Nachweis liefert.

Warum scheitern Quality Gates in SAP-Einführungen?

Sie werden unter Termindruck übersprungen, die Kriterien sind vage, die Prüfer haben keine Zeit zur Vorbereitung, oder eine Führungskraft setzt sich über ein nicht bestandenes Gate hinweg. Die Grundursache ist, Gates als Ballast statt als Schutz zu behandeln.

Welches Tool sollte ich zur Steuerung von SAP Quality Gates nutzen?

Für neue Programme SAP Cloud ALM. Es ist in SAP-Cloud-Abonnements und Enterprise Support enthalten und unterstützt Fit-to-Standard, Tests und Nachverfolgbarkeit. SAP Solution Manager 7.2 verlässt Ende 2027 die Mainstream-Wartung. Jira, Tricentis Tosca und ServiceNow funktionieren gut, wo ein Unternehmen sie bereits betreibt. Die Regel lautet: eine einzige maßgebliche Quelle.

Wie beurteilen Sie die Go-live-Bereitschaft am letzten Quality Gate?

Prüfen Sie fünf Dinge anhand von Nachweisen: Datenmigration geprobt und abgestimmt, Schulung für jede Rolle abgeschlossen, Cutover-Plan mit Go/No-go-Punkten geprobt, Rollback-Plan getestet und Hypercare mit Eskalationswegen besetzt. Fällt eines durch und der Fachbereich will trotzdem weitermachen, halten Sie es als unterzeichnete Fachentscheidung fest.