Übergabe, Abschluss und Reporting¶
Die Abschlussphase beginnt, wenn die Validierung abgeschlossen ist. Sie zeigt dem Kunden, was gebaut wurde, übergibt, was der Kunde künftig besitzen muss, und schließt das Projekt formell ab. Diese Seite enthält außerdem die Vorlage für den Bericht an das Steering Committee, den du während der gesamten Implementierung verwendest.
Abschlussschritte¶
| # | Schritt | Ergebnis |
|---|---|---|
| 1 | Prüfen, dass alle Validierungspunkte bestanden oder akzeptiert sind | Ein geschlossenes Validierungs-Work-Item |
| 2 | Das Übergabematerial vorbereiten | Siehe Was übergeben wird |
| 3 | Das Meeting zur technischen Übergabe abhalten | Vereinbarte nächste Schritte |
| 4 | Die Übergabe-Aktionen abschließen | Offene Punkte zugewiesen |
| 5 | Den Kunden bitten, die Lieferung schriftlich abzunehmen | Abnahme. In einem kommerziellen Auftrag löst sie die Rechnung aus, die außerhalb des Plattform-Teams abgewickelt wird. |
| 6 | In den Betrieb wechseln | Das Plattform-Team betreibt die Plattform (Betriebsverantwortlichkeiten) |
Meeting zur technischen Übergabe¶
Lade dieselben Personen ein wie zum Kick-off (Planen) sowie die Personen, die die Plattform betreiben werden. Nutze ein Standard-Slide-Deck oder eine Live-Demo der Umgebung. Eine gute Agenda:
- Was gebaut wurde. Der hub pro Plattform-Umgebung und Region: management groups, subscriptions, Netzwerk, firewall, Gateways, Policies und Monitoring. Zeige es im Azure portal und verweise auf das Design (Plattform).
- Wie es in der pipeline-Plattform eingerichtet ist. Repositories, Entry-pipelines, Agents, Environments und Genehmigungen, Service Connections oder Federated Credentials und das PIM-Modell. Zeige einen Plan- und einen Apply-Lauf.
- Wie Änderungen gemacht werden. Das Konfigurations-Repository, pull requests, canary vor prod und die Standardänderungen (Änderungen sicher durchführen, Häufige Anfragen).
- Wie ein Spoke erstellt wird. Gehe den Test-Spoke und die Standardänderung Neuer Spoke durch. Verweise für Workload-Teams auf den Bereich Nutzer.
- Service Management. Das Betriebsmodell, die Behandlung von Incidents, der Wartungskalender, der monatliche Health Check und die Service Levels (Betrieb).
- Definitionen. Begriffe, die der Kunde hören wird (Glossar).
- Bekannte Probleme und offene Punkte aus der Validierung (Bekannte Probleme).
- Nächste Schritte. Meist der Umzug von Workloads auf die Plattform (Onboarding und Einen Workload migrieren) und das erste Versions-Update.
Was übergeben wird¶
| Punkt | Detail |
|---|---|
| Designdokument und das beantwortete Discovery-Sheet | Der Kunde besitzt das Design ab jetzt |
| Zugriff | Die Liste der Gruppen und ihrer Mitglieder, die PIM-Zuweisungen und ihr Ablauf (die Standard-Eligibility beträgt ein Jahr), die Genehmiger |
| Identitäten | Die Deployment-Service-Principals, wo ihre Secrets oder Federated Credentials liegen, Ablaufdaten und wer sie rotiert (Wartung) |
| Repositories und pipelines | Wo sie liegen, welche Version fixiert ist, welche Schutzmaßnahmen aktiv sind |
| Konfigurationswerte | Alert-Empfänger, der Security-Kontakt, Regionen, IP-Plan, Namensgebung |
| Betriebsdokumente | Eskalationskontakte, Support-Zeiten und Eingangskanal (Platzhalter aus dem Vertrag oder der eigenen Vereinbarung des Teams), der Wartungskalender |
| Validierungsnachweis | Die ausgefüllten Checklisten |
| Offene Punkte | Akzeptierte Abweichungen, nicht gebaute Lücken, zutreffende bekannte Probleme |
Im Modell Eigenbetrieb (self-managed) erledigen die neuen Eigentümer noch am selben Tag die Day-one-Checkliste: Alert-Empfänger und Security-Kontakt auf die eigenen setzen, die Deployment-Identitäten übernehmen, Genehmigungen einrichten und über die zu fixierende Version entscheiden.
Vorlage für den Steering-Committee-Bericht¶
Nutze diesen Bericht für das Steering Committee während der Implementierung: eine Seite mit dem Status pro Phase. Verwende die Statuswörter Green (im Plan), Amber (gefährdet) und Red (außer Plan oder blockiert). Ersetze die Beispiele.
1. Management Summary¶
- Gesamtstatus: Green / Amber / Red
- Wichtigste Highlights: eine kurze Zusammenfassung der wichtigsten Erfolge und Sorgen
2. Status je Phase¶
| Phase | Status | Wichtige Aktivitäten | Risiken und Probleme |
|---|---|---|---|
| Plan | Abgeschlossen / In Arbeit / Verzögert | Scope vereinbart; Workshop durchgeführt; Stakeholder abgestimmt | Keine, oder beschreiben (zum Beispiel „verzögerter Input der Stakeholder“) |
| Prepare | Abgeschlossen / In Arbeit / Verzögert | Voraussetzungen geprüft; Identität eingerichtet; Deployment-Identitäten erstellt; Repositories bereit; pipelines und Agents bereit | Zum Beispiel „Agent-Einrichtung durch Berechtigungen blockiert“ |
| Deploy | Nicht gestartet / In Arbeit / Blockiert | Job runners deployt; hub in canary deployt; hub in prod deployt; Test-Spoke deployt | Zum Beispiel „Warten auf Genehmigung des Produktions-Deployments“ |
| Validate | Nicht gestartet / In Arbeit / Blockiert | Security-Baseline geprüft; hub geprüft; Agents geprüft; Spoke canvas geprüft; Verifizierung durch eine zweite Person erledigt | Zum Beispiel „keine zweite Person verfügbar“ |
| Closure | Nicht gestartet / In Arbeit / Blockiert | Übergabe geplant; Abnahmekriterien geprüft; Projekt abgeschlossen | Zum Beispiel „Freigabe durch den Kunden verzögert“ |
3. Risiken und Probleme¶
| Risiko oder Problem | Auswirkung | Owner | Status |
|---|---|---|---|
| Beispiel: Berechtigungen für die Agent-Einrichtung | Hoch | IT-Lead des Kunden | Offen |
| Beispiel: Verfügbarkeit der Stakeholder | Mittel | Engagement Lead | Offen |
4. Nötige Entscheidungen¶
- Liste die Punkte auf, die eine Entscheidung des Steering Committees brauchen.
5. Nächste Schritte und Aktionen¶
- Liste die nächsten Aktionen auf und wer dafür verantwortlich ist.