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.
This commit is contained in:
@@ -0,0 +1,199 @@
|
||||
# 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)
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# Tool-Landschaft: #Einfachbahn / DigiPaLö
|
||||
|
||||
Stand: 2026-06-17 | Quelle: DB Planet "#Einfachbahn" Produktseite + PDFs
|
||||
|
||||
## Produkte (Customer Journey)
|
||||
|
||||
| Tool | Zweck | Nutzer intern | Nutzer extern (Kunden/EVU) |
|
||||
|------|-------|---------------|---------------------------|
|
||||
| **Infraportal** | Zentrales Eingangstor zur DB InfraGO für Kunden | Nutzeradmin, Stammdatenadmin | Superuser: Nutzer-/Rechteverwaltung, Anliegen einreichen |
|
||||
| **DB NetzCockpit (NiCo)** | Internes Portal für DB InfraGO Mitarbeitende | Kalender, Nutzeradmin, Stammdatenadmin | – |
|
||||
| **Trassenfinder** | Routensuche auf Knopfdruck, Infrastrukturdaten | Trassenkonstrukteur:innen, Bauplaner:innen | Routensuche, Infrastrukturinfo, Übergabe an TPN |
|
||||
| **GretA** | Grenzlastberechnung (max. Last für Fahrzeuge) | GretA Leser/Fahrplan/Grenzlast/Admin | EGB beantragen, Regelgrenzlast-Suche (zugangsfrei) |
|
||||
| **strecken.zeit** | Streckenöffnungszeiten (4.400+ Betriebsstellen) | Leser/User/Admin: Vorlagen, Zeiten pflegen | Veröffentlichung (reguliert, SNB-Bestandteil) |
|
||||
| **BAPSI 2.0** | Baukommunikation SE + Infrastrukturanschlüsse | Leser/SE-IA-Bearbeiter/Admin | Baubetroffenheit einsehen, filtern |
|
||||
| **PlaTo** | Planungsparameter-Veröffentlichung + Stellungnahme | Bearbeiter/Admin: Fragen beantworten | Veröffentlichungen einsehen, Stellungnahmen abgeben |
|
||||
| **iTrace** | Marktorientierte Infrastrukturentwicklung | Infrastrukturentwicklung, Vertrieb, Fahrplan | iTrace-Ideen erstellen, Status einsehen |
|
||||
| **Formula** | Formularcenter: Fahrplanunterlagen + Förderung | – | Bestellung vereinfachen |
|
||||
| **BÜ Info** | Bahnübergangs-Informationen | Meldungen erstellen/verwalten | Meldungen einsehen |
|
||||
|
||||
## Aktuelle Projekte (aus DB Planet)
|
||||
|
||||
- BAKO (Baukommunikation)
|
||||
- DisKo (Dispositionskonzept)
|
||||
- EULE
|
||||
- ZAB Beta-Test
|
||||
- Infraportal
|
||||
- #freiefahrt
|
||||
- Trassenfinder Übergabe
|
||||
- KODA
|
||||
- AnDi Redesign
|
||||
- Transparente Anlagen in SE
|
||||
- VP Züge bereitstellen
|
||||
- Digitales Hallo
|
||||
- YODA
|
||||
|
||||
## Technologie-Hinweise
|
||||
|
||||
- Web-basierte Anwendungen (Angular vermutet, basierend auf APN-Migration)
|
||||
- Integration mit TPN (Trassenportal Netz) für Übergabe
|
||||
- NetzCockpit als internes Pendant zum Infraportal
|
||||
- BAPSI 2.0 importiert aus BBPneo (Baubetriebsplan)
|
||||
- Rollen-/Rechtemodell über Infraportal Superuser
|
||||
@@ -0,0 +1,148 @@
|
||||
# IT-Relevanz-Analyse der Funktionsbeschreibungen (FuBen)
|
||||
|
||||
**Datum:** 2026-06-18
|
||||
|
||||
**Scope:** IWF 2, 3, 4, 5, 6, 7, 8 und ihre Untereinheiten
|
||||
|
||||
**Ausgeschlossen:** IWF 1 (Strategie/Steuerung) und IWF 9 (Prozesse und IT)
|
||||
|
||||
**Suchbegriffe:** IT, Software, Anwendungen, Systeme, Digital, Tools, Plattform, Portal, Datenbank, Automatisierung, Datenmanagement, Schnittstelle, SAP, ERP, Applikation, elektronisch
|
||||
|
||||
## Legende Bewertung
|
||||
|
||||
| Symbol | Bedeutung |
|
||||
|---|---|
|
||||
| ✅ Ja | Aufgabe sollte in die IT-Abteilung wandern |
|
||||
| ⚠️ Teilweise | IT-Unterstützung nötig, fachliche Verantwortung bleibt in der OE |
|
||||
| 🔍 Prüfen | Kontext unklar, weitere Analyse nötig |
|
||||
|
||||
---
|
||||
|
||||
## Ergebnisse
|
||||
|
||||
| OE | IT-relevante Textstelle | Bewertung |
|
||||
|---|---|---|
|
||||
| IWF 2 – Strategischer Fahrplan und Kapazitätsmanagement / Segmente | Fachliche Betriebsführung, Wartung und Weiterentwicklung des Systems „Netzmonitor“ Durchführen / Responsible | ⚠️ Teilweise – Systemnutzung mit fachlichem Kontext |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | Darstellen und Monitoren der Daten des Fahrplan- und Kapazitätsmanagements über alle Fahrplanphasen. | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | der Vorhaltung und Weiterentwicklung der notwendigen Daten in den für die Geschäftsanalytik im Fahrplan und Kapazitätsmanagement relevanten Systemen | 🔍 Prüfen – möglicherweise IT-relevant (Systembezug) |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | der Plan-IT (integriertes Verkehrsmodell für die Netzentwicklung), Verkehrsmodellierung und widerstandsbasierten und fahrplanscharfen Verkehrsumlegung der netzweiten Prognose auf das Netz | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | der Implementierung von Tools zur Transparenzschaffung der heutigen Kapazitätsnutzung sowie in Fragestellungen des Kapazitätsmanagements über alle Fahrplanphasen hinweg | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | der fachlichen Betriebsführung, Wartung und Weiterentwicklung der Plattform für Daten des Fahrplans und Kapazitätsmanagements | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | der konsistenten Zusammenführung von Daten aus verschiedenen Quellsystemen zur Sicherstellung von Vergleichbarkeit und Reproduzierbarkeit | ⚠️ Teilweise – Systemnutzung mit fachlichem Kontext |
|
||||
| IWF 22 – Bautaktkonzeption | Erarbeitung von verkehrlichen Rahmenbedingungen (Netzmodell, Ausschlüsse, Definition von Bautakten) als Grundlage für die Bautaktbildung und Weiterentwicklung und Anwendung von mathematischen Modellen zur Optimierung von Bauprogrammen und Bewertung von deren Kapazitätsauswirkungen | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 22 – Bautaktkonzeption | Informiert werden über die Anwendung von Fahrplaninstrumenten für Baumaßnahmen in den Prozessphasen „Strategische Bauplanung“ und „Integrierte Bündelung“. Besonderheiten | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 221 – Baubedarfsbündelung und Bautakte | der fachlich strategischen und prozessualen Anforderungen zur Entwicklung und Weiterentwicklung der fachlich verantworteten und/oder betriebsgeführten Systeme (z.B. BaBetT, MakSi-SP) | ⚠️ Teilweise – Systemnutzung mit fachlichem Kontext |
|
||||
| IWF 221 – Baubedarfsbündelung und Bautakte | der fachlichen Tests und der fachlichen Abnahmen der inhaltlich verantworteten und/oder betriebsgeführten Systeme (z.B. BaBetT) | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 221 – Baubedarfsbündelung und Bautakte | der Releaseplanung der inhaltlich verantworteten Systeme in Abstimmung mit allen Beteiligten (z.B. BaBetT, MakSi-SP) Funktionsbeschreibung V.IWF 221 Baubedarfsbündelung und Bautakte Seite 2 | 🔍 Prüfen – möglicherweise IT-relevant (Systembezug) |
|
||||
| IWF 221 – Baubedarfsbündelung und Bautakte | der Definition von Anforderungen aus gesetzlichen Vorgaben an IT der Baubetriebsplanung Mitwirken / Consulted | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 221 – Baubedarfsbündelung und Bautakte | über die Anwendung von Fahrplaninstrumenten für Baumaßnahmen im Planungshorizont 10 bis 2 Jahre vor Ausführung der Baumaßnahmen Besonderheiten | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 24 – Fahrwegkapazität und EBWU | der Koordination neuer IT-Anforderungen für V.IWF 2 in den entsprechenden Gremien (FBAK) und der fachlichen Anwenderbetreuung bei der Nutzung der EBW-Verfahren | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 3 – Netzfahrplan | ...ittelfristfahrplan und Jahresfahrplan mit besonderem Fokus auf Innovationen und Digitalisierung im Fahrplan | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 3 – Netzfahrplan | aller strategischen Entwicklungen des operativen Fahrplans und Kapazitätsmanagements in internationalen Angelegenheiten inkl. erforderlicher IT-Anforderungen und der entsprechenden Abstimmung in internationalen Gremien und Organisationen | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 31 – Regelwerk und Kompetenzmanagement Netzfahrplan | aller Abstimmungen und Anforderungen zur Erstellung und Weitergabe der Fahrplanunterlagen einschließlich Erheben aller dafür erforderlichen IT-Anforderungen | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 31 – Regelwerk und Kompetenzmanagement Netzfahrplan | der Koordination der fachlichen Anforderungen der Bereiche Produkt- und Vertriebsmanagement, Europäische Korridore und Kooperationen, Betrieb, Fahrplan und Kapazitätsmanagement, Netzzugang und Regulierung und Prozesse und IT inklusive Lean Mitwirken / Consulted | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 311 – Operative Exzellenz Fahrplan | von fachlichen Bedarfsanforderungen an IT-Anwendungen im Zusammenhang mit der Umsetzung der Ansätze aus dem Programm | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 33 – Erstellung Netzfahrplan | der konzeptionellen Weiterentwicklung der IT durch Ableitung und Dokumentation fachlicher Anforderungen das Vorbereiten von Eskalationen bis hin zum TOP-Management | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 33 – Erstellung Netzfahrplan | der Erarbeitung von Verfahren zur Bereitstellung /Verteilung von Fahrplanunterlagen/-daten Besonderheiten | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 331 – Integrierte Bündelung und Baumaßnahmen Netzfahrplan | Prozessentwicklung und die daraus resultierenden IT-Anforderungen Hauptaufgaben Verantworten / Accountable | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 331 – Integrierte Bündelung und Baumaßnahmen Netzfahrplan | der fachlichen Erarbeitung von Bedarfsanforderungen für IT-Anwendungen im Rahmen der entsprechenden Vorgaben für alle im Aufgabengebiet zu verantwortenden Themen | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 331 – Integrierte Bündelung und Baumaßnahmen Netzfahrplan | bei fachlichen IT Anforderungen | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 34 – Zugfahrtsimulation und Befahrbarkeitsuntersuchungen | der Weiterentwicklung und Vorhaltung geeigneter Werkzeuge und Datenbanken für Zugfahrtsimulation und Triebfahrzeugdaten | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 34 – Zugfahrtsimulation und Befahrbarkeitsuntersuchungen | der Aufbereitung und Weitergabe von fahrdynamischen Fahrzeugdaten an nachgelagerte Systeme | 🔍 Prüfen – möglicherweise IT-relevant (Systembezug) |
|
||||
| IWF 34 – Zugfahrtsimulation und Befahrbarkeitsuntersuchungen | bei der Implementierung fahrdynamisch zugmassenrelevanter Applikationen in anderen Anwendungen, konzernweit und beratend für die Fahrzeugindustrie | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 4 – Unterjähriger Fahrplan und Baubetriebsmanagement | Die OE verantwortet die Weiterentwicklung des operativen Fahrplan- und Kapazitätsmanagements für die Phase unterjähriger Baufahrplan und kurzfristige Baubetriebsplanung mit besonderem Fokus auf Innovationen und Digitalisierung Hauptaufgaben Verantworten / Accountable | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 4 – Unterjähriger Fahrplan und Baubetriebsmanagement | der fachlich strategischen und prozessualen Anforderungen zur Entwicklung und Weiterentwicklung der fachlich verantworteten und/oder betriebsgeführten Systeme (z.B. BBP, PAULA, TaT-Lue) | ⚠️ Teilweise – Systemnutzung mit fachlichem Kontext |
|
||||
| IWF 4 – Unterjähriger Fahrplan und Baubetriebsmanagement | der fachlichen Tests und der fachlichen Abnahmen der inhaltlich verantworteten und/oder betriebsgeführten Systeme (z.B. BBP, PAULA, TaT-Lue) | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 4 – Unterjähriger Fahrplan und Baubetriebsmanagement | der fachlichen Betriebsführung der IT–Anwendung „Paula/Tages-La“ zur Erarbeitung von La – Einträgen, einschließlich der qualifizierten Datenübergabe an die EVU Durchführen / Responsible | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 4 – Unterjähriger Fahrplan und Baubetriebsmanagement | der Releaseplanung der inhaltlich verantworteten Systeme in Abstimmung mit allen Beteiligten (z.B. BBP, PAULA, TaT-Lue) Mitwirken / Consulted | 🔍 Prüfen – möglicherweise IT-relevant (Systembezug) |
|
||||
| IWF 41 – Unterjähriger Fahrplan und Baufahrplan | der konzeptionellen Weiterentwicklung der IT durch Ableitung und Dokumentation fachlicher Anforderungen Durchführen / Responsible | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 41 – Unterjähriger Fahrplan und Baufahrplan | der Erarbeitung von Verfahren zur Bereitstellung und Verteilung von Fahrplanunterlagen und -daten | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 42 – Kurzfristige Baubetriebsplanung | der Definition von Anforderungen an die IT der Baubetriebsplanung | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 5 – Kapazitätssteuerung | der Definition von Anforderungen aus gesetzlichen Vorgaben an Prozesse und IT der Baubetriebsplanung | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 5 – Kapazitätssteuerung | der Weiterentwicklungsaktivitäten des Portals zur Erstanmeldung Durchführen / Responsible | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 51 – Unterjährige Kapazitätsbewertung und -steuerung | bei den notwendigen und vorgeschlagenen Maßnahmen und ggf. Umsetzung von baubetrieblichen Optimierungen durch die Regionen sowie bei der Anwendung von Fahrplanhebeln Besonderheiten | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Weiterentwicklung der Eingabeunterstützung/Nutzerführungen in den IT-Systemen des eigenen Verantwortungsbereichs | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Entwicklung von Tools zur Verbesserung der Analysefähigkeit | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Sicherstellung des Anforderungsmanagements für die IT-Systeme im eigenen Verantwortungsbereich (bspw. Portal zur Erstanmeldung und Bauprognose-App) | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Formulierung und Abstimmung von fachlichen IT-Anforderungen zur Weiterentwicklung der Kennzahlenerhebung/-verfügbarkeit | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Umsetzung und Etablierung von Prognosemodellen für ausgewählte Kennzahlen unter Anwendung moderner Methoden des maschinellen Lernens und der Statistik | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Erarbeitung von Eingabeszenarien und Nutzerführungskonzepten für das Portal zur Erstanmeldung | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Bündelung von Weiterentwicklungsaktivitäten des Portals zur Erstanmeldung Funktionsbeschreibung V.IWF 52 Kennzahlen und Analysen Kapazitätssteuerung Seite 2 | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Integration von Planungsvorgaben (bspw. Standardsperrzeiten) im Portal zur Erstanmeldung sowie Unterstützung beim Nachhalten der Vorgaben im Rahmen der baubetrieblichen Anzeige und der Erstanmeldung | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | Erarbeitung von Umsetzungskonzepten für die Anforderungen an die IT-Systeme im eigenen Verantwortungsbereich Mitwirken / Consulted | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 6 – Netzzugang und Regulierung | der fristgerechten Lieferung von Daten für das europäische RINF | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 6 – Netzzugang und Regulierung | ...Owner“ die Transparenz, Qualität, Verfügbarkeit, Teilbarkeit und Compliance der Daten, die durch das zuständige Data-Gremium zugeordnet sind inkl. der Benennung von „Data Stewards“, mit deren Hilfe Maßnahmen zur Verbesserung der Datenqualität entwickelt, umgesetzt und der Umsetzungserfolg mittels KPIs ge... | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 6 – Netzzugang und Regulierung | an Prozessschnittstellen zu anderen Teilen der End-to-End-Prozesslandkarten sowie an der Datenstrategie und dem unternehmensweiten Datenmanagement in Abstimmung mit der CDO- Organisation Besonderheiten | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 61 – Netzzugangsrecht | der Entwicklung von digitalen Auswertungs- und Erwiderungsmöglichkeiten in den in den Verantwortungsbereich fallenden Rechtsgebieten („legal tech“) in Zusammenarbeit mit Kooperationspartnern | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 7 – Marktplanung und -entwicklung | der Definition der Anforderungen für die Weiterentwicklung der Abrechnungssysteme und IT- Systeme für das Vertriebscontrolling | 🔍 Prüfen – möglicherweise IT-relevant (Systembezug) |
|
||||
| IWF 7 – Marktplanung und -entwicklung | der Digitalisierung von wertschöpfenden Prozessen, um einen maximalen Automatisierungsgrad bei höchstem Geschäftspartnernutzen zu gewährleisten, insbesondere die fachliche Priorisierung, Korrektheit und Sinnhaftigkeit (Richtigkeit) der fachlichen Anforderungen an die IT-Umsetzung (Business Owner) | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 7 – Marktplanung und -entwicklung | der Anwendung von Prognose-Instrumenten zur Vorhersage von kurz-, mittel- und langfristigen marktspezifischen Absatz- und Umsatzentwicklungen | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 71 – Infrastrukturentwicklung | bei der Digitalisierung und Automatisierung von Aufgaben durch Einbringen von Anforderungen in die Entwicklung von IT-Anwendungen, fachliche Beratung bei der Implementierung und Abnahme (Testing) der Anwendungen, sowie ggf. Prozessanpassungen Besonderheiten | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 72 – Grundsätze Abrechnung und operative Abrechnung | der qualitätsgerechten Einführung weiterentwickelter Abrechnungsprozesse und -systeme | ⚠️ Teilweise – Systemnutzung mit fachlichem Kontext |
|
||||
| IWF 72 – Grundsätze Abrechnung und operative Abrechnung | bei der Digitalisierung und Automatisierung von Aufgaben durch Einbringen von Anforderungen in die Entwicklung von IT-Anwendungen, fachliche Beratung bei der Implementierung und Abnahme (Testing) der Anwendungen, sowie ggf. Prozessanpassungen Besonderheiten | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 73 – Forderungsmanagement und operative Abrechnung | der qualitätsgerechten Einführung weiterentwickelter Forderungsmanagementprozesse und - systeme | ⚠️ Teilweise – Systemnutzung mit fachlichem Kontext |
|
||||
| IWF 73 – Forderungsmanagement und operative Abrechnung | bei der Digitalisierung und Automatisierung von Aufgaben durch Einbringen von Anforderungen in die Entwicklung von IT-Anwendungen, fachliche Beratung bei der Implementierung und Abnahme (Testing) der Anwendungen, sowie ggf. Prozessanpassungen Besonderheiten | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 8 – Produkt- und Preismanagement | der fachlichen Führung und funktionalen Steuerung der regionalen und zentralen Vertriebsorganisationseinheiten mit dem Ziel der einheitlichen Anwendung aller Regularien zu Entgelten und Produkten | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 8 – Produkt- und Preismanagement | des Risikomanagements bezüglich aller preisrelevanten externen Risiken, und hier insbesondere den regulierungsrechtlichen und zivilrechtlichen Risiken und der Durchsetzbarkeit der Anwendung der Entgeltsysteme | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 8 – Produkt- und Preismanagement | der Digitalisierung von wertschöpfenden Prozessen, um einen maximalen Automatisierungsgrad bei höchstem Geschäftspartnernutzen zu gewährleisten, insbesondere die fachliche Priorisierung und Korrektheit und Sinnhaftigkeit (Richtigkeit) der ... | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 8 – Produkt- und Preismanagement | der Entwicklung der IT-gestützten Entgeltmodelle sowie der vertrieblichen Unterlagen für die Entgeltsysteme von Trassen, Serviceeinrichtungen, Zusatz- und Nebenleistungen sowie Infrastrukturanschlüssen | 🔍 Prüfen – möglicherweise IT-relevant (Systembezug) |
|
||||
| IWF 81 – Produkt- und Preismanagement Serviceeinrichtungen und Infrastrukturanschlüsse | Fachliche Steuerung des Vertriebs in den Regionen und der Zentrale in allen Fragen der Anwendung der Produkte und Entgeltregelungen für Serviceeinrichtungen und Infrastrukturanschlüsse Hauptaufgaben Verantworten / Accountable | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 81 – Produkt- und Preismanagement Serviceeinrichtungen und Infrastrukturanschlüsse | der Rolle des fachlichen Ansprechpartners für die Anwendung der Entgelte und Produkte Serviceeinrichtungen und Infrastrukturanschlüsse | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 81 – Produkt- und Preismanagement Serviceeinrichtungen und Infrastrukturanschlüsse | bei der Digitalisierung und Automatisierung von Aufgaben durch Einbringen von Anforderungen in die Entwicklung von IT-Anwendungen, fachliche Beratung bei der Implementierung und Abnahme (Testing) der Anwendungen, sowie ggf. Prozessanpassungen Besonderheiten | ✅ Ja – klare IT-Aufgabe |
|
||||
| IWF 82 – Produkt- und Preismanagement Trasse | Fachliche Steuerung des Vertriebs in den Regionen und der Zentrale in allen Fragen der Anwendung der Produkte und Entgeltregelungen von Trassen Hauptaufgaben Verantworten / Accountable | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 82 – Produkt- und Preismanagement Trasse | der Rolle des fachlichen Ansprechpartners für die Regionen und Zentrale und Unterstützung dieser bei der Anwendung der Entgelte und Produkte Trasse | ⚠️ Teilweise – IT-Unterstützung nötig, fachliche Verantwortung bleibt |
|
||||
| IWF 82 – Produkt- und Preismanagement Trasse | des Risikomanagements bezüglich aller preisrelevanten externen Risiken für die Trasse, und hier insbesondere den regulierungsrechtlichen und zivilrechtlichen Risiken und der Durchsetzbarkeit der Anwendung der Entgeltsysteme | ✅ Ja – IT-Aufgabe |
|
||||
| IWF 82 – Produkt- und Preismanagement Trasse | der fachlichen Führung der IT-Instrumente zum Schienenlärmschutzgesetz | 🔍 Prüfen – Kontext unklar |
|
||||
| IWF 82 – Produkt- und Preismanagement Trasse | bei der Digitalisierung und Automatisierung von Aufgaben durch Einbringen von Anforderungen in die Entwicklung von IT-Anwendungen, fachliche Beratung bei der Implementierung und Abnahme (Testing) der Anwendungen, sowie ggf. Prozessanpassungen Besonderheiten | ✅ Ja – klare IT-Aufgabe |
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Kategorie | Anzahl |
|
||||
|---|---|
|
||||
| ✅ Klare IT-Aufgaben | 33 |
|
||||
| ⚠️ Teilweise IT-relevant | 20 |
|
||||
| 🔍 Zu prüfen | 19 |
|
||||
| **Gesamt** | **72** |
|
||||
|
||||
### Verteilung nach Organisationseinheit
|
||||
|
||||
| OE | Anzahl IT-Stellen |
|
||||
|---|---|
|
||||
| IWF 2 – Strategischer Fahrplan und Kapazitätsmanagement / Segmente | 1 |
|
||||
| IWF 21 – Strategischer Fahrplan, Netzkonzeption und Geschäftsanalytik | 6 |
|
||||
| IWF 22 – Bautaktkonzeption | 2 |
|
||||
| IWF 221 – Baubedarfsbündelung und Bautakte | 5 |
|
||||
| IWF 24 – Fahrwegkapazität und EBWU | 1 |
|
||||
| IWF 3 – Netzfahrplan | 2 |
|
||||
| IWF 31 – Regelwerk und Kompetenzmanagement Netzfahrplan | 2 |
|
||||
| IWF 311 – Operative Exzellenz Fahrplan | 1 |
|
||||
| IWF 33 – Erstellung Netzfahrplan | 2 |
|
||||
| IWF 331 – Integrierte Bündelung und Baumaßnahmen Netzfahrplan | 3 |
|
||||
| IWF 34 – Zugfahrtsimulation und Befahrbarkeitsuntersuchungen | 3 |
|
||||
| IWF 4 – Unterjähriger Fahrplan und Baubetriebsmanagement | 5 |
|
||||
| IWF 41 – Unterjähriger Fahrplan und Baufahrplan | 2 |
|
||||
| IWF 42 – Kurzfristige Baubetriebsplanung | 1 |
|
||||
| IWF 5 – Kapazitätssteuerung | 2 |
|
||||
| IWF 51 – Unterjährige Kapazitätsbewertung und -steuerung | 1 |
|
||||
| IWF 52 – Kennzahlen und Analysen Kapazitätssteuerung | 9 |
|
||||
| IWF 6 – Netzzugang und Regulierung | 3 |
|
||||
| IWF 61 – Netzzugangsrecht | 1 |
|
||||
| IWF 7 – Marktplanung und -entwicklung | 3 |
|
||||
| IWF 71 – Infrastrukturentwicklung | 1 |
|
||||
| IWF 72 – Grundsätze Abrechnung und operative Abrechnung | 2 |
|
||||
| IWF 73 – Forderungsmanagement und operative Abrechnung | 2 |
|
||||
| IWF 8 – Produkt- und Preismanagement | 4 |
|
||||
| IWF 81 – Produkt- und Preismanagement Serviceeinrichtungen und Infrastrukturanschlüsse | 3 |
|
||||
| IWF 82 – Produkt- und Preismanagement Trasse | 5 |
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Fazit
|
||||
|
||||
Die Analyse zeigt, dass IT-bezogene Aufgaben über die gesamte Organisation verteilt sind. Besonders in den Bereichen Kapazitätsmanagement (IWF 2), Netzfahrplan (IWF 3), Kapazitätssteuerung (IWF 5) und Produkt-/Preismanagement (IWF 8) finden sich Aufgaben mit starkem IT-Bezug, die potenziell in eine zentrale IT-Abteilung wandern könnten.
|
||||
|
||||
**Empfehlung:** Die mit ✅ markierten Aufgaben sollten prioritär geprüft werden, ob sie in IWF 9 (Prozesse und IT) zentralisiert werden können.
|
||||
@@ -0,0 +1,158 @@
|
||||
# Konsistenzprüfung gegen verifizierte Fakten
|
||||
|
||||
Stand: 2026-06-18 | Methode: Automatischer Abgleich aller Output-Dateien gegen 16 verifizierte Fakten
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Datei | Inkonsistenzen |
|
||||
|-------|---------------|
|
||||
| index.html | 0 |
|
||||
| uebersicht.html | 1 |
|
||||
| reorganisation.html | 2 |
|
||||
| architektur.html | 3 |
|
||||
| organigramm-zukunft.html | 3 |
|
||||
| bereich-reorg.html | 1 |
|
||||
| 2026-06-17-strategische-reorganisation.md | 1 |
|
||||
| **Gesamt** | **11** |
|
||||
|
||||
---
|
||||
|
||||
## Detaillierte Befunde
|
||||
|
||||
### 1. uebersicht.html
|
||||
|
||||
**Fakt 1 — Team XWing fehlt bei ART Abrechnung**
|
||||
- Verifiziert: Teams **Coruscant, Rogue One, XWing** → ART Abrechnung / AC Trasse
|
||||
- In Datei: ART Abrechnung listet Coruscant, Rogue One, Taskforce Wookies, Team SAP — aber **Team XWing fehlt**
|
||||
- Handlung: XWing als Team im ART Abrechnung ergänzen
|
||||
|
||||
---
|
||||
|
||||
### 2. reorganisation.html
|
||||
|
||||
**Fakt 6 — strecken.zeit in falscher Domäne (Variante B, Stream 1)**
|
||||
- Verifiziert: **strecken.zeit** → belongs to **Stream 3** (Fahrplan & Kapazität), NOT Stream 1
|
||||
- In Datei (Variante B): strecken.zeit ist korrekt in Stream 3 gelistet (Tools: „KonBel, InKa, TAKT, strecken.zeit, UjK, UjV, KuK") ✅
|
||||
- **Aber** in Variante B → Stream 1 listet „strecken.info" — das ist korrekt (strecken.info ≠ strecken.zeit)
|
||||
- **Kein Fehler bei strecken.zeit hier.**
|
||||
|
||||
**Fakt 2 — INKA Zuordnung mehrdeutig**
|
||||
- Verifiziert: **INKA** = Integrierte Kapazitätsmanagementplattform, Teil von **ART CM / Team CMDP**
|
||||
- In Datei (Variante A, Stream 3): InKa wird unter Stream 3 (Fahrplan & Kapazität) gelistet mit Kommentar „heute: SuN + UjK + UjV + KuK + **CM**"
|
||||
- Bewertung: Die Stream-Zuordnung (InKa → Stream 3) ist eine **Reorganisations-Entscheidung** und kein Faktenfehler. Aber die IST-Zugehörigkeit (ART CM) sollte explizit erwähnt werden, um Verwechslung zu vermeiden.
|
||||
- Handlung: Klarstellen, dass InKa im IST bei ART CM liegt und im SOLL nach Stream 3 wandert.
|
||||
|
||||
**Fakt 5 — SIC OP Ownership unklar**
|
||||
- Verifiziert: **ART Plattform** → produces **SIC OP** (Secure Integrated Compliant Operations Platform)
|
||||
- In Datei: Stream 3 listet SIC OP als Tool, mit Kommentar „heute: SuN + UjK + UjV + KuK + CM" — **ART Plattform wird nicht als SIC-OP-Owner genannt**
|
||||
- Im Plattform-Querschnitt steht: „SIC OP Betrieb + pathOS-Infra + CI/CD → konsolidiert"
|
||||
- Bewertung: SIC OP taucht in zwei Kontexten auf (als Fahrplan-System UND als Plattform-Betrieb), ohne dass ART Plattform als Produzent explizit benannt wird.
|
||||
- Handlung: Klarstellen, dass ART Plattform der Producer von SIC OP ist.
|
||||
|
||||
---
|
||||
|
||||
### 3. architektur.html
|
||||
|
||||
**Fakt 2 — INKA als Teil von CMDP dargestellt, aber Name falsch**
|
||||
- Verifiziert: **INKA** = **Integrierte Kapazitätsmanagementplattform**
|
||||
- In Datei: „CMDP (CM Data Platform) — Datenplattform für Kapazitätsmanagement — Teams Crush + Marlin **(inkl. INKA)**"
|
||||
- Bewertung: INKA wird hier als Unterkomponente von CMDP dargestellt. Das ist konsistent mit Fakt 2 (Teil von ART CM / Team CMDP), aber der vollständige Name „Integrierte Kapazitätsmanagementplattform" fehlt, und die Darstellung suggeriert INKA sei ein Modul von CMDP statt ein eigenständiges Produkt.
|
||||
- Handlung: INKA als eigenständiges System im ART CM hervorheben mit vollem Namen.
|
||||
|
||||
**Fakt 3 — Data Team IWF9 Beschreibung unpräzise**
|
||||
- Verifiziert: **Data Team IWF9** — Leitung **Markus Germany**, direkt bei IWF9, **NOT FINANCE 4 DB**
|
||||
- In Datei: „Data Team (IWF9) — 5 Data Scientists — Abrechnung, Vertriebsdaten, kundenrelevante Daten. Power BI Self-Service." Owner: „Abteilung IWF9"
|
||||
- Bewertung: Leiter „Markus Germany" wird nicht genannt. Kein expliziter Hinweis, dass es NICHT FINANCE 4 DB ist.
|
||||
- Handlung: Leitung (Germany) ergänzen; Klarstellung, dass es kein FINANCE 4 DB Team ist.
|
||||
|
||||
**Fakt 6 — strecken.zeit falsche Domäne**
|
||||
- Verifiziert: **strecken.zeit** → belongs to **Stream 3** (Fahrplan & Kapazität)
|
||||
- In Datei: strecken.zeit ist unter Domäne „Fahrplan-Veröffentlichung & Kommunikation" gelistet mit Owner „DigiPaLö (11)"
|
||||
- Bewertung: Die Domäne „Fahrplan-Veröffentlichung & Kommunikation" ist **nicht** Stream 3 (Fahrplan & Kapazität). Zudem: Im SOLL gehört strecken.zeit zu Stream 3, aber hier steht Owner „DigiPaLö" — das ist der IST-Zustand (O2C). Die architektonische Sicht vermischt IST-Owner mit SOLL-Stream-Zuordnung.
|
||||
- Handlung: Klarstellen, dass strecken.zeit fachlich zu Fahrplan & Kapazität (Stream 3) gehört, auch wenn heute bei DigiPaLö verortet.
|
||||
|
||||
---
|
||||
|
||||
### 4. organigramm-zukunft.html
|
||||
|
||||
**Fakt 5 — SIC OP als Produkt von ART Plattform nicht erwähnt**
|
||||
- Verifiziert: **ART Plattform** → produces **SIC OP** (Secure Integrated Compliant Operations Platform)
|
||||
- In Datei (IST-Tab): ART Plattform wird nirgends namentlich erwähnt. In Variante C steht „Plattform — SIC OP Betrieb, CI/CD, QuEST" im Querschnitt — aber ohne Zuordnung zu ART Plattform als Produzent.
|
||||
- In Datei (Variante D): SIC OP taucht bei „Solution / Architektur (~12) — SIC OP Strategie" auf — hier als Strategiethema, nicht als Betriebsprodukt des ART Plattform.
|
||||
- Handlung: ART Plattform als Producer von SIC OP kennzeichnen.
|
||||
|
||||
**Fakt 16 — Data Team im Aftersales-Stream**
|
||||
- Verifiziert: **Data Team** → im **Aftersales-Stream** (Variante C/D), **NOT in Querschnitt**
|
||||
- In Datei (Variante D): Data Team erscheint bei „Team Data & Analytics (~20) — InKa, ML, Data Governance, **Data Team**" innerhalb der **IT-Abteilung (Querschnitt)**
|
||||
- Bewertung: Das Data Team wird der IT-Abteilung zugeordnet, nicht dem Aftersales-Stream. In Variante C steht es korrekt bei „Aftersales: Abrechnung & aktuelle Information" → „Data Team (Germany, ~5) — Power BI, Analytics" ✅
|
||||
- **Inkonsistenz:** Variante D platziert das Data Team in der IT-Abt. (Team Data & Analytics), während Fakt 16 es im Aftersales-Stream verortet. Die Varianten C und D widersprechen sich hier.
|
||||
- Handlung: In Variante D klarstellen, dass Data Team (Germany) fachlich dem Aftersales-Stream zugeordnet bleibt, auch wenn es organisatorisch in der IT-Abt. sitzt — ODER die Variante D korrigieren.
|
||||
|
||||
**Fakt 15 — Solution / Architektur Verortung**
|
||||
- Verifiziert: **Solution / Architektur (ex-IWF 15)** → im **Querschnitt-Team der IT-Abt.**
|
||||
- In Datei (Variante D): „Solution / Architektur (~12) — SIC OP Strategie, Übergreifend" — innerhalb der IT-Abteilung ✅
|
||||
- In Datei (Variante A): Stream 3 listet „Team Solution (ex-IWF 15, ~12)" — **innerhalb von Stream 3**, nicht im Querschnitt!
|
||||
- **Inkonsistenz:** Variante A ordnet Solution/Architektur dem Stream 3 zu, während Fakt 15 sie im Querschnitt der IT-Abt. verortet.
|
||||
- Handlung: In Variante A Solution/Architektur aus Stream 3 in den Querschnitt verschieben.
|
||||
|
||||
---
|
||||
|
||||
### 5. bereich-reorg.html
|
||||
|
||||
**Fakt 16 — Data Team im Aftersales, nicht in IT-Querschnitt**
|
||||
- Verifiziert: **Data Team** → im **Aftersales-Stream** (Variante C/D), NOT in Querschnitt
|
||||
- In Datei (SOLL-Tab, Aftersales): „+ Data Team (Germany)" → korrekt ✅
|
||||
- In Datei (Transition-Tab, IT-Abt. Ziel-Teams): „Team Data & Analytics (~20) — InKa, ML, Data Governance, **Data Team (Germany)**"
|
||||
- **Inkonsistenz:** Das Data Team taucht sowohl in der Aftersales-Abteilung (fachlich) als auch in der IT-Abt. „Team Data & Analytics" auf. Unklare Doppelzuordnung.
|
||||
- Handlung: Klare Trennung: Data Team = fachlich Aftersales, organisatorisch ggf. IT — aber nicht in beiden Listen ohne Erklärung.
|
||||
|
||||
---
|
||||
|
||||
### 6. 2026-06-17-strategische-reorganisation.md
|
||||
|
||||
**Fakt 2 — InKa Zuordnung IST**
|
||||
- Verifiziert: **INKA** = Integrierte Kapazitätsmanagementplattform, Teil von **ART CM / Team CMDP**
|
||||
- In Datei (Ist-Zustand Diagramm): InKa wird unter „6. Auswerten" dargestellt neben ART CM (44) — korrekt ✅
|
||||
- In Datei (Kapitel „Identifizierte Synergien"): „**InKa** (C2S, 44 Pers.) = Kapazitätsdaten"
|
||||
- **Inkonsistenz:** InKa wird mit 44 Personen gleichgesetzt. Aber 44 ist die Größe des **gesamten ART CM** (4 Teams). InKa ist nur ein Produkt innerhalb des ART CM/CMDP, nicht das ganze ART.
|
||||
- Handlung: Formulierung korrigieren: „InKa (ART CM, Team CMDP) = Kapazitätsdaten | ART CM gesamt: 44 Personen"
|
||||
|
||||
---
|
||||
|
||||
## Keine Inkonsistenzen gefunden bei
|
||||
|
||||
| Fakt | Beschreibung | Status |
|
||||
|------|-------------|--------|
|
||||
| 1 | Coruscant, Rogue One → ART Abrechnung, NEVER #Einfachbahn | ✅ Korrekt (uebersicht.html hat Kommentar-Anmerkung) |
|
||||
| 4 | pathOS Teams (PI 41) — Backend, Frontend, Ops, ProF, FbF | ✅ Korrekt überall |
|
||||
| 7 | TPN → Stream 2 (Bestellen & Vertrag) | ✅ Korrekt überall |
|
||||
| 8 | TTTneo → übergreifend (Stream 2 + 3) | ✅ Korrekt überall |
|
||||
| 9 | Team Juice → ART Uj Veröffentlichung | ✅ Korrekt (uebersicht.html) |
|
||||
| 10 | Nexus, Ains, Galaxy, PlanBau → ART Uj Konstruktion | ✅ Korrekt (uebersicht.html) |
|
||||
| 11 | IWF 6 → bleibt als eigene Abteilung bestehen | ✅ Korrekt (bereich-reorg + organigramm-zukunft) |
|
||||
| 12 | IWF 7 + IWF 8 → fusioniert → regionale Vertriebsorg. (~100 Pers.) | ✅ Korrekt überall |
|
||||
| 13 | IT-Abt. Leitung: Helena Gruber, Chief Expert: Anatol Scholz | ✅ Korrekt überall |
|
||||
| 14 | Bereichsleitung V.IWF: Dr. Matthias Feil, 658 MA | ✅ Korrekt überall |
|
||||
|
||||
---
|
||||
|
||||
## Empfohlene Korrekturen (priorisiert)
|
||||
|
||||
### Priorität 1 (Faktisch falsch)
|
||||
1. **uebersicht.html** — Team XWing bei ART Abrechnung ergänzen
|
||||
2. **organigramm-zukunft.html (Variante A)** — Solution/Architektur aus Stream 3 in Querschnitt verschieben
|
||||
3. **organigramm-zukunft.html (Variante D)** — Data Team Doppelzuordnung auflösen (Aftersales vs. IT-Querschnitt)
|
||||
|
||||
### Priorität 2 (Mehrdeutig/unvollständig)
|
||||
4. **architektur.html** — strecken.zeit → fachlich Stream 3 klarstellen (nicht „Kommunikation")
|
||||
5. **architektur.html** — INKA als eigenständiges Produkt mit vollem Namen
|
||||
6. **architektur.html** — Data Team Leitung (Markus Germany) ergänzen
|
||||
7. **reorganisation.html** — ART Plattform als SIC-OP-Producer nennen
|
||||
8. **2026-06-17-strategische-reorganisation.md** — InKa ≠ 44 Personen (das ist ART CM gesamt)
|
||||
|
||||
### Priorität 3 (Verbesserung)
|
||||
9. **bereich-reorg.html** — Data Team Doppelauftritt erklären (fachlich Aftersales, org. IT)
|
||||
10. **reorganisation.html** — InKa IST-Zugehörigkeit (ART CM) explizit machen
|
||||
11. **architektur.html** — Abgrenzung FINANCE 4 DB vs. Data Team IWF9 hinzufügen
|
||||
Reference in New Issue
Block a user