# Strategische Reorganisation O2C + C2S Stand: 2026-06-17 | Status: Entwurf — Feedback-Iteration nötig ## Übergreifendes Ziel Eine Struktur schaffen, die: - Am E2E-Kundenprozess orientiert ist (Customer Journey) - Abstimmungszeiten reduziert - Synergien zwischen O2C und C2S hebt - Klar in Aufbauorganisation (disziplinarisch) und Ablauforganisation (Value Teams) trennt ## Ist-Zustand: Zwei getrennte Welten ``` ┌─────────────────────────────────────────────────────────────────┐ │ KUNDE (EVU/ZB) │ │ 1. Informieren → 2. Planen → 3. Bestellen → 4. Fahren → │ │ 5. Abrechnen → 6. Auswerten │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ Trassenfinder pathOS/TPN pathOS AC Trasse InKa GretA, IDBF Infraportal Bestellung SAP BRIM Power BI strecken.zeit APN │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌───┴───┐ ┌────┴───┐ ┌──┴──┐ │DigiPaLö │ │ pathOS │ │pathOS │ │ ART │ │ART │ │(11 P.) │ │ (53 P.) │ │ │ │Abrech. │ │ CM │ │ │ │ │ │ │ │(52 P.) │ │(44) │ └─────────┘ └─────────┘ └───────┘ └────────┘ └─────┘ O2C O2C O2C O2C C2S ``` **Problem:** Der Kundenprozess ist fragmentiert über 2 Value Teams (O2C/C2S) mit getrennter Führung, getrennten Plattformen, getrennten PI-Plannings. ## Identifizierte Synergien und Bruchstellen ### 1. Kunden-Schnittstelle ist gespalten - **Infraportal** (DigiPaLö/O2C) = Kundenportal - **InKa** (ART CM/C2S) = Auslastung, Kapazität — Kunden greifen dort auf Daten zu - **Trassenfinder** (DigiPaLö/O2C) = Routensuche — nutzt IDBF-Daten (C2S) → Der Kunde springt zwischen O2C- und C2S-Systemen, ohne es zu merken. ### 2. Datenplattformen sind gedoppelt - **IDBF / Infrastrukturmanager** (C2S, 49 Pers.) = Infrastrukturdaten - **Trassenfinder** (O2C, 11 Pers.) = zeigt dieselben Infrastrukturdaten - **InKa** (ART CM / Team CMDP, C2S) = Integrierte Kapazitätsmanagementplattform, Auslastungsdaten - **Data Team IWF9** (O2C, 5 Pers.) = Abrechnungs-/Vertriebsdaten - **Power BI Dashboards** existieren in beiden Bereichen → Mehrere Teams verarbeiten und visualisieren dieselben Grunddaten. ### 3. Plattform-Fragmentierung - **SIC OP** (C2S Plattform, 47 Pers.) = Plattform für C2S-Teams - **pathOS Release-Zug** (O2C) = eigene Deployment-Infrastruktur - **CNP** (APN Migration) = nochmal andere Plattform → Drei verschiedene Betriebsmodelle für Systeme, die am gleichen Kundenprozess hängen. ### 4. Data Science bei O2C ist nicht FINANCE 4 DB - Das **Data Team IWF9** (Leitung: Markus Germany) ist direkt bei IWF9 verortet - 5 Data Scientists, Abrechnung/Vertriebsdaten/kundenrelevante Daten, Power BI Self-Service - Unabhängig vom Konzern-Finance-Team FINANCE 4 DB (CXF 2), das in DB-Planet-Suche auftaucht ## Zielarchitektur: E2E-orientierte Streams ### Variante A: 5 Streams + Plattform (Kommunikation & Bau als eigener Stream) ``` ┌─────────────────────────────────────────────────────────────────┐ │ E2E Customer Journey │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Stream 1: ZUGANG & INFORMATION │ │ → Infraportal, Trassenfinder, NiCo, GretA, iTrace, PlaTo, │ │ IDBF-Portal/Infrastrukturmanager │ │ → ~60 Personen │ │ │ │ Stream 2: BESTELLEN & VERTRAGSMANAGEMENT │ │ → pathOS, TrassenOrder, TPN, APN, Click&Ride │ │ → ~95 Personen │ │ (TTTneo-Projekt übergreifend mit Stream 3) │ │ │ │ Stream 3: FAHRPLAN & KAPAZITÄT │ │ → SIC OP (Plattform für Fahrplan-IT), KonBel, InKa, TAKT, │ │ strecken.zeit, UjK, UjV, KuK │ │ → ~450 Personen │ │ (TTTneo-Projekt übergreifend mit Stream 2) │ │ │ │ Stream 4: KOMMUNIKATION, BAU & TRANSPARENZ │ │ (NEU — herausgelöst aus Stream 3 + DigiPaLö-Teile) │ │ → Regelkommunikation (KOM), BBPneo/BARD, BAPSI 2.0, KomBAU, │ │ DB Livemaps, strecken.info │ │ → #Einfachbahn + neXt als "Schnelle Lösungen"-Team │ │ → ~140 Personen │ │ │ │ Stream 5: ABRECHNUNG & ANALYTICS │ │ → AC Trasse, SAP BRIM, Data Team IWF9, Power BI │ │ → ~60 Personen │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ PLATTFORM (Querschnitt) │ │ → SIC OP Betrieb + pathOS-Infra + CI/CD → konsolidiert │ │ → QuEST (E2E Testing) │ │ → ~65 Personen │ │ │ │ PROJEKTE (temporär, übergreifend) │ │ → TTTneo (Stream 2 + 3) │ └─────────────────────────────────────────────────────────────────┘ ``` **Vorteil Variante A:** Klare Trennung von Bau-Kommunikation aus dem Fahrplan-Kern. Stream 4 bündelt alles, was mit externer Transparenz Richtung Kunde zu tun hat (Baustellen, Livemaps, strecken.info). #Einfachbahn + neXt als schnelle, kundennahe Einheit kann unabhängig iterieren. **Risiko:** Neuer Stream 4 hat Abhängigkeiten zu Stream 3 (Bau-Daten kommen aus Fahrplanwelt). Abstimmung nötig für Datenflüsse. --- ### Variante B: 4 Streams + Plattform (Kommunikation & Einfachbahn in Stream 1) ``` ┌─────────────────────────────────────────────────────────────────┐ │ E2E Customer Journey │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Stream 1: ZUGANG, INFORMATION & KOMMUNIKATION │ │ → Infraportal, Trassenfinder, NiCo, GretA, iTrace, PlaTo, │ │ IDBF-Portal, Regelkommunikation (KOM), BBPneo/BARD, │ │ BAPSI 2.0, KomBAU, DB Livemaps, strecken.info, │ │ #Einfachbahn + neXt als "Schnelle Lösungen"-Team │ │ → ~200 Personen │ │ │ │ Stream 2: BESTELLEN & VERTRAGSMANAGEMENT │ │ → pathOS, TrassenOrder, TPN, APN, Click&Ride │ │ → ~95 Personen │ │ (TTTneo-Projekt übergreifend mit Stream 3) │ │ │ │ Stream 3: FAHRPLAN & KAPAZITÄT │ │ → SIC OP (Plattform für Fahrplan-IT), KonBel, InKa, TAKT, │ │ strecken.zeit, UjK, UjV, KuK │ │ → ~450 Personen │ │ (TTTneo-Projekt übergreifend mit Stream 2) │ │ │ │ Stream 4: ABRECHNUNG & ANALYTICS │ │ → AC Trasse, SAP BRIM, Data Team IWF9, Power BI │ │ → ~60 Personen │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ PLATTFORM (Querschnitt) │ │ → SIC OP Betrieb + pathOS-Infra + CI/CD → konsolidiert │ │ → QuEST (E2E Testing) │ │ → ~65 Personen │ │ │ │ PROJEKTE (temporär, übergreifend) │ │ → TTTneo (Stream 2 + 3) │ └─────────────────────────────────────────────────────────────────┘ ``` **Vorteil Variante B:** Weniger Streams = weniger Abstimmung auf oberster Ebene. Alles was der Kunde "sieht" (Information, Kommunikation, Transparenz) liegt in einem Stream. Einheitliche Kundenschnittstelle. **Risiko:** Stream 1 wird sehr groß (~200 Pers.) und heterogen (Portal-Entwickler neben Bau-Kommunikatoren). Führungsspanne hoch. ## Vergleich | Dimension | Variante A (5 Streams) | Variante B (4 Streams) | |-----------|----------------------|----------------------| | Streams | 5 + Plattform | 4 + Plattform | | Größter Stream | ~450 (Fahrplan) | ~450 (Fahrplan) | | Kundennähe | Stream 4 fokussiert | Stream 1 bündelt alles | | Abstimmung | Mehr inter-Stream (4↔3) | Weniger inter-Stream | | #Einfachbahn | Eigener Raum in Stream 4 | Teil eines großen Stream 1 | | Führungskomplexität | Moderat pro Stream | Stream 1 sehr breit | | Schnelle Lösungen | Eigener Speed-Bereich | Konkurriert mit Portal-Betrieb | ## Empfehlung **Variante A** wenn: Schnelligkeit und Kundenorientierung für Bau-Transparenz und #Einfachbahn-Innovation Priorität haben. Eigener Stream = eigene Velocity. **Variante B** wenn: Minimale Abstimmung auf oberster Ebene und "One Face to Customer" wichtiger sind als Speed pro Sub-Domäne. ## Nächste Schritte 1. **Feedback-Runde** — Welche Variante passt zur strategischen Ausrichtung? 2. **Abhängigkeiten kartieren** — Welche APIs/Datenflüsse laufen zwischen den Streams? 3. **Führungsmodell** — Wer leitet welchen Stream? (Aufbau vs. Ablauf trennen) 4. **Transition-Plan** — Welche Teams bewegen sich wohin? Reihenfolge? 5. **Metriken definieren** — Woran messen wir Erfolg? (Lead Time, Abstimmungsstunden, Kundenzufriedenheit)