336 lines
11 KiB
Markdown
336 lines
11 KiB
Markdown
# 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
|