Session Brief: Change Analysis

Ziel

Artefakt: Change Matrix

Arbeitsfrage

Welche Unterschiede zwischen Soll- und Ist-Zustand erklären die beobachtete Abweichung, und welche dieser Differenzen sind ursächlich, beitragend oder zufällig?

Kontext

Was funktionierte zuletzt, was funktioniert jetzt nicht; Zeitraum der Abweichung; Liste der bekannten Veränderungen seit Baseline (Deploys, Configs, Personal, Daten, externe Systeme); Logs und Diffs.

Setup

• Format: Methoden-Session
• Dauer: 60-180 min, je nach Komplexität
• Modus: Workshop oder async
• Teilnehmende: Ein Lead-Investigator; 2-5 Personen mit Kenntnis der Veränderungsbereiche (Engineering, Ops, Daten, Lieferant); ein Scribe; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.
• Owner: Ein Lead-Investigator
• Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
• Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Change Matrix hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Whiteboard oder Tabelle mit drei Spalten (Soll, Ist, Differenz); Zugang zu Versionssystemen, Konfigurationsständen, Deploy-Logs, Mitarbeiter-Schichtplänen; Vorlage für Differenz-Liste.

Vorbereitung

Tabelle mit Soll-, Ist- und Differenz-Spalten anlegen. Kategorien als Zeilen: Code, Konfiguration, Daten, Infrastruktur, Personal, Lieferant, Umfeld, Prozess. Anweisung: pro Zeile Soll und Ist möglichst konkret, Differenz mit Quelle und Zeitstempel.

Agenda

1. Phase 1: Baseline und Ist-Zustand erfassen (20-30 min) Owner: Facilitator Aktion: Baseline-Zustand (wann funktionierte es zuletzt) und Ist-Zustand pro Kategorie konkret beschreiben. Versions-IDs, Konfigurations-Hashes, Personalbesetzungen, Umfeldbedingungen. Hinweis: Wenn Baseline nicht konkret rekonstruierbar ist, Change Analysis funktioniert nicht. Lieber Wochenarbeit für saubere Baseline als oberflächliche Vermutungen. Output: Change Matrix

2. Phase 2: Differenzen auflisten (30-60 min) Owner: Facilitator Aktion: Pro Kategorie alle Differenzen zwischen Soll und Ist notieren. Auch scheinbar irrelevante Änderungen erfassen (Library-Update, neue Person im Team, geänderter Lieferanten-Service). Hinweis: Häufiger Fehler: nur die offensichtlichen Änderungen erfassen. Differenzen wie „neuer Sicherheitspatch in OS“ oder „NTP-Server gewechselt“ tauchen oft erst bei systematischer Liste auf. Output: Ursachenhypothesen

3. Phase 3: Differenzen bewerten (30-45 min) Owner: Facilitator Aktion: Pro Differenz: ursächlich plausibel, beitragend, zufällig. Begründung pro Bewertung. Bei mehreren plausiblen Ursachen Reihenfolge der Prüfung festlegen. Hinweis: Confirmation Bias vermeiden: die offensichtlichste Differenz ist nicht automatisch die Ursache. Pro Differenz prüfen: wann wirkt diese Veränderung, passt das zur Timeline. Output: Validierungsfragen

4. Phase 4: Hypothese testen (30-90 min) Owner: Facilitator Aktion: Verdächtige Differenz isoliert prüfen: Rollback in Staging, A/B-Vergleich, gezielter Test. Ergebnis dokumentieren. Hinweis: Testen statt vermuten. Wenn Test nicht möglich, mindestens Plausibilität anhand Timeline und Logs prüfen. Hypothese ohne Test bleibt Kandidat, kein Ergebnis. Output: Maßnahmenliste

5. Phase 5: Maßnahmen und Lessons (30-45 min) Owner: Owner Aktion: Korrekturmaßnahme für ursächliche Differenz. Strukturelle Lessons: warum war diese Veränderung möglich ohne Aufmerksamkeit. Change-Management-Verbesserungen. Hinweis: Häufig zeigt sich: Veränderung war ungeplant oder nicht kommuniziert. Strukturell heisst nicht „mehr Reviews“, sondern bessere Erkennung relevanter Differenzen, z. B. Change Calendar oder Diff Notifications. Output: Change Matrix

6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Change Matrix

Abschluss

• Ergebnisartefakt aktualisieren: Change Matrix
• Ablageort, Version und Review-Empfänger festlegen.
• Owner, nächster Schritt und Reviewtermin festlegen.

Change Matrix: Change Analysis

Arbeitsfrage

Welche Unterschiede zwischen Soll- und Ist-Zustand erklären die beobachtete Abweichung, und welche dieser Differenzen sind ursächlich, beitragend oder zufällig?

Kontext

Was funktionierte zuletzt, was funktioniert jetzt nicht; Zeitraum der Abweichung; Liste der bekannten Veränderungen seit Baseline (Deploys, Configs, Personal, Daten, externe Systeme); Logs und Diffs.

Beteiligte

• Owner: Ein Lead-Investigator
• Teilnehmende: Ein Lead-Investigator; 2-5 Personen mit Kenntnis der Veränderungsbereiche (Engineering, Ops, Daten, Lieferant); ein Scribe; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.

Input

Whiteboard oder Tabelle mit drei Spalten (Soll, Ist, Differenz); Zugang zu Versionssystemen, Konfigurationsständen, Deploy-Logs, Mitarbeiter-Schichtplänen; Vorlage für Differenz-Liste.

Vorlage

Change Analysis Arbeitsmatrix

Ergebnisartefakte

• Change Matrix:
• Ursachenhypothesen:
• Validierungsfragen:
• Maßnahmenliste:

Entscheidung oder Empfehlung

Welche Konsequenz ergibt sich aus der Matrix?

Fertigstellungscheck

• Change Matrix ist vollständig genug für Review:
• Ablageort:
• Version / Status:
• Review durch:
• Nächster Schritt:

Nächster Schritt

• Ergebnis prüfen
• offene Fragen markieren
• Review oder Entscheidung terminieren