13 KiB
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.