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

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.