update 01.06.2026
This commit is contained in:
parent
7f1a09572e
commit
1af051990f
21 changed files with 1365 additions and 380 deletions
384
02_Spielfiguren/rollenkarten_gamma.md
Normal file
384
02_Spielfiguren/rollenkarten_gamma.md
Normal file
|
|
@ -0,0 +1,384 @@
|
|||
# Rollenkarten — Gamma-Vorlage
|
||||
|
||||
Material, um aus den 17 Rollen des Service-Lifecycle (Quelle: `spm_rollen.yaml`
|
||||
v1.1) eine **Gamma-Präsentation im Kartenformat** zu erzeugen — je Rolle eine
|
||||
Karte mit gleicher Struktur:
|
||||
**Was macht die Rolle? · Warum brauchen wir sie? · Konkretes Beispiel · Wo im SLC ist sie beteiligt?**
|
||||
|
||||
---
|
||||
|
||||
## Teil 1 — Prompt für das Gamma-Eingabefeld
|
||||
|
||||
> Erstelle eine Präsentation im **Karten-/Kartendeck-Stil**: **eine Karte pro
|
||||
> Rolle**, insgesamt 17 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 Kategorie-Tag mit
|
||||
> Farbe — **Governance = Gold/Gelb, Management = Blau, Teams = Grün, Operative
|
||||
> Einzelrollen = Grau, Externe = Weiß** — und das Rollen-Kürzel als Badge
|
||||
> (z. B. SPM, SO, SOR, AL B&C, PL, L1, L2). Jede Karte hat **genau diese vier
|
||||
> Abschnitte** mit fettem Label und kurzem Text/Bullets:
|
||||
> **Was macht die Rolle? · Warum brauchen wir sie? · Konkretes Beispiel · Wo im SLC ist sie beteiligt?**
|
||||
> Halte den Text knapp (max. ~4 Bullets pro Abschnitt), eine Karte = eine Rolle.
|
||||
> Verwende die unten gelieferten Inhalte 1:1 als Grundlage und erfinde keine
|
||||
> zusätzlichen Fakten. Füge je Karte ein passendes Personen-/Rollen-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 17 Rollen des Service-Lifecycle
|
||||
|
||||
Jede Rolle hat einen klaren Auftrag im Lebenszyklus eines Services — von der
|
||||
strategischen Steuerung (Governance) über die operative Führung bis zu den Teams
|
||||
und externen Partnern. Diese Karten erklären **was** die Rolle tut, **warum** es
|
||||
sie braucht, ein **Beispiel** und **wo** sie im Lifecycle mitwirkt.
|
||||
|
||||
> Lesehilfe RACI: **A** = ergebnisverantwortlich (genau eine Rolle), **R** = führt
|
||||
> aus, **C** = wird einbezogen, **I** = wird informiert.
|
||||
|
||||
---
|
||||
|
||||
## R1 · Service-Portfolio-Manager (SPM) — Governance
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Steuert das gesamte Service-Portfolio: entscheidet über Aufnahme, Änderung und
|
||||
Stilllegung, sichert Strategie, Priorisierung und Wirtschaftlichkeit, aggregiert
|
||||
alle Review-Berichte.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Hält das Gesamtportfolio konsistent und wirtschaftlich — verhindert Wildwuchs und
|
||||
Doppelungen einzelner Services.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Prüft, ob das neue Beteiligungs-Modul ins Portfolio passt und wirtschaftlich ist,
|
||||
und bündelt Review-Erkenntnisse mehrerer Portale.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Beratend (C) an den Gates, Portfolio-Aufnahme an Gate 3; aktiv im Review.
|
||||
Phasen: Design/Transition, Review.
|
||||
|
||||
---
|
||||
|
||||
## R2 · Service Operations Runde (SOR) — Governance · Gremium
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche Anpassungen
|
||||
bewertet und entscheidet. Ständige Mitglieder: SPM + SO + AL B&C + AL App.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Bündelt alle relevanten Perspektiven für tragfähige Go/No-Go-Entscheidungen —
|
||||
keine Aktivierung im Alleingang.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Entscheidet an Gate 1 „Entwicklung statt Konfiguration" und gibt an Gate 3 den
|
||||
Go-Live des Beteiligungs-Moduls frei (Konsent-Prinzip).
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Accountable an Gate 1 (tr_01), Gate 3 (tr_12), im periodischen Review (rv_03) und
|
||||
bei der Außerbetriebnahme (rv_06).
|
||||
|
||||
---
|
||||
|
||||
## R3 · Service Owner (SO) — Governance
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Trägt die fachliche End-to-End-Verantwortung für einen Service über den ganzen
|
||||
Lifecycle: Anforderungen, Qualität, Weiterentwicklung; primärer Entscheider für
|
||||
Inhalt und Wert.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Eine klar verantwortliche Person, die den Service „besitzt" — sonst zerfasert die
|
||||
Verantwortung über viele Stellen.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Verantwortet das Beteiligungs-Modul von der Definition über den ELS-Exit bis zum
|
||||
Review und entscheidet allein an Gate 2.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Accountable in fast allen Design-Aktivitäten, an Gate 2 (tr_09), bei ELS (op_01),
|
||||
Qualitätsbericht (op_06) und Reviews. **Alle Phasen.**
|
||||
|
||||
---
|
||||
|
||||
## R4 · Abteilungsleitung Basis & Cloud (AL B&C) — Management
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Verantwortet den stabilen, sicheren Betrieb der Infrastruktur-Services (Netze,
|
||||
Server, Cloud), koordiniert die Infrastruktur-Betriebsteams und sichert
|
||||
SLA-/Policy-Einhaltung. Ständiges SOR-Mitglied.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Stellt sicher, dass die technische Basis tragfähig ist, und bringt die
|
||||
Infrastruktur-Perspektive in die SOR-Entscheidungen.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Bewertet, ob Server und Cloud die Lastspitzen zum Fristende des Beteiligungs-
|
||||
Moduls tragen, und stimmt im SOR mit ab.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Transition & Operation; Betriebsreife-Bewertung in der SOR. Bildet zusammen mit
|
||||
AL App den „Betrieb" in den Operation-Aktivitäten (op_01–op_05).
|
||||
|
||||
---
|
||||
|
||||
## R5 · Abteilungsleitung Applikationen (AL App) — Management
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Verantwortet den Betrieb der Anwendungs-Services (Fachverfahren, Standardsoftware,
|
||||
Eigenentwicklungen), koordiniert die App-Betriebsteams und sichert SLA/Policy.
|
||||
Ständiges SOR-Mitglied.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Bringt die Anwendungs- und Fachverfahrens-Perspektive in Betrieb und SOR ein —
|
||||
das Pendant zu AL B&C.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Verantwortet den anwendungsseitigen Betrieb der Beteiligungs-Module und bewertet
|
||||
deren Betriebsreife im SOR.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Transition & Operation; ständiges SOR-Mitglied. Zusammen mit AL B&C = der
|
||||
„Betrieb" (ehem. Operations Manager) in den Aktivitäten.
|
||||
|
||||
---
|
||||
|
||||
## R6 · Support Manager (Sup Mgr) — Management
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level):
|
||||
Prozesse, Leitlinien, Wissensmanagement und effizientes Incident/Request-Handling.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Sorgt für funktionierenden, konsistenten Support — sonst wird die
|
||||
Ticketbearbeitung uneinheitlich und langsam.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Legt Ticketkategorien und Reaktionszeiten fürs Beteiligungs-Modul fest und
|
||||
verantwortet den sauberen Abschluss von Incidents.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Accountable in sp_03–sp_08, Responsible in sp_01. Phasen: Transition
|
||||
(Support-Readiness) & Support.
|
||||
|
||||
---
|
||||
|
||||
## R7 · Problem Manager (Prob Mgr) — Management
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Identifiziert wiederkehrende oder strukturelle Störungen, führt Root-Cause-
|
||||
Analysen durch, steuert Problemlösungen und stellt Workarounds bereit.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Bekämpft Ursachen statt Symptome — verhindert, dass dieselben Störungen immer
|
||||
wieder auftreten.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Analysiert die wiederkehrenden Speicher-Timeouts und dokumentiert Problem Record
|
||||
und Workaround.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Accountable in sp_09/sp_10, Responsible in sp_11 und rv_01. Phasen: Support &
|
||||
Review.
|
||||
|
||||
---
|
||||
|
||||
## R8 · Projektleitung (PL) — Management
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen und
|
||||
Lieferanten, sichert Termine und Qualität, liefert die Projektartefakte.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Bringt Bau und Beschaffung termin- und budgetgerecht ans Ziel.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Steuert den Dienstleister beim Bau der Beteiligungs-Module und verantwortet Tests
|
||||
und Build-Abschluss.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Accountable in tr_02, tr_03, tr_07, tr_08; Responsible in den Design-Aktivitäten
|
||||
und an den Gates. Phasen: Design/Transition.
|
||||
|
||||
---
|
||||
|
||||
## R9 · Betriebsteam (Betrieb) — Team
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Führt alle laufenden Betriebsaufgaben aus — von Routine bis Infrastruktur:
|
||||
Monitoring, Standard-Changes, Deployment, Systempflege, tiefe Diagnosen.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Hält den Service täglich am Laufen und sichert Stabilität und Verfügbarkeit.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Rollt das Beteiligungs-Modul aus (tr_10), überwacht es und setzt freigegebene
|
||||
Standard-Changes um.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in op_03–op_07 und tr_10; beratend in Design/Transition. Phasen:
|
||||
Operation (+ Transition).
|
||||
|
||||
---
|
||||
|
||||
## R10 · Service-Support Team (Support) — Team
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, sorgt für schnelle
|
||||
Wiederherstellung; Bindeglied zwischen Anwendern, Betrieb und Problemmanagement.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Erste Hilfe für Nutzer; hält Störungen klein und Anwender handlungsfähig.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Beantwortet Bürgerfragen zum Kommentieren und pflegt die Wissensdatenbank.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in sp_02; beratend bei der Support-Readiness in der Transition.
|
||||
Phasen: Support.
|
||||
|
||||
---
|
||||
|
||||
## R11 · Projektteam (Projekt) — Team
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Fachlich-technisches Team für Entwicklung, Konfiguration, Tests und Dokumentation;
|
||||
unterstützt Übergabe und Betriebsbefähigung.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Die „Hände", die im Projekt bauen und konfigurieren.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Entwickelt Formulare und Kommentar-Workflows, konfiguriert und dokumentiert die
|
||||
Beteiligungs-Module.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in tr_03, tr_05, tr_06. Phasen: Design/Transition.
|
||||
|
||||
---
|
||||
|
||||
## R12 · Queue Koordinator (Queue Koord) — Operative Rolle
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Überwacht das Ticketaufkommen, verteilt und routet Tickets an die richtigen
|
||||
Gruppen und sichert Priorisierung und SLA-Einhaltung.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Sorgt für sauberen, schnellen Ticketfluss zur richtigen Stelle.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Routet ein gemeldetes Speicherproblem priorisiert an den 2nd Level.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in sp_03. Phasen: Support.
|
||||
|
||||
---
|
||||
|
||||
## R13 · 1st Level Agent (L1) — Operative Rolle
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Erste Anlaufstelle für Nutzer: nimmt Incidents/Requests auf, löst Standardfälle,
|
||||
dokumentiert sauber und eskaliert fachgerecht an den 2nd Level.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Löst den Großteil der Fälle schnell und entlastet die höheren Support-Level.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Erklärt einer Bürgerin anhand der Wissensdatenbank, wo der Kommentar-Button ist.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in sp_04, sp_05, sp_07, sp_08. Phasen: Support.
|
||||
|
||||
---
|
||||
|
||||
## R14 · 2nd Level Agent (L2) — Operative Rolle
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere Analysen
|
||||
durch und stellt Lösungen bereit; kooperiert mit Betrieb, Herstellern und
|
||||
Problemmanagement.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Knackt die Fälle, die der 1st Level nicht lösen kann.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Diagnostiziert, warum Kommentare unter Last nicht gespeichert werden, und eröffnet
|
||||
bei Bedarf einen Problem Record.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in sp_06–sp_09; beratend in sp_10/sp_11. Phasen: Support.
|
||||
|
||||
---
|
||||
|
||||
## R15 · Testmanagement (Test Mgmt) — Operative Rolle
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression)
|
||||
während Entwicklung und Transition; sichert Qualität und Betriebsreife.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Stellt sicher, dass nur Funktionierendes live geht.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Prüft, ob eine Online-Konsultation fristgerecht startet und endet und Eingaben
|
||||
korrekt gespeichert werden.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in tr_04 und tr_07. Phasen: Transition.
|
||||
|
||||
---
|
||||
|
||||
## R16 · Architektur (Arch) — Operative Rolle
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen,
|
||||
bewertet Designvarianten und Risiken, sichert technische Konsistenz und
|
||||
Zukunftsfähigkeit.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Hält Lösungen technisch konsistent und zukunftsfähig statt zu Insellösungen.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Entwirft die Architektur der Beteiligungs-Module und die Schnittstellen zu Portal
|
||||
und DMS.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
Responsible in ds_02; R/C an Gate 1 und im Build. Phasen: Design.
|
||||
|
||||
---
|
||||
|
||||
## R17 · Lieferant / Hersteller / Entwickler (Lieferant) — Externe Rolle
|
||||
|
||||
**Was macht die Rolle?**
|
||||
Stellt externe System-, Software- oder Infrastrukturkomponenten bereit oder
|
||||
entwickelt spezifische Anpassungen; wird bei Build, Fehleranalyse und
|
||||
Komponentensupport eingebunden.
|
||||
|
||||
**Warum brauchen wir sie?**
|
||||
Bringt externe Leistung und Know-how, wo intern nicht vorhanden.
|
||||
|
||||
**Konkretes Beispiel**
|
||||
Ein externer Dienstleister entwickelt die Beteiligungs-Module und unterstützt bei
|
||||
kniffligen Incidents.
|
||||
|
||||
**Wo im SLC ist sie beteiligt?**
|
||||
C/I in tr_02, Responsible in tr_03; beratend in sp_06/sp_11. Phasen:
|
||||
Design/Transition & Support.
|
||||
|
||||
---
|
||||
|
||||
## Übersicht — Rollen nach Kategorie
|
||||
|
||||
- **Governance (Gold/Gelb):** SPM · SOR (Gremium) · SO
|
||||
- **Management (Blau):** AL B&C · AL App · Support Manager · Problem Manager · Projektleitung
|
||||
- **Teams (Grün):** Betriebsteam · Service-Support Team · Projektteam
|
||||
- **Operative Einzelrollen (Grau):** Queue Koordinator · 1st Level Agent · 2nd Level Agent · Testmanagement · Architektur
|
||||
- **Externe (Weiß):** Lieferant / Hersteller / Entwickler
|
||||
|
||||
> Hinweis: In älteren Aktivitäts-Referenzen taucht „Operations Manager" auf — diese
|
||||
> Rolle wurde laut GOV-SOR-005 durch **AL B&C** und **AL App** ersetzt (beide
|
||||
> gleichwertig, beide ständige SOR-Mitglieder). Die **SOR** ist ein Gremium, kein
|
||||
> Einzelner: am Gate vertreten durch SPM + SO + AL B&C + AL App.
|
||||
Loading…
Add table
Add a link
Reference in a new issue