11 KiB
Artefaktkarten — Gamma-Vorlage
Material, um aus den 15 konsolidierten Artefakten (A1–A15, siehe
README_karten.md Abschnitt 3) eine Gamma-Präsentation im Kartenformat zu
erzeugen — je Artefakt eine Karte mit der gleichen Struktur:
Was umfasst es? · Warum brauchen wir es? · Konkretes Beispiel · Wo wird es gebraucht?
Teil 1 — Prompt für das Gamma-Eingabefeld
Erstelle eine Präsentation im Karten-/Kartendeck-Stil: eine Karte pro Artefakt, insgesamt 15 Karten plus Titel- und Übersichtskarte. Zielgruppe: Mitarbeitende der Stadt Freiburg / DIGIT, die den Service-Lifecycle kennenlernen. Sprache: Deutsch, sachlich-verständlich, „for dummies"-tauglich. Design: klares Freiburg-Layout (Rot/Weiß), je Karte oben ein Phasen-Tag (Design = blau, Transition = orange, Operation = grün, Support = teal, Review = lila). Jede Artefaktkarte hat genau diese vier Abschnitte mit fettem Label und kurzem Text/Bullets: Was umfasst es? · Warum brauchen wir es? · Konkretes Beispiel · Wo wird es gebraucht? Halte den Text knapp (max. ~4 Bullets pro Abschnitt), eine Karte = ein Artefakt. Verwende die unten gelieferten Inhalte 1:1 als Grundlage und erfinde keine zusätzlichen Fakten. Füge je Karte ein passendes Icon hinzu.
Tipp: In Gamma „Aus Text einfügen / Paste in text" wählen und Teil 2 komplett
hineinkopieren. Die ----Trenner erzeugen die einzelnen Karten.
Teil 2 — Karteninhalte (zum Einfügen in Gamma)
Die 15 Artefakte des Service-Lifecycle
Jedes Artefakt ist ein greifbares Ergebnis im Lebenszyklus eines Services — von der ersten Idee (Design) bis zur Ablösung (Review). Diese Karten erklären, was es ist, warum es gebraucht wird, ein Beispiel und wo es im Lifecycle entsteht.
A1 · Projektauftrag
Was umfasst es? Der freigegebene Auftrag aus dem Demand-Lifecycle: Ziel, Rahmen, benannte Projektleitung sowie zugesagtes Budget und Ressourcen (nach DSR/MB-Freigabe).
Warum brauchen wir es? Er ist das Startsignal und Mandat für die Design-Phase — ohne ihn gibt es weder einen legitimierten Start noch zugewiesene Ressourcen.
Konkretes Beispiel Ein neues Landesgesetz verpflichtet zur Online-Bürgerbeteiligung. Der Demand-Lifecycle gibt das Projekt „Beteiligungs-Module fürs Bürgerportal" mit benannter Projektleitung frei.
Wo wird es gebraucht? Eingang in die Design-Phase → Aktivität ds_01.
A2 · Service-Definition
Was umfasst es? Zweck, Nutzen und Zielgruppen des Services, Utility & Warranty, die SLA-/SLO-Anforderungen sowie Abhängigkeiten zu anderen Services.
Warum brauchen wir es? Sie legt fachlich fest, was der Service leisten soll — der Bezugspunkt für Design, Betrieb und das spätere Review.
Konkretes Beispiel „Beteiligungs-Modul: Bürger:innen kommentieren Bauvorhaben fristgebunden online; Zielverfügbarkeit 99,5 %."
Wo wird es gebraucht? Erstellt in ds_01; im Review (rv_02/rv_04) fortgeschrieben.
A3 · Service Design Document (SDD)
Was umfasst es? Servicearchitektur (Komponenten, Schnittstellen), Design der Betriebs- und Supportprozesse, Security/Datenschutz/Compliance, Monitoring/Reporting und das Rollenmodell.
Warum brauchen wir es? Es übersetzt das „Was" der Service-Definition in das Wie — der technische und organisatorische Bauplan und Voraussetzung für Gate 1.
Konkretes Beispiel Architektur der Beteiligungs-Module inkl. Schnittstellen zu Portal und DMS, Barrierefreiheit und Lastdesign für das Ende von Beteiligungsfristen.
Wo wird es gebraucht? Entsteht in ds_02; an Gate 1 (tr_01) auf Vollständigkeit geprüft.
A4 · Implementation Blueprint
Was umfasst es? Plan zur organisatorischen Einführung: Integration, Rollenübergaben, Anpassung von Prozessen/Tools, Trainings & Kommunikation, Bewertung der Time-to-Operate.
Warum brauchen wir es? Er stellt sicher, dass der Service nicht nur gebaut, sondern auch wirklich in die Organisation eingeführt und übernommen werden kann.
Konkretes Beispiel Schulungsplan für die Sachbearbeiter:innen im Planungsamt plus Übergabeplan an Betrieb und Support.
Wo wird es gebraucht? Entsteht in ds_03; Input für Gate 1.
A5 · Gate-/SOR-Vorlage
Was umfasst es? Die Entscheidungsvorlage für ein Gate: Aufwand/Risiken/Budget, Empfehlung und die zu prüfenden Dimensionen. An Gate 2 als „Transition-Steckbrief".
Warum brauchen wir es? Sie macht Gate-Entscheidungen nachvollziehbar und legitimiert — ohne Vorlage keine SOR-/SO-Freigabe.
Konkretes Beispiel SOR-Vorlage an Gate 1: „Entwicklung statt Konfiguration, geschätzt X Personentage, Budget vorhanden, Betrieb grundsätzlich bereit."
Wo wird es gebraucht? tr_01 (Gate 1), tr_09 (Gate 2, Steckbrief), tr_11 (Gate-3-Antrag).
A6 · Betriebsdokumentation
Was umfasst es? Service Operation Manual, Betriebshandbuch, Arbeitsanweisungen, Eskalationswege, Standard Changes, Known Errors und Konfigurations-/Betriebsrichtlinien.
Warum brauchen wir es? Sie macht den Service betreib- und supportbar — ohne sie kein stabiler Regelbetrieb und keine schnelle, einheitliche Störungsbehebung.
Konkretes Beispiel Runbook „Beteiligungsverfahren anlegen und archivieren", Eskalationspfad bei Speicherfehlern, Standard-Change „neues Verfahren freischalten".
Wo wird es gebraucht? Erstellt in tr_06; bereitgestellt und gepflegt in op_02.
A7 · Test-Report
Was umfasst es? Ergebnisse von Funktions-, Integrations- und Abnahmetests, der Nachweis der Betriebsreife sowie Testprotokolle und Freigaben.
Warum brauchen wir es? Er belegt, dass der Service funktioniert, bevor er live geht — Grundlage für die Freigabe an Gate 2.
Konkretes Beispiel Abnahmetest: Eine Online-Konsultation startet und endet fristgerecht, Eingaben werden korrekt und vollständig gespeichert.
Wo wird es gebraucht? Entsteht in tr_07; Input für Gate 2 (tr_09).
A8 · Aktivierter Service
Was umfasst es? Der freigegebene, produktive Service inklusive Aufnahme ins Portfolio und aktiviertem Katalog-Eintrag (ggf. mit Support-Dokumentation).
Warum brauchen wir es? Es markiert den offiziellen Go-Live — ab hier ist der Service in Betrieb und im Portfolio sichtbar und steuerbar.
Konkretes Beispiel Das Beteiligungs-Modul ist live, im Service-Katalog gelistet und für Bürger:innen nutzbar.
Wo wird es gebraucht? Ergebnis von Gate 3 (tr_12); Übergang in Operation und Support.
A9 · Service-Qualitätsbericht
Was umfasst es? SLA-/SLO-Auswertung, technische KPIs (Verfügbarkeit, Response Time), Abgleich gegen Qualitätsziele und Verbesserungspotenziale — inkl. Monitoring-/Betriebsdaten.
Warum brauchen wir es? Er zeigt objektiv, ob der Service seine Versprechen hält, und ist die Zuarbeit fürs Review.
Konkretes Beispiel Quartalsbericht: 99,7 % Verfügbarkeit, aber Lastspitzen zum Fristende und ein Formular mit auffällig hoher Abbruchquote.
Wo wird es gebraucht? Erstellt in op_06 (Daten aus op_05); Input für das Review (rv_01/rv_02).
A10 · Incident Record
Was umfasst es? 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 brauchen wir es? Es dokumentiert Störungen/Anfragen nachvollziehbar, sichert SLA-Konformität und liefert Daten für Trendanalysen.
Konkretes Beispiel „Kommentar-Speichern schlägt unter Last fehl" — aufgenommen, an den 2nd Level eskaliert, gelöst und sauber geschlossen.
Wo wird es gebraucht? sp_04–sp_08 (Service Requests: sp_04/sp_07).
A11 · Problem Record
Was umfasst es? Beschreibung, Symptome und Diagnosewege, bekannte Workarounds, die Ursache (Root Cause, wenn gefunden), Change-Bedarf sowie Status und Priorität.
Warum brauchen wir es? Es bündelt die strukturelle Ursachenarbeit hinter wiederkehrenden oder ungelösten Incidents — das einzige im Blueprint formal definierte Artefakt.
Konkretes Beispiel Problem Record „Timeout beim Speichern unter Last" mit dokumentiertem Workaround und einer Change-Empfehlung.
Wo wird es gebraucht? Erzeugt in sp_09/sp_10, aktualisiert in sp_11; ausgewertet im Review (rv_01).
A12 · Workaround
Was umfasst es? Eine vorläufige Umgehungslösung, die den Betrieb stabil hält, bis die eigentliche Ursache behoben ist — mit Eintrag in die Wissensdatenbank.
Warum brauchen wir es? Es hält den Service nutzbar, obwohl die Ursache noch offen ist, und reduziert den Druck auf den Support.
Konkretes Beispiel „Kommentare in kleineren Blöcken speichern", bis der Timeout-Fix ausgerollt ist.
Wo wird es gebraucht? Entsteht in sp_11 aus der operativen Root-Cause-Analyse.
A13 · Wissensdatenbank-Eintrag
Was umfasst es? Standardlösungen, Known Errors, Workarounds, FAQ und Anleitungen — das zentrale Arbeitsmittel für 1st und 2nd Level Support.
Warum brauchen wir es? Es beschleunigt den Support, sichert konsistente Antworten und entlastet die höheren Support-Level.
Konkretes Beispiel FAQ „Wie kommentiere ich ein Bauvorhaben?" plus Known-Error-Eintrag zum Speicher-Timeout.
Wo wird es gebraucht? Gepflegt in sp_02, genutzt in sp_05/sp_06, gespeist aus sp_11.
A14 · Service-Review-Bericht
Was umfasst es? 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 brauchen wir es? Es liefert die strukturierte Grundlage für die SOR-Entscheidung über die Zukunft des Service.
Konkretes Beispiel Review nach zwei Quartalen: Dimension Stabilität „gelb" wegen des Lastproblems → Empfehlung IMPROVEMENT.
Wo wird es gebraucht? Erstellt in rv_02; Grundlage für die SOR-Entscheidung in rv_03.
A15 · DPM-Rücklauf
Was umfasst es? Die Übergabe an den Demand-Lifecycle — Variante A: Neuer Demand (Redesign/ Erweiterung) oder Variante B: Retirement-Plan / Decommissioning-Auftrag (Stilllegung).
Warum brauchen wir es? Es schließt den Lebenszyklus: größere Änderungen oder das Ende eines Service laufen kontrolliert über den Demand-Lifecycle, nicht „nebenbei".
Konkretes Beispiel Variante A: eine komplett neue Beteiligungsplattform → neuer Demand. Variante B: das Modul wird durch eine Landeslösung ersetzt → Retirement-Plan.
Wo wird es gebraucht? rv_05 (Neuer Demand) bzw. rv_06 (Retirement) → Demand-Lifecycle (DPM).
Übersicht — Artefakte nach Phase
- Design: A2 Service-Definition · A3 Service Design Document · A4 Implementation Blueprint (Eingang: A1 Projektauftrag)
- Transition: A5 Gate-/SOR-Vorlage · A6 Betriebsdokumentation · A7 Test-Report · A8 Aktivierter Service
- Operation: A9 Service-Qualitätsbericht (+ A6 wird hier gepflegt)
- Support: A10 Incident Record · A11 Problem Record · A12 Workaround · A13 Wissensdatenbank-Eintrag
- Review: A14 Service-Review-Bericht · A15 DPM-Rücklauf