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-export/pages/27526066_3.1 Fachliche Ist-Analyse.md

@@ -0,0 +1,73 @@
+# 3.1 Fachliche Ist-Analyse
+
+> Confluence Page ID: 27526066
+> Version: 85
+> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/3 Geschäftsprozesse/3.1 Fachliche Ist-Analyse
+> Labels: 
+
+---
+
+## Spannungsfeld Vertrieb und Fahrplan
+
+Den größten Teil ihrer Einnahmen erzielt die DB Netz AG aus der Vermarktung von Trassen, also aus dem Verkauf von Nutzungsrechten für Zugfahrten auf ihrem Streckennetz an die Kunden. Zugangsberechtigt sind im Wesentlichen zugelassene Eisenbahnverkehrsunternehmen, Zweckverbände des Schienenpersonennahverkehrs (SPV) sowie bestimmte Behörden.
+Die Anwendungen TPN und GFD-Z unterstützen heute überwiegend die Prozesse der Kundeninteraktion, kaufmännischen Abwicklung und des Trassenmanagements. Ausgehend von der Entgegennahme der Trassenanmeldungen der Eisenbahnverkehrsunternehmen bzw. Zugangsberechtigten, erfolgen die Fahrplankonstruktion und die Erstellung eines entsprechenden Angebots für den Kunden. Nach Angebotsannahme ist der Vertrag geschlossen und für beide Seiten gelten die in der Eisenbahninfrastrukturbenutzungsverordnung und den Schienennetznutzungsbedingungen (SNB) festgelegten Rechte und Pflichten.
+Zurzeit durchlaufen Trassenanmeldungen grundsätzlich folgenden Weg durch die IT-Landschaft: (Kunde-) TPN > GFD-Z > RUT-K > GFD-Z > TPN (-Kunde). TPN ist zwar als Bestellsystem für den Kunden bekannt, wird aber darüber hinaus hauptsächlich zur internen Steuerung des Fahrplanerstellungsprozesses verwendet und bildet daher sowohl Funktionen der Domäne Vertrieb, als auch der Domäne Fahrplan ab. Die Betriebsführung und Weiterentwicklung des Systems TPN wird federführend von der Domäne Fahrplan verantwortet. Daraus ergibt sich immer wieder das Problem, dass eine Weiterentwicklung vertrieblicher Anforderungen unmittelbar gegen fahrplanerische Anforderungen abzuwägen ist. Diese Abwägung aber findet allein im Fahrplan statt. Zudem sind aufgrund der Integration in die DaVIT-Welt die Release-Zyklen mit 2 Releases pro Jahr strikt vorgegeben und unflexibel. 
+Das System vermittelt den Eindruck, sich eher als System für die Domäne Fahrplan zu verstehen. Der Kunde ist nicht Hauptanwender und steht damit nicht im Fokus des Systems, weshalb insbesondere die Aspekte der kundenfreundlichen und intuitiven Bedienung im System TPN vernachlässigt sind. 
+Für die Durchführung einer Zugfahrt werden aus Kundensicht neben dem Produkt Trasse auch die Produkte Anlage, Stationshalt und Energie benötigt. Für diese verschiedenen Produkte existieren derzeit separate Systeme, in denen die Bestellung der jeweiligen Produkte in gesonderten Bestellvorgängen ermöglicht wird. Für die Zukunft stellt sich der Vertrieb der DB Netz AG vor, dass alle Produkte in einem Bestellvorgang vom Kunden angestoßen und bestellt werden können. Da TPN maßgeblich in die angeschlossenen Fahrplansysteme integriert ist und diese sich lediglich mit dem Produkt Trasse beschäftigen und keine Berührungspunkte mit den Produkten Anlage, Energie und Stationshalt haben, wird es als ausgeschlossen angesehen, dass das Systems TPN so ertüchtigt werden könnte, zukünftig die Bestellung von Bündelprodukten (Trassen + Anlagen + Energie + Stationshalt) zu ermöglichen.
+Die Ablösung von TPN wurde bereits in einigen Projekten (WIN, IngriT, APlus) seit 2009 versucht, bisher allerdings nicht erfolgreich umgesetzt. Hierzu gab es bereits in der Vergangenheit mehrere Analysen zum System TPN, unter anderem resultierte daraus folgende "Pain-Point" Liste, die in Kapitel  näher beschrieben wird.
+## Verschiedene Produkte, Systeme und Planungstools
+
+Neben dem Produkt Trasse gibt es im Bereich des Fahrplans weitere Produkte , die im Ist-Zustand allerdings außerhalb des Bestellsystems TPN zu bestellen sind. Hierzu zählen insbesondere Fahrplan- bzw. Betriebsprogrammstudien und Fahrplankonzepte. Zurzeit wird deren Bestellung nicht durchgängig durch IT-Verfahren unterstützt. Die Erstellung der Konstruktionsergebnisse für Fahrplan- und Betriebsprogrammstudien wird im Konstruktionssystem RUT-K durchgeführt, Fahrplankonzepte werden in spezialisierten Tools erstellt. Für die vor- und nachgelagerten Tätigkeiten der Kundenanfrage, der Steuerung der Erstellung der Produkte, Änderungsanfragen, Zurückweisungen und die Übergabe der Ergebnisse an den Kunden werden Formulare, Laufzettel, Faxe und Emails verwendet.
+Im Rahmen des Aufbau eines neuen Bestellsystem für die Kunden, soll auch der Bestellprozess für diese genannten Produkte systemseitig berücksichtigt werden. Je nach Tooling in den Prozessen wird dies aber ggf. außerhalb des MVP verfolgt.
+Neben TPN als Anmeldungssystem existiert im Ist-Zustand (derzeit noch nicht produktiv) das System Click&Ride. Über Click&Ride ist es möglich, im Güterverkehr sehr kurzfristig Trassen zu bestellen, die automatisch ohne manuelle Prozessschritte durch einen Mitarbeiter des Fahrplans konstruiert und dem Kunden angeboten werden können. Click&Ride ist als alternatives Vertriebsverfahren zum Bestellsystem TPN zu verstehen, ausschließlich ausgelegt für den speziellen Anwendungsfall zur Anmeldung von unterfristigen Schienengüterverkehr. 
+Darüber hinaus gibt es weitere vertriebliche Angebote, die in anderen Kontexten als dem Anmeldeprozess bei der DB Netz AG im Ist-Zustand dem Kunden bereitgestellt werden. Hierzu zählt unter anderem der Trassenfinder, mit dem die DB Netz AG eine separate Anwendung bereitstellt, die Kunden bei ihrer Trassenplanung unterstützen soll. Es handelt sich um ein webbasiertes Tool, das eine schnelle und einfache zugkonfigurationsabhängige Laufwegssuche bereitstellt und zusätzlich Prognosen über Mindestfahrtdauer, Trassenentgelt und Energieverbrauch liefert.
+Neben dem Trassenfinder ist vor allem auch die Anwendung GretA hervorzuheben, bei der es sich ebenfalls um eine separate Web-Anwendung handelt, mithilfe derer Regelgrenzlasten für einen gewählten Streckenabschnitt mit bestimmter Traktion abgefragt bzw. bei Bedarf eine Einzelgrenzlastberechnung beantragt werden kann.
+Mit MaTeo wird daneben ein Verfahren bereitgestellt, dass Kunden die Beantragung eine Machbarkeitsstudie für außergewöhnliche Transporte ermöglicht, welche eine Voraussetzung für die Anmeldung ebendieser Zugfahrten schafft.
+Es ist offensichtlich, dass im Laufe der Jahre zusätzlich zum eigentlich Bestellsystem TPN separate Systeme geschaffen worden sind, die alle das Ziel verfolgen, den Kunden beim Bestellvorgang von Trassen zu unterstützen. Diese sind aber jeweils als eigenständige Systeme aufgebaut worden und verlangen dem Kunden ab, an vielen Stellen und in vielen Systemen einen Vorgang zu bearbeiten. Zukünftig sollen solche Funktionalitäten in einem Bestellsystem kontextbezogen für den Kunden angeboten werden, sodass ein Kunde hierfür nicht auf verschiedene Systeme zurückgreifen und Daten unter Umständen wiederholt eingeben muss. 
+## TAF/TAP-TSI
+
+Im Rahmen der europaweiten Standardisierung durch TAF/TAP-TSI wird die Nachrichtenstruktur im Bestellprozess verändert. Hierzu gibt es ein Konzeptionsteam der DB Netz AG, das die Konzeption von TAF/TAP-TSI aus Sicht der DB Netz AG insbesondere für den Bereich Fahrplan begleiten.
+Parallel zur Erstellung eines Fachgrobkonzept durch das Konzeptionsteam, wird im ersten Halbjahr 2019 (Ende Mai/Juni 2019) eine EVU-SST Dokumentation der neuen TAF/TAP-TSI Strukturen und Prozessen veröffentlicht. In dieser EVU-SST wird der Inhalt, die Struktur, fachliche Regeln und Nachrichtenabfolgen der zukünftigen Schnittstelle zum Bestellsystem der DB Netz für alle EVUs detailliert beschreiben. Die Dokumentation ist auch für das Projekt Bestellsystem als wesentliche Rahmenbedingung für das DB-eigene TAF/TAP-Common Interface zu bewerten.
+Die Standardisierung erwirkt eine europaweite Vereinheitlichung von Objekten (s. Kapitel 2), Nachrichtentypen (Kapitel 3) und Basisprozessen (Kapitel 4). Die Änderungen aufgrund der TAF/TAP-TSI wirken sich auf die Fahrplan IT (Objektmodell, Nachrichtentypen, Identifikatoren, Funktionalitäten), aber auch auf Sub-Prozesse und Richtlinien (z.B. Zugnummernvergabe) aus. Herausforderung ist, dass die Spezifikationen der TSI leider an vielen Stellen noch eher unspezifisch sind und es im Zuge der Entwicklung eine enge Abstimmung mit unseren Schnittstellenpartnern und der RNE brauchen wird. 
+Die RNE stellt eine eigene Common Interface Software als technisches Modul zur Verfügung, das für Teilnehmer an TAF/TAP-TSI grundsätzlich nutzbar ist. Die Implementierung der RNE ist aber nach initialer Bewertung der Dokumentation und einer Proof-of-Concept-Implementierung durch das Projektteam Bestellsystem ungeeignet, da sie teils auf abgängigen Technologien basiert und keine horizontale Skalierung erlaubt. Außerdem ist der Konfigurationsaufwand zum Aufbauen von Kommunikation zwischen einzelnen Partnern erheblich, da das Common-Interface der RNE ein dezidiertes Mapping zu jedem einzelnen Kommunikationspartner verlangt. Ein Aufwand der so für die DB Netz AG nicht wirtschaftlich vertretbar leistbar ist. Insbesondere die Skalierbarkeit ist aber eine zentrale Anforderung, die wir aus Unternehmenssicht an das DB-eigene Common Interface stellen. Eine detaillierte Betrachtung der Nicht-Eignung des RNE CI-Moduls findet sich in .
+Deshalb ist durch die DB Netz AG ein eigenes Common Interface zu entwickeln und bereitzustellen, welches den Nachrichtenaustausch mit den Kommunikationspartner als Netzwerkkomponente bereitstellt. Es empfiehlt sich zudem, hier mittelfristig eine konzernweite Strategie für die Vereinheitlichung der Common Interfaces aufzusetzen, um die für alle Teilnehmer identischen Software-Anteile des CI an nur einer Stelle aktuell zu halten und in den Fachbereichen lediglich die fachliche Spezifikation vornehmen zu müssen.
+## Weitere fachliche Rahmenbedingungen im IST-Zustand
+
+## Rahmenverträge
+
+Bis Ende 2016 war es im Rahmen des Produkts "Rahmenverträge" für EVUs möglich, Rahmenverträge mit der Zusicherung einer Kapazität über mehrere Jahre zu schließen. Es wurde die Entscheidung getroffen, ab 2017 keine neuen Rahmenverträge mehr zu schließen und das Produkt den Kunden nicht mehr anzubieten. Bisher geschlossene Rahmenverträge behalten jedoch weiterhin ihre Gültigkeit entsprechend ihrer ursprünglich abgeschlossenen Vertragslaufzeit. Bestehende Verträge mit der längsten Gültigkeit laufen bis 2031. Weiterhin gültige Rahmenverträge müssen im Rahmen des Bestell- und anschließenden Konstruktionsprozesses weiterhin Berücksichtigung finden.
+Bestellsystem-seitig müssen daher die Rahmenverträge als Produkt in begrenztem Umfang weiter unterstützt werden. Kunden müssen die Möglichkeit haben, bei Anmeldungen zum Netzfahrplan auf eine gültige Rahmenvertragskapazität zu verweisen. Weitere Funktionalitäten werden nach Betrachtung der Fallzahlen und betroffenen Kunden nicht implementiert. Diese Festsetzung wurde durch I.NMF 1 und I.NMF 2 in Abstimmung mit den beteiligten Fachabteilungen I.NMF 11 und I.NMF 24 gemeinsam getroffen und protokolliert (Termin Zielbild TAF-TAP TSI im Fahrplan vom 28. Mai 2019)
+Eine Wiederaufnahme von Rahmenvertragsprodukten wird auf mehreren Ebenen diskutiert. Neben Gedanken zu einem Ablöser des klassischen Rahmenvertrags soll aus dem Projekt Time Table Redesign (TTR) das Produkt Rolling Planning eingeführt werden, das ähnliche Wirkung im Fahrplan erzeugt. Das Ablöseprodukt des klassischen Rahmenvertrags ist aber gänzlich neu zu definieren, was neben dem eigentlichen Entwurf auch rechtliche Anpassungen, etwa im ERegG nach sich ziehen müsste. Mit einer schnellen Umsetzung ist daher aktuell nicht zu rechnen. Auch das Produkt "Rolling Planning" aus TTR ist zum Zeitpunkt dieser Vorstudie nicht abschließend spezifiziert, so dass belastbare Anforderungen nicht betrachtet werden können. Die Anforderungen aus beiden neuen Rahmenvertrags-Produkten können daher nur im Wege von Change Requests in das Projekt Bestellsystem eingesteuert werden. 
+## Rolle "Kundenmanager"
+
+Die Rolle Kundenmanager im Sinne von TPN mit der Aufgabe der Prüfung einer Produktzuordnung wird so nicht wieder installiert. Der Prozess, für den diese Rolle eingerichtet wurde, wurde nach Aussage von I.NMK 2 nie operativ verankert. Die Prüfung der Produktzuordnung und der zugehörigen Preisermittlung wird künftig vollautomatisiert und Bedarf daher auch keines manuellen Eingriffs in der Oberfläche des Bestellportals.
+Inwieweit eine manuelle Korrektur der Produktzuordnung in der Datenbank der SteuerungVertriebsAblauf ermöglicht werden muss, wird im Rahmen der Projektumsetzung und Feature-Readyness abschließend verifiziert, da daraus keine erheblichen Aufwandsmehrungen erwartet werden.
+## Teilangebote im kurzfristigen Gelegenheitsverkehr
+
+Im Ist-Zustand ist es infolge der "Konstruktion unter dem rollenden Rad" möglich, Teilangebote für die EVUs zur Verfügung stellen. Dies ist grundsätzlich einem kundenfreundlichen Vorgehen geschuldet, dass der Kunde eine sehr kurzfristige Abfahrt seines Zuges realisieren kann, auch wenn nicht alle Teile seiner Anmeldung bereits das Stafettenverfahren durchlaufen haben. So kann es in ungünstigen Fällen dazu führen, dass Züge unterwegs eine Wartezeit einlegen müssen, da für die Weiterfahrt noch kein Fahrplan vorliegt.
+I.NMF 2 will die Erstellung von Teilangeboten in der Zukunft nicht weiter unterstützen.
+## Umsetzung § 22 ERegG in Fahrplan-IT
+
+Gemäß § 22 ERegG dürfen Drittunternehmen (EVU) in einen zwischen der DB Netz AG und einem EVU bestehenden ENV eintreten. Zukünftig soll es im neuen Bestellsystem möglich sein, beitretende EVU in Erst- und Änderungsbestellungen hinzuzufügen. Dabei sollen Kundennummer und Bestellerangaben für die neuen EVU abgefragt werden. Die Informationen sollen auch zur Veröffentlichung der Fahrplanunterlagen genutzt werden können und an Folgesysteme des Betriebs und der Abrechnung gehen. Systematische Datenabfragen durch SAPBINe / Netzmonitor müssen möglich sein. 
+Diese Anforderung ist zum Zeitpunkt der Erhebung auch noch nicht im Bestandssystem TPN implementiert, wird aber vsl. trotz der Abgängigkeit des Systems noch eingebaut werden. Diese Anforderung ist zum Zeitpunkt der Erhebung auch noch nicht im Bestandssystem TPN implementiert. 
+## Kennzeichnung besonderer Fristen
+
+Bisher sind im Gelegenheitsverkehr im Bestandssystem TPN nur die Fristarten "kurzGV" (48 Stunden) und "aufwB" (4 Wochen) hinterlegt, in die alle Trassenanfragen eingruppiert werden. Die BNetzA hinterfragt immer mehr die Tatbestände, die zu einer besonders aufwändigen Bearbeitung gem. Ziffer 4.2.2.4 führen und verlangt Anpassungen. Zudem nimmt die Anzahl von Bestellungen auf den europäischen Güterverkehrskorridoren zu, deren Bearbeitungsfristen individuell vom Corridor-OSS vorgegeben werden.
+Aus diesem Grund wird gefordert, zukünftig eine neue Fristenart (z.B. "Manuell") im System hinterlegen zu können. Hierfür muss zur Wahrung der Rechtsverbindlichkeit der Friständerung eine Begründung abgefragt / eingegeben werden (am besten strukturierte Begründungsgruppen).
+Diese Anforderung ist zum Zeitpunkt der Erhebung auch noch nicht im Bestandssystem TPN implementiert, wird aber vsl. trotz der Abgängigkeit des Systems noch eingebaut werden. Annahme ist derzeit, dass die Berechnung/Festlegeung von Bearbeitungsfristen erst im Modul SteuerungKonstruktionsAblauf erfolgt, da nur im Fahrplan eine fachlich abschließende Bewertung vorgenommen werden kann.
+## Kennzeichnung sicherheitsrelevanter Züge
+
+Gem. § 62 Abs (2) BPolG ist die DB Netz AG verpflichtet, Fahrplandaten an die BPOL herauszugeben. Die BPOL benötigt vor allem Daten für "sicherheitsrelevante Züge", also z. B. Reisesonderzüge zu Großereignissen, Militär- und Castortransporte. Bislang muss der Trassenkonstrukteur selbst bei der Veröffentlichung des Fahrplans entscheiden, ob er die BPOL anschreiben muss.
+§ 62 Abs (2) BPolG legt die Informationspflichten auch dem EVU auf. Da die DB Netz AG nicht sicher erkennen kann, ob es ein "sicherheitsrelevanter Zug" ist, soll das EVU selbst diese Kennzeichnung im Rahmen der Trassenanmeldung treffen müssen. Im Falle einer Kennzeichnung werden für die Veröffentlichung des Fahrplans automatisch bestimmte Sicherheitsstellen mit in den Verteiler aufgenommen.
+Diese Anforderung ist zum Zeitpunkt der Erhebung auch noch nicht im Bestandssystem TPN implementiert, wird aber vsl. trotz der Abgängigkeit des Systems noch eingebaut werden.
+## Schienenlärmschutzgesetz im Gelegenheitsverkehr
+
+Beim Verkehr von lauten Zügen bzw. lauten Zügen mit Befreiung müssen die Bestimmungen des Schienenlärmschutzgesetz im Bestellsystem eingehalten werden.
+Da es sich bei dieser Angabe um eine Pflichtangabe handelt ist die korrekte Angabe durch den Kunden zu gewährleisten. Aus diesem Grund muss der Kunde in der Trassenbestellung GelV im Bestellportal bzw. über die EVU-Schnittstelle die Angabe"leise", "laut" oder "laut mit Befreiung" übergeben. Diese Anforderung ist zum Zeitpunkt der Erhebung auch noch nicht im Bestandssystem TPN implementiert.
+## Pünklichkeitsmerkmal/Pünklichkeitssensibilität
+
+Zur Abbildung der Anforderung aus ERegG §39 ist für alle Trassenanmeldungen ab dem Fahrplanjahr 2021 durch den Kunden anzugeben, ob ein Zug "pünklichkeitssensibel" ist. Die Pünklichkeitssensibilität wirkt auf das Anreizsystem Pünktlichkeit und definiert die Höhe von durch Kunden oder DB Netz zu leistenden Ausgleichszahlungen bei Überschreitung von Ankunftspünktlichkeits-Schwellwerten. Im Bestellsystem muss sichergestellt werden, dass die PÜ-Sensibilität durch den Kunden befüllt wird (ggf. Defaultregelung "Nein" möglich) und das Merkmal an das Abrechnungssystem übergeben wird. Die Eintragung und Pflege des Stammdatums im M15 Infrastrukturmanager ist durch den Fachbereich I.NMK 2 sicherzustellen. Die Anforderung des für eine TAF/TAP TSI-konforme Umsetzung benötigten NetworkSpecificParameter ist ggf. durch I.NMK 2 bei I.NMF 11 zu vertreten. Das Projekt Bestellsystem hat die Anforderung an I.NMF 11 im Rahmen der Vorstudienerstellung übermittelt. 
+## Konsequenzen im Ist-Zustand aufgrund des Programms FIB
+
+Die Trennung der IT-Welten aus Fahrplan und Vertrieb führt dazu, dass einige Komponenten aus dem heutigen TPN im Fahrplan neu aufgebaut oder angebunden werden müssen. Die Zuständigkeitsklärung bezüglich funktionaler Komponenten wurde zwischen den Projekten Bestellsystem und BaDiFa (RuT-K neu) vorgenommen. Die Behandlung der IT-technischen Änderungen im Fahrplan sind konsequenterweise nicht Gegenstand des Projektes Bestellsystem sondern werden im durch BaDiFa übernommen bzw. geklärt.
+Die Projekte Bestellsystem und BaDiFa laufen parallel und stehen während der Vorstudien- und Entwicklungsphase in engem kontinuierlichen Austausch, um sicherzustellen, dass auch in der Abarbeitung von Inhalten in beiden Projekten eine Parallelität besteht und möglichst frühzeitig integriertes Testen im End-to-End Durchlauf ermöglicht wird.