Technische Änderungsdoku
Standardformat für technische Änderungen an Moodle, Webserver und Integrationen.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Technische Änderungsdoku – 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 bei Technische Änderungsdoku technische Standards zu änderungstypen (standard, normal, emergency) verbindlich dokumentiert werden müssen
- wenn Teamwechsel/Vertretung denselben Ablauf für risikoklasse und freigabestufe sicher ausführen soll
- wenn Störungen oder Changes zeigen, dass Nachweise wie change-request inkl. risikoabschätzung bisher fehlen
- wenn Konfig- oder Betriebsabweichungen (z. B. changes werden als „klein“ eingestuft ohne klare kriterien) wiederholt auftreten
Eher nicht passend bei
- wenn es bei Technische Änderungsdoku 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.
- Ist-Stand und Scope für Technische Änderungsdoku erfassen, inklusive änderungstypen (standard, normal, emergency) und kritischer Abhängigkeiten.
- Sollzustand / Standards festlegen; wichtig sind Entscheidungen zu risikoklasse und freigabestufe.
- Änderungen kontrolliert testen (Staging, Testsystem oder Checkliste) und Ergebnis dokumentieren.
- Produktiv umsetzen, Nachtests durchführen und change-request inkl. risikoabschätzung + testprotokolle / abnahme verlinken.
- Monitoring/Reviews auswerten und wiederkehrende Befunde wie „Changes werden als „klein“ eingestuft ohne klare Kriterien“ in den Standard einarbeiten.
Entscheidungsregeln
Technische Änderungsdoku ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Entscheidungsrahmen
Für Technische Änderungsdoku 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 Technische Änderungsdoku 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 Technische Änderungsdoku 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 Technische Änderungsdoku; 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: Dokus werden aktualisiert ohne Änderungsvermerk.
Moodle-Referenz (offizielle Doku 5.1)
Kurze Verweise auf die offizielle Moodle-Dokumentation für Technische Änderungsdoku. So bleibt diese Seite AFANDI-spezifisch und vermeidet doppelte Grundlagen.
Offizielle Referenzen
Dokumentationsfokus
- Änderungen immer mit Datum, Verantwortlichen, Impact und Rückfalloption dokumentieren.
- UI-Pfad, Rolle und Testfall explizit notieren (nicht nur den gewünschten Endzustand).
- Abweichungen von AFANDI-Standards separat markieren, damit Updates leichter reviewbar bleiben.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu Technische Änderungsdoku – 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?
- Sind Pflichtfelder auf den Vorlagen konsistent?
Prüf-Fokus für „Technische Änderungsdoku“: Moodle-Betrieb; 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 „Technische Änderungsdoku“ 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 „Technische Änderungsdoku“ als Nächstes besonders klar machen: welche änderungstypen (standard, normal, emergency) im Standardfall gelten und welche Ausnahmen befristet sind.