# 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.