Orchestrator/bahn/project-audit/data/confluence-export/pages/38010944_10 Planungsalternativen.md

10 Planungsalternativen

Confluence Page ID: 38010944 Version: 15 Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/10 Planungsalternativen Labels:

---

CIO-Auftrag nach Vorstellung initiale Kostenschätzung

Auftrag von CIO vom 05.09.2019:

Was bekommt die DB Netz von BaDiFa und Bestellsystem, sofern die Planzahlen DAN zu Grunde gelegt werden?

• Planzahlen aus DAN 2016:

• BaDiFa (2 Epics, ohne Vorprojekt):            29,6 Mio. EUR

• Bestellsystem (1 Epic, ohne Vorprojekt):  16,7 Mio. EUR                                                                 46.3 Mio. EUR

•  Ansatz: Es werden beide Projekte (BaDiFa und Bestellsystem) zusammen betrachtet und versucht im Rahmen dieses CIO-Auftrags, zumindest ein Vorsystem durch ein M(M)VP erfolgreich abzulösen (hier: TPN).

• Frage: Was muss BaDiFa mit RUT-K tun, um im Zusammenspiel mit dem neuen Bestellsystem und der bestehenden DaViT-Welt ab spätestens 03/ 2023 TAF/TAP-TSI-konform produktiv gehen zu können?

• Und: Was bekommt die DB Netz AG dadurch NICHT?

10.1 Betrachtete Alternativen

Alternativ zur Umsetzung des Minimal Viable Products (MVP) wurden folgende Szenarien in Hinblick auf Umsetzbarkeit, Kostenentwicklung und Risiken abgeklopft, um eine kostenoptimierte Umsetzungsvariante zu finden.

10.1.1 Nur TAF/TAP-TSI konforme Bestellschnittstelle

Grundsätzlich besteht die Möglichkeit, statt zweier Eingangskanäle künftig ausschließlich eine technische Bestellschnittstelle für die Trassenanmeldungen bereitzustellen. Da die Schnittstelle allen Teilnehmern am Bahnverkehr gleichermaßen zur Verfügung gestellt wird ist formal argumentierbar, dass damit auch das Erfordernis der Diskriminierungsfreiheit erfüllt ist. Auf Basis der Kostenindikation und Aufwandsschätzung wird davon ausgegangen, dass diese Variante mit erwarteten Umsetzungskosten von < 5 Mio. EUR zuzüglich Rahmenkosten innerhalb des Planbudgets umgesetzt werden könnte.  Betrachtet man die Schnittstellennutzung heute an TPN ist festzustellen, dass die Vielzahl von Anmeldungen bereits heute über Drittsysteme  gemeldet wird. Der Schluss drängt sich auf, dass die Abschaffung des Webportals vertretbar sein könnte. Betrachtet man aber die Verteilung über die Kundennummern, stellt sich eine andere Situation dar: 58% unserer Kunden nutzen den TPN-Client als Anmeldeverfahren und decken dabei Anmeldungen über 73% aller registrierten Kundennummern ab. Eine Entscheidung gegen ein Bestellportal trifft also die Vielzahl unserer Kunden. Politisch brisant wird diese Variante, wenn man bedenkt, dass insbesondere die konzerninternen Kunden DB Fernverkehr, DB Regio und DB Cargo heute Schnittstellenkunden sind. Die Argumentation der Diskriminierungsfreiheit wird schwerer, wenn man bedenkt, dass eine neu eingeführte Härte durch Wegfall eines Bestellportals vor allem konzernexterne Unternehmen trifft. Durch Aufgabe des Angebots eines Bestellportals würde zudem ein zentraler Hebel entfallen, über den Kunden Hilfestellung und Informationsbereitstellung bei der Erstellung seiner Anmeldungen gestellt werden könnte. Die erlebte Zugangsqualität in das System Schiene würde ausschließlich durch Software von Drittanbietern bestimmt. Das Projektteam rät aus den genannten Gründen von der betrachteten Variante ab.

10.1.2 Nur TAF/TAP-TSI konformes Bestellportal

Grundsätzlich besteht die Möglichkeit, auf das Angebot einer technischen Schnittstelle zu verzichten und alle Kunden dazu zu verpflichten, über das Bestellportal anzumelden. Dies entspricht dem Vorgehen der SBB, die, außer für Anmeldungen aus PCS (RNE Path Coordination System), alle Kunden ausschließlich über das Bestellportal bedient. Kostenseitig würde dies den Projektumfang um grob 3,5 Mio. EUR reduzieren. Die Abbildung der Projektkosten würden damit etwas näher an die Werte aus der MiFri-Planung gerückt. Allerdings gehen wir davon aus, dass unter Betrachtung aller Rahmenkosten weiterhin eine Kostenerhöhung gegenüber Plan erforderlich sein wird. Die Abschaffung einer technischen Schnittstelle wird allerdings erhebliche Effizienzeinbußen bei unsere Schnittstellenkunden nach sich ziehen. Bedenkt man, dass die Vielzahl (ca. 60%) aller Anmeldungen über die Schnittstelle abgeben werden, wird eine Abschaffung dieses technischen Verfahrens einen erheblichen Mehraufwand bei unseren Kunden auslösen. Betroffen wären vor allem die Großkunden, für die sich in der Vergangenheit bereits die Anschaffung eines dritten Planungssystems mit Schnittstelle angeboten hatte. Dies sind auch hier wieder vor allem DB Fernverkehr, DB Regio und DB Cargo. Im Sinne einer zunehmenden Automatisierung und Technisierung bei der Abarbeitung von Trassenanmeldungen DB Netz-seitig, erscheint das Ansinnen, auf das Angebot einer technischen Schnittstelle zu verzichten auch kontraproduktiv.  Das Projektteam rät aus den genannten Gründen von der betrachteten Variante ab.

10.1.3 Weiternutzung TPN-Webclient

Die Weiternutzung des TPN Webclient bietet den Charme, dass man die Abbildung der Fachlichkeit Fahrplan in einer Weboberfläche bereits umgesetzt hat und "nur" noch den Unterbau in TAF/TAP TSI-Konformität bringen muss. Genau hierin liegen aber in allen Varianten die erheblichen Aufwandstreiber. TPN kann heute mit Objekten und Identifikatoren aus TAF/TAP nicht umgehen. Stattdessen ist TPN darauf ausgelegt, alle Vorgänge und Züge anhand der Zugnummer zu unterscheiden, die in TAF/TAP vertrieblich eine untergeordnete Rolle spielen wird. Zudem bleiben die Geschäftsprozess zwar weitgehend gleich, die Abbildung der Geschäftsvorfälle systemseitig muss aber grundlegend verändert bzw. neu aufgebaut werden, da TAF/TAP ein stark abweichendes Kommunikationskonzept mit sich bringt. In der Umsetzung wäre neben der Komplexität der Einführung neuer TAF/TAP Objekte und Nachrichtenabfolgen zusätzlich das Management aller Abhängigkeiten und die Sicherstellung der Funktionsfähigkeit bestehender Features zu gewährleisten. Gerade aufgrund der monolithischen, eng integrierten Architektur von TPN ist das Herauslösen der GUI-Elemente auch nicht einfach zu bewerkstelligen. Dabei bietet TPN heute nur eingeschränkt Ende-zu-Ende-Testautomatisierung, die bei der Bewältigung dieser Aufgaben unterstützen könnte. Nach Ansicht des Projektteams heben sich die Einsparpotenziale mit den damit erkauften Komplexitäten im besten Fall auf. Wahrscheinlicher scheint, dass ein solcher Umbau von TPN zusätzliche Aufwände erzeugt und somit teurer würde, als dies in der Neubauvariante der Fall wäre. Dies gilt insbesondere, da die Web-Oberfläche von TPN ein Nachbau des vorherigen Desktop-Clients von TPN (TPN Anita Client) ist und somit die Frontend- und Backend-Komponenten eng miteinander verzahnt sind. Somit entstünde ein System, dass keinen klaren Architekturansatz verfolgt und dass die Betriebsführung mit erheblichen Risiken belasten würde. Das Projektteam rät aus den genannten Gründen von der betrachteten Variante ab.

10.1.4 Reduktion des MVP

Obwohl das in dieser Studie definierte Minimal Viable Product (MVP) aus Sicht des Projektteams bereits das zu erfüllende Minimum eines Viable Products beschreibt, ist eine weitere Reduktion der Features abbildbar. Dies hat hart die Nicht-Erfüllung des Ziels eines kundenfreundlichen und planungsunterstützenden Bestellportals zur Folge. So kann zwar eine Einführung von TAF/TAP TSI sichergestellt werden, wir gehen dabei aber weiterhin nur marginal auf Kundenanforderungen am Bestellportal ein. Das Angebot wird daher gegenüber dem heutigen TPN kundenseitig kaum Verbesserungen einführen. Die dabei abgebildete Aufwandsersparnis beträgt ca. 15% und kann damit das Ziel, das neue Bestellsystem im Rahmen des MiFri-Budgets zu erstellen auch nicht erfüllen. Vorteil dieser Variante wäre also ausschließlich eine Kostenreduktion um ca. 2 Mio EUR. Diese Variante verfehlt grundlegende Ziele, die wir als Anbieter gegenüber unsere Kunden im Sinne der Stärkung des Systems Schiene verfolgen. Das Projektteam rät aus den genannten Gründen von der betrachteten Variante ab, hält diese aber für die tragfähigste Lösung der hier betrachteten Alternativen zum MVP. Daher wird im folgenden Kap. 10.2 eine die Ausgestaltung des Featureverzichts detailliert beschrieben und eine Kostenschätzung auf dieser Basis hergeleitet.

10.2 Alternative Kosten bei Reduktion des MVP (Szenario nach Kap. 10.1.4)

10.2.1 Reduktion des Scopes durch Weglassen von Features

Die Auswahl von entbehrlichen Features aus dem MVP kann nur auf solche Features fallen, die nicht unmittelbar für die Abwicklung einer TAF/TAP TSI konformen Kommunikation zur Trassenanmeldung oder -verwaltung dienen. Das führt per Definition des MVP nahezu zwangsläufig dazu, dass ausschließlich an solchen Features gespart werden kann, die dem Kunden einen Planungsnutzen bringen. Lediglich der Verzicht auf die Integration des Verfahrens Click&Ride im Bestellportal und an der Schnittstelle bildet einen Verzicht ab, den in der Konsequenz die DB Netz AG zu tragen hat. Im einzelnen als verzichtbar identifizierte Features unter der genannten Maßgabe sind im folgenden thematisch gruppiert aufgelistet:

Planungsunterstützende Features

• M31-529 Geographische Laufwegsanzeige
• M31-531 Prüfen der Entgeltprognose
• M31-534 Anzeige von Plausibilisierungshinweisen
• M31-535 Anzeige von Produktzuordnung Die Features sind vor allem auf Kundenseite wirksam und bieten den Kunden grundlegende Informationen, die die Planung seiner Zugfahrt erleichtern und potenziell geeignet wären den CSI positiv zu beeinflussen. Mit Streichen dieser Features wird dem Kunden nicht die Möglichkeit genommen, eine Zugfahrt analog zum heutigen TPN Webclient anzumelden. Insofern sind die Features fachlich verzichtbar. Im Sinne der Vision eines den Kunden unterstüzenden Bestellportals sind die Featureausschlüsse schwerwiegend.

Konfigurationsfunktionen

• M31-568 Konfiguration von Auswahllisten und UI-Workflows
• M31-569 Definieren von Vorlagen Konfigurationsfunktionen sollen den Kunden darin unterstützen, dass Bestellportal so aufzusetzen, dass es die kundeneigenen Prozesse und Herangehensweisen bestmöglich unterstützt. Ohne diese Funktionen kann der Kunde weiterhin vollumfänglich im Bestellportal arbeiten, die Effizienz kann aber unter Umständen leiden und der Trainingsaufwand für Mitarbeiter beim Kunden fällt höher aus.

Volltextsuche

• M31-561 Objekte finden per Volltextsuche Die Volltextsuche ist ein kundenorientiertes Feature, das dem Kunden bei der Arbeit mit der Vorgangsverwaltung unterstützen wird. Mit dem Wegfall stehen dem Kunden ausschließlich Spaltenfilter-Werkzeuge zur Verfügung.

Integration Verfahren Click&Ride

• M31-626 Anmeldung einer kurzfristigen Fahrlagenberatung mit Buchungsoption (Verfahren Click&Ride) Kunden können das Verfahren Click&Ride nach Wegfall dieses Features im Bestellsystem oder an der Bestellschnittstelle nicht gezielt anfordern. Die Nutzung der Click&Ride App wird weiterhin ermöglicht. Neben dem Verlust an Komfort für den Kunden gegenüber MVP gehen hier vorwiegend Effizienzeffekte für die DB Netz AG verloren, da eine Zuscheidung in das Verfahren Click&Ride technisch und ggf. manuell geprüft werden muss und die Effizienzgewinne aus der automatischen Konstruktion nicht vollumfänglich gehoben werden können.

Das Weglassen der oben benannten Features reduziert den Projektscope auf Basis der Schätzzahlen aus der Magic Estimation um etwas über 15% der geschätzten Storypoints. Eine weitere Reduktion kann nur abgebildet werden, wenn es Beschlüsse gibt, TAF/TAP-TSI nicht vollumfänglich einzuführen (Z.B. Verzicht auf CaseReference). Die Scopereduktion geht hart zulasten der Vision eines kundenorientierten Bestellportals, dass den Kunden bei seiner Arbeit bestmöglich unterstützt. Zwar können gegenüber dem heutigen TPN einige Verbesserungen verwirklicht werden, die herausgenommenen Features betreffen aber zum Teil sehr grundlegende Funktionen, die man als Kunde berechtigterweise in einem zeitgemäßen Bestellsystem erwartet. 

10.2.2 Anpassung der Teamzusammenstellung

Aufgrund des geänderten Scopes wurde die Teamzusammenstellung justiert. Es wurde eine Reduktion von 3 Teams auf 2 Teams vorgenommen, gleichzeitig aber die Teamgröße leicht erhöht (ALT: Team 1: 9 Personen, Team 2: 8 Personen Team 3: 8 Personen; NEU: Team 1: 11, Team 2: 10). Hieraus lässt sich für den Zeitraum 01/ 2020 - 04/ 2023 eine Gesamtsumme von 16.020.000 EUR für Personalkosten herleiten. Die detaillierte Herleitung kann im Dokument Kalkulation_Ressourcen_Bestellsystem nachvollzogen werden. Team 1  | | | Ressource | Einsatz ab | Einsatz bis | VzP | | Business Analyst | 15.01.2020 | 30.04.2023 | 1 | | Business Analyst | 15.01.2020 | 30.04.2023 | 1 | | Business Analyst | 15.01.2020 | 30.04.2023 | 0,5 | | Technischer Architekt | 15.01.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 0,5 | | Tester | 15.01.2020 | 30.04.2023 | 1 | | Scrum Master | 15.01.2020 | 30.04.2023 | 0,5

Team 2 | | | Ressource | Einsatz ab | Einsatz bis | VzP | | Business Analyst | 01.04.2020 | 30.04.2023 | 1 | | Business Analyst | 01.04.2020 | 30.04.2023 | 1 | | Technischer Architekt | 01.04.2020 | 30.04.2023 | 1 | | UI-Entwickler | 01.04.2020 | 30.04.2023 | 1 | | UI-Entwickler | 01.04.2020 | 30.04.2023 | 1 | | UI-Entwickler | 01.04.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 01.04.2020 | 30.04.2023 | 1 | | Backend-Entwickler | 01.04.2020 | 30.04.2023 | 0,5 | | Tester | 01.04.2020 | 30.04.2023 | 1 | | Scrum Master | 01.04.2020 | 30.04.2023 | 0,5

Querschnitt-Ressourcen | | | Ressource | Einsatz ab | Einsatz bis | VzP | | UX-Designer | 15.01.2020 | 30.04.2023 | 1 | | Change Manager | 15.01.2021 | 30.04.2023 | 0,75 | | Anwendungsmanager (Projektbegleitung durch I.NVI 4) | 15.01.2020 | 30.04.2023 | 0,5

Kosten für aktivierbare Eigenleistungen (AEL) und ART Vertrieb sind separat zu betrachten

Da in der ursprünglichen Planung aus DAN, keine Kosten für aktivierbare Eigenleistungen sowie Kosten, die im Zusammenhang mit der Gründung eines Release Train Vertrieb entstehen, berücksichtigt waren, werden diese in der Kostenindikation separat ausgewiesen und zunächst nicht im GWU des Projekts berücksichtigt. Aufgrund der angepassten Teamgröße wurde auch die Ressourcenplanung für aktivierbare Eigenleistungen angepasst. Diese belaufen sich nach Anpassung im Zeitraum 01/ 2020 - 04/ 2023 auf insgesamt etwa 2.269.000 EUR , die detaillierte Herleitung kann im Dokument Kalkulation_Ressourcen_Bestellsystem nachvollzogen werden.

| | | Ressouce | Organisationseinheit | Einsatz ab | Einsatz bis | VzP | | Release Train Engineer | I.NVI | 01.01.2020 | 30.04.2023 | 1 | | PMO/ Scrum Master | I.NVI | 01.01.2020 | 30.04.2023 | 1 | | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1 | | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1 | | Product Manager | I.NMK | 01.01.2020 | 30.04.2023 | 0,5 | | Change Manager | I.NMK | 01.01.2020 | 30.04.2023 | 0,5

Im Kontext der Gründung eines eigenen ART Vertriebs werden zusätzlich zu den projektspezifischen Bedarfen folgende Ressourcen benötigt:  ART-Vertrieb Ressourcen | | | Ressource | Einsatz ab | Einsatz bis | VzP | | Testmanager (System Team) | 15.01.2020 | 30.04.2023 | 1 | | CI/CD-Entwickler (System Team) | 15.01.2020 | 30.04.2023 | 1 | | Systemtester (System Team) | 15.01.2020 | 30.04.2023 | 1 | | Systemtester (System Team) | 15.01.2020 | 30.04.2023 | 1 | | Solution Architect (ART-Ebene) | 15.01.2020 | 30.04.2023 | 1

Umsetzungspuffer von 15% auf 20% erhöht

Aufgrund der Rückmeldung des CIOs im Termin am 05.09.2019, wurde der Umsetzungspuffer von 15% auf 20% erhöht. Damit ergibt sich ein Puffer in Höhe von 3.204.000 EUR.

Berücksichtigung der Erhöhung von Tagessätzen in Folge der Projektlaufzeit

In der ursprünglichen Kalkulation (siehe Kapitel ) wurde keine Erhöhung von Tagessätzen in Folge der Projektlaufzeit berücksichtigt. Um eine realistischere und stichhaltigere Planung auszuweisen, wurde eine jährliche Erhöhung der Tagessätze in Höhe von 3% im Rahmen der überarbeiteten Kostenschätzung berücksichtigt.

10.1 Ermittlung der Gesamtkosten für das Umsetzungsprojekt von 01/2020 - 04/2023

| | | Position | Betrag | | Umsetzungskosten im Zeitraum 01/ 2020 - 04/ 2023 | 14.930 TEUR | | Einheitsaufschlag DB Systel (Annahme: 6%) | 896 TEUR | | Puffer (Annahme: 20 % der Umsetzungskosten) | 3.165 TEUR | | Release-Kosten (inkl. LuP + Pentest) | 520 TEUR | | Umgebungskosten | 1.038 TEUR | | Technische Betriebsführungskosten (von 11/2022 - 04/2023) | 125 TEUR | | Zulieferung von I.NMF 32/FaPü | 1.000 TEUR | | Zulieferung von Projekt AC-Trasse | 260 TEUR | | Zulieferung von CST (KDV + BBZ) | 70 TEUR | | PGM (Annahme: 150 TEUR/ Jahr) | 500 TEUR | | Miete (Annahme: 150 TEUR/ Jahr) | 500 TEUR | | Schulung | - | | SUMME (GWU) | 23.004 TEUR | | + Aktivierbare Eigenleistungen | 2.269 TEUR | | + Kosten ART Vertrieb | 3.622 TEUR