384 lines
13 KiB
Markdown
384 lines
13 KiB
Markdown
# 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.
|