Orchestrator/bahn/project-audit/data/confluence-export/pages/27526069_3.3 Wesentliche Aenderungen -Soll-.md

3.3 Wesentliche Änderungen ("Soll")

Confluence Page ID: 27526069 Version: 58 Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/3 Geschäftsprozesse/3.3 Wesentliche Änderungen ("Soll") Labels:

---

Einführung

Durch die Umsetzung des Bestellsystems in der Ausbaustufe "Minimal Viable Product" werden die Prozesse zum Kapazitätsmanagement im wesentlichen in neuen Systemen nachgebaut ohne Veränderungen einzuführen. An den grundsätzlichen Inhalten und dem Ablauf der Prozesse „LN 34 Fahrplan und Kapazitätsmanagement durchführen“ und "LN 32 Trassen und Anlagen vermarkten" ergeben sich dementsprechend keine Änderungen. Gemäß des FIB-Fachkonzepts ist eine Umbenennung der beiden zuvor genannten Prozesse vorgesehen, da diese auf die beiden Domänen Vertrieb und Fahrplan eindeutig aufgeteilt werden sollen. Das Ziel ist eine klare Aufteilung der Prozesse in einen reinen Anmelde-/Bestellvorgang und anschließend in einen Konstruktions-/Produktionsvorgang. Die Namensänderungen und ggf. Prozessumgestaltung sind nicht im Rahmen des Projekts zur Erstellung eines neuen Bestellsystems zu verantworten. Die Namensänderung kann über das Programm FIB in Absprache mit den Process Ownern der LN-Prozesse durchgeführt werden. Die jeweils aktuellen, in der Rolle des Process Owner verantwortlichen Personen, können im Prozessportal der DB Netz AG eingesehen werden. Darüber hinaus können die relevanten Geschäftsprozesse in BPMN Notation mit der neuen Nachrichtenstruktur von TAF/TAP-TSI im Enterprise Architect Modell (Projekte/ Plan-Phase/ Bestellportal/ Prozesse - Arbeitsstand) eingesehen werden.

Trennung Fahrplan <> Vertrieb

Die Trennung Fahrplan <> Vertrieb beinhaltet das Ziel, die IT-Landschaft so neu zu ordnen, dass die Verantwortlichkeiten der IT-Komponenten bei den Prozessschritt-Verantwortlichen Domänen verortet ist. Die heutige Prozesslandschaft unterscheidet grundsätzlich in Verantwortlichkeiten des Vertriebs und des Fahrplans auf Ebene der LN Prozesse. Künftig hat der Vertrieb eine Rolle in den Prozessen der Trassenanmeldungen, sowohl im Netzfahrplan als auch im Gelegenheitsverkehr, wobei die entsprechenden Prozessschritte Vorgänge Trassenanmeldung (Ausgangsszustand: Trassenanmeldung liegt vor) und Ergebnisübermittlung von Fahrplankonstruktionen (Aufgabe des Konstrukteurs: Trassenangebot abgeben) heute nicht weiter detailliert sind. Eine weitere Detaillierung wird voraussichtlich auch nur in verfeinierten Prozessabbildungen erforderlich sein. Durch die Trennung Fahrplan <> Vertrieb übernimmt der Vertrieb die Verantwortung für den Nachrichtentransport zwischen EVU und Fahrplan. Dies wird technisch über eine TAF/TAP TSI Kommunikationsschnittstelle, das so genannte Common Interface, realisiert. Für Kunden, die nicht über ein schnittstellenfähiges, externes Zugfahrt-Planungssystem verfügen bietet der Vertrieb außerdem mit dem Bestellportal eine entsprechende Komponente an, die aus Prozesssicht DB Netz gewährleistet, dass alle Kunden in einem einheitlichen, technischen Anmeldungsformat Trassen bestellen und so gleichberechtigt am System Schiene im Netz der DB Netz AG teilnehmen können. Der Prozessstart aller Geschäftvorfälle im Zusammenhang mit Trassenanmeldungen, Trassenvertragsänderungen oder Trassenvertragsstornierungen liegt dabei entweder weiter beim Kunden oder beim Fahrplan. Der Vertrieb übernimmt keine gestaltende Rolle in den Prozessen sondern gewährleistet in Richtung Kunden ausschließlich die Einhaltung der TAF/TAP konformen Kommunikation und stellt die Kommunikationswege bereit. In Richtung Fahrplan tritt der Vertrieb als Konstruktionsauftraggeber auf, ohne Einfluss darauf zu nehmen, wie das Fahrplankonstruktionsergebnis zustande kommt. Mit dem Ziel der Trennung Fahrplan <> Vertrieb werden folgende neue Begrifflichkeiten definiert:

Vermarktetes Produkt

Das Bestellsystem wird in der ersten Produktivversion im Wesentlichen nur die Vermarktung der Trassenprodukte der DB Netz AG zum Ziel haben. Die Trassenprodukte und das Trassenpreissystem sind in Abstimmung mit dem Regulierer durch I.NMK 2 entwickelt worden und unterliegen turnusmäßigen Prüfungen und ggf. Anpassungen alle fünf Jahre. Nachdem das aktuelle Trassenpreissystem 2018 eingeführt wurde, ist die nächste Anpassung für das Fahrplanjahr 2023 zu erwarten. Anpassungen sind dabei voraussichtlich in Produktsegmentierungen zu erwarten, die grundsätzliche Produktdefinition als Trasse in der Abrechnungsgröße Trassenkilometer bleibt bestehen. Eine Zuordnung von Trassenanmeldungen durch den Kunden zu Produktsegmenten erfolgt anhand angegebener Anmeldeattribute durch die DB Netz AG, nicht durch Auswahl des Kunden. Das Bestellportal sieht aber vor, eine Prognose über Produktsegmentierungen bereits im Planungs-GUI anzuzeigen, um größtmögliche Transparenz zu erzeugen. Das Schlagwort "Bündelprodukte" bezeichnet die Gruppierung verschiedener Produkte der DB Netz und weiterer Konzerngesellschaften zu einem scheinbaren Produkt Zugfahrt. Für den Kunden soll es so möglich werden, in einem Anmeldevorgang alle wesentlichen Produkte und Dienstleistungen, die für die Durchführung seiner Zugfahrt erforderlich sind, zu planen und zu bestellen. Die Thematik der Bündelprodukte wird im Rahmen dieses Projekts berücksichtigt aber nicht umgesetzt. Insbesondere die interne Trennung in die Auftragstypen Kundenauftrag und Produktionsauftrag schafft bereits die technisch erforderliche Basis für die künftige Implementierung von Bündelprodukten.

Auftragstypen

Kundenauftrag

Ein Kundenauftrag kann im Bestellsystem über drei Kanäle eingehen: Das Bestellportal, die Click&Ride App und die Bestellschnittstelle. Jede vom Kunden initiierte Prozessauslösung aus diesen drei Eingangskanälen veranlasst in der Komponente SteuerungVertriebsAblauf das Anlegen eines Vorgangs/Kundenauftrags. Der Kundenauftrag durchwandert im Laufe seines Lebenszyklus dabei mehrere Status, die abhängig vom Auftragstyp sind. SteuerungVertriebsAblauf stellt sicher, dass die korrekten Prozesse in der DB Netz AG angestoßen werden, um den Kundenauftrag zu erfüllen und löst den Versand von auftragsbezogenen Nachrichten an den Kunden aus. Ein typisches Beispiel für einen Kundenauftrag ist eine Trassenanmeldung, die vom Kunden mit der Erwartung an uns herangetragen wird, in einen gültigen Trassenvertrag zu münden.

Produktionsauftrag

Da der Vertrieb in der Komponente SteuerungVertriebsAblauf nicht die eigentliche Durchführung des Kundenauftrags vornimmt sondern lediglich überwacht, wird zu jedem eingehenden Kundenauftrag mindestens ein Produktionsauftrag ausgelöst. Der Produktionsauftrag geht an einen fachlichen Partner, der einen Teil der vom Kunden beauftragten Leistung zu bearbeiten hat. Mit Erledigung eines Produktionssauftrags erreicht dieser seinen End-of-Life. Im Beispiel einer Trassenanmeldung sind Produktionsaufträge vom Vertrieb an den Fahrplan beispielsweise die Trassenkonstruktion und die Trassenbuchung, jeweils als eigenständiger Produktionsauftrag

Produktion

Die Produktion im Sinne des Bestellsystems bezeichnet die Erledigung der Produktionsaufträge, also die Erstellung einer Fahrplankonstruktion, die Buchung einer Trasse, die Stornierung eines Trassenvertrags und ähnliche vom Kunden ausgelöste Vorgänge. Diese Produktionen liegen aus Sicht des Bestellsystems alle außerhalb des Systems in den jeweiligen Fachabteilungen, also zunächst im Fahrplan, mit Integration der Bündelprodukte auch bei DB Netz Vertrieb bzw. DB Station&Service.

Beendigung der Praxis von Teilangeboten im kurzfristigen Gelegenheitsverkehr

Die heutige Praxis, im kurzfristigen Gelegenheitsverkehr Trassen gestückelt zu planen und RB-scharf geplante Teilstücke direkt dem Kunden anzubieten und fahrbahr zu machen, soll nach dem Willen von I.NMF 2 beendet werden. Nach unserer Einschätzung ist dies auch stark zu empfehlen, da das gelebte Vorgehen mit Teilangeboten unter TAF/TAP nach nicht abbildbar ist: Das Objekt Path ist an einem Verkehrstag in Bezug auf den zugrundeliegenden PathRequest immer als Start-Ziel-durchgängig aufzubauen. Eine Aneinanderreihung von Path-Objekten zur Erfüllung eines einzelnen PathRequest bezogen auf einen einzelnen Verkehrstag ist nicht vorgesehen. Damit kann das Trassenangebot per PathDetailsMessage erst dann unterbreitet werden, wenn der gesamte PathRequest-bezogene Laufweg planerisch abgedeckt ist. Dies gewährleistet auch, dass die Trassenentgeltberechnung den gesamten Laufweg berücksichtigt und so korrekt längenspezifische Produktmerkmale über den gesamten Laufweg zugeordnet werden und eine korrekte Preisberechnung erfolgen kann. Für betroffenen Kunden bedeutet das einen Einschnitt gegenüber der heutigen Praxis kurzfristige Fahrten auch dann schon beginnen zu können, wenn der Fahrplan für die gesamte Fahrt noch noch nicht konstruiert und veröffentlicht ist. Als Workaround steht dem Kunden frei, durch Schneiden eines PathRequest, zum Beispiel an den Konstruktionsgrenzen der Regionalbereiche oder geeigneten Betriebsstellen in deren Nähe, eine schnellere Konstruktion erster Teilstücke zu erreichen. Dabei besteht allerdings natürlich kein Anspruch auf nahtlose Verkettung der einzelnen PathRequests zu einem nahtlosen Path.

Etablierung des Click&Ride-Prozesses (kurzfristige Trassenberatung mit Buchungsoption/KfB)

Mit Click&Ride wird wieder ein Trassenprodukt angeboten, dass einen der (zwischenzeitlich eingestellten) Trassenstudie sehr ähnlichen Charakter mit klar umgrenzten Auswirkungen hat. Mit dem Ziel das Produkt Click&Ride vollumfänglich anzubieten, wurde auch für die Kommunikation über das TAF/TAP Common Interface eine Kommunikationsprozess definiert, der unseren Kunden - auch wenn diese externe Planungssysteme verwenden - das gezielte Auslösen von Click&Ride-Anfragen erlauben. Das Produkt läuft in der technischen Schnittstellenbeschreibung unter dem Namen "kurzfristige Trassenberatung mit Buchungsoption" und bildet die Anfrage in Form einer Studienanmeldung ab. Das Konstruktionsergebnis wird ebenfalls als Studienergebnis qualifiziert und dem Kunden zur Verfügung gestellt. Dieser hat dann für einen begrenzten Zeitraum von 10 Minuten die Option einer unmittelbaren Anmeldung des Studienergebnis. Dabei verzichtet der Kunde auf eine gesonderte Angebotsannahme und kommt so zur Buchung des bis dahin reservierten Studienergebnis. Nach 10 Minuten werden so erstellte Trassen automatisch gelöscht und die reservierten Kapazitäten wieder freigegeben. Click&Ride wird parallel auch über die App bzw. künftig zusätzlich über das Bestellportal angeboten. Als Ergänzung zur Click&Ride Anmeldung ist außerdem angedacht mit dem neuen Produkt "Kapazitätsanfrage", eine kurzfristige Trassenberatung anzubieten, die ausdrücklich keine Buchungsoption mit sich bringt. Diese könnte in einem weiteren Zeitraum vor der eigentlichen Buchung ausgelöst werden und die fachlichen Voraussetzungen aus Click&Ride relaxieren, da keine unmittelbare Reservierung und Buchung erfolgt. Ein solches Produkt bietet unseren Kunden die Möglichkeit, für bestimmten Verkehrstage eine Anfrage zu modellieren und so einen Eindruck über Fahrtzeiten unter Berücksichtigung geplanter Kapazitätsverbräuche zu erhalten. Damit kann der EVU-Kunde gegenüber seinen Kunden genauer Planen und Anbieten, ohne dass DB Netz-seitig Verbindlichkeiten geschaffen werden.

Nachrichtenabfolge unter TAF/TAP TSI Regeln

Auch wenn grundsätzlich keine Änderungen an den Prozessen der DB Netz AG geplant sind, bringt die Einführung von TAF/TAP TSI als Kommunikationsstandard einige Änderungen mit sich, die je nach Detaillierungsgrad von Prozessdarstellungen sichtbar werden. Die offensichtliche Änderung, die sicher zu Erweiterungen der Prozesse LN34-01 (Netzfahrplan erstellen) und LN34-03 (Gelegenheitsverkehre bearbeiten) führen wird ist die Tatsache, dass TAF/TAP TSI eine Buchungsbestätigung einführt, die die Prozesse der Trassenvermarktung abschließt. So ist eine PathConfirmedMessage des EVU durch das EIU mit einer PathDetailsMessage mit TypeOfInformation "Booked" zu beantworten. Diesen Prozessschritt kennt die heutige Prozesslandschaft nicht. Die weiteren Änderungen durch TAF/TAP TSI werden im Wesentlichen erst auf technischen Prozessdarstellungen sichtbar. Hier sieht TAF/TAP TSI grundsätzlich vor, dass alle Nachrichten, egal ob sie durch den Kunden oder das EIU versendet werden, mit entweder einer ReceiptConfirmationMessage (Empfangsquittung) oder einer ErrorMessage (Fehlernachricht mit Fehlercodierung) zu beantworten. Auf eine ReceiptConfirmationMessage kann dann verzichtet werden, wenn die fachlich-inhaltlich zu erwartende Antwort kurzfristig übermittelt werden kann. Diese Anpassungen im fachlichen Kommunikationsablauf führen aber voraussichtlich nicht zu Anpassungsbedarfen in den Prozessdarstellungen des Prozessportals.

Einführung der echten netzausgelösten Stornierung / Änderung der netzausgelösten Änderung im GelV

TAF/TAP TSI führt erstmals die Möglichkeit ein, Trassen tatsächlich netzausgelöst zu stornieren bzw. zu ändern. Die heutige technische Implementierung in TPN erlaubt eine Änderung faktisch nur kundenausgelöst abzubilden. Das führt dazu, dass Kunden informiert werden, welche Änderung netzausgelöst erforderlich ist und diese dann vom Kunden bestellt wird. TAF/TAP erlaubt es, diesen Geschäftsvorfall netzseitig auszulösen. Der Fahrplan-Konstrukteur kann dazu die Trasse als nicht mehr verfügbar ankündigen (Objekt: Path / per PathNotAvailableMessage). Dabei gibt es die Möglichkeit zur Unterscheidung zwischen den Ausprägungen "Alternativangebot wird derzeit erarbeitet" und "keine Alternative verfügbar". Das Alternativangebot wird dann in einer gesonderten PathDetailsMessage mit der Ausprägung "netzausgelöstes Alternativangebot" übermittelt. Die PathDetailsMessage kann dann durch den Kunden im standardisierten Prozesslauf zur Angebotsannahme oder -ablehnung bearbeitet werden.

Abbildung von Rahmenvertragsprozessen

Die DB Netz AG bietet im Fahrplan über die laufende Rahmenvertragsperiode hinaus keine neuen Rahmenverträge mehr an (Bekanntgabetext DB Netz AG). Diese Festsetzung ist unabhängig von FIB und dem Projekt Bestellsystem getroffen worden. Auch mit dem Produktionsstart nach der aktuellen Rahmenvertragsperiode müssen Rahmenverträge aber weiter berücksichtigt werden, da mit einzelnen Verkehrsanbietern Rahmenverträge abgeschlossen wurden, die bis in das Fahrplanjahr 2031 hinein wirken. Nach einer betriebswirtschaftlichen Bewertung wurde gemeinsam zwischen I.NMF 1 und I.NMF 2 festgelegt, dass die für die Erfüllung der Verpflichtungen aus Rahmenverträgen erforderlichen Funktionen ausschließlich in den Systemen des Fahrplans abgebildet werden. Im Bestellsystem wird der Prozess Rahmenvertrag ausschließlich insoweit unterstützt, dass Anmeldungen zum Netzfahrplan das Attributfeld "RV-Kapazitätsnummer" beinhalten können und so den Kunden mit Rahmenverträgen die Referenzierung auf bestehende Rahmenverträge weiterhin ermöglicht wird. Das Änderungswesen zu Rahmenverträgen wir ausschließlich direkt zwischen Fahrplan und Kunde geregelt. Hintergrund der Entscheidung ist, dass ab Fahrplanjahr 2024 nur eine geringe Anzahl von EVU hinter den bestehenden Rahmenverträgen steht und die Anzahl der Geschäftsvorfälle - vor allem derjenigen, die kundenseitig ausgelöst werden - so gering ist, dass der Aufbau von neuen IT-Systemen zur Unterstützung dieser abgängigen Prozesse betriebswirtschaftlich nicht sinnvoll ist. Die zur Vertragserfüllung und Erfüllung der gesetzlichen Anforderungen notwendigen Funktionen werden aber im neuen Konstruktionssystem des Fahrplans vollständig abgebildet sein, so dass keine Risiken aus dieser Änderung erwartet werden. Die Prozesse bleiben grundsätzlich unverändert. Lediglich die beteiligten Systeme ändern sich.