This commit is contained in:
breitenbach76 2026-06-07 15:02:35 +02:00
parent 7d474a054e
commit 0eddf2b322
11 changed files with 118 additions and 342 deletions

View file

@ -912,21 +912,51 @@ const STATIONEN = [
Die Akte ist rein digital: erzeugte Artefakte werden per Choice bestimmt und
gesammelt; Gates sind hart gekoppelt (oeffnen nur mit den geforderten Artefakten). */
const ARTEFAKTE = {
A1:{name:"Projektauftrag", phase:"design"},
A2:{name:"Service-Definition", phase:"design", live:true},
A3:{name:"Service Design Document", phase:"design"},
A4:{name:"Implementation Blueprint", phase:"design"},
A5:{name:"Gate-/SOR-Vorlage", phase:"transition"},
A6:{name:"Betriebsdokumentation", phase:"transition"},
A7:{name:"Test-Report", phase:"transition"},
A8:{name:"Aktivierter Service", phase:"transition"},
A9:{name:"Service-Qualitätsbericht", phase:"operation"},
A10:{name:"Incident Record", phase:"support"},
A11:{name:"Problem Record", phase:"support", live:true},
A12:{name:"Workaround", phase:"support"},
A13:{name:"Wissensdatenbank-Eintrag", phase:"support", live:true},
A14:{name:"Service-Review-Bericht", phase:"review"},
A15:{name:"DPM-Rücklauf", phase:"review"}
A1:{name:"Projektauftrag", phase:"design",
was:"Der freigegebene Auftrag aus dem Demand-Lifecycle: Ziel, Rahmen, benannte Projektleitung sowie zugesagtes Budget und Ressourcen (nach DSR/MB-Freigabe).",
warum:"Er ist das Startsignal und Mandat für die Design-Phase — ohne ihn gibt es weder einen legitimierten Start noch zugewiesene Ressourcen."},
A2:{name:"Service-Definition", phase:"design", live:true,
was:"Zweck, Nutzen und Zielgruppen des Services, Utility & Warranty, die SLA-/SLO-Anforderungen sowie Abhängigkeiten zu anderen Services.",
warum:"Sie legt fachlich fest, WAS der Service leisten soll — der Bezugspunkt für Design, Betrieb und das spätere Review."},
A3:{name:"Service Design Document", phase:"design",
was:"Servicearchitektur (Komponenten, Schnittstellen), Design der Betriebs- und Supportprozesse, Security/Datenschutz/Compliance, Monitoring/Reporting und das Rollenmodell.",
warum:"Es übersetzt das „Was“ der Service-Definition in das WIE — der technische und organisatorische Bauplan und Voraussetzung für Gate 1."},
A4:{name:"Implementation Blueprint", phase:"design",
was:"Plan zur organisatorischen Einführung: Integration, Rollenübergaben, Anpassung von Prozessen/Tools, Trainings & Kommunikation, Bewertung der Time-to-Operate.",
warum:"Er stellt sicher, dass der Service nicht nur gebaut, sondern auch wirklich in die Organisation eingeführt und übernommen werden kann."},
A5:{name:"Gate-/SOR-Vorlage", phase:"transition",
was:"Die Entscheidungsvorlage für ein Gate: Aufwand/Risiken/Budget, Empfehlung und die zu prüfenden Dimensionen. An Gate 2 als „Transition-Steckbrief“.",
warum:"Sie macht Gate-Entscheidungen nachvollziehbar und legitimiert — ohne Vorlage keine SOR-/SO-Freigabe."},
A6:{name:"Betriebsdokumentation", phase:"transition",
was:"Service Operation Manual, Betriebshandbuch, Arbeitsanweisungen, Eskalationswege, Standard Changes, Known Errors und Konfigurations-/Betriebsrichtlinien.",
warum:"Sie macht den Service betreib- und supportbar — ohne sie kein stabiler Regelbetrieb und keine schnelle, einheitliche Störungsbehebung."},
A7:{name:"Test-Report", phase:"transition",
was:"Ergebnisse von Funktions-, Integrations- und Abnahmetests, der Nachweis der Betriebsreife sowie Testprotokolle und Freigaben.",
warum:"Er belegt, dass der Service funktioniert, BEVOR er live geht — Grundlage für die Freigabe an Gate 2."},
A8:{name:"Aktivierter Service", phase:"transition",
was:"Der freigegebene, produktive Service inklusive Aufnahme ins Portfolio und aktiviertem Katalog-Eintrag (ggf. mit Support-Dokumentation).",
warum:"Es markiert den offiziellen Go-Live — ab hier ist der Service in Betrieb und im Portfolio sichtbar und steuerbar."},
A9:{name:"Service-Qualitätsbericht", phase:"operation",
was:"SLA-/SLO-Auswertung, technische KPIs (Verfügbarkeit, Response Time), Abgleich gegen Qualitätsziele und Verbesserungspotenziale — inkl. Monitoring-/Betriebsdaten.",
warum:"Er zeigt objektiv, ob der Service seine Versprechen hält, und ist die Zuarbeit fürs Review."},
A10:{name:"Incident Record", phase:"support",
was:"Aufnahme, Bearbeitung, Lösung und Abschluss einer Störung oder eines Service Requests — inklusive Klassifizierung für Auswertungen. (Trägt auch den Request Record.)",
warum:"Es dokumentiert Störungen/Anfragen nachvollziehbar, sichert SLA-Konformität und liefert Daten für Trendanalysen."},
A11:{name:"Problem Record", phase:"support", live:true,
was:"Beschreibung, Symptome und Diagnosewege, bekannte Workarounds, die Ursache (Root Cause, wenn gefunden), Change-Bedarf sowie Status und Priorität.",
warum:"Es bündelt die strukturelle Ursachenarbeit hinter wiederkehrenden oder ungelösten Incidents — das einzige im Blueprint formal definierte Artefakt."},
A12:{name:"Workaround", phase:"support",
was:"Eine vorläufige Umgehungslösung, die den Betrieb stabil hält, bis die eigentliche Ursache behoben ist — mit Eintrag in die Wissensdatenbank.",
warum:"Es hält den Service nutzbar, obwohl die Ursache noch offen ist, und reduziert den Druck auf den Support."},
A13:{name:"Wissensdatenbank-Eintrag", phase:"support", live:true,
was:"Standardlösungen, Known Errors, Workarounds, FAQ und Anleitungen — das zentrale Arbeitsmittel für 1st und 2nd Level Support.",
warum:"Es beschleunigt den Support, sichert konsistente Antworten und entlastet die höheren Support-Level."},
A14:{name:"Service-Review-Bericht", phase:"review",
was:"Das „Service Performance & Improvement Review“: Bewertung über 4 Dimensionen (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit) per Ampel und eine Handlungsempfehlung (CONTINUE / IMPROVEMENT / REDESIGN / RETIRE).",
warum:"Es liefert die strukturierte Grundlage für die SOR-Entscheidung über die Zukunft des Service."},
A15:{name:"DPM-Rücklauf", phase:"review",
was:"Die Übergabe an den Demand-Lifecycle — Variante A: Neuer Demand (Redesign/Erweiterung) oder Variante B: Retirement-Plan / Decommissioning-Auftrag (Stilllegung).",
warum:"Es schließt den Lebenszyklus: größere Änderungen oder das Ende eines Service laufen kontrolliert über den Demand-Lifecycle, nicht „nebenbei“."}
};
// Welche Station erzeugt welches A-Artefakt (Choice-Schritt -> Aufnahme in die Akte).
const STATION_ARTEFAKT = {
@ -1291,7 +1321,7 @@ function activitySteps(st){
legend: raciLegendHtml(),
auf:`<h4 class="aufH">RACI</h4>${raciTable(st)}` },
{ label:"Artefakt", artefakt:true,
frage:`Welche <b>Artefaktkarte</b> entsteht hier und gehört in die <b>Service-Akte</b>?`,
frage:`Welches <b>Artefakt</b> entsteht hier und kommt in die <b>Service-Akte</b>?`,
auf:`<h4 class="aufH">Artefakt</h4><p style="margin:0"><b>${st.artefakt}</b></p>` }
];
}
@ -1353,10 +1383,16 @@ function renderActivity(st){
html += `<div class="choiceGrid">${opts}</div>`;
if(S.arteWrong) html += `<div class="hint bad">Nicht ganz — überlegt nochmal, welches Ergebnis diese Station liefert.</div>`;
} else if(S.actReveal){
if(isArteChoice)
html += `<div class="aufBox"><h4 class="aufH">Artefakt</h4><p style="margin:0"><b>${arteId} — ${ARTEFAKTE[arteId].name}</b> in die Service-Akte gelegt.</p></div>`;
else
if(isArteChoice){
const A = ARTEFAKTE[arteId];
html += `<div class="aufBox">
<p style="margin:0 0 12px"><b>${arteId} — ${A.name}</b> in die Service-Akte gelegt.</p>
<h4 class="aufH">Was umfasst es?</h4><p style="margin:0 0 10px">${A.was}</p>
<h4 class="aufH">Warum brauchen wir es?</h4><p style="margin:0">${A.warum}</p>
</div>`;
} else {
html += `<div class="aufBox">${step.auf}</div>`;
}
}
let actions = `<div class="actions">`;
@ -1395,7 +1431,7 @@ function renderGate(st){
<div>
<p>${st.beschreibung}</p>
<ul class="crit">${pruef}</ul>
<p class="muted">Artefaktkarten in der Akte? Pflicht-Figuren am Gate-Puck?</p>
<p class="muted">Geforderte Artefakte in der Akte (siehe oben)? Pflicht-Figuren am Gate-Puck?</p>
</div>
</details>`;
}