Vor dem Start
Eine Annahme testen, nicht schon den Vollbetrieb bauen.
Der Pilot soll eine konkrete Unsicherheit reduzieren: Funktioniert der Kernfall mit den verfügbaren Daten, Systemen und Rollen kontrolliert genug, um eine nächste Entscheidung zu rechtfertigen? Umfang, Testdauer und Datenzugriff werden so klein gehalten, dass ein Abbruch ohne verdeckte Betriebsabhängigkeit möglich bleibt.
1. Pilotauftrag
- Ein Satz beschreibt Eingang, Bearbeitung und erwarteten Zielstatus.
- In-Scope und ausdrücklich ausgeschlossene Fälle sind getrennt.
- Eine fachliche und eine technische Verantwortungsrolle sind benannt.
- Der Pilot nutzt einen freigegebenen Testbestand; Echtdaten sind nur vorgesehen, wenn sie notwendig und geprüft sind.
- Der heutige manuelle oder technische Rückfallweg bleibt funktionsfähig.
2. Prüffälle und Nachweise
- Normalfälle, Grenzfälle, fehlende Angaben und fehlerhafte Eingaben sind enthalten.
- Jede Systemübergabe besitzt einen erwarteten Zustand und eine prüfbare Fehlermeldung.
- Quellen, Anbieterangaben und Versionsstände werden am Test dokumentiert.
- Menschliche Prüfer können Ergebnis, Quelle und Unsicherheit sehen und tatsächlich eingreifen.
- Protokolle enthalten genug Kontext für Fehleranalyse, aber keine unnötigen sensiblen Inhalte.
3. Abbruchkriterien
Abbruch ist kein Scheitern, sondern eine vorab vereinbarte Entscheidung. Mindestens die folgenden Signale brauchen einen klaren Besitzer:
- Falsche Zuordnung oder unerlaubtes Schreiben in ein Folgesystem.
- Quelle, Datenherkunft oder Anbieterweg ist nicht mehr nachvollziehbar.
- Eine erforderliche menschliche Freigabe kann umgangen werden.
- Fehler lassen sich nicht innerhalb des vorgesehenen Pilotbetriebs erkennen oder zurückrollen.
- Der Aufwand verlagert sich nur in manuelle Nacharbeit, ohne den Kernprozess belegbar zu verbessern.
4. Exit vor dem ersten Produktivzugriff
- Welche Daten, Konfigurationen, Protokolle und Arbeitsergebnisse werden in welchem Format exportiert?
- Wer entzieht API-Schlüssel, Konten, Rollen und Systemberechtigungen?
- Welche Pilotdaten müssen gelöscht oder nach einem festgelegten Verfahren weiter aufbewahrt werden?
- Wie läuft der Prozess nach Abschaltung weiter – manuell, im Altsystem oder über einen Ersatzdienst?
- Welche Dokumentation und welches Wissen müssen intern übergeben werden?
5. Abschlussentscheidung
Die Kernannahme ist mit freigegebenen Fällen belegt; Betrieb, Freigabe und Exit sind tragfähig.
Der Nutzen ist plausibel, aber Daten, Rollen, Fehlerweg oder Anbieterangaben sind noch offen.
Der Kernfall ist nicht kontrollierbar, nicht wirtschaftlich begründbar oder erzeugt eine unvertretbare Abhängigkeit.