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