Migrate all repos into monorepo context folders

Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation.html

@@ -0,0 +1 @@
+<p style="text-align: left;">Diese Seite stellt die <strong>interne fachliche Dokumentation zum TTT-Programm</strong><span> </span>dar. Sie dokumentiert konsolidiert alle fachlichen Klärungspunkte und ergänzt die extern bindende Schnittstellenbeschreibung.<br /><br /></p><p style="text-align: left;">Als Vorstufe zu dieser ausführlichen fachlichen Dokumentation gibt es auch diese: <ac:link><ri:page ri:content-title="37 Fachliche Dokumentation - Arbeitsdokument" /></ac:link></p><p style="text-align: left;"><br /></p><p style="text-align: left;">Sie ist folgendermaßen untergliedert:</p><p style="text-align: left;"><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="2ae5e403-cde5-4263-9f30-3f0a6b709114" /></p><p style="text-align: left;"><br /></p><p style="text-align: left;"><br /></p><h2 style="text-align: left;">Hinweise zur Nutzung der Dokumentation</h2><p style="text-align: left;">Auf jeder Seite befindet sich oben ein Seitenstatus nach folgendem Muster:</p><ac:structured-macro ac:name="info" ac:schema-version="1" ac:macro-id="3ed8404f-44fd-423a-8dbe-0de35ea011a0"><ac:parameter ac:name="title">Seitenstatus</ac:parameter><ac:rich-text-body><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><td>Bearbeitungsstand</td><td><div class="content-wrapper"><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="8c457940-abff-432f-8ed1-8a4687343415"><ac:parameter ac:name="title">?</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro></p></div></td></tr><tr><td>Ansprechpartner</td><td><div class="content-wrapper"><p>@ Mister X</p></div></td></tr><tr><td>Letzte große Aktualisierung</td><td><div class="content-wrapper"><p>TT.MM.JJJJ</p></div></td></tr></tbody></table><p><br /></p></ac:rich-text-body></ac:structured-macro><p><strong>Bearbeitungsstand</strong></p><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="c4d584b5-97ed-4ff4-bc04-b8f934e32947"><ac:parameter ac:name="title">offen</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro> Das Thema wurde noch nicht für die Dokumentation freigeben oder die Dokumentation zu diesem Thema wurde noch nicht begonnen.</p><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="8b19f167-093a-48c5-b29f-190c09b1e8e7"><ac:parameter ac:name="colour">Yellow</ac:parameter><ac:parameter ac:name="title">in arbeit</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro> Das Thema befindet sich im Dokumentationsprozess. Teile sind eventuell schon dokumentiert.</p><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="873c0dfe-bd18-45ec-8fee-7bf7bf4a7370"><ac:parameter ac:name="colour">Red</ac:parameter><ac:parameter ac:name="title">veraltet</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro> Die Anforderungen an das Thema haben sich geändert. Die Seite ist nicht mehr aktuell und spiegelt eventuell unvollständige Informationen wider. </p><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="70d614d7-0483-4215-8170-47314f33c6ec"><ac:parameter ac:name="colour">Green</ac:parameter><ac:parameter ac:name="title">fertig</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro> Das Thema wurde final dokumentiert. Eine erneute Änderung der Dokumentation zu diesem Thema ist voraussichtlich nicht notwendig.</p><p><strong>Ansprechpartner</strong></p><p>Die Person, die zu dem Thema für Rückfragen zur Verfügung steht.</p><p><strong>Letzte große Aktualisierung</strong></p><p>Das Datum wann eine Aktualisierung der Seite erfolgte, die fachlich und inhaltlich relevante Auswirkungen hat.</p><p><br /></p><p><br /></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation.md

@@ -0,0 +1,38 @@
+# TAF/TAP TSI Fachliche Dokumentation
+
+> Page ID: 490596078 | Version: 7 | Space: TTSI
+
+---
+
+Diese Seite stellt die interne fachliche Dokumentation zum TTT-Programm dar. Sie dokumentiert konsolidiert alle fachlichen Klärungspunkte und ergänzt die extern bindende Schnittstellenbeschreibung.
+
+
+Als Vorstufe zu dieser ausführlichen fachlichen Dokumentation gibt es auch diese: 
+
+
+Sie ist folgendermaßen untergliedert:
+
+
+
+
+
+## Hinweise zur Nutzung der Dokumentation
+
+Auf jeder Seite befindet sich oben ein Seitenstatus nach folgendem Muster:Seitenstatus
+|  | Bearbeitungsstand | 
+?
+|  | Ansprechpartner | 
+@ Mister X
+|  | Letzte große Aktualisierung | 
+TT.MM.JJJJ
+
+
+Bearbeitungsstand
+offen Das Thema wurde noch nicht für die Dokumentation freigeben oder die Dokumentation zu diesem Thema wurde noch nicht begonnen.
+Yellowin arbeit Das Thema befindet sich im Dokumentationsprozess. Teile sind eventuell schon dokumentiert.
+Redveraltet Die Anforderungen an das Thema haben sich geändert. Die Seite ist nicht mehr aktuell und spiegelt eventuell unvollständige Informationen wider. 
+Greenfertig Das Thema wurde final dokumentiert. Eine erneute Änderung der Dokumentation zu diesem Thema ist voraussichtlich nicht notwendig.
+Ansprechpartner
+Die Person, die zu dem Thema für Rückfragen zur Verfügung steht.
+Letzte große Aktualisierung
+Das Datum wann eine Aktualisierung der Seite erfolgte, die fachlich und inhaltlich relevante Auswirkungen hat.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Abkürzungen.html

@@ -0,0 +1 @@
+<ac:structured-macro ac:name="info" ac:schema-version="1" ac:macro-id="3ed8404f-44fd-423a-8dbe-0de35ea011a0"><ac:parameter ac:name="title">Seitenstatus</ac:parameter><ac:rich-text-body><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><td>Bearbeitungsstand</td><td><div class="content-wrapper"><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="430c1060-979a-4a92-bfa8-4fcce5169314"><ac:parameter ac:name="colour">Yellow</ac:parameter><ac:parameter ac:name="title">in arbeit</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro></p></div></td></tr><tr><td>Ansprechpartner</td><td><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3cd97fcdaeab017fd00cf0a40001" /></ac:link>  </p></div></td></tr><tr><td>Letzte große Aktualisierung</td><td><div class="content-wrapper"><p><time datetime="2026-04-09" /></p></div></td></tr></tbody></table><p><br /></p></ac:rich-text-body></ac:structured-macro><p><br /></p><p><br /></p><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><th><p>Abkürzung</p></th><th><p>Beschreibung</p></th></tr><tr><td><p>CI  </p></td><td><p>Common Interface (technische Schnittstelle für Trassenanmeldung als einer von zwei Wegen von pathOS)</p></td></tr><tr><td>EIU</td><td>Eisenbahninfrastrukturunternehmen</td></tr><tr><td>EVU</td><td>Eisenbahnverkehrsunternehmen</td></tr><tr><td><span style="color:var(--ds-text,#172b4d);">FLP</span></td><td><br /></td></tr><tr><td>NSP</td><td>Network Specific Parameter (<span style="color:var(--ds-text,#333333);">Spezifische Attribute im Zuständigkeitsbereich eines EIU , die nicht in den europäisch festgelegten Standard-Attributen von TAF/TAP-TSI beinhaltet sind. Es handelt sich also um </span><span style="color:var(--ds-text,#333333);">EIU-spezifische nationalen Parameter, die vom jeweiligen EIU festgelegt werden können und dann im Zuständigkeitsbereich dieses EIU für Nachrichten zur Abwicklung der Geschäftsvorfälle zu nutzen sind. )</span></td></tr><tr><td><p>OTN</p></td><td><p>Operational Train Number</p></td></tr><tr><td><p>PA</p></td><td><p>Path</p></td></tr><tr><td><p>pathOS</p></td><td><p><span style="color:var(--ds-text,#333333);">Neues Trassenbestellsystem ab Fahrplanjahr 2027, bestehend aus einer technischen Schnittstelle und einem Webportal</span></p></td></tr><tr><td><p>PDM</p></td><td><p>Path Details Message</p></td></tr><tr><td><p>PLC</p></td><td><p>Primary Location Code</p></td></tr><tr><td><p>PRM</p></td><td><p>Path Request Message</p></td></tr><tr><td><p>PTCM</p></td><td><p>Passenger Train Composition Message (Personenverkehr)</p></td></tr><tr><td><p>RA</p></td><td><p>Responsible Applicant (bestellendes und vertragsbindendes EVU)</p></td></tr><tr><td><p>RoR</p></td><td><p><span style="color:var(--ds-text,#172B4D);">Reason of Reference ( siehe <a href="https://arija-confluence.jaas.service.deutschebahn.com/x/YP38HQ" class="">https://arija-confluence.jaas.service.deutschebahn.com/x/YP38HQ</a>)</span></p></td></tr><tr><td><p>RRU</p></td><td><p>ResponsibleRU</p></td></tr><tr><td><p>RU</p></td><td><p>Railway Undertaking, englische Bezeichnung für ein EVU (Eisenbahnverkehrsunternehmen)</p></td></tr><tr><td><span style="color:var(--ds-text,#172b4d);">SLC</span></td><td>Subsidiary Location Code</td></tr><tr><td><p>TCM</p></td><td><p>Train Composition Message (Güterverkehr) </p></td></tr><tr><td><p>TOI</p></td><td><p>TypeOfInformation (Art der Nachricht an den Kunden)</p></td></tr><tr><td><p>TPN</p></td><td><p>Trassen Portal Netz</p></td></tr><tr><td><p>TR</p></td><td><p>ReferenceTrain</p></td></tr></tbody></table><p><br /></p><p>Eine ausführlichere Erläuterungen von Begriffen finden sich auf:</p><p><a href="https://www.dbinfrago.com/resource/blob/11089224/1c9c5e81637ecedea763f04efad4013d/Download-TAF-TAP-Glossar-data.pdf">Download-TAF-TAP-Glossar-data.pdf</a></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Abkürzungen.md

@@ -0,0 +1,80 @@
+# Abkürzungen
+
+> Page ID: 553972827 | Parent: TAF-TAP-TSI-Fachliche-Dokumentation
+
+---
+
+Seitenstatus
+|  | Bearbeitungsstand | 
+Yellowin arbeit
+|  | Ansprechpartner | 
+  
+|  | Letzte große Aktualisierung | 
+
+
+
+
+
+
+
+|  | 
+Abkürzung | 
+Beschreibung
+|  | 
+CI   | 
+Common Interface (technische Schnittstelle für Trassenanmeldung als einer von zwei Wegen von pathOS)
+|  | EIU | Eisenbahninfrastrukturunternehmen
+|  | EVU | Eisenbahnverkehrsunternehmen
+|  | FLP | 
+
+|  | NSP | Network Specific Parameter (Spezifische Attribute im Zuständigkeitsbereich eines EIU , die nicht in den europäisch festgelegten Standard-Attributen von TAF/TAP-TSI beinhaltet sind. Es handelt sich also um EIU-spezifische nationalen Parameter, die vom jeweiligen EIU festgelegt werden können und dann im Zuständigkeitsbereich dieses EIU für Nachrichten zur Abwicklung der Geschäftsvorfälle zu nutzen sind. )
+|  | 
+OTN | 
+Operational Train Number
+|  | 
+PA | 
+Path
+|  | 
+pathOS | 
+Neues Trassenbestellsystem ab Fahrplanjahr 2027, bestehend aus einer technischen Schnittstelle und einem Webportal
+|  | 
+PDM | 
+Path Details Message
+|  | 
+PLC | 
+Primary Location Code
+|  | 
+PRM | 
+Path Request Message
+|  | 
+PTCM | 
+Passenger Train Composition Message (Personenverkehr)
+|  | 
+RA | 
+Responsible Applicant (bestellendes und vertragsbindendes EVU)
+|  | 
+RoR | 
+Reason of Reference ( siehe https://arija-confluence.jaas.service.deutschebahn.com/x/YP38HQ)
+|  | 
+RRU | 
+ResponsibleRU
+|  | 
+RU | 
+Railway Undertaking, englische Bezeichnung für ein EVU (Eisenbahnverkehrsunternehmen)
+|  | SLC | Subsidiary Location Code
+|  | 
+TCM | 
+Train Composition Message (Güterverkehr) 
+|  | 
+TOI | 
+TypeOfInformation (Art der Nachricht an den Kunden)
+|  | 
+TPN | 
+Trassen Portal Netz
+|  | 
+TR | 
+ReferenceTrain
+
+
+Eine ausführlichere Erläuterungen von Begriffen finden sich auf:
+Download-TAF-TAP-Glossar-data.pdf

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Einleitung.html

@@ -0,0 +1 @@
+<ac:structured-macro ac:name="info" ac:schema-version="1" ac:macro-id="3ed8404f-44fd-423a-8dbe-0de35ea011a0"><ac:parameter ac:name="title">Seitenstatus</ac:parameter><ac:rich-text-body><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><td>Bearbeitungsstand</td><td><div class="content-wrapper"><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="408debbd-480f-45f1-a12f-2e271b2eab91"><ac:parameter ac:name="title">Offen</ac:parameter></ac:structured-macro></p></div></td></tr><tr><td>Ansprechpartner</td><td><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3cd97ead808b017eb53d06d20002" /></ac:link> <ac:link><ri:user ri:userkey="8aeb3cd97fcdaeab017fd00cf0a40001" /></ac:link> </p></div></td></tr><tr><td>Letzte große Aktualisierung</td><td><div class="content-wrapper"><p><time datetime="2026-04-14" /></p></div></td></tr></tbody></table><p><br /></p></ac:rich-text-body></ac:structured-macro><p><br /></p><p><br /></p><p>Diese fachliche Dokumentation begleitet die Einführung der TAF/TAP‑TSI zum Netzfahrplan 2027 und beschreibt aus Prozess- und Fachsicht die Bestellung und Zuweisung von Trassen, die Bestellung und Zuweisung von Rahmenvertragskapazitäten sowie weitere Nebenleistungen im Bestellsystem der DB InfraGO. Sie richtet sich an Fachbereiche, Prozessverantwortliche, Betrieb und Governance und schafft ein einheitliches Verständnis von Rollen, Abläufen, fachlichen Regeln und Datenverantwortungen. Grundlage ist die Verpflichtung aus EU‑VO 62/2006/EG zur Nutzung harmonisierter TAF/TAP‑TSI‑Strukturen. Die technische Ausgestaltung der EVU‑Schnittstelle (Migration von TPN‑SST auf die TAF/TAP‑TSI‑konforme EVU‑SST, SST‑Dokumentation 4.0.0 ff.) wird nur kontextuell erwähnt; Details sind Gegenstand der separaten Schnittstellendokumentation.</p><p>Fokus und Geltungsbereich:</p><ul><li data-uuid="6d210739-8467-438e-b09c-02e1589b29b6">End‑to‑end‑Beschreibung der Geschäftsvorfälle im Trassenbestell‑ und Zuweisungsprozess (interoperabler und nicht interoperabler Verkehr)</li><li data-uuid="055fc1c4-d68f-409e-8f87-9d22e1521e30">Rollen, Verantwortlichkeiten, Governance und Datenqualität als Grundlage für Interoperabilität und Compliance</li><li data-uuid="d51bbac0-b3b3-4f09-9d78-7f9591675198">Übergang zum Netzfahrplan 2027 inklusive fachlicher Migrations‑ und Abnahmeaspekte</li></ul><p>Out of scope</p><ul><li data-uuid="53493ec6-e259-406b-9909-21aee5178c8e">Technische Spezifika sind out of scope</li><li data-uuid="27bd4987-10e1-4433-8a91-b17789574f00">Fachliche Regeln für Rahmenverträge und Rahmenvertragskapazitäten sowie die Bestellung weiterer Nebenleistungen sind out of scope</li></ul><p>Die folgenden Kapitel der Dokumentation liefern die fachliche Sicht auf:</p><ul><li data-uuid="526859ba-0586-4bd8-9fe5-93b929625c86">Geschäftsvorfälle im Trassenbestell‑ und Zuweisungsprozess untergliedert für die verschiedenen Fahrplanphasen</li><li data-uuid="31a426b6-01f4-40aa-b009-8b3974c3e849">Fachliche Beschreibungen von Prozessen, Regeln, Datenobjekten, die im Zusammenhang mit TTT stehen oder eingeführt werden</li><li data-uuid="a12598d9-0582-4aac-8b72-d6388952e0dd">Weitere Themen mit Bezug zu TTT</li></ul><p><br /></p><p><br /></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Einleitung.md

@@ -0,0 +1,31 @@
+# Einleitung
+
+> Page ID: 493882116 | Parent: TAF-TAP-TSI-Fachliche-Dokumentation
+
+---
+
+Seitenstatus
+|  | Bearbeitungsstand | 
+Offen
+|  | Ansprechpartner | 
+  
+|  | Letzte große Aktualisierung | 
+
+
+
+
+
+
+
+Diese fachliche Dokumentation begleitet die Einführung der TAF/TAP‑TSI zum Netzfahrplan 2027 und beschreibt aus Prozess- und Fachsicht die Bestellung und Zuweisung von Trassen, die Bestellung und Zuweisung von Rahmenvertragskapazitäten sowie weitere Nebenleistungen im Bestellsystem der DB InfraGO. Sie richtet sich an Fachbereiche, Prozessverantwortliche, Betrieb und Governance und schafft ein einheitliches Verständnis von Rollen, Abläufen, fachlichen Regeln und Datenverantwortungen. Grundlage ist die Verpflichtung aus EU‑VO 62/2006/EG zur Nutzung harmonisierter TAF/TAP‑TSI‑Strukturen. Die technische Ausgestaltung der EVU‑Schnittstelle (Migration von TPN‑SST auf die TAF/TAP‑TSI‑konforme EVU‑SST, SST‑Dokumentation 4.0.0 ff.) wird nur kontextuell erwähnt; Details sind Gegenstand der separaten Schnittstellendokumentation.
+Fokus und Geltungsbereich:
+- End‑to‑end‑Beschreibung der Geschäftsvorfälle im Trassenbestell‑ und Zuweisungsprozess (interoperabler und nicht interoperabler Verkehr)
+- Rollen, Verantwortlichkeiten, Governance und Datenqualität als Grundlage für Interoperabilität und Compliance
+- Übergang zum Netzfahrplan 2027 inklusive fachlicher Migrations‑ und Abnahmeaspekte
+Out of scope
+- Technische Spezifika sind out of scope
+- Fachliche Regeln für Rahmenverträge und Rahmenvertragskapazitäten sowie die Bestellung weiterer Nebenleistungen sind out of scope
+Die folgenden Kapitel der Dokumentation liefern die fachliche Sicht auf:
+- Geschäftsvorfälle im Trassenbestell‑ und Zuweisungsprozess untergliedert für die verschiedenen Fahrplanphasen
+- Fachliche Beschreibungen von Prozessen, Regeln, Datenobjekten, die im Zusammenhang mit TTT stehen oder eingeführt werden
+- Weitere Themen mit Bezug zu TTT

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Fachliche Beschreibungen.html

@@ -0,0 +1 @@
+<p><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="12860d70-5cda-4330-aa51-9cc87c4ea79d"><ac:parameter ac:name="all">true</ac:parameter></ac:structured-macro></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Fachliche Beschreibungen.md

@@ -0,0 +1,7 @@
+# Fachliche Beschreibungen
+
+> Page ID: 490596333 | Parent: TAF-TAP-TSI-Fachliche-Dokumentation
+
+---
+
+true

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Geschäftsvorfälle im Trassenbestell- und Zuweisungsprozess.html

@@ -0,0 +1 @@
+<p><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="1002529e-284b-4785-8524-311497b62b25"><ac:parameter ac:name="all">true</ac:parameter></ac:structured-macro></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Geschäftsvorfälle im Trassenbestell- und Zuweisungsprozess.md

@@ -0,0 +1,7 @@
+# Geschäftsvorfälle im Trassenbestell- und Zuweisungsprozess
+
+> Page ID: 490596584 | Parent: TAF-TAP-TSI-Fachliche-Dokumentation
+
+---
+
+true

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Weitere Themen mit Bezug zu TTT.html

@@ -0,0 +1 @@
+<p><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="03bde4fc-9a70-455c-88c8-d22fa84ca5c2"><ac:parameter ac:name="all">true</ac:parameter></ac:structured-macro></p><hr /><p>Neben den beschriebenen Geschäftsvorfällen und den fachlich beschriebenen Themen gibt es weitere Themen mit einem Bezug zu TTT. Diese sind entweder außerhalb des Fahrplans mit Schnittstellen zu diesem angesiedelt (Betrieb, Abrechnung, usw.) oder es sind Themen die vorläufig zur Produktivsetzung nicht umgesetzt werden (z.B. Bestellung von Rahmenverträgen).</p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Fachliche-Dokumentation_Weitere Themen mit Bezug zu TTT.md

@@ -0,0 +1,8 @@
+# Weitere Themen mit Bezug zu TTT
+
+> Page ID: 493882135 | Parent: TAF-TAP-TSI-Fachliche-Dokumentation
+
+---
+
+true
+Neben den beschriebenen Geschäftsvorfällen und den fachlich beschriebenen Themen gibt es weitere Themen mit einem Bezug zu TTT. Diese sind entweder außerhalb des Fahrplans mit Schnittstellen zu diesem angesiedelt (Betrieb, Abrechnung, usw.) oder es sind Themen die vorläufig zur Produktivsetzung nicht umgesetzt werden (z.B. Bestellung von Rahmenverträgen).

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte.html

@@ -0,0 +1 @@
+<ac:layout><ac:layout-section ac:type="two_right_sidebar"><ac:layout-cell><h1>1 Einführung &amp; Ziele der Programmakte</h1><h2>1.1 Einführung</h2><p>Die TAF/TAP TSI InfraGO Programmakte dokumentiert als Single Source of Truth das gesamte Programm auf den Ebenen Auftrag, Organisation, Governance, Funktionen und Prozesse.</p><h2>1.2 Ziel der Programmakte</h2><ul><li>Klarheit &amp; Struktur über das gesamte Programm hinweg</li><li>Transparenz für neue Teammitglieder, Gremien &amp; Stakeholder</li><li>Standardisierte Basis für Reporting, Steuerung und Kommunikation</li><li>Dokumentation von Entscheidungen, Risiken und Fortschritt</li></ul><p>Zur Dokumentation werden bereits vorhandene Confluence, Jira u. Beam Seiten für Projekte, Architektur, Testkonzept verlinkt und nicht vollständig die Inhalte übertragen. Auf Ebene der einzelnen Unterseiten bzw. Kapitel der Programmakte, wird der Status der Ergebnisse transparent gemacht, sodass eine kontinuierliche Aktualisierung der Arbeitsinhalte z.B. zur Planung bei gleichzeitiger Finalisierung von abgestimmten Inhalten z.B. Programmauftrag erfolgen kann.</p><h2>Inhalt Programmakte</h2><p><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="a1f421f8-9b82-4b28-bd4d-228a46fde211"><ac:parameter ac:name="depth">2</ac:parameter></ac:structured-macro></p></ac:layout-cell><ac:layout-cell><ac:structured-macro ac:name="info" ac:schema-version="1" ac:macro-id="1f6e3419-b039-4627-94c6-d1719ae77520"><ac:rich-text-body><p><strong style="letter-spacing: 0.0px;">Eigner der Seite</strong></p><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><th>Eigner Programmakte</th><th>Vetretung</th></tr><tr><td><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3e8a95ff72ca0196109f672f0043" /></ac:link> </p></div></td><td><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3e8a8c3c7f6b018cca66fe41010e" /></ac:link> </p></div></td></tr></tbody></table><p>Eigner der Programmakte ist die Programmleitung. Der Status wird nach signifikanten Abstimmungen eine hoch versioniert und hierzu aus der Versionshistorie von Confluence in die Tabelle übernommen.</p></ac:rich-text-body></ac:structured-macro><p><br /></p><p><span style="font-size: 16.0px;font-weight: bold;letter-spacing: -0.006em;">Bearbeitungsstatus</span></p><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><td>Status</td><td><div class="content-wrapper"><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="c63385e3-1782-4b10-994c-c4e0e9d424d1"><ac:parameter ac:name="colour">Green</ac:parameter><ac:parameter ac:name="title">Fertig</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro></p></div></td></tr><tr><td>Bearbeiter*in</td><td><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3e8a95ff72ca0196109f672f0043" /></ac:link> </p></div></td></tr><tr><td>Letzte abgestimmte Version<br />(Versionsnummer)</td><td>159</td></tr><tr><td>Erläuterung Abstimmung<br />(z.B. Gremium, Protokoll)</td><td>n.a.</td></tr></tbody></table><p><br /></p><p><br /></p></ac:layout-cell></ac:layout-section></ac:layout>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte.md

@@ -0,0 +1,38 @@
+# TAF/TAP TSI InfraGO Programmakte
+
+> Page ID: 424295009 | Version: 160 | Space: TTSI
+
+---
+
+## 1 Einführung & Ziele der Programmakte
+
+## 1.1 Einführung
+
+Die TAF/TAP TSI InfraGO Programmakte dokumentiert als Single Source of Truth das gesamte Programm auf den Ebenen Auftrag, Organisation, Governance, Funktionen und Prozesse.
+## 1.2 Ziel der Programmakte
+
+- Klarheit & Struktur über das gesamte Programm hinweg
+- Transparenz für neue Teammitglieder, Gremien & Stakeholder
+- Standardisierte Basis für Reporting, Steuerung und Kommunikation
+- Dokumentation von Entscheidungen, Risiken und Fortschritt
+Zur Dokumentation werden bereits vorhandene Confluence, Jira u. Beam Seiten für Projekte, Architektur, Testkonzept verlinkt und nicht vollständig die Inhalte übertragen. Auf Ebene der einzelnen Unterseiten bzw. Kapitel der Programmakte, wird der Status der Ergebnisse transparent gemacht, sodass eine kontinuierliche Aktualisierung der Arbeitsinhalte z.B. zur Planung bei gleichzeitiger Finalisierung von abgestimmten Inhalten z.B. Programmauftrag erfolgen kann.
+## Inhalt Programmakte
+
+2
+Eigner der Seite
+|  | Eigner Programmakte | Vetretung
+|  | 
+  | 
+ 
+Eigner der Programmakte ist die Programmleitung. Der Status wird nach signifikanten Abstimmungen eine hoch versioniert und hierzu aus der Versionshistorie von Confluence in die Tabelle übernommen.
+
+
+Bearbeitungsstatus
+|  | Status | 
+GreenFertig
+|  | Bearbeiter*in | 
+ 
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 159
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) | n.a.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_10 Roll-out und Hypercare.md

@@ -0,0 +1,70 @@
+# 10 Roll-out und Hypercare
+
+> Page ID: 467740446 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+  Diese Seite dient der Übersicht und Dokumentation zu den Themen Roll-out- und Hypercare im Rahmen des TTT Programms.
+ 
+
+
+
+
+
+|  | 
+Bearbeitungsstatus
+|  | Status | 
+YellowWIP
+|  | Bearbeiter*in | 
+ 
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 
+
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) | 
+
+
+
+## Einführungsplanung
+
+ 
+
+
+
+
+
+## Zielsetzung Hypercare
+
+- Sicherstellung des stabilen IT-Betriebs nach Go-Live durch abgestimmte Verfügbarkeiten und klare Eskalationswege
+- Schnelle Fehlerbehebung & Reaktion im Störungsfall
+- Auch bei intensiver Hypercare planmäßige Weiterentwicklung für spätere Fahrplanphasen (z.B. ujBau) sicherstellen
+- Fokus / Kritische Erfolgsfaktoren:
+- Erreichbarkeit der Teams (Zeitslots)
+- Schnelle Reaktionszeiten bei Defects/Incidents
+- Klare und schnelle Eskalationswege bei Störungen
+
+
+- Hypercare in diesem Ausmaß ist Projekt- und kein Betriebsaufwand
+- Wunsch für Teamverfügbarkeit für betroffene Teams - kann team-individuell im Detail festgelegt werden -
+- Unter der Woche:
+- Mindestzeit: 08:00–18:00 Uhr
+- Ideal: 07:00–19:00 Uhr
+- Rufbereitschaft / möglicher Einsatz:
+am Wochenende zur Bearbeitung neuer Defects (Prio 1 und 2) oder auch Abarbeitung von Lastspitzen geplant in erwarteten "heißen Phasen"
+
+
+## Planung und Gestaltung Hypercare
+
+Wir begleiten die Fahrplanphasen und fachlichen Rollout durch Hypercare, d.h. mit zusätzlicher Aufmerksamkeit und schnellen Reaktionszeiten für Beobachtungen auf Produktion. Dazu unterscheiden wir zwei Ausprägungen:
+|  | Hypercare | Heiße Phase Hypercare
+|  | 
+- Erhöhte Aufmerksamkeit und Reaktionszeit für Incidents
+- Mitwirkende Teams haben Kapazität frei für Analyse/Incident Behebung
+- Teams sind auch in Tagesrandzeiten unter der Woche zuverlässig verfügbar
+- Standardisierter Management Bericht über aktuellen Stand | 
+zusätzlich:
+- punktuelle Rufbereitschaft oder Arbeit außerhalb üblicher Arbeitszeiten für Wochenenden geplant
+-   Es ist nicht unser Ziel, regelmäßig am Wochenende zu arbeiten. Das ist ausschließlich eine Absicherung für den Fall, dass wir eine Bugwelle aufbauen, die wir zeitlich beschleunigt abbauen müssen. 
+
+
+Weitere Details werden auf den Unterseiten ausgearbeitet:

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_11 Taskforce Fahrplanwechsel.md

@@ -0,0 +1,257 @@
+# 11 Taskforce Fahrplanwechsel
+
+> Page ID: 578171019 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+## Zielsetzung Taskforce
+
+- Fokussierung auf Abschluss der fachlichen Klärung
+- Zusammenarbeit zwischen Fahrplan, Betrieb und Abrechnung intensivieren („wir wissen, wen wir ansprechen müssen“)
+- Abhängigkeits‑ und Risikomanagement in Bezug auf Betrieb und Abrechnung, um die Einführung abzusichern
+
+
+
+
+## Operationalisierung Taskforce
+
+Die Taskforce startet in der ersten Woche mit folgenden Schritten:
+- Abschluss fachliche Klärungspunkte fokussieren zunächst Fahrplan und Betrieb
+- E2E-Test mit Betrieb strukturieren und neu aufplanen
+- Kommunikation verbessern (alle wissen wo wir stehen)
+Danach wird der Scope inkrementell erweitert:
+- Fachliche Klärungspunkte für Abrechnung strukturieren und klären
+- Maßnahmen zur Reduktion des Risikos der späten Testergebnisse ableiten
+- Abhängigkeiten zur Abrechnung adressieren
+- Intensives Fortschrittstracking E2E-Test mit Betrieb
+- E2E-Test mit Abrechnung im Detail aufplanen
+- E2E-Test mit Abrechnung durchführen
+
+
+Die Taskforce stimmt Fortschritt und Unterstützungsbedarfe wöchentlich mit Management Vertretern ab: Synchronisation Taskforce Fahrplanwechsel
+
+
+## Abschluss fachliche Klärungspunkte fokussieren
+
+Die fachlichen Klärungspunkte zur Schnittstelle zwischen Fahrplan und Betrieb werden in Jira erfasst und die Ergebnisse dort getrackt.
+Die betroffenen Tickets sind: TTT Klärungsthemen - Agile Board - DB InfraGO ITD Lifecycle Management Tool
+
+Für alle diese Klärungspunkte wird zum Abschluss ein OnePager mit dem Ergebnis erstellt und im wöchentlichen Termin Synchronisation Taskforce Fahrplanwechsel eingebracht.
+
+Bisherige - abgelöste - Dokumentation
+Die folgenden Dokumentationen wurden in die Jira Tickets und die finale Ergebnisdokumentation überführt:
+
+
+- nn
+ Vollständigkeitscheck der Klärungstickets - in Arbeit
+Stand aus LKs
+|  | 
+# | 
+Finding | 
+Lösungsklärung | 
+Umsetzung | 
+Kommentar
+|  | 
+Zieldatum | 
+Stand | 
+Zieldatum | 
+Stand
+|  | 
+1 | 
+Umgang mit zeitlicher Stornierung (mittig oder am Ende) | 
+16.3.2026
+30.03.2026
+22.04.2026 | 
+ | 
+tbd | 
+ | 
+Testfälle am 02.04.26 fehlgeschlagen. Workshop zur Lösungsfindung erforderlich. Vermutung: IT-Anpassungen auf Seiten Betrieb und Fahrplan notwendig.
+|  | 
+2 | 
+Räumliche Stornierung | 
+16.3.2026
+30.3.2026
+tbd | 
+ | 
+tbd | 
+ | 
+Nicht alle Cases sind testbar; Abhängig vom Umsetzungszeitpunkt Fahrplan.
+|  | 
+3 | 
+Ausland-Inland-Ausland / Inland-Ausland-Inland im E2E-Test mit Betrieb | 
+16.3.2026
+23.3.2026
+02.04.2026
+20.04.2026 | 
+ | 
+tbd | 
+ | 
+Testcase ist testbar; Abstimmung zwischen Fahrplan und Betrieb ongoing; Testdurchführung ab 13.04.26 geplant
+|  | 
+4 | 
+Baubedingte Neubestellung (Verkaufsfaktor 0) | 
+16.3.2026
+30.3.2026
+02.04.2026
+20.04.2026 | 
+ | 
+tbd | 
+ | 
+Testcase ist testbar; Abstimmung zwischen Fahrplan und Betrieb ongoing; Testdurchführung ab 13.04.26 geplant
+|  | 
+5 | 
+Alle bekannten Logik-Änderungen mit TTT zwischen Fahrplan und Betrieb abstimmen | 
+16.3.2025
+02.04.2026 | 
+ | 
+n.a. | 
+n.a. | 
+Alle bekannten Logik-Änderungen wurden besprochen und werden in internen E2E-Tests berücksichtigt.
+|  | 
+6 | 
+Vergabe täglich wechselnder OTNs | 
+15.05.2026 | 
+ | 
+tbd | 
+ | 
+Anpassungsbedarf auf Seiten Fahrplan zu klären
+
+
+|  | 
+1 | 
+Umgang mit mittigem Teilausfall | 
+16.3.2026
+30.03.2026
+22.04.2026 | 
+ | 
+tbd | 
+ | 
+Testfälle konnten noch nicht alle durchgeführt werden. Nächster Termin am 01.04.
+|  | 
+2 | 
+Änderungsbestellungen (in Mitte) werden in NSS nicht korrekt verarbeitet | 
+16.3.2026
+30.3.2026
+02.04.2026 | 
+ | 
+tbd | 
+ | 
+Testfälle konnten noch nicht alle durchgeführt werden. Nächster Termin am 01.04.
+|  | 
+3 | 
+Klärung I-A-I im E2E-Test mit Betrieb | 
+16.3.2026
+23.3.2026
+02.04.2026 | 
+ | 
+tbd | 
+ | 
+Testfälle konnten noch nicht alle durchgeführt werden. Nächster Termin am 01.04.
+|  | 
+4 | 
+E2E-Test Betrieb Teilstorno Szenarien in NSS nicht verarbeitet | 
+16.3.2026
+30.3.2026
+02.04.2026 | 
+ | 
+tbd | 
+ | 
+Testfälle konnten noch nicht alle durchgeführt werden. Nächster Termin am 01.04.
+|  | 
+5 | 
+Alle bekannten Logik-Änderungen mit TTT zwischen Fahrplan und Betrieb abstimmen | 
+16.3.2025
+02.04.2026 | 
+ | 
+n.a. | 
+n.a. | 
+Alle bekannten Änderungen wurden besprochen. Risiko u.a. bei einer potentiellen täglichen neuen Vergabe der OTN
+
+
+Liste beim Betrieb
+
+20260408_lla_Testcases_Fahrplan.xlsx
+
+
+
+## E2E-Test mit Betrieb strukturieren und im Detail aufplanen
+
+Zielsetzung der geschärften Planung für den E2E-Test:
+- Fortschrittssteuerung ermöglichen
+- Fokus auf kritischste Themen zuerst
+- Abhängigkeiten zu Lieferplanung im Fahrplan insb. ujBau auflösen
+|  | Aufgabe | Wer | Bis wann | Ergebnis
+|  | 
+Dokumentation in Jira vervollständigen und parallele Listen etc. ablösen
+- Doku aus Termin2026-04-13 - Protokoll Aufplanung TTTSOL E2E-Betrieb - TAF/TAP Steuerung InfraGO - ariJa Confluence
+- Excelliste aus Betrieb mit kritischen Testfällen → war Grundlage für Tabelle von  , aber wurde ggf. weitergepflegt
+→ In Liste Ticket einfügen, damit Vollständigkeit auch dokumentiert | 
+ ,   | 
+  | 
+- Priorisierung fachlich pro Testfall → für den eigentlichen E2E-Test der Ziellösung
+- Kritisch
+- Hoch 
+- Mittel 
+- Niedrig
+- Kriterium für Prio:
+- Fokus auf Risiko: Dort wo wir das größte Risiko sehen, dass Fehler auftreten oder Anpassungen notwendig sind, schauen wir zuerst hin.
+-   Alle Testfälle werden durchgeführt. (Kein Auswahlkriterium)
+- Prio "Blocker" für alle Testfälle, die als Unterstützung für noch offene Konzeptfragen durchgeführt werden
+- Aus der Liste links sind entstanden:
+
+- Kritisch - besonders kritisch, zuerst anschauen im E2E-Test damit Risiko reduziert und potentieller Entwicklungsaufwand
+- und einige Blocker - für Konzeptklärung
+
+
+- An Testfälle den Bearbeiter dranschreiben - sofern es den gibt
+- Board mit Übersicht über die Testfälle mit passenden Filtern für folgende Infos:
+- open: geplant, technisch möglich (keine Entwicklung mehr offen) aber preconditions potentiell noch offen
+- Review = Preconditions liegen vor, Preconditions ebenfalls vorliegend
+- in progress: wird gerade getestet
+- blocked: entwicklung fehlt → Heike mit Fahrplan: Transparenz, an welcher Lieferung das jeweils hängt
+- Fertig: erfolgreich in Ziellösung getestet
+-  Welchen Status vergeben wir wenn der Testfall auf Status failed steht (fachlicher Fehler im Segmentverbund)? 
+- Kanban-Board mit Testfällen mit Stauts sowie Swimmlanes als Prio
+
+
+-  legt Board an und aktualisiert Testfallstatus  
+-   steuert Priorisierung ein als Planungsgrundlage nächste Woche (Ziel:  )
+
+
+- Termineinladung Regelabstimmung zu E2E-Testplanung und Fortschritt: Fr 12:00 Uhr, Sebastian, Heiko, Heike
+- Weiterarbeit an Reportung und Detailorga Einladung: Jens, Heiko, Heike, Andreas → Termin am Di schon eingeladen
+
+
+Wiedervorlage:
+- Preconditions
+- Testfälle
+- Testdurchführungen Test des Zielsystems zum Fahrplan
+- Testdurchführungen zur Unterstützung für Finalisierung fachliche Klärung
+|  | 
+Testfälle für Test des Zielsystems strukturieren und fachlich priorisieren "Paketieren" → Priorisierung auf Eben Testfall
+Abgrenzung: Tests als Unterstützung für aktuelle fachliche Klärung | tbd | tbd | 
+
+
+|  | Datum vollständige Testbarkeit auf KTU in Ziellösung für Fahrplanwechsel pro Testfallpaket | 
+ ,   | tbd (sobald Testfallpakete vorliegen) | 
+
+|  | Planung finalisieren
+
+- Pakete ggf. an Lieferzeitpunkte anpassen
+- Risiken identifizieren und potentiell Tests auf "Zwischenlösung" mit manuellen Eingriffen oder Workarounds einplanen | 
+tbd | tbd | 
+
+|  | 
+ | 
+
+ | 
+ | 
+
+
+
+## Kommunikation verbessern (alle wissen wo wir stehen)
+
+## Zielsetzung
+
+- Eine gemeinsame, allen Beteiligten bekannte Sicht auf die offenen Aufgaben und Ergebnisse. 
+- Schnellen Austausch ermöglichen, um Ansprechpartner:innen zu finden und "kleine" Fragen ohne warten auf einen Termin zu klären.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_2 Programmauftrag.md

@@ -0,0 +1,199 @@
+# 2 Programmauftrag
+
+> Page ID: 431620258 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+Anhand dieses Programmauftrages arbeiten die Mitwirkenden des Programms TAF/TAP TSI auf die Einführung zu. Es bildet die Grundlage für die Steuerung durch das Programm.
+
+
+2Gliederung* Bearbeitungsstatus
+
+
+
+
+## Bearbeitungsstatus
+
+|  | Status | 
+GreenFertig
+|  | Bearbeiter*in |  
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 44
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) | 
+Bestätigt durch Auftraggeber am  
+und Solution Steuerung am 
+
+
+## 2.1 Einleitung
+
+TAF/TAP TSI steht für „Telematics Applications for Freight and Passenger Services Technical Specifications for Interoperability“. Dabei handelt es sich um europäische Standards, die die Interoperabilität und den Datenaustausch im Schienenverkehr verbessern sollen.
+Die DB InfraGO AG (InfraGO) muss im Zusammenspiel mit den Eisenbahnverkehrsunternehmen auf Grundlage zweier EU-Verordnungen (1305/2014 TAF TSI und 454/2011 TAP TSI) die Steuerung des Zugbetriebs sowie Planungen und Anmeldungen von Zugfahrten standardisieren und digitalisieren. Hierfür wird die InfraGO die technischen Protokolle der „Telematic Applications Freight Services” (TAF) und „Telematics Applications Passenger Services” (TAP) mit den „Technical Specifications for Interoperability relating to Telematics Applications for Freight and Passenger Services“ (TSI), kurz TAF/TAP TSI (TTT) implementieren.
+Die InfraGO hat nach Inkrafttreten der EU-Verordnungen 2014 eine Nutzung von TTT im Fahrplan-jahr (FplJ 2017/2018) angekündigt. Bis 2024 wurde die Inbetriebnahme allerdings bereits 4-mal verschoben, bevor im Produktionsboard am 04.09.2024 eine erneute Verschiebung beschlossen werden musste. Die daraufhin eingesetzte Task Force hat im Produktionsboard am 30.10.2024 eine Neuplanung und Restrukturierung der Arbeiten und Verantwortlichkeiten vorgestellt, die eine Inbetriebnahme von TTT im FplJ 2027 vorsieht. Eine Übersicht des bisherigen Verlaufs aus Marktsicht findet sich auf der DB-externen Seite „DB-WATCH.de".
+Da die Implementierung der TTT-Funktionalitäten mehrere Geschäftsprozesse und eine Vielzahl von Systemen der DB InfraGO betrifft, braucht es für eine erfolgreiche Einführung eine übergreifende Steuerung. Hierbei kommt es im wesentlichen darauf an, die Abhängigkeiten und Risiken sowie das integrierte Testen über die unterschiedlichen involvierten IT-Umsetzungseinheiten innerhalb der DB InfraGO sicherzustellen.
+
+
+Die Einführung von TAF/TAP TSI (TTT) betrifft die End-2-End-Prozesse
+- Order-2-Cash O2C
+- Capacity-2-Schedule C2S
+- Schedule-2-Operate S2O
+und damit Kern-Geschäftsprozesse der DB InfraGO Geschäftsbereich Fahrweg.
+
+
+Die IT-Implementierung erfolgt in verschiedenen Umsetzungseinheiten:
+- Value Team O2C für die Funktionen der Trassenbestellung & -abrechnung
+- Value Team S2O für die betrieblichen Meldungen
+- Value Team C2S für die Fahrplanung und Veröffentlichung 
+
+(Quelle: https://db-planet.deutschebahn.com/pages/digitale-transformation-db-infrago/apps/content/end-2-end-prozesse-und-unsere-value-teams)
+
+
+
+
+## 2.2 Programmsteckbrief
+
+|  | Auftraggeber | 
+Robert Arnhold - CIO/CDO der DB InfraGO (I.IVI)
+|  | 
+Lenkungskreis LK | 
+Robert Arnhold (I.IVI)
+Matthias Feil (I.IBF)
+Miriam Grafflage (I.IBV)
+Christoph Koch (I.IBB)
+Anatol Scholz (I,IBF 1)
+Bastian Ebinger (I.IVI 4)
+Heike Sperber (Programmleitung)
+
+|  | Nutzeneigner | 
+Matthias Feil (I.IBF)
+Miriam Grafflage (I.IBV)
+Christoph Koch (I.IBB)
+|  | Programmleitung | 
+  (ab  )
+|  | Zeitleiste und Meilensteine | Zielsetzung ist die Einführung der TTT-Funktionalitäten in den relevanten Systemen für das Fahrplanjahr 2027
+|  | Bestätigungsdatum Lenkungskreis | 
+geplant für  
+|  | Budgetrahmen / Benötigte Ressourcen | 
+Das Programm TTT beschafft und steuert die Ressourcen auf Ebene des Programms. 
+Die notwendigen Ressourcen in den verschiedenen IT-Umsetzungseinheiten werden über die jeweiligen Value Teams (VTs) beschafft und gesteuert.
+Der Ressourcenbedarf auf Programmebene - mit Stand vom   - ist:
+- Übergreifendes Testmanagement - 5 VZP
+- PMO Reporting - 1 VZP
+- PMO Taskforces und übergreifende IT-Themen - 2 VZP
+- PMO Masterplan und Risikomanagement - 1 VZP
+- Technische Projektleitung TTT Projekt Netz und GelV - 1 VZP
+- Technische Unterstützung Fokusgruppe ujBau - 1 VZP
+- IT-Controlling / Mittelabflusskontrolle und Beauftragungen - 0,2 VZP
+Der Budgetrahmen für 2025 ist abgesichert, die Hinterlegung der notwenigen Mittel für 2026 ist Bestandteil der laufenden Planungsrunde (PLR25). 
+Die bisherigen Beauftragungen laufen bis Mitte 2025 und werden gemäß den Erfordernissen kontinuierlich erweitert.
+|  | Strategische Bewertung | 
+Die DB InfraGO hat folgende Vorteile für die Einführung von TTT identifiziert:
+- Stärkere Wettbewerbsfähigkeit
+- Grenzüberschreitend eine Identifikation
+- Einheitlicher Kommunikationsweg für Trasseninformationen
+- Bessere betriebliche Durchführung
+- 
+Aktive Mitgestaltung der europäischen Harmonisierung und konsequente Umsetzung der TAF/TAP TSI-Vorgaben für Infrastruktur und Betrieb
+- 
+Verlässliche Einführung bis 2027 als zentrale Zielsetzung, um nationale und grenzüberschreitende Prozesse vollständig auf die neuen Standards umzustellen
+- 
+Maximale Transparenz und Begleitung der Marktteilnehmer, durch intensive Information, klare Anleitungen und frühzeitige Einbindung in Umstellungsprozesse
+- 
+Bereitstellung moderner, intuitiver IT-Lösungen für Trassenanmeldung und Betrieb, um die Prozesseffizienz im Eisenbahnsektor deutlich zu erhöhen
+- 
+Nachhaltige Verbesserung der Wettbewerbsfähigkeit des Schienenverkehrs in Europa, durch digitalen, standardisierten und zuverlässigen Datenaustausch.
+Trotzdem liefert die Einführung von TTT an sich keinen direkten Geschäftsnutzen für die DB InfraGo über die Einhaltung der zugehörigen EU-Verordnungen (1305/2014 TAF TSI und 454/2011 TAP TSI) hinaus.
+Somit ist TTT eine regulatorische Anforderung aus EU-Verordnungen, die durch die DB InfraGO und allen weiteren Marktteilnehmern entsprechend umgesetzt werden müssen.
+|  | Ziel | 
+Das Programm TAF / TAP TSI der DB InfraGO steuert die Einführung der TAF/TAP TSI Norm für die gesamte Prozesskette von Vertrieb über Fahrplankonstruktion bis hin zu Betrieb aus.
+Fokus ist hierbei das Sicherstellen der zeitgerechten Einführung der TTT Funktionalitäten durch ein übergreifendes Abhängigkeits- und Risikomanagement sowie das Steuern integrierter Tests innerhalb der DB InfraGO und Koordination entsprechender Tests mit dem Markt. 
+Die eigentliche IT-Implementierung erfolgt in den unterschiedlichen involvierten IT-Umsetzungseinheiten innerhalb der DB InfraGO.
+|  | Nutzen (quantifiziert) | 
+keiner
+|  | Wirtschaftlichkeitsrechnung | 
+nicht anwendbar
+|  | Scope TTT Realisierung in den Umsetzungseinheiten | 
+Der inhaltlich zu realisierende Scope der IT-Umsetzung richtet sich nach
+- EU Dokumentation
+- Dokumentation der Schnittstelle des Bestellsystems der DB InfraGO AG für EVU-Systeme
+
+Die Implementierung von TTT ist aus Sicht des DB Konzerns insgesamt ein komplexes Unterfangen. Die InfraGO agiert als Eisenbahninfrastrukturunternehmen (EIU) im Sinne eines Service Providers gegenüber einem Markt von EVU, der diskriminierungsfrei bedient werden muss und zusammen mit den größten EVU der DB (DB Regio, DB Fernverkehr, DB Cargo) etwa 400 Marktteilnehmer umfasst. Da nach Umschaltung auf TTT kein Parallelbetrieb des bisherigen Trassensystems möglich ist, muss InfraGO von Anfang an eine stabile, betriebsfähige Lösung liefern.
+Innerhalb der InfraGO setzt sich die TTT-Gesamtlösung aus einem Verbund von Systemen zusammen, die über Schnittstellen interagieren und verschiedene Teile der benötigten Leistungsprozesse umsetzen, so dass mehrere Solutions (O2C, C2S, S2O) zusammenarbeiten und eine integrierte Gesamtlösung schaffen müssen.
+|  | In Scope - TTT Solution Steuerung (Programm) | 
+Das TTT-Programm bildet die steuernde Klammer über mehrere IT-Projekte und agile IT-Produktentwicklungen aus den Bereichen Vertrieb (I.IBV), Fahrplan (I.IBF) und Betrieb (I.IBB) für die TTT-relevanten Aspekte. Die Umsetzung von TAF/TAP TSI wird vor allem aus 3 Solution Value Teams getragen:
+- Das VT Order2Cash organisiert Prozessabläufe und Systeme an der Kundenschnittstelle.
+- Das VT Capacity2Schedule steht für Kapazitätsmanagement und Fahrplan.
+- Das VT Schedule2Operate steht für den Eisenbahnbetrieb der InfraGO.
+
+
+Scope TTT Solution Steuerung (Programm)
+- Integrierte Gesamtplanung über die beteiligten IT-Projekte und agilen IT-Umsetzungsorganisationen hinweg (basierend auf Projekt- / Produktplanung) insbesondere Abhängigkeitsmanagement​
+- Integrierte Testplanung (Ende-zu-Ende, E2E) und Durchführung InfraGO mit Markt​
+- Integrierte Releaseplanung InfraGO mit Fokus Markttests (basierend auf Projekt / Solution Plan)​
+- Integrierter Einführungsplanung DB InfraGO (basierend auf Projekt / Solution Plan)​
+- Kommunikation mit dem Markt​
+- Übergreifende Umsetzungsüberwachung und Berichterstattung​
+- Übergreifendes Risikomanagement (Zeit / Scope / Qualität)​
+- Koordination und Nachhalten von TTT-spezifischen fachlichen Klärungen zwischen DB InfraGO und dem Markt sowie Nat. / Internat. Gremien​
+- Budget- und Ressourcensteuerung für Programmteam
+|  | Out of Scope - TTT Solution Steuerung (Programm) | 
+- Budgetmanagement der IT-Projekte / agilen IT-Umsetzungsorganisationen je Value Team​
+- Ressourcensteuerung der IT-Projekte / agilen IT-Umsetzungsorganisationen je Value Team​
+- Anforderungs- & Scopemanagement der IT-Projekte und IT-Produktentwicklungen je Value Team​
+- Fachliches Veränderungsmanagement (Prozesse, Schulung, Mitbestimmung u.a.)​
+- Herstellung Betriebsbereitschaft der IT-Projekte und IT-Produktentwicklungen je Value Team​
+- Zeitgerechte und qualitative Lieferung der IT-Projekte und IT-Produktentwicklungen je Value Team
+|  | Programmorganigramm | 
+siehe 
+|  | Beteiligte u. Ressourcen (Stakeholders) | 
+- "Markt" - EVU als Kunden der DB InfraGO
+- DB Konzern, da die Einführung als ein zentrales Digitalisierungsvorhaben eingestuft ist
+- Fachbereiche der DB InfraGo:
+- Vertrieb
+- Fahrplan
+- Betrieb
+- Value Teams und agile Produktorganisationen:
+- Das VT Order2Cash organisiert Prozessabläufe und Systeme an der Kundenschnittstelle.
+- Das VT Capacity2Schedule steht für Kapazitätsmanagement und Fahrplan.
+- Das VT Schedule2Operate steht für den Eisenbahnbetrieb der InfraGO.
+- CIO/CDO Bereich der DB InfraGo Fahrweg
+- Sekundärasset Verantwortliche
+- CISO und IT-Governance
+|  | Lieferobjekte | 
+- Integrierter Gesamtplan für die Umsetzung und Einführung von TTT (siehe )
+- Risikoreporting und Mitigationsmaßnahmen (siehe )
+- Testkonzept und Testplan (siehe )
+|  | Chancen | Umsetzung von TTT schafft Grundlage für fachliche Weiterentwicklung in Bezug auf Prozessvereinfachung und Prozessdigitalisierung vor allem im Bereich Fahrplan.
+|  | Risiken | 
+Die kritischsten Risiken des Programms sind unten aufgelistet. 
+Die Gesamtsicht auf alle Risiken, die die Einführung TTT betreffen, werden in Jira kontinuierlich aktualisiert, siehe .
+|  | Abhängigkeiten | 
+- EVUen im Markt müssen ihre Prozesse insb. zur Bestellung zeitlich passend umstellen - siehe Risiko
+- Abhängigkeiten zu anderen Programmen und Projekten insb. in Bezug auf Ressourcenverfügbarkeit (z. B. .B. Annex VII, SB², ujBau) - siehe Risiko
+
+
+## Wichtigste Programmrisiken - Stand  
+
+|  | Schlüssel | Zusammenfassung | Beschreibung
+|  | TTTSOL-52 | Unrealistische Go-Live-Entscheidung für Fpl27 gefährdet Betrieb | 
+Start von TTT zum FplJ 2027 kann nicht innerhalb der geplanten Parameter und Prämissen umgesetzt werden, mit teils gravierenden Folgen bzgl. Kosten und Reputation für den gesamten DB-Konzern. Sofern eine Go-Live-Entscheidung auf Basis falscher Annahmen, fehlerhafter Informationen und unrealistischer Prognosen unumkehrbar getroffen wird, können sich daraus massive betriebliche Risiken für die Beauftragung und Disponierbarkeit von Trassen ergeben. 
+|  | TTTSOL-51 | Rückstand bei funktionalen Anforderungen gefährdet planmäßige Inbetriebnahme | 
+Ein Umsetzungsstand hinter Plan bei funktionalen und nicht-funktionalen Anforderungen erhöht das Risiko, die Inbetriebnahme nicht wie geplant durchführen zu können. Es drohen wirtschaftliche Nachteile und Reputationsschäden durch weitere Verschiebungen.
+|  | TTTSOL-50 | Budgetrisiken gefährden zeit- und qualitätsgerechte Umsetzung von TTT | 
+Unvorhergesehene Budgetreduktionen können die zeit- und qualitätsgerechte Umsetzung von TTT erheblich beeinträchtigen. Aktuell wird unter der Annahme geplant, dass die Teams konstant bleiben, aber bei Preissteigerung und optimistisch gleichbleibendem Budget ist diese Annahme nicht haltbar.
+|  | TTTSOL-49 | Unzureichendes Abhängigkeitsmanagement führt zu Fehlplanungen und Verzögerungen | 
+Fehlendes Verständnis und unzureichende Steuerung der Abhängigkeiten können zu Fehlplanungen und weiteren Verzögerungen führen. 
+|  | TTTSOL-48 | Unzureichende Operationalisierung der vereinbarten Priorisierung führt zu Ressourcenengpässen und gefährdet die Einführung zum Fpl27 | 
+Konkurrenz um begrenzte Ressourcen kann zu Verzögerungen und ineffizienten Arbeitsprozessen führen. Die aktuelle Priorisierung von TTT vor anderen kritischen Themen (Annex VII, KaZu Novum..) ist nicht ausreichend ausgesteuert um das Ziel der Einführung für Fpl27 zu erreichen.
+|  | TTTSOL-47 | Mangelnde Qualitätssicherung gefährdet den zweckmäßigen Einsatz der Lösung mit wirtschaftlichen und regulatorischen Folgen | 
+Ohne ausreichende Verifikation und Qualitätssicherung der Gesamtlösung ist der zweckmäßige Einsatz gefährdet, mit potentiell gravierenden wirtschaftlichen und ggf. regulatorischen Folgen
+|  | TTTSOL-44 | 
+Überplanung im Bereich ujBau gefährden Programmziel und operatives Geschäft nach einer potentiellen Einführung | 
+In der Railmap Planung vom 23.4.2025 sind 110 Jobsize Capabilities (Annahme 8Jobsize ~ 1 Team für ein PI) nicht mit Kapazität hinterlegt bzw. nicht eingeplant. Dazu gehören u.a. Enabler zur Sicherstellung der Inbetriebnahme neuer Tools.
+Der Priorisierungskonflikt zwischen Enabler, die TTT relevant sind, um die notwendigen Tools einzuführen und Fachlichkeit für andere Themen wurde zugunsten der anderen Themen entschieden. 
+Es besteht das Risiko, dass neue Tools, die für die Einführung TTT zum Fpl27 notwendig sind, nicht eingeführt werden können oder zwar mit bewusster Risikoübernahme eingeführt werden, danach aber nicht stabil betriebsführbar sind und das operative Geschäft dauerhaft behindern.
+|  | TTTSOL-42 | 
+Fehlende fachliche Steuerung der Meilensteine und Intransparenz über fachliche Vollständigkeit der Detaillierung gefährdet das Programmziel | 
+Zur Erreichung von TTT Meilensteinen - insb. im ujBau aber auch im TTT Projekt Netz & GelV - sind Lieferungen mehrerer Teams notwendig.
+Der Scope ist in Capabilities/Meilensteien übergreifend beschrieben. Die Umsetzung in den Teams erfolgt anhand von Stories. Unzureichende fachliche Steuerung / Scope-Mgmt kann dazu führen, dass zwar die beteiligten Teams ihre geplanten Stories abschließen, die angestrebte Capability oder der angestrebte Meilenstein aber nicht erreicht wird, da der notwendige Scope nur unzureichend heruntergebrochen wurde und unvollständig in den Teams ankam.
+Aus Programm-Ebene sind solche Unvollständigkeiten erst zu spät - wenn das Ergebnis der Capability / des Meilensteins im anschließenden Systemintegrationstest nicht die nötwendige Qualität hat - sichtbar. Damit ist die notwendige Steuerbarkeit nicht gegeben.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_3 Programm Organisation.html

@@ -0,0 +1 @@
+<p><ac:inline-comment-marker ac:ref="1ca73ba3-6e65-495b-9636-591c92216af1">Die Organisation des TTT-Programms gliedert sich in zwei zentrale Ebenen: </ac:inline-comment-marker></p><ul style="list-style-type: square;"><li>Die Programmsteuerung, die alle übergreifenden Steuerungs- und Unterstützungsfunktionen bündelt. In <ac:link><ri:page ri:content-title="2 Programmauftrag" /></ac:link> ist der genaue Scope erklärt.</li><li>Die Projektebene, bestehend aus den fachlichen Solutions Vertrieb (O2C), Fahrplan (C2S) und Betrieb (S2O), die jeweils spezifische Geschäftsanforderungen und Capabilities umsetzen.</li></ul><p><ac:inline-comment-marker ac:ref="1ca73ba3-6e65-495b-9636-591c92216af1">Das Programm TAP/TAF TSI umfasst damit folgende Organisationselemente:</ac:inline-comment-marker></p><p><span class="toc-item-body"><a href="https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=431620297"><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="5213f40b-a349-446c-9c4f-f7b307e90319"><ac:parameter ac:name="depth">2</ac:parameter></ac:structured-macro></a></span></p><p><br /></p><p><br /></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_3 Programm Organisation.md

@@ -0,0 +1,11 @@
+# 3 Programm Organisation
+
+> Page ID: 431620291 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+Die Organisation des TTT-Programms gliedert sich in zwei zentrale Ebenen: 
+- Die Programmsteuerung, die alle übergreifenden Steuerungs- und Unterstützungsfunktionen bündelt. In  ist der genaue Scope erklärt.
+- Die Projektebene, bestehend aus den fachlichen Solutions Vertrieb (O2C), Fahrplan (C2S) und Betrieb (S2O), die jeweils spezifische Geschäftsanforderungen und Capabilities umsetzen.
+Das Programm TAP/TAF TSI umfasst damit folgende Organisationselemente:
+2

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_4 Tools.html

@@ -0,0 +1 @@
+<ac:layout><ac:layout-section ac:type="two_right_sidebar"><ac:layout-cell><p>Das Programm TAF/TAP TSI nutzt auf Ebene der Programmsteuerung und Solutions sowie Projekte hauptsächlich die folgenden Tools:</p><p><br /></p><p><span class="toc-item-body"><a href="https://arija-confluence.jaas.service.deutschebahn.com/display/TTSI/4.1+TTT+Enterprise+Architecture"><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="8ea7da37-3c28-4dfc-ae20-52356378c923"><ac:parameter ac:name="depth">2</ac:parameter></ac:structured-macro></a></span></p><p><br /></p><p><br /></p></ac:layout-cell><ac:layout-cell><p><strong>Bearbeitungsstatus</strong></p><table><colgroup class=""><col class="" /><col class="" /></colgroup><tbody class=""><tr class=""><td>Status</td><td><div class="content-wrapper"><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="79e4e444-9868-4163-a24d-15cd57f6b003"><ac:parameter ac:name="colour">Yellow</ac:parameter><ac:parameter ac:name="title">in arbeit</ac:parameter><ac:parameter ac:name="" /></ac:structured-macro></p></div></td></tr><tr class=""><td>Bearbeiter*in</td><td><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3e8a953fa638019571399ebb0210" /></ac:link> </p></div></td></tr><tr class=""><td>Letzte abgestimmte Version<br />(Versionsnummer)</td><td><br /></td></tr><tr class=""><td>Erläuterung Abstimmung<br />(z.B. Gremium, Protokoll)</td><td><br /></td></tr></tbody></table></ac:layout-cell></ac:layout-section></ac:layout>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_4 Tools.md

@@ -0,0 +1,24 @@
+# 4 Tools
+
+> Page ID: 431620391 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+Das Programm TAF/TAP TSI nutzt auf Ebene der Programmsteuerung und Solutions sowie Projekte hauptsächlich die folgenden Tools:
+
+
+2
+
+
+
+
+Bearbeitungsstatus
+|  | Status | 
+Yellowin arbeit
+|  | Bearbeiter*in | 
+ 
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 
+
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) |

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_5 Integrierter Programmplan _Masterplan_.md

@@ -0,0 +1,56 @@
+# 5 Integrierter Programmplan "Masterplan"
+
+> Page ID: 431640505 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+Auf dieser Seite ist das Vorgehen zur integrierten Programmplanung dokumentiert:
+Bearbeitungsstatus 
+
+
+##  Bearbeitungsstatus
+
+|  | Status | 
+GreenFertig
+|  | Bearbeiter*in | 
+ , ,   
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 30
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) | Freigegeben durch Programmleitung
+
+
+## Zielsetzung
+
+Ziel des integrierten Gesamtplans für TTT ist eine Solution/Projekt-übergreifende Planung mit Transparenz über Meilensteine, Abhängigkeiten und terminliche Notwendigkeiten herzustellen. Diese Planung soll:
+- Kritische Abhängigkeiten zwischen den Solutions/Projekten aufzeigen
+- Eine belastbare zeitliche Planung bis zur Betriebsbereitschaft liefern 
+- Abhängigkeiten insbesondere zwischen den zu unterstützenden Geschäftsprozessen NEP1, NEP2, GelV sowie ujBau, Betrieb und Vertrieb präzise auflösen
+- Planungsprämissen und Risiken transparent machen
+- Handlungsempfehlungen zur Risikomitigation ermöglichen
+Die "Masterplanung" wird somit zum zentralen Steuerungsinstrument des Gesamtprogramms, mit dem Ziel, die operative Umsetzungsfähigkeit zum Fahrplanjahr 2027 sicherzustellen.
+
+
+## Planerisches Vorgehen
+
+Die übergreifende Programmplanung basiert auf den einzelnen Plänen aus den Projekten/Solutions, die über mehrere Iterationen hinweg in einen abgestimmten Gesamtplan überführt werden. Grundlage dafür ist die Tatsache, dass die einzelnen Solutions/Projekte bereits eigenständig geplant haben und jeweils Planungsmethodiken entwickelt haben, die in ihrem Kontext etabliert sind. 
+Die Planungen in den Solutions/Projekten dienen somit nicht als Vorstufe, sondern als faktischer Startpunkt der übergreifenden Planung. Die Aufgabe liegt in der Aggregation, Klärung und Synchronisierung dieser Inputs. Dabei sind die Pläne weniger als Entwürfe, sondern als reale Steuerungsgrundlage zu verstehen, deren Qualität und Passfähigkeit zunächst bewertet werden muss.
+- Die vorliegenden Planungen sind unterschiedlich weit entwickelt, teils mit konkreten Meilensteinplanungen, teils mit groben Umsetzungszeiträumen
+- Es bestehen Abhängigkeiten zu anderen Vorhaben, zur betrieblichen Einsatzreife und zu regulatorischen Fristen (z. B. TAF/TAP-Anforderungen)
+- Auch technische Konvergenzpunkte, z. B. gemeinsame Altsystemanbindungen oder koordinierte Umschaltzeitpunkte, sind planungsrelevant
+Auf dieser Basis erfolgt die methodische Konsolidierung. Das bedeutet: Es werden keine parallelen Planungsphasen aufgesetzt, sondern ein strukturierter Prozess etabliert, um bestehende Inhalte übergreifend verwertbar zu machen. Hierbei übernimmt das zentrale PMO eine koordinierende Rolle. Es sammelt, prüft und verdichtet die Planungsstände, ohne die Verantwortung für die Inhalte aus den Solutions/Projekten herauszulösen. 
+Herzstück dieses Vorgehens ist die Planungswerkstatt. Dort werden die kritischen Punkte adressiert – nicht als reine Reviewrunde, sondern als aktives Abstimmungsformat. Ziel ist ein gemeinsames Verständnis darüber, welche Zeitachsen realistisch sind und wie sie zusammenpassen müssen, um tragfähig zu sein. Dabei steht nicht das „Big Picture“ im Vordergrund, sondern die konkrete operative Anschlussfähigkeit der Planung:
+- Offene Fragen zu funktionalen Überschneidungen oder technischen Integrationsbedarfen werden dort direkt geklärt
+- Zielkonflikte zwischen betrieblichen Go-Live-Zeitpunkten und internen Entwicklungszyklen werden explizit gemacht
+- Die Planungswerkstatt stellt sicher, dass Planung nicht nur synchronisiert, sondern auch fachlich fundiert abgestimmt ist
+Im Anschluss wird der gemeinsam verabschiedete Masterplan in ein zentrales Steuerungstool (Jira) überführt. Dabei handelt es sich nicht um ein statisches Dokument, sondern um eine dynamisch fortschreibbare Referenzstruktur, die als „Single Source of Truth“ für alle programmweiten Steuerungsfragen dient. Der Plan bildet die Grundlage für Folgeprozesse – etwa zur Kapazitätsplanung, Testabstimmung und Umsetzungssteuerung. Auch die technische Integration spielt hier eine wichtige Rolle. Für EVU-nahe Systeme bedeutet das insbesondere:
+- Konsistenz zwischen IT-Systemplanung und betrieblichem Fahrplanprozess (z. B. VNP/ENP, Trassenmanagement)
+- Abbildung von Meilensteinen, die mit externen Partnern abgestimmt werden müssen (Marktschnittstellen, Zulieferer)
+- Integration betrieblicher Abhängigkeiten, insbesondere rund um Inbetriebnahmen und betriebsnahe Tests
+Die Qualität der übergreifenden Programmplanung bemisst sich letztlich nicht primär an der Vollständigkeit des Plans, sondern an seiner Wirksamkeit in der Steuerung der Umsetzung. Ziel ist ein integriertes, realistisch belastbares Steuerungsinstrument, das laufend weiterentwickelt und geschärft wird, nicht als Planungsdokument, sondern als operative Entscheidungsbasis.
+
+
+
+## Aktueller Planungsstand
+
+Der aktuelle Stand der Planung liegt hier:

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_6 Teststrategie, Testkonzept und Testplanung.md

@@ -0,0 +1,205 @@
+# 6 Teststrategie, Testkonzept und Testplanung
+
+> Page ID: 431633569 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+Die Qualitätssicherung der TAF/TAP TSI-Gesamtlösung erfolgt entlang einer übergreifenden, abgestimmten Teststrategie.
+Ziel ist die frühzeitige Validierung der fachlichen und technischen Anforderungen sowie die Sicherstellung der Betriebsfähigkeit in End-to-End-Prozessen. Das erfolgt sowohl innerhalb der DB InfraGO als auch im Zusammenspiel mit den Eisenbahnverkehrsunternehmen (EVU).
+Dieses Kapitel beschreibt die grundlegenden Teststufen, das Testvorgehen in den Solutions sowie die Planung und Steuerung der integrierten Tests inklusive der Markttests.
+2
+## Bearbeitungsstatus
+
+|  | Status | 
+GreenFertig
+|  | Bearbeiter*in | 
+ 
+ 
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 110
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) | Freigabe durch Programmleitung
+
+
+
+
+## Überblick Teststufen und Verantwortung für diese
+
+Der Test im Rahmen der Umsetzung von TAP/TAF TSI umfasst folgende Teststufen:
+- Kundentest
+- Abnahmetest
+- Systemintegrationstest
+- Systemtest
+- Integrationstest
+- Komponententest
+
+
+
+Dabei ist die Verantwortung für die Teststufen wie folgt definiert:
+- Die Steuerung der Tests erfolgt durch das TTT Testmanagement ab Ebene Systemintegrationstest. 
+- Die Durchführung liegt von Komponententest bis Systemintegrationstests bei den Projekten/Solutions
+- Die Unterscheidung zwischen Durchführung und Steuerung ist dabei wie folgt zu verstehen:
+- Steuerung: Die die einzelnen Solutions bzw. Teams/Systeme (Beispiel TPN, Rut-K, GFD, PathOS, ...) den Anforderungsscope ihrers Systems bzw. ihrer Umsetzungsleistung kennen, jedoch nicht zwingend Anforderungen, welche sich aus übergreifenden Geschäftsprozessen an sie ergeben, ist die Verantwortung für Testaktaktivitäten, da Anforderungsscope bekannt, bis auf Systemtestebene durch die Solutions/Teams zu steuern. Gegen übergreifende Anforderungen, kommend aus E2E-Geschäftsprozessen bzw. TTT generell, steuert das übergreifende Testmanagement der Programmsteuerung/Solution Steuerung, da diese den E2E-Prozessscope betrachten. Dies beginnt bei der InfraGO-internen, aber System-übergreifenden Integrationstests (Teststufe Systemintegrationstest nach Pyramide) bis hin zu Abnahmetests mit den Kunden.
+- Durchführung: Die Durchführung der Testaktivitäten bis einschließlich Systemtest findet auf Ebene der Entwicklungsteams statt. Systemintegrationstests (beispielsweise die ART-üg Tests) werden durch das übergreifende Testteam Quest der Solution C2S durchgeführt. Punktuell kann hier Unterstützungsleistung aus den einzelnen Teams angefragt werden. Die InfraGO-Abnahmetests und die Kundentests werden moderiert durch die Makrttestleads und durchgeführt durch dedizierte Kollegen aus den Solutions, welche für diese Teststufen bereitgestellt werden.
+
+
+## Verantwortung für Qualitätssicherung in TTT Testmanagement
+
+Das Testmanagement im Programm TTT steuert die folgenden Teststufen: 
+- Systemintegrationstest:
+- Hierbei steht die übergreifende Zusammenarbeit von Systemen und Services im Vordergrund auf der funktionalen E2E-Kette
+- Die einzelnen Systeme und Services sind hierbei als Blackbox zu sehen. Die Bestellung werden per TPN bzw. Portal eingekippt und geprüft wird das entsprechende Ergebnis (Vertrag mit dem Kunden)
+- Testumfang: ausgewählte Tests (automatisiert/manuell) entsprechend der Priorisierung regressiv nach jedem Release und progressiv für jede neue Funktionalität
+- Dokumentation:
+- Testfälle sind in Xray hinterlegt
+- Ziel:
+- manuelle Testausführungen werden zukünftig in Xray ausgeführt ( ~25% der ART-übergreifenden Testfälle) 
+- automatisierte Testausführungen werden in TDM dokumentiert (~75% der ART-übergreifenden Testfälle)
+- Test-Bericht:
+- Ziel ist es, automatisiert aus Xray bzw. TDM Testergebnisse zu reporten
+- die Ergebnisse der automatisierten Tests sind sichtbar in https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/GelV_ART_ue_GTests_%C3%9Cbersicht.html?env=abnTTT 
+- allerdings fehlt hier stand heute die Verbindung zu den getesteten Anforderungen und gefundenen Defects
+- Beispiel 
+- Aktuell werden die Ergebnisse der manuellen Tests manuell zusammengestellt
+- Abnahmetest
+- Hierbei geht es um eine Blackbox Betrachtung der DB InfraGO mit Fokus auf realistische Kundenbestellungen und deren Verarbeitung
+- Bestellung werden manuell über das Portal eingepflegt oder über das Common Interface gesendet (  Abdeckung beider Kanäle ist wichtig) und orientieren sich an realistischen Kundenbestellungen, entweder vom Vertrieb oder den Testfällen der Kunden
+- Testumfang: Testfälle werden manuell entlang neuer Funktionalität durchgeführt, Regression ist bisher nicht vorgesehen
+- Dokumentation:
+- Testfälle werden in Xray hinterlegt
+
+
+- Kundentest
+- Hierbei geht es um Blackboxtests gemeinsam mit dem Kunden mit dem Ziel, Teilprozesse, Gesamtprozesse und Varianzen dieser (Attribute) zu testen
+- Kunden schicken Bestellungen über ihre Systeme an das Common Interface, darüber kommen sie ins unsere Systeme. Wir bearbeiten die Bestellungen und schicken sie über das Common Interface zurück an die Kunden. Diese prüfen die eingegangenen Nachrichten.
+- Testumfang: Testfälle werden manuell entlang des testbaren Scopes durchgeführt
+- Dokumentation:
+- Testdurchführung wird in den Testsheets gemeinsam mit den Kunden dokumentiert (Ablage in Teams, das mit den Testpartnern geteilt wird)
+- Bericht siehe 100 Statusreporting
+Das übergreifende Testmanagement verantwortet dabei folgende Testarten: 
+- 
+Funktionale Tests nach Testpyramide (beschrieben bereits oben)
+- 
+Smoketests: Werden stündlich auf der ITU und KTU durchgeführt und prüfen eine einfache Anmeldung bis zum Vertragsschluss im GelV und NEP. Ergebnisse können hier getrackt werden:
+- ITU GelV: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/GelV_Index.html?env=ituTTT
+- ITU NEFP: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/Nfpl_Index.html?env=ituTTT
+- ITU uj Bau: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/ujBau_Index.html?env=ituTTT
+- 
+KTU GelV: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/GelV_Index.html?env=abnTTT
+- 
+KTU NEFP: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/Nfpl_Index.html?env=abnTTT
+- 
+Shakedown Tests: Gemeinsam mit Kunden wird nach dem InfraGO Release und vor einer Kundentestsession eine Basisbestellung (Einfach Anmeldung Basiszug mit jeweiligen EVU im NEFP) durchgeführt.
+- 
+(Kundentests) Markttests
+- 
+Last- und Performance Test für die Gesamtprozesskette
+
+
+## Verantwortung für Qualitätssicherung in Projekten/Solutions
+
+Die Projekte / Solutions sind für die Qualitätssicherung, der von ihnen gelieferten Software verantwortlich. Dazu steuern sie die Tests in folgenden Teststufen:
+- Komponententest
+- Integrationstests
+- Systemtest
+Die Projekte/Solution verantworten darüber hinaus die qualitätsgesicherte Lieferung in die Teststufen Systemintegrationstest und Abnahmetest sowie den Kundentest.
+Durch die einzelnen Projekte/Solutions sind die folgenden Testarten abzudecken:
+- Funktionale Tests (siehe Testpyramide)
+- Last- und Performance Tests auf Ebene eines Systems
+- 
+Penetration Tests
+- 
+Desaster Recovery
+
+
+## Testvorgehen
+
+Das Vorgehen zum ART-übergreifenden Test umfasst die folgenden Teilaspekte:
+- Testscope & Testfälle
+- Testablauf insb. Kundentests
+- Defect Mgmt
+- Testreporting
+- Umgebungen
+- Testdatenmanagement
+
+
+## Testscope
+
+Der gemeinsame Nenner der Entwicklung aller InfraGO Anteile, sowie der Entwicklung unserer Kunden stellt die öffentlich verfügbare Schnittstellenbeschreibung dar. In aktuellster Form ist zu finden unter https://www.dbinfrago.com/web/schienennetz/netzzugang-und-regulierung/taf-tap-tsi/evu_schnittstelle-11089208. Zim   ist die aktuelle Version 4.6.1.
+Für den Test betrachten wir auf strategischer Ebene die TTT Teilprozesse und die technischen/fachlichen Attribute, welche in Summe eine TTT-Nachricht beschreiben:
+Prozesse
+Die Teilprozesse, Prozessbilder und Beschreibungen sind hierbei in folgendem Dokument zu finden: (Original Quelle: Link | Auszug: Link)  in Kapitel 5.
+- Intern bilden wir die Prozesse aktuell wie folgt ab - veraltet-
+
+|  | Zusammenfassende Sicht aus TTTneo: 
+|  | 
+
+Attribute - veraltet
+Die technischen/fachlichen Attribute sind hauptsächlich in folgendem Anforderungsdokument zu finden: (Original Quelle: Link | Auszug: Link)
+- Intern haben wir im Conflience ein Attributmapping aus der Schnittstellenbeschreibung in die umsetzenden Systeme aufgebaut:
+
+|  | Attributmapping TTTneo: https://arija-confluence.jaas.service.deutschebahn.com/x/hUdKGQ
+|  | 
+
+
+
+## Testvorgehen entlang Anforderungsmatrix
+
+Der Scope übergreifend betrachtet ergibt sich entsprechend aus der Kombination von Teilprozessen/Geschäftsvorfällen mit den zugehörigen Attributen. Dies kann in Form einer Matrix dargestellt werden, wobei auf der X-Achse die Teilprozesse genannt sind und auf der Y-Achse die Attribute genannt sind. Das Testvorgehen deckt diese Anforderungsmatrix nun in drei Schritten jeweils pro Teststufe ab:
+- Happy Path Tests Teilprozesse
+- Ablauf: Es ist im ersten Schritt sicherzustellen, dass alle (im aktuellen Testscope (bspw. für den Sommer NEP1) Teilprozesse mit einem Basiszug (einfachstes Setup von Attributen, keine Infrastrukturherausforderungen, kurzer Laufweg,...) erfolgreich durchlaufen werden können
+- Gewünschte Erkenntnisse: Die Prozesse sind nach Schnittstellenvereinbarung sauber implementiert und können von Kunden durchlaufen werden (Betrachtung rein der Prozesssicht, bewusst ohne Komplexität, um prozessuale Fehler auszuschließen)
+- Einfach Attributtests
+- Ablauf: Es sind Einzelattribute (bspw. Alternative Charakteristika, Nachtsprung, Gefahrengüter,...) in einem möglichst einfach Szenario (kurzer Laufweg, keine komplexen Attributkombinationen,...) zu prüfen
+- Gewünschte Erkenntnisse: Die Attribute für sich genommen funktionieren und können durch die InfraGO Systeme und die im Schritt 1 getesteten Teilprozesse sauber verarbeitet werden
+- Komplexe Tests
+- Ablauf: Da wir nun wissen, dass alle Teilprozesse und alle Einzelattribute funktionieren, testen wir nun die beliebige (erlaubte) Kombination von Attributen und Teilprozessen (intern am Beispiel real vom Kunden bestellter Züge), durch Kunden anhand ihrer produktionsnahen Bestellungen
+- Gewünschte Erkenntnisse: Kann unser System produktive Züge von Heute (und nach Schnittstellenbeschreibung auch von Morgen erlaubte) sauber abbilden und die Prozesse mit gewünschten Ergebnis (zum Beispiel Vertragsendzustand) abbilden?
+
+
+Die Testfälle sind in  ausgeführt.
+
+
+## Defect Management
+
+in Arbeit
+
+
+## Testreporting
+
+Das Reporting erfolgt - zum Stand  wöchentlich 100 Statusreporting. Zusätzlich erfolgt ein Beitrag zum Lenkungskreis TTT.
+
+
+## Umgebungen - veraltet
+
+Die Umgebungen zur Durchführung der Systemintegrations-, Abnahme- und Markttests werden durch die Projekte/Solutions verwaltet und bereitgestellt.
+Für C2S und O2C gibt es folgende Umgebungen:
+- Fachliche Beschreibung: für C2S  und Details für TTT Neo 
+- Technische Übersicht und aktueller Status Smoke-Test: https://reporting-phaseg.konbel.comp.db.de/itt/Testergebnisdashboard-TTT/
+Es gab signifikante Herausforderungen zur Umgebungsstabilität. Daher wurde eine Taskforce ins Leben gerufen. Seit April 2025 wurden Fehler der Umgebungen zunächst in Excel getrackt (https://dbsw.sharepoint.com/:x:/r/teams/TTT-Portfolio-Management/_layouts/15/Doc.aspx?sourcedoc=%7B6A721131-9152-4EB2-93F0-311F6836178A%7D&file=KTU_Fehlertracking_Liste.xlsx&action=default&mobileredirect=true). Seit  werden Probleme mit der Umgebung als Defects erfasst und in Jira getrackt.
+
+
+## Testdatenmanagement
+
+ Das Testdatenmanagement erfolgt heute dezentral bei den jeweiligen Systemen. Da - auch produktiv - viele Systeme für gleiche fachliche Daten unterschiedliche Quellen nutzen, kommt es immer wieder zu Herausforderungen insb. in Bezug auf die Infrastrukturdaten, da das Mapping bei IDBF im Infrastrukturdatenmanager (IM) veraltet ist.
+
+
+## Testplanung
+
+Die Testplanung für Integrations- und Markttests basiert jeweils auf den Release- bzw. Lieferplänen der Projekte/Solutions. Die benötigten Testaktivitäten werden nach dem Abschluss von Entwicklung und Qualitätssicherung in den ARTs - Erreichung Meilenstein in Planung der Projekte/Solutions - geplant. 
+Je nach fachlichem Inhalt des Meilensteins werden die benötigten Testfälle ermittelt und daraus die notwendige Zeit für die Testdurchführung inkl. Nachtests unter der Annahme, dass FixIT aller kritischen Defects zeitnah erfolgt, ermittelt. 
+- 10 Testkonzept u. Planung
+Stand vom  gibt es die zeitliche Planung oben, aber diese ist noch nicht ressourcentreu. 
+
+
+## Informativ: Testvorgehen in den Projekten / Solutions
+
+Hier sind informativ Link zu Dokumentation des Vorgehens zur Qualitätssicherung in Projekten / Solutions eingefügt, sofern sie der Programmsteuerung und dem übergreifenden Testmanagement vorliegen. Die Liste hat keinen Anspruch auf Vollständigkeit:
+- Dokumentation aus Sicht O2C
+- QA Test Bestellsystem
+- Dokumentation aus Sicht C2S
+- 
+- 
+- 
+- Dokumentation aus Sicht S2O
+- Planung auf Ebene Meilenstein:Â

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

@@ -0,0 +1,158 @@
+# 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

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_8 Go_No-Go Entscheidung Fplj 27.html

@@ -0,0 +1 @@
+<ac:layout><ac:layout-section ac:type="two_right_sidebar"><ac:layout-cell><p>Auf dieser Seite wird die Erarbeitung der Kriterien für die Go/No-Go-Entscheidung sowie später deren Bewertung dokumentiert. Ebenfalls enthalten wird das Vorgehen sein.</p><p><ac:structured-macro ac:name="toc" ac:schema-version="1" ac:macro-id="894dec33-6ab6-4e09-9e9d-b55f16a74cc8"><ac:parameter ac:name="exclude">Bearbeitungsstatus</ac:parameter></ac:structured-macro></p><p><br /></p></ac:layout-cell><ac:layout-cell><h3 style="text-align: left;"><span>Bearbeitungsstatus</span></h3><table class="wrapped"><colgroup><col /><col /></colgroup><tbody><tr><td style="text-align: left;vertical-align: top;">Status</td><td style="text-align: left;vertical-align: top;"><div class="content-wrapper"><p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="35155432-a751-4989-a1a3-262d4213fd28"><ac:parameter ac:name="colour">Yellow</ac:parameter><ac:parameter ac:name="title">IN ARBEIT</ac:parameter></ac:structured-macro></p></div></td></tr><tr><td style="text-align: left;vertical-align: top;">Bearbeiter*in</td><td style="text-align: left;vertical-align: top;"><div class="content-wrapper"><p><ac:link><ri:user ri:userkey="8aeb3e8a95ff72ca0196109f672f0043" /></ac:link> <ac:link><ri:user ri:userkey="8aeb3e8a953fa638019561281539013e" /></ac:link> </p></div></td></tr><tr><td style="text-align: left;vertical-align: top;">Letzte abgestimmte Version<br />(Versionsnummer)</td><td style="text-align: left;vertical-align: top;"><br /></td></tr><tr><td style="text-align: left;vertical-align: top;">Erläuterung Abstimmung<br />(z.B. Gremium, Protokoll)</td><td style="text-align: left;vertical-align: top;"><br /></td></tr></tbody></table></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><p><br /></p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><h1>Zeitlicher Rahmen Go/No-Go-Entscheidung</h1><p>Auszug aus Lenkungskreis TTT vom <time datetime="2025-07-23" /> </p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="two_right_sidebar"><ac:layout-cell><p>Messung vor Stellungnahmeverfahren (04.08.) für LK 06.08.</p><p>Messung nach Stellungnahmeverfahren (15.09.) für LK <s>17.09.</s> -&gt;<em> </em><strong><em>angepasst Entscheidungstermin: 16.09.</em></strong></p><p><ac:image ac:height="241"><ri:attachment ri:filename="image-2025-7-22_10-56-58-1.png" /></ac:image></p></ac:layout-cell><ac:layout-cell><p>Formaler Hintergrund:<br /><br /></p><p><ac:image ac:thumbnail="true" ac:height="150"><ri:attachment ri:filename="image-2025-6-2_15-5-38-1.png" /></ac:image></p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><p><br /></p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><p><br /></p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><h1 style="color:var(--ds-text,#172b4d);">Zielsetzung Vorbereitung Go/No-Go-Entscheidung</h1><p>Vorbereitung/Ermöglichung einer faktenbasierten Go/No-Go-Entscheidung, welche eine realistische Einschätzung des Erfolges eines Go-Lives zum Fplj 27 zulässt.</p><p><span style="color:var(--ds-background-accent-red-bolder,#c9372c);"><strong>Kriterien werden ausgewählt mit zwei Perspektiven:  </strong></span></p><ul><li data-uuid="57d2ad52-b267-4e05-87c9-5bd9ef99dbd6">Um mit <strong>9 Monaten Vorlauf <u><span>sicher zu sein</span></u></strong>, dass der GoLive erfolgreich sein wird, benötigen wir die erfüllten Kriterien.<ul><li data-uuid="afd69660-bd67-4bfe-82e0-737e6c67cc09">Das ist NICHT die Sichtweise: Welche Kriterien erfüllen wir nach aktuellem Plan wann.  Die Messung, ob die definierten Kriterien erfüllt sind, folgt als Schritt 2. Ggf. können dann auch noch Abweichungen von den Kriterien als Risiken akzeptiert werden.</li></ul></li><li data-uuid="6106abca-4f84-4ee5-ac3e-968456b8f2c9">Sind wir vorbereitet, um mit unvorhergesehenen Ereignissen umzugehen? (Rückfallszenario, Plan B)</li></ul></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><p><br /></p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><h1>Kriterien Go/No-Go-Entscheidung</h1><p>Die Kriterien für die Go/No-Go Entscheidung werden hier ausgearbeitet und auch die Messungen dokumentiert. <ac:link><ri:page ri:content-title="01 Kriterien Go/No-Go mit Messungen" /></ac:link></p></ac:layout-cell></ac:layout-section><ac:layout-section ac:type="single"><ac:layout-cell><p><br /></p></ac:layout-cell></ac:layout-section></ac:layout>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_8 Go_No-Go Entscheidung Fplj 27.md

@@ -0,0 +1,50 @@
+# 8 Go/No-Go Entscheidung Fplj 27
+
+> Page ID: 452989953 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+Auf dieser Seite wird die Erarbeitung der Kriterien für die Go/No-Go-Entscheidung sowie später deren Bewertung dokumentiert. Ebenfalls enthalten wird das Vorgehen sein.
+Bearbeitungsstatus
+
+
+## Bearbeitungsstatus
+
+|  | Status | 
+YellowIN ARBEIT
+|  | Bearbeiter*in | 
+  
+|  | Letzte abgestimmte Version
+(Versionsnummer) | 
+
+|  | Erläuterung Abstimmung
+(z.B. Gremium, Protokoll) | 
+
+
+
+## Zeitlicher Rahmen Go/No-Go-Entscheidung
+
+Auszug aus Lenkungskreis TTT vom  
+Messung vor Stellungnahmeverfahren (04.08.) für LK 06.08.
+Messung nach Stellungnahmeverfahren (15.09.) für LK 17.09. -> angepasst Entscheidungstermin: 16.09.
+
+Formaler Hintergrund:
+
+
+
+
+
+
+
+## Zielsetzung Vorbereitung Go/No-Go-Entscheidung
+
+Vorbereitung/Ermöglichung einer faktenbasierten Go/No-Go-Entscheidung, welche eine realistische Einschätzung des Erfolges eines Go-Lives zum Fplj 27 zulässt.
+Kriterien werden ausgewählt mit zwei Perspektiven:  
+- Um mit 9 Monaten Vorlauf sicher zu sein, dass der GoLive erfolgreich sein wird, benötigen wir die erfüllten Kriterien.
+- Das ist NICHT die Sichtweise: Welche Kriterien erfüllen wir nach aktuellem Plan wann.  Die Messung, ob die definierten Kriterien erfüllt sind, folgt als Schritt 2. Ggf. können dann auch noch Abweichungen von den Kriterien als Risiken akzeptiert werden.
+- Sind wir vorbereitet, um mit unvorhergesehenen Ereignissen umzugehen? (Rückfallszenario, Plan B)
+
+
+## Kriterien Go/No-Go-Entscheidung
+
+Die Kriterien für die Go/No-Go Entscheidung werden hier ausgearbeitet und auch die Messungen dokumentiert.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_9 Terminkalender.html

@@ -0,0 +1 @@
+<p><span style="color:var(--ds-text,#172b4d);">In diesem Terminkalender sind die Termine rund um TTT aufgenommen, die zur Steuerung oder Kundenkommunikation dienen.</span></p><p style="text-align: left;"><span style="color:var(--ds-text,#172b4d);">Die Testplanung erfolgt separat unter</span><span> </span><a href="https://arija-confluence.jaas.service.deutschebahn.com/spaces/TTSI/pages/431633569/6+Teststrategie+Testkonzept+und+Testplanung">6 Teststrategie, Testkonzept und Testplanung</a>.</p><p style="text-align: left;"><br /></p><p style="text-align: left;"><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="968388e8-8130-422c-8e05-387fe5a39f63" /></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmakte_9 Terminkalender.md

@@ -0,0 +1,8 @@
+# 9 Terminkalender
+
+> Page ID: 509056664 | Parent: TAF-TAP-TSI-Programmakte
+
+---
+
+In diesem Terminkalender sind die Termine rund um TTT aufgenommen, die zur Steuerung oder Kundenkommunikation dienen.
+Die Testplanung erfolgt separat unter 6 Teststrategie, Testkonzept und Testplanung.

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung.html

@@ -0,0 +1 @@
+<p><span class="toc-item-body"><a href="https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=431620297"><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="2d2e70de-2ed8-4843-9585-35da3565a165"><ac:parameter ac:name="depth">2</ac:parameter></ac:structured-macro></a></span></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung.md

@@ -0,0 +1,7 @@
+# TAF/TAP TSI Programmsteuerung
+
+> Page ID: 428930895 | Version: 12 | Space: TTSI
+
+---
+
+2

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_01 So arbeiten wir.html

@@ -0,0 +1 @@
+<p>In Ergänzung zur  sind hier operative Arbeitsabläufe im jeweils aktuellen Stand festgehalten. Diese Dokumentation richtet sich an die jeweiligen Beteiligten:</p><p><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="c378bcbb-be65-4760-9e17-89ee42d13e32" /></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_01 So arbeiten wir.md

@@ -0,0 +1,7 @@
+# 01 So arbeiten wir
+
+> Page ID: 452990804 | Parent: TAF-TAP-TSI-Programmsteuerung
+
+---
+
+In Ergänzung zur  sind hier operative Arbeitsabläufe im jeweils aktuellen Stand festgehalten. Diese Dokumentation richtet sich an die jeweiligen Beteiligten:

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_02 Programmtermine.html

@@ -0,0 +1 @@
+<p><ac:structured-macro ac:name="pagetree" ac:schema-version="1" ac:macro-id="34124533-4e90-4203-8740-9b558cb16a24"><ac:parameter ac:name="root"><ac:link /></ac:parameter></ac:structured-macro></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_02 Programmtermine.md

@@ -0,0 +1,7 @@
+# 02 Programmtermine
+
+> Page ID: 386396509 | Parent: TAF-TAP-TSI-Programmsteuerung
+
+---
+
+

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_03 Programmreporting.html

@@ -0,0 +1 @@
+<p><ac:structured-macro ac:name="pagetree" ac:schema-version="1" ac:macro-id="0af3a902-6979-4c7e-b89b-d11e77274c0d"><ac:parameter ac:name="root"><ac:link /></ac:parameter></ac:structured-macro></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_03 Programmreporting.md

@@ -0,0 +1,7 @@
+# 03 Programmreporting
+
+> Page ID: 386396593 | Parent: TAF-TAP-TSI-Programmsteuerung
+
+---
+
+

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_04 Marktkommunikation.html

@@ -0,0 +1 @@
+<p><ac:structured-macro ac:name="children" ac:schema-version="2" ac:macro-id="edc6f6fb-2d12-442d-88ed-9742244eacd9" /></p>

bahn/project-audit/data/confluence-ttsi/TAF-TAP-TSI-Programmsteuerung_04 Marktkommunikation.md

@@ -0,0 +1,7 @@
+# 04 Marktkommunikation
+
+> Page ID: 556717763 | Parent: TAF-TAP-TSI-Programmsteuerung
+
+---
+
+