Was das go/no-go entscheidet
Ein go/no-go ist der Moment, in dem der Fachbereich sagt: Diese Version des CRM darf an diesem Datum in Produktion gehen. Oder er sagt: noch nicht. Es ist keine Formalität am Ende des Tests. Es ist der Grund, warum getestet wurde.
Ein gutes go/no-go hat drei Teile:
- Fakten. Was getestet wurde, was bestanden ist, was noch offen ist. Aus den Testergebnissen, nicht aus dem Gedächtnis.
- Eine Beurteilung. Die Verantwortlichen der Prozesse sagen, ob sie mit dieser Version ihre Arbeit machen können und unter welchen Auflagen.
- Eine Entscheidung. Der Lenkungsausschuss wägt die Fakten und die Beurteilungen gegen den Go-live-Termin ab und entscheidet.
Den meisten go/no-go-Meetings, die schiefgehen, fehlt der erste Teil. Man streitet darüber, wie schlimm ein Issue ist oder ob ein Prozess überhaupt getestet wurde, weil niemand die Zahlen hat. Der Rest dieses Leitfadens handelt davon, dafür zu sorgen, dass die Fakten vorliegen, bevor das Meeting beginnt.
Ausgangskriterien: vor dem ersten Testtag vereinbaren
Ausgangskriterien legen fest, wann der Test gut genug für den Go-live ist. Vereinbaren Sie sie vor dem ersten Testtag mit dem Lenkungsausschuss. Am Ende kochen die Emotionen hoch und die Termine sind nah. Das ist der falsche Zeitpunkt, um festzulegen, was zählt.
Kriterien, die für die meisten CRM-Go-lives funktionieren:
- Kein Critical-Issue ist offen.
- Jeder Must-Testfall ist bestanden.
- Jedes offene High-Issue hat einen Workaround oder einen Termin für den Fix, den der Fachbereich akzeptiert.
- Jeder Testfall im Umfang hat ein Ergebnis.
- Der Verantwortliche jedes Prozesses hat abgenommen.
Vereinbaren Sie, was die Begriffe bedeuten
Kriterien funktionieren nur, wenn alle dieselbe Skala verwenden. Schreiben Sie auf, was jeder Schweregrad bedeutet, und teilen Sie es mit den Testern und dem Lenkungsausschuss gleichermaßen:
| Schweregrad | Bedeutung |
|---|---|
| Critical | Ein zentraler Prozess funktioniert nicht und es gibt keinen Umweg, oder Daten gehen verloren oder sind falsch. Blockiert den Go-live. |
| High | Ein zentraler Prozess funktioniert nur mit einem Workaround, oder eine wichtige Funktion fällt aus. |
| Medium | Eine Funktion arbeitet nicht wie vorgesehen, aber es gibt einen vertretbaren Umweg. |
| Low | Kosmetisch: Text, Layout, eine kleine Unannehmlichkeit. |
Machen Sie dasselbe für die Priorität. Ein Testfall mit Must deckt ab, was am ersten Tag funktionieren muss, etwa ein Angebot erstellen oder einen Fall weiterleiten. Wenn ein Must-Testfall fehlschlägt, ist der Go-live gefährdet. Wie Sie Prioritäten setzen, lesen Sie in Testfälle schreiben, die Tester aus dem Fachbereich verstehen.
Schreiben Sie auf, was nicht getestet wird
Jeder UAT lässt etwas aus: ein Land, das später live geht, einen Bericht, der noch nicht fertig ist, eine Integration, die nur im Systemtest getestet wurde. Halten Sie es vor dem Test schriftlich fest. Dann kann beim go/no-go niemand sagen, er sei davon ausgegangen, dass es abgedeckt war.
Wer entscheidet
Zwei Gruppen von Personen nehmen teil, mit unterschiedlichen Rollen.
Die Verantwortlichen der Prozesse nehmen ab
Für jeden Prozess oder jede Gruppe im Test nimmt eine Person aus dem Fachbereich ab: der Vertriebsleiter für Lead to Cash, die Leitung des Kundenservice für Case Management, die Finanzleitung für die Fakturierung. Sie wissen, was ihre Teams brauchen, und sie leben mit dem Ergebnis. Ihre Abnahme sagt: Meine Leute können mit dieser Version ihre Arbeit machen.
Benennen Sie sie zu Beginn des Projekts, nicht in der letzten Woche. Ein Prozessverantwortlicher, der den Test erst im go/no-go-Meeting sieht, unterschreibt entweder ungelesen oder bittet um eine weitere Woche.
Der Lenkungsausschuss entscheidet
Der Lenkungsausschuss trifft die Entscheidung für den gesamten Go-live. Meist gehören ihm der Sponsor aus dem Fachbereich, der Projektmanager, eine Führungskraft aus der IT und, bei einem Implementierungspartner, jemand vom Partner an. Er wägt Dinge ab, die ein einzelner Prozessverantwortlicher nicht sehen kann: einen auslaufenden Vertrag mit dem alten CRM, einen Schulungsplan, ein Migrationswochenende, andere Projekte am selben Termin.
Der Testleiter bereitet vor, entscheidet aber nicht
Der Testleiter bringt die Fakten und eine Empfehlung mit. Er nimmt nicht für den Fachbereich ab und trifft nicht die Entscheidung. Diese Rollen getrennt zu halten, sorgt dafür, dass die Entscheidung Bestand hat, wenn nach dem Go-live etwas schiefgeht.
Der Bericht: was hineingehört
Der go/no-go-Bericht ist für Personen, die nicht am Test beteiligt waren. Halten Sie ihn kurz: eine Seite, mit den Details dahinter für alle, die sie sehen wollen.
- Eine Empfehlung. Go, Go mit Auflagen oder No-go, mit der Begründung in ein oder zwei Zeilen.
- Umfang. Welche Prozesse und User Stories im Test waren und was nicht getestet wurde.
- Was getestet wurde. Die Umgebung, das Release und der Build. Ein Ergebnis gehört zu einer Version des Systems.
- Die Zahlen. Testfälle bestanden, fehlgeschlagen, blockiert und nicht abgeschlossen.
- Pro Gruppe oder Prozess. Dieselben Zahlen, mit der Abnahme jeder Gruppe.
- Pro Priorität. Wie viele Must-, Should- und Could-Testfälle bestanden sind und welche Must-Testfälle nicht.
- Issues nach Schweregrad. Wie viele offen, bereit für den Retest und geschlossen sind, mit den offenen Critical- und High-Issues namentlich.
- Die Abnahmen. Wer abgenommen hat, wann, mit welcher Entscheidung und welchen Auflagen.
- Bekannte Risiken. Die Workarounds, die der Fachbereich in den ersten Wochen nutzen wird, und wer dabei unterstützt.
Senden Sie den Bericht einen Tag vor dem Meeting. Wer ihn zu Hause liest, stellt bessere Fragen.
In UAT StudioDer Go/no-go report auf dem Dashboard enthält die Einschätzung (GO, GO with conditions oder NO-GO, mit den Gründen), die Zahlen, den Fortschritt pro Tag, die Ergebnisse pro Gruppe, pro Epic und pro Priorität, die Issues nach Schweregrad, die offenen Critical- und High-Issues namentlich und jede Abnahme der Runde. Die Einschätzung folgt festen Regeln und ist eine Empfehlung: Der Lenkungsausschuss entscheidet. Teilen Sie ihn als PDF oder laden Sie ihn als Folien für die Präsentation im Lenkungsausschuss herunter.
Was mit offenen Issues zu tun ist
Am Ende eines UAT gibt es immer offene Issues. Die Frage ist nicht, ob es welche gibt, sondern ob jedes eine Entscheidung hat. Gehen Sie sie vor dem Meeting mit dem Fachbereich und dem Entwicklungsteam durch, wie in der täglichen Triage.
| Schweregrad | Was der Fachbereich vor dem Go-live braucht |
|---|---|
| Critical | Behoben und erneut getestet. Lässt es sich nicht rechtzeitig beheben, lautet die Antwort No-go, oder der Prozess wird aus dem Go-live herausgenommen. |
| High | Behoben, oder ein Workaround, den der Prozessverantwortliche akzeptiert, mit einem Termin für den Fix. |
| Medium | Ein Termin für den Fix oder die Entscheidung, vorerst damit zu leben. |
| Low | Kommt auf das Backlog. Kein Grund zu warten. |
Umstufen mit Bedacht
In den letzten Tagen entsteht Druck, ein Critical-Issue auf High herabzustufen. Manchmal ist das richtig: Ein Workaround findet sich, oder der Prozess erweist sich als selten. Tun Sie es offen, in der Triage, mit dem Prozessverantwortlichen, und schreiben Sie auf, warum. Tun Sie es nie heimlich, damit die Zahlen besser aussehen. So scheitert ein Go-live in seiner ersten Woche.
Wünsche sind keine Fehler
Tester finden Dinge, die sie gern anders hätten. Funktioniert das System wie vorgesehen, ist es ein Change Request: Er kommt auf das Backlog, nicht in dieses Release, und zählt nicht gegen den Go-live.
In UAT StudioDie Triage gibt jedem Issue einen Schweregrad, eine Priorität, einen Zuständigen und eine Entscheidung: Fix, Reject oder Change request. Mit dem Modul AI test design schreibt Summarize with AI auf dem Tab Issues eine kurze Übersicht der offenen Issues für das go/no-go-Meeting: nach Thema gruppiert, mit dem, was den Go-live blockiert. Ohne das Modul liefert Summarize with your own AI einen Prompt, den Sie in die KI Ihres Unternehmens einfügen.
Ein Go mit Auflagen
Viele CRM-Go-lives bekommen ein Go mit Auflagen. Das System ist gut genug, sofern vor oder direkt nach dem Go-live etwas erledigt wird. Das ist eine faire Entscheidung, solange die Auflagen echt sind.
Eine gute Auflage ist:
- Konkret. Die Rabattfreigabe für Aufträge über 50.000 ist behoben und erneut getestet, nicht die Freigaben funktionieren.
- Zugeordnet. Eine Person ist namentlich dafür verantwortlich.
- Terminiert. Vor dem Go-live oder ein Termin in den ersten Wochen danach.
- Geprüft. Jemand bestätigt, dass es erledigt wurde, und der Lenkungsausschuss erfährt davon.
Achten Sie auf die Zahl der Auflagen. Zwei oder drei sind normal. Fünfzehn bedeuten, dass der Test nicht fertig ist. Ein Go mit Auflagen ist kein Weg, ein No-go zu vermeiden.
Go-live in Teilen
Manchmal ist ein Prozess nicht bereit, der Rest aber schon. Dann können Sie ohne diesen Prozess live gehen oder ein Land oder Team später nachziehen. Entscheiden Sie das ausdrücklich, halten Sie den neuen Termin für den wartenden Teil fest und planen Sie dafür eine eigene UAT-Runde und Abnahme.
Abnahme pro Gruppe
Bitten Sie um eine Abnahme pro Prozess oder Gruppe, nicht um eine Unterschrift für alles. Ein Vertriebsleiter kann das Case Management nicht beurteilen und sollte es auch nicht müssen. Jeder Verantwortliche wählt eine von drei Antworten:
- Accepted: Meine Leute können mit dieser Version ihre Arbeit machen.
- Accepted with conditions: sofern die Auflagen erfüllt werden. Schreiben Sie jede auf: wer sie erledigt und bis wann.
- Rejected: nicht gut genug für den Go-live. Fragen Sie, was die Antwort ändern würde.
Sammeln Sie die Abnahmen vor dem Meeting, damit der Lenkungsausschuss auf Grundlage des vollständigen Bildes entscheidet. Eine Abnahme gehört zu einer Version: Folgt ein neuer Build oder eine neue Testrunde, nehmen Sie erneut ab.
In UAT StudioDie Karte Sign-off auf dem Dashboard hat eine Zeile für das gesamte Projekt und eine für jede Gruppe, mit Accepted, Accepted with conditions oder Rejected. Datum, Uhrzeit und die Zahl der offenen Critical-Issues werden festgehalten. Standardmäßig kann niemand abnehmen, solange ein Critical-Issue offen ist; ist No sign-off while Must test cases have not passed angehakt, wartet die Abnahme außerdem, bis jeder Must-Testfall bestanden ist. Ablehnen ist immer möglich. Eine Abnahme gehört zur aktuellen Runde.
Das go/no-go-Meeting leiten
Planen Sie das Meeting zusammen mit den Testtagen, mit dem Termin im Kalender des Lenkungsausschusses. Reservieren Sie eine Stunde. Ein typischer Ablauf:
- Der Testleiter zeigt den Bericht: Umfang, Zahlen, offene Issues, Abnahmen. Zehn Minuten, mit den Zahlen auf dem Bildschirm.
- Jeder Prozessverantwortliche sagt in ein oder zwei Sätzen, warum er so abgenommen hat und welche Auflagen er stellt.
- Fragen zu den offenen Critical- und High-Issues: Gibt es einen Fix, einen Workaround, einen Termin?
- Fragen außerhalb des Tests: Schulung, Datenmigration, Support in den ersten Wochen, der Plan für ein Rollback.
- Die Entscheidung: Go, Go mit Auflagen oder No-go. Lesen Sie sie laut vor, mit den Auflagen, Verantwortlichen und Terminen.
Lautet die Entscheidung No-go, schließen Sie mit einem Plan: was sich ändern muss, eine neue Testrunde und ein Termin für das nächste go/no-go. Ein No-go mit Plan ist eine normale Projektentscheidung. Ein No-go ohne Plan fühlt sich wie ein Scheitern an.
Das Entscheidungsprotokoll
Schreiben Sie die Entscheidung noch am selben Tag auf. Monate später, nach einem Vorfall oder bei einem Audit, wird jemand fragen, wer entschieden hat, mit diesem offenen Issue live zu gehen. Die Antwort sollte in einer Minute zu finden sein.
Ein Entscheidungsprotokoll enthält für jedes go/no-go:
- Das Datum und wer am Meeting teilgenommen hat.
- Die Entscheidung: Go, Go mit Auflagen oder No-go.
- Jede Auflage, mit Verantwortlichem, Termin und später dem Zeitpunkt, zu dem sie erledigt wurde.
- Die offenen Issues, die der Fachbereich akzeptiert hat, mit der Begründung.
- Den Bericht, auf dem die Entscheidung beruhte, so wie er in diesem Moment war.
Bewahren Sie es bei den Projektunterlagen auf und verfolgen Sie die Auflagen in den ersten Wochen nach dem Go-live, bis jede erledigt ist.
In UAT StudioSave snapshot im go/no-go-Bericht hält den Bericht so fest, wie er bei der Entscheidung war; er ändert sich nicht mehr, und Show öffnet ihn später wieder. Jede Abnahme bleibt im Verlauf, auch die ersetzten oder zurückgezogenen. Für einen Auditor laden Admins das Evidence pack herunter: den Bericht, die Testfälle, Ergebnisse und Issues, den Verlauf jedes Issues, jede Abnahme und das Audit-Log, mit einer Prüfsumme für jede Datei.
Kostenlos nutzbar
Die Ausgangskriterien, die Abnahme und der Bericht stehen auch in der UAT-Checkliste für einen CRM-Go-live, als kostenlose Excel-Datei. Für den gesamten Test lesen Sie die Leitfäden für einen Salesforce UAT und einen Dynamics 365 UAT.