Orchestrator/bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_7 Risikomanagement.md

# 7 Risikomanagement

> Page ID: 431634876 | Parent: TAF-TAP-TSI-Programmakte

---

Das Risikomanagement im TTT-Programm stellt sicher, dass potenzielle Gefährdungen für Ziel, Zeit, Budget und Qualität frühzeitig erkannt, transparent bewertet und aktiv gesteuert werden. Die Komplexität der TTT-Gesamtlösung – mit Beteiligung mehrerer Value Teams (VTs) wie C2S, O2C und S2O – erfordert ein gestuftes Vorgehen: Risiken werden dort gemanagt, wo sie entstehen (Subsidiaritätsprinzip), bei übergreifender Relevanz aber auf Programmebene eskaliert und weiterbearbeitet. Diese Logik folgt einem integrativen Modell mit ROAM-Methodik, Jira-basiertem Tracking und regelmäßiger Gremienanbindung innerhalb des s durch das . Im Folgenden werden diese Inhalte näher beleuchtet: 
 
|  | 
Bearbeitungsstatus
|  | Status | 
YellowWIP
|  | Bearbeiter*in | 
 
 
|  | Letzte abgestimmte Version
(Versionsnummer) | 21
|  | Erläuterung Abstimmung
(z.B. Gremium, Protokoll) | n.a. Freigabe durch Programmleitung


## Begriffsdefinition

Im Programm TTT unterscheiden wir zwischen Risiken und Impediments.
- Risiko: Ein Risiko ein Ereignis oder ein Zustand, der mit einer gewissen Wahrscheinlichkeit eintreten wird, also noch nicht eingetreten ist, und der bei Eintreten dazu führt, dass die Zielerreichung der TTT Einführung als ganzes oder eines zugehörigen Teilschritts nicht in Zeit und Qualität erreicht wird.
- Impediment:  Ist ein eingetretenes Ereignis oder Zustand, das dazu führt, dass die Zielerreichung der TTT Einführung als ganzes oder eines zugehörigen Teilschritts nicht in Zeit und Qualität erreicht wird. Dies kann ein eingetretenes Risiko sein, falls dieses zuvor identifiziert wurde, kann aber auch ohne die vorherige Identifikation als Risiko auftreten. 
Ein Impediment ist auch, wenn ein Zustand eintritt, der in der Konsequenz kausal die Zielerreichung verhindert, obwohl das Ziel zeitlich noch nicht verfehlt wurde.


## Risikomanagement in den Solutions und ARTs

Innerhalb der ARTs (z. B. C2S, O2C) erfolgt das Risikomanagement operativ über agile Prozesse und Toolunterstützung in ariJa (Jira). Jedes Team kann Risiken erfassen, bewerten (Impact & Probability), einem Owner zuweisen und Maßnahmen dokumentieren. Wesentliche Merkmale sind:
- Beschreibung nach Ursache – Risiko – Auswirkung (siehe )
- Verknüpfung mit Features, Enablern und Objectives (siehe Verknüpfung)
- ROAM-Status: Resolved, Owned, Accepted, Mitigated (siehe )
- Transparenz durch Risiko-Dashboards auf ART- und Solution-Ebene (vgl. Risikodashboard TTTneo)
- Regelmäßige Review-Termine im ART Sync bzw. Risk Board
Im C2S-Bereich ist der Prozess detailliert beschrieben und wird aktiv gelebt, etwa durch das C2S Risiko-Board und die regelmäßige Integration in das PI-Planning sowie das ART-Sync (). Analog agiert auch das O2C-VT mit einem eigenen ROAM-Board und klarer Trennung zwischen operativem und eskalierendem Risikohandling​ ()


Konkreter Risikomanagement Prozess auf Solution-Ebene C2S, erklärt anhand folgender Seiten: 
- 
-  / 
- 
Darin integriert ist auch der TTT-Projekt Risikomanagement Prozess: 


## Risikomanagement auf Programmebene (PMO)

Die Programmleitung führt ein programmweites Risikoregister in Jira (TTT Solution Steuerung), in dem solution-übergreifende Risiken erfasst und bewertet werden. Grundlage für das Reporting und das Risikomanagement auf Programmsteuerungsebene ist das .​ Dieses aggregiert:
- ART-/Solution-Risiken mit TTT-Relevanz
- Programmrisiken aus Steuerungs-, Ressourcen-, Test- und Marktperspektive
- ROAM-Status je Risiko
- Ausweis Dauer der nicht gelöster Risiken (seit Erstellungsdatum)
- Verlinkung zu Jira-Issues und Ownern
Das PMO verantwortet die Konsolidierung, Pflege und Steuerung dieser Risiken, bereitet regelmäßig Eskalationen für die Lenkungskreise (TTT Solution Steuerung, CIO Board) vor und speist relevante Themen in das Reporting an das Solution Steuerung Gremium ein. Grundlage bildet das .
Nachfolgend sind die wesentlichen Punkte aus Programmsicht dargestellt.


## Risiko Kaskade

In der Darstellung rechts sind die unterschiedlichen Quellen von Risiken sowie deren Hinterlegung in Jira-Projekten dargestellt:
- Auf Programmebene (TTTSOL): Übergreifende Risiken und Risiken, die aus dem Testing heraus für Teams/ARTs/LS/Steuerung entstehen
- Auf ART-Ebene: Risiken, die mehrere Teams innerhalb eines ARTs betreffen, z.B. O2CBS
- Anmerkung: Risiken, die allein ein Team betreffen sind in der Darstellung nicht enthalten.
Die Kaskadierung sieht vor, dass die Risiken vom Team und ART Ebene über JF Termine (JF Testing, JF O2C, JF TTT-Projekt [neo], JF ujBau, JF S2O) geklärt werden und nach Bedarf auch im übergreifenden Arbeitsmeeting bzw. im Gremium Lenkungskreis TTT bzgl. Entscheidungen und notwendiger Maßnahmen diskutiert werden. 
Die Governance für das Risikomanagement ist demnach mehrstufig aufgesetzt:
- Team- und ART-Ebene: initiale Risikoerfassung, Monitoring, Maßnahmenverfolgung
- Programmebene: zentrale Steuerung über PMO und Programmleitung, Eskalation kritischer Risiken in den Lenkungskreis TTT, Reporting & Maßnahmenabgleich



## Risiken in Jira erfassen

Bei der Anlage eines Risikos soll der Vorgangstyp "Risk" verwendet werden und die Felder des Formulars sowie das Template in der Beschreibung möglichst vollständig ausgefüllt werden. Die Anlage auf Programmebene erfolgt im Projekt "TTT Solution Steuerung". 
Das folgende Template ist im Beschreibungsfeld in Jira zu befüllen: 
---
h4. Kontext:
h4. Auswirkungen:
Als Folge von [definitiver Ursache] kann [unsicheres Ereignis] auftreten, welches die [Auswirkung, Tragweite] auslösen kann.
h4. Anmerkungen:
h4. Mögliche Maßnahmen zur Mitigation:
 ---
Folgende Stichwörter / Labels sind anzugeben, damit das Risiko zum Programm zugeordnet und im Reporting verwendet werden kann: "TTT" UND "TTTneo" / "ujBau" / "ujSol" / "C2S" / "Test" / "O2C" / "S2O" (siehe auch 4.2 Jira)
Wenn das Risiko zu anderen Risiken gehört (z. B. wegen eines Splits), dann sollte auch eine Verknüpfung über "relates to" angelegt werden. Zudem sollten Risiken mit Issues verknüpft werden, aus denen sie entstanden sind und/oder die sie beeinflussen mittels "relates to". Maßnahmen werden mit Risiken durch "Treats" verknüpft.
Die Structure TTT Risiken stellt die Sicht der Verknüpfungen aller TTT Risiken dar und bietet damit einen Überblick über die definierte Maßnahmen, verbundene weitere Risiken und Abhängigkeiten. 




## Risikobewertung

## Impact und Probability von Risiken

Wir bewerten Risiken nach Auswirkung (Impact) und Eintrittswahrscheinlichkeit (Probability), um ihre Dringlichkeit zu bestimmen. Dabei ist die gewählte Bewertung zu begründen. Die unten folgenden Tabellen stellen die Kriterien für die Abstufungen dar. Diese ergänzen die Definitionen der Dokumentationen der ARTs/Teams (z.B. 20_Risiko Management, TTTneo_Risiken, Risikomanagement - C2S) um eine zeitliche Komponente, die aufgrund der zeitlichen Kritikalität von TTT spezifiziert wurde. 
Bei Veränderung des Risikos z.B. durch aktive Behandlung durch eine Maßnahme, sollte auch die Bewertung geprüft und ggf. angepasst werden. Dies geschieht durch Angabe von Residual Impact und Residual Probability in den entsprechenden Feldern. Die Begründung der Anpassung wird per Kommentar erläutert.


## Abstufungen Impact

|  | Stufe | Beschreibung | Impact - Zeitliche Skala
|  | 5 - Catastrophic | kritischer Pfad zum Go-Live gefährdet, massive Auswirkungen auf Programmplanung | 
zeitlicher Impact auf Meilensteine im kritischen Pfad: mehr als 2 Wochen 
|  | 4 - Major | wesentliche Meilensteine im kritischen Pfad gefährdet, Auswirkungen auf mehrere ARTs oder Releasezyklen | zeitlicher Impact auf Meilensteine im kritischen Pfad: bis zu 2 Wochen
|  | 3 - Moderate | einzel-ART/Team-Ziel außerhalb des kritischen Pfades gefährdet, jedoch lokal abfangbar, sonst Go-Live gefährdet | zeitlicher Impact auf Meilensteine außerhalb vom kritischem Pfad: 2 bis 4 Wochen
|  | 2 - Minor | kleinere Terminabweichung ohne Folgen für kritischen Pfad zum Go-Live | Terminabweichungen außerhalb des kritischen Pfades: bis zu 2 Wochen    
|  | 1 - Insignificant | keine oder kleinere Abweichung ohne Folgen für den kritischen Pfad zum Go-Live | kleinere Abweichungen ohne Auswirkung auf kritischen Pfad: 0-3 Tage     


Abstufungen Probability | 
|  | 
Stufe | 
Beschreibung
|  | 5 - Almost Certain  | Das Risiko wird sehr wahrscheinlich eintreten (>90 %). Frühere Erfahrungen bestätigen dies.
|  | 4 - Very Likely  | Das Risiko wird mit hoher Wahrscheinlichkeit eintreten (70–90  %). Erste Anzeichen sind bereits sichtbar.
|  | 3 - Likely  | Es besteht eine realistische Wahrscheinlichkeit (40–70 %), aber noch keine konkreten Hinweise.
|  | 2 - Unlikely  | Das Risiko ist möglich, aber eher theoretisch (<40  %). Bisher keine Anzeichen.
|  | 1 - Very Unlikely  | Eintritt fast ausgeschlossen (<10 %). Keine Hinweise, rein hypothetisch.


Um sicherzustellen, dass Risiken auf Programmsteuerungsebene schnellstmöglich bewertet und geROAMed werden, ist wöchentlich im Anschluss an das Arbeitsmeeting TTT Programmsteuerung und Leads ein 30-minütiger Termin im gleichen Teilnehmerkreis geplant. Sollte die Agenda des Arbeitsmeetings es zulassen, können die Risiken bereits dort besprochen werden und der Nachfolgetermin entfällt. Personen, die bei den zu besprechenden Risiken nicht involviert sind, können den Termin vorzeitig verlassen. 


## Reports in Jira & Confluence

TTT Risikomgmt.: 
- Hier findet sich ein Dashboard, zu einer Liste an Risiken, die zu TTT gehören.
- Voraussetzung ist, dass sie in Jira richtig geflaggt werden: Es ist das Stichwort/Label "TTT" anzugeben. → vgl. 
- Ziel ist es sowohl Programmsteuerungs- als auch Programmrisiken (ARTs u. Teams) einheitlich in Jira abzubilden und gesamtheitlich zu reporten.



## Risikoreporting

TTT Risikomanagement basiert auf Jira als Single Source of Truth und Confluence für zielgerichtete Reporting Views.
Ziel ist es sowohl Programmsteuerungs- als auch Programmrisiken (ARTs u. Teams) einheitlich in Jira abzubilden und gesamtheitlich zu reporten.
Auszug TTT Risiko Dashboard - Risikomatrix:



## Governance und Schnittstellen

Die Governance für das Risikomanagement ist mehrstufig aufgesetzt:
- Team- und ART-Ebene: initiale Risikoerfassung, Monitoring, Maßnahmenverfolgung
- Solution-Ebene: Bündelung, Bewertung, Priorisierung (Solution-Sync, Deep Dives)
- Programmebene: zentrale Steuerung über PMO und Programmleitung, Eskalation kritischer Risiken in den Lenkungskreis / Solution Steuerung, Reporting & Maßnahmenabgleich


Überblick verlinkte Tools und Prozesse:
-  (C2S - Integrierte Fahrplan Plattform - ART)
-  (C2S - IDBF - ART)
-  (O2C - Order2Cash)
- 
- 
Capacity Management - ART: 20_Risiko Management
- 
Risiko Beschreibung TTTneo: TTTneo_Risiken
- Projekt TTTneo Risikodashboard in Jira