Change Management
Standard für geplante Änderungen an Moodle, Integrationen und Basis-IT – mit Risiko, Freigabe und Rückfallplan.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Change Management – mit Fokus auf konkrete Entscheidungen statt allgemeiner Leitlinien.
Zentral sind hier vor allem risikoklasse und freigabestufe und testtiefe vor produktivänderung, damit Teams denselben Maßstab anwenden.
Nachvollziehbar wird der Standard erst durch verlinkte Nachweise wie change-request inkl. risikoabschätzung und durch dokumentierte Grenzfälle/Ausnahmen.
Wann diese Seite hilft
Typische Situationen, in denen diese Seite als Arbeitsdokument Mehrwert bringt – und wo eine andere Doku passender ist.
Typische Einsätze
- wenn für Change Management ein organisationsweiter Standard mit klaren Grenzen zu änderungstypen (standard, normal, emergency) festgelegt werden soll
- wenn Entscheidungen zu risikoklasse und freigabestufe zwischen Teams aktuell unterschiedlich getroffen werden
- wenn Audit oder internes Review konkrete Nachweise wie change-request inkl. risikoabschätzung einfordert
- wenn Ausnahmen im Bereich „Änderungsfreigaben“ häufiger werden und sauber befristet/regelt werden müssen
Eher nicht passend bei
- wenn es bei Change Management nur um einen einmaligen Einzelfall ohne Standardisierungsbedarf geht
- wenn ein detailliertes Projektticket oder eine technische Schritt-für-Schritt-Anleitung gepflegt werden soll
Empfohlener Ablauf
Pragmatische Reihenfolge, die in der Praxis funktioniert – vom Scope bis zum Review.
- Anwendungsbereich für Change Management fachlich und organisatorisch festziehen; Scope-Lücken vermeiden (insb. änderungstypen (standard, normal, emergency)).
- Standardentscheidungen definieren: Risikoklasse und Freigabestufe und Testtiefe vor Produktivänderung – inklusive zuständiger Rollen.
- Ausnahmen mit Kriterien, Fristen und Re-Review modellieren; häufige Grenzfälle zu betroffene systeme und integrationen explizit abfangen.
- Nachweise im Regelprozess verankern (mindestens change-request inkl. risikoabschätzung und testprotokolle / abnahme).
- Prüfung anhand realer Abweichungen fahren und Stolperfallen wie „Changes werden als „klein“ eingestuft ohne klare Kriterien“ in die Regel zurückspiegeln.
Entscheidungsregeln
Change Management ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Entscheidungsrahmen
Für Change Management zuerst den Anwendungsbereich konkret machen: Änderungstypen (Standard, Normal, Emergency).
Verantwortung
Entscheidungen zu risikoklasse und freigabestufe und testtiefe vor produktivänderung nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Abweichungsregeln
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier betroffene systeme und integrationen.
Review-Auslöser
Prüfbar ist die Regel erst, wenn change-request inkl. risikoabschätzung und testprotokolle / abnahme sauber verlinkt sind.
Was dokumentiert werden soll
Hier nur die spezifischen Inhalte zu Change Management pflegen; allgemeine Doku-Regeln bleiben in der zentralen Leitlinie. Zentrale Leitlinie.
Die Seite ist dann gut, wenn eine Vertretung den Standard anwenden oder prüfen kann, ohne erst Personenwissen einsammeln zu müssen.
Kontext
Begriffe, Scope und Grenzen zu Change Management konkretisieren – inklusive änderungstypen (standard, normal, emergency).
Umsetzungsvorgaben
Den Standard so notieren, dass risikoklasse und freigabestufe und rollback-kriterium und abbruchpunkt eindeutig entschieden sind.
Prüfpfad
Artefakte direkt nennen und verlinken: Change-Request inkl. Risikoabschätzung, Testprotokolle / Abnahme, Rollback-Plan und Kommunikationsnachweise.
Offene Punkte / Ausnahmen
Aktive Ausnahmen, letzte Änderung und nächster Review gehören auf die Seite – besonders bei Themen mit betroffene systeme und integrationen.
Typische Stolperfallen
Pflege hier echte Fallstricke aus der Praxis von Change Management; allgemeine Hinweise gehören in die zentrale Leitlinie. Zentrale Leitlinie.
- Umfang driftet: Changes werden als „klein“ eingestuft ohne klare Kriterien.
- Regel bleibt abstrakt: Rollback ist beschrieben, aber nicht testbar.
- Nachweis fehlt: Kommunikation startet erst nach dem Change.
- Ausnahme entgleist: Standard bleibt abstrakt ohne Anwendungsbezug.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu Change Management – nicht nur gegen den Wortlaut. Entscheidend ist, ob Standard, Ausnahmen und Nachweise im Alltag tragen.
- Wurden Risikoklassen konsistent vergeben?
- Waren Rollback-Kriterien im Change eindeutig?
- Wurden Freeze-Regeln eingehalten?
- Ist der Scope noch korrekt?
Prüf-Fokus für „Change Management“: Änderungsfreigaben; prüfe dabei insbesondere änderungstypen (standard, normal, emergency).
Sinnvolle Kennzahlen
Wenige Kennzahlen genügen – wichtig ist, dass sie Entscheidungen oder Verbesserungen auslösen.
Für „Change Management“ Kennzahlen direkt an risikoklasse und freigabestufe und die häufigsten Praxisrisiken koppeln.
Change-Erfolgsquote
Anteil Changes ohne Incident oder Rollback
Intervall: monatlich
Rollback-Rate
Anteil Changes mit Rückfall auf Vorzustand
Intervall: monatlich
Freigabe-Lead-Time
Zeit zwischen vollständigem Antrag und Freigabe
Intervall: monatlich
Nächste Schritte
Ergänze jetzt die konkrete Entscheidung zu risikoklasse und freigabestufe inkl. Verantwortlichen, Datum und Verweis auf change-request inkl. risikoabschätzung.
Auf „Change Management“ als Nächstes besonders klar machen: welche änderungstypen (standard, normal, emergency) im Standardfall gelten und welche Ausnahmen befristet sind.