# 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