Veränderungsprozesse begleiten und dokumentieren
Jede produktive IT verändert sich permanent: ein Patch, ein neuer Switch, eine größere Disk, ein Major-Release, ein neues Modul, ein Cloud-Migrations-Projekt. Verändert sich etwas, ohne dass es geplant, kommuniziert, dokumentiert und nachbereitet wurde, kommt es zu Incidents, Audit-Beanstandungen, verstörten Anwendern, finanziellem Schaden. Change Management (siehe auch Change Management Lektion) und seine Dokumentation sind deshalb Pflicht-Disziplin – nicht „Bürokratie", sondern Risikovermeidung. Diese Lektion fokussiert auf die Doku-Aspekte entlang des Change-Lebenszyklus: RFC-Dokumentation (Request for Change), Risiko- und Impact-Analyse, CAB-Protokolle, Implementierungs-Dokumentation, PIR (Post-Implementation-Review) und Lessons Learned. Außerdem: Kommunikation an Stakeholder, Schulung der Anwender bei größeren Changes – die menschliche Seite der Veränderung, die oft den Unterschied zwischen technischem Erfolg und akzeptiertem Erfolg ausmacht.
1) Change-Lifecycle mit Doku-Pflichten
Sieben Phasen, jeweils mit eigenen Doku-Anforderungen. Klick die Phasen:
2) Change-Typen und ihre Doku-Tiefe
Nicht jeder Change braucht 5-seitiges RFC-Dokument. Pragmatische Klassifizierung (siehe auch Change-Typen):
| Change-Typ | Beispiel | Doku-Aufwand |
|---|---|---|
| Standard Change | Routinemäßiger Patch, neuer User, Standard-Workflow | Kurz-RFC oder vorab-genehmigt, Logging im Ticketsystem |
| Normal Change | Neuer Server, Software-Update, Firewall-Regel | Volles RFC mit Impact, Risiko, Test-Plan, CAB-Genehmigung |
| Major Change | Domain-Migration, ERP-Release, große Architektur-Änderung | Volles RFC + ausführliche Risiko-Analyse + erweitertes Stakeholder-Mgmt |
| Emergency Change | Sicherheits-Patch bei aktivem Exploit | RFC im Nachhinein (innerhalb 24 h), ggf. mündlich vorab genehmigt |
3) Lessons-Learned-Vorlage
Nach jedem nennenswerten Change: kurze Reflexion. Beispiel-Vorlage:
Lessons Learned · CHG-2026-0451
1. Change-Übersicht
2. Lessons
| Kategorie | Beobachtung | Maßnahme |
|---|---|---|
| positiv | Pre-Check-Skript hat 2 Server identifiziert, die nicht patchbar waren – im Vorfeld erkannt | Skript in Standard-Pipeline aufnehmen |
| positiv | Anwender-Kommunikation 5 Tage vorab + Tag-vorher-Reminder gut angenommen | Schema beibehalten |
| improvement | Reboot-Schleife auf DB-Servern war reproduzierbar in Test, wurde aber als „bekanntes Issue" abgehakt | Issues aus Test-Phase explizit als Risiko ins RFC aufnehmen |
| improvement | Wartungsfenster zu kurz geplant – keine Pufferzeit | Bei Patch-Operationen 50 % Puffer einplanen, Maintenance-Fenster auf 6 h |
| negativ | On-Call-Eskalations-Liste war veraltet (Mitarbeiter nicht mehr im Team) | Quartalsweise Review der Eskalations-Listen, Process Owner: HR + IT-OPS |
3. Teilnehmer der Retro
4. To-Dos
- Pre-Check-Skript als Pipeline-Step (M. Schmidt, bis 30.04.)
- Test-Issues als Risiko-Items in zukünftige RFCs (K. Wagner, ab nächstem RFC)
- Wartungs-Fenster-Standard auf 6 h (Process-Update durch K. Wagner, bis 15.04.)
- Quartals-Review-Termin Eskalations-Listen (HR + IT-OPS, Erstmals 30.06.)
4) Kommunikation bei Changes
Technisch perfekt durchgeführter Change kann scheitern, wenn die Kommunikation schlecht ist. Die wichtigsten Touchpoints:
📢 Ankündigung (T-7 Tage)
Allgemeine Information an betroffene User. Was passiert wann, welche Auswirkungen, was muss der User tun (vorbereiten, Daten sichern)? Per E-Mail, Intranet, Mitarbeiter-Versammlung.
⏰ Reminder (T-1 Tag)
Kurze Erinnerung. „Morgen 04:00-08:00 Wartung, keine Aktion nötig, hier sind die Auswirkungen". Reduziert Support-Anrufe.
🚧 Während des Changes
Status-Page oder Slack/Teams-Channel mit Live-Status. „Phase 1 abgeschlossen, Phase 2 läuft, geplante Wiederinbetriebnahme 07:00." Wichtig bei längeren Wartungen.
✅ Abschluss-Mail
„Change erfolgreich, System wieder verfügbar." Bei Issues: ehrlich, mit Workaround. Reduziert Unsicherheit.
🎓 Schulung bei großen Changes
Wenn Anwender etwas Neues lernen müssen (neue Oberfläche, neuer Prozess), Schulung vor Go-Live anbieten. Mehrere Termine, on-demand-Videos, Schnellstart-PDF.
📞 Hotline / Hyper-Care
Nach großen Changes: 1-2 Wochen erhöhter Support, dedizierte Hotline, Service-Desk verstärkt. Senkt Frust deutlich.
5) Schulung als Teil der Doku
Bei nutzer-sichtbaren Changes ist Schulung Pflicht. Bestandteile:
- Trainings-Konzept: wer wird geschult, in welcher Form, mit welchem Inhalt?
- Schulungs-Material: Slides, Hand-outs, kurze Videos, FAQ.
- Trainer-Vorbereitung: wer schult, welche Vorbereitung, welche Test-Umgebung?
- Teilnehmer-Liste mit Bestätigung: wer wurde wann geschult? Wichtig für Compliance.
- Self-Service-Material: für später hinzukommende User – im Wiki, mit Volltextsuche.
- Feedback-Loop: nach Schulung kurze Umfrage, wo Verständnis-Lücken sind.
Für IT-interne Changes (z. B. neue Monitoring-Lösung): Train-the-Trainer-Konzept. Erst Power-User schulen, die dann die Endanwender mitnehmen.
6) Risk- und Impact-Analyse
Standard-Tool in jedem RFC. Hilfreiches Schema:
| Frage | Beispiel-Antwort |
|---|---|
| Welche Systeme sind betroffen? | srv-erp-app01/02, DB-Cluster, Frontend |
| Welche User-Gruppen? | Buchhaltung (85), Vertrieb (40) |
| Welche externen Schnittstellen? | EDI zu Lieferanten, Online-Shop |
| Welche Geschäftsprozesse? | Faktura, Bestellabwicklung |
| Was ist das Worst-Case-Szenario? | System 4 h nicht erreichbar, ca. 12 k€ Verlust an Faktura-Stunden |
| Wahrscheinlichkeit? | Niedrig (5 %) – Test war erfolgreich |
| Rollback-Plan? | VM-Snapshot vor Change, Restore in 30 Min |
| Wann darf Change ausgeführt werden? | Sonntag 04:00-08:00 (Wartungsfenster) |
| Wer entscheidet bei Eskalation? | CAB-Vorsitzender + IT-Leitung |
7) Auto-Doku aus Tools
Viele Doku-Aufgaben lassen sich automatisieren:
- Ticket-System dokumentiert RFC-Inhalt, Genehmigungen, Status-Übergänge automatisch (JIRA, ServiceNow).
- Git-Commits als Implementierungs-Doku – jeder Code/Config-Change mit Datum, Autor, Commit-Message.
- CMDB-Update nach Change automatisch (z. B. Patch-Stand, Version-Felder).
- CI/CD-Pipelines dokumentieren Deploys mit Zeitstempel und Resultat.
- Monitoring-Annotations: Change-Zeitpunkt im Dashboard markieren – sieht man später bei Trend-Anomalien.
- Slack/Teams-Bot postet automatisch Change-Status (Start, Phase-Wechsel, Ende).
8) Antipatterns
- Doku nur fürs CAB. Nach Genehmigung wird RFC nicht mehr aktualisiert – Implementierung weicht ab, niemand merkt es. Lösung: lebendiges RFC bis zum PIR.
- PIR übersprungen. „Change ist durch, fertig" – keine Lessons Learned, nächster Change macht gleichen Fehler. Lösung: PIR Pflichtbestandteil.
- Lessons Learned, die niemand sieht. Liegen im Projektordner, niemand sucht sie. Lösung: zentrale Wissensbasis, Tags pro Thema, suchbar.
- Schulung vergessen. Neuer Workflow eingeführt, niemand weiß wie er funktioniert. Hyper-Care-Phase wird zur Dauer-Hotline. Lösung: Schulung im Plan einplanen.
- Anwender nicht informiert. Nach Wartung „warum geht das nicht mehr?" – obwohl es nur anders geht. Lösung: klare Vor-Kommunikation.
- Emergency Change ohne nachträgliche Doku. In der Hitze gehandelt, danach vergessen aufzuschreiben. Audit findet's. Lösung: nachträgliche RFC-Pflicht (z. B. innerhalb 24 h).
- Standardchange wird missbraucht. Major Change wird als „Standard" deklariert, um CAB zu umgehen. Lösung: klare Definition was Standard ist + Stichproben.
- Rollback-Plan nicht getestet. Stand zwar im RFC, aber im Ernstfall klappt's nicht. Lösung: Rollback in Test-Umgebung üben.
- Kommunikation per Voice-Mail. Mündliche Genehmigung – niemand kann später beweisen. Lösung: alles schriftlich, im Tool.
- Doku auf Stand der Vergangenheit. Change wurde durchgeführt, Server-Steckbrief nicht aktualisiert. Lösung: Doku-Update als Definition-of-Done.
Zusammenfassung
Veränderungsprozesse brauchen Doku entlang aller 7 Phasen: RFC → Assessment → CAB → Planung → Implementierung → Verifikation → PIR. Change-Typen mit unterschiedlicher Tiefe: Standard (vorab genehmigt), Normal (volles RFC mit CAB), Major (zusätzliche Risiko-Analyse), Emergency (Nachbearbeitung innerhalb 24 h). Kommunikation ist mindestens so wichtig wie die Technik: Ankündigung T-7, Reminder T-1, Live-Status, Abschluss-Mail, Schulung bei großen Changes, Hyper-Care. Der Post-Implementation-Review mit Lessons Learned ist Pflicht – kein Change ohne Reflexion, sonst macht der nächste denselben Fehler. Auto-Doku aus Ticket-System, Git, CMDB und Pipelines reduziert den manuellen Aufwand stark.
Verwandte Lektionen: Change Management · Change-Typen · Übergabeprotokoll · und mehrWeitere relevante LektionenLeistungserbringung abstimmenProzess-DokuContinual ImprovementIncident ManagementProblem ManagementPatch-ManagementCI/CD