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/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/11-Team-und-Workflow-Analyse.md

@@ -0,0 +1,80 @@
+# 11. Team und Workflow Analyse
+
+Version: 35 | Last modified: 2026-06-15T17:19:07.463+02:00
+Source: confluence page ID 581015844
+
+---
+
+Team und Workflow Analyse
+Stand: 2026-06-15 | Basis: Runbook, Confluence, GitLab-Berechtigungen
+
+Team-Struktur (IST - seit PI 39)
+
+Seit PI 39 neue Struktur: Team STeam wurde aufgelöst. Stattdessen gibt es ein OPs-Team mit 2 festen + rotierenden Mitgliedern aus allen Teams. Die STeam-Aufgaben wurden auf die Entwicklungsteams verteilt.
+
+Team | Subdomaene | Kern-Verantwortung | Projekte (ca.) | 
+
+Team Zero | TAF/TAP Schnittstellen | Common Interface, Stammdaten, TAF/TAP-TDM-Konverter, TBV-Konverter + OPs-Anteil | ~12 | 
+
+Team 404 | Bestellportal | Portal UI (Angular), Portal Middleware + OPs-Anteil | ~4 | 
+
+Team CIB | Prozesse + Backend | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector + OPs-Anteil | ~15 | 
+
+Team OPs (NEU) | Infrastruktur / DevOps | CI/CD, Deployment, Monitoring, Security. 2 feste + rotierende Mitglieder | ~47 (verteilt) | 
+
+Team STeam | Infrastruktur | AUFGELOEST seit PI 39 - Aufgaben verteilt auf alle Teams + OPs | 
+
+Team BSSUPPORT | Support | 2nd Level Support | 0 (Jira) | 
+
+Team FbF | Fachliche Betriebsführung | Fachlicher Betrieb, Konfiguration | 0 | 
+
+Umgebungs-Pipeline
+
+Stage | Umgebungen | Zweck | 
+
+DEV | BU, EU, BASE-AT, IEU, SIT, SIT2, LUP, Demo | Entwicklung, Review, Integration, Performance | 
+
+ABN | E2E, SAT1-3, ABN1-2-4-8, PREPROD | TTT-Integration, Kundentests, Abnahme | 
+
+PROD | PROD | Produktionsumgebung (SL Gold) | 
+
+17+ Umgebungen mit jeweils eigenem Kafka-Cluster, DB-Instanz und Keycloak.
+
+Identifizierte Engpaesse
+
+ID | Engpass | Schwere | Details | 
+
+E1 | Deployment-Bottleneck | KRITISCH | 17+ Umgebungen, manuelle Orchestrierung, kein Auto-Smoketest, TTT-Abstimmung nötig | 
+
+E2 | OPs-Team Kapazität | HOCH | Nur 2 feste Mitglieder für 47 Infra-Projekte. Rotierende Besetzung birgt Wissensverlust-Risiko. | 
+
+E3 | Cross-Team Dependencies | HOCH | 10+ interne APIs, kein Contract Testing (ADR-50 obsolet), Schnittstellenänderungen erfordern Koordination | 
+
+E4 | TTT-Abhängigkeit | MITTEL | Releases müssen mit TTT-Releasemanagement abgestimmt werden | 
+
+E5 | Wissenskonzentration | MITTEL | DevOps-Know-How erst seit 02/2025 im Aufbau, Ziel "You build it, you run it" noch nicht erreicht | 
+
+Reorganisations-Empfehlungen
+Kurzfristig (nächste PIs)
+
+DevOps-Wissen verteilen: Jedes Team mindestens 2 Personen mit Deployment-Faehigkeit
+
+Deployment-Automatisierung: Smoketests nach jedem Deployment
+
+Release-Checkliste digitalisieren: Confluence-Checkliste in Pipeline integrieren
+
+Mittelfristig (2-3 PIs)
+
+Infra-Verantwortung aufteilen: Teams übernehmen Infra für eigene Services (STeam wird Enabler)
+
+Contract Testing einführen: Pact oder aehnliches zwischen den Teams
+
+Umgebungen reduzieren: 17+ prüfen, SAT1/SAT2/SAT3 konsolidieren?
+
+Langfristig (6+ Monate)
+
+Team-Schnitt an Subdomaenen: Klare Ownership pro Bounded Context
+
+Platform Team: STeam wird Platform Team mit Self-Service-Tools
+
+TTT-Entkopplung: Eigene E2E-Tests die TTT-Abhängigkeit reduzieren

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/18-Velocity-und-Team-Analyse.md

@@ -0,0 +1,154 @@
+# 18. Velocity und Team-Analyse
+
+Version: 23 | Last modified: 2026-06-15T17:19:11.486+02:00
+Source: confluence page ID 581024118
+
+---
+
+Velocity und Team-Analyse (12 Monate)
+Stand: 2026-06-15 | Zeitraum: April 2025 — April 2026 | 4875 Issues analysiert
+
+Monatlicher Durchsatz (alle Teams)
+
+Monat | 404 | CIB | Zero | OPs | DevOps | Total | Bugs | Bug% | Kontext | 
+
+2025-05 | 108 | 86 | 154 | — | 13 | 361 | 37 | 10% | Entwicklung | 
+
+2025-06 | 77 | 63 | 110 | — | 32 | 282 | 34 | 12% | Entwicklung | 
+
+2025-07 | 137 | 88 | 167 | — | 84 | 476 | 83 | 17% | Pre-Go/No-Go | 
+
+2025-08 | 90 | 41 | 182 | — | 99 | 412 | 65 | 16% | Go/No-Go Vorb. | 
+
+2025-09 | 160 | 82 | 119 | — | 78 | 439 | 71 | 16% | Go/No-Go positiv | 
+
+2025-10 | 158 | 78 | 128 | — | 57 | 421 | 81 | 19% | Pre-Go-Live | 
+
+2025-11 | 178 | 119 | 92 | — | 69 | 458 | 104 | 23% | Pre-Go-Live Peak | 
+
+2025-12 | 97 | 48 | 100 | — | 45 | 290 | 73 | 25% | GO-LIVE | 
+
+2026-01 | 134 | 83 | 98 | 39 | 117 | 471 | 96 | 20% | Hypercare | 
+
+2026-02 | 102 | 54 | 79 | 88 | 38 | 361 | 103 | 29% | Hypercare Peak | 
+
+2026-03 | 172 | 74 | 100 | 127 | 57 | 530 | 117 | 22% | Stabilisierung | 
+
+2026-04* | 108 | 80 | 52 | 51 | 26 | 317 | 64 | 20% | Normalisierung | 
+
+*April noch nicht abgeschlossen
+
+Bug-Rate Entwicklung
+
+Phase | Zeitraum | Bug-Rate | Bewertung | 
+
+Entwicklung | Apr-Jun 2025 | 10-14% | Normal | 
+
+Pre-Go-Live | Jul-Nov 2025 | 16-23% | Steigend (erwartbar) | 
+
+Go-Live | Dez 2025 | 25% | Go-Live Stress | 
+
+Hypercare Peak | Feb 2026 | 29% | Höchster Wert! | 
+
+Normalisierung | Apr 2026 | 20% | Sinkend, aber noch hoch | 
+
+Team-Überblicke
+
+Team 404 (Portal) — 15 Personen, 1537 Issues/12M
+Bug-Rate steigt seit Go-Live (22% → 33%). Portal ist Kundenfacing — Bugs werden direkt von EVUs gemeldet.
+
+Person | Total | Done | Open | Bugs | Bewertung | 
+
+Ana Cvitkovic | 78 | 71 | 7 | 3 | ⭐ Top-Performer: Höchster Output, niedrigste Bug-Rate | 
+
+Jasmin Keskin | 45 | 33 | 12 | 19 | Hohe Bug-Zuweisung (42%) | 
+
+Emmanuel Kontcheu Tagne | 42 | 32 | 10 | 29 | ⚠ 69% Bugs! Primaer Bug-Fixer | 
+
+Diego Da Costa Souza | 41 | 30 | 11 | 6 | Spring Boot 4 Portal — erledigt | 
+
+Leon Hörpel | 35 | 22 | 13 | 25 | 71% Bugs, hoher Backlog | 
+
+Dominik Rücker | 31 | 19 | 12 | 16 | 52% Bugs | 
+
+Annette Halbhuber | 26 | 13 | 13 | 12 | 50% offen, 46% Bugs | 
+
+Simon Reitinger | 15 | 15 | 0 | 11 | 100% Done, primaer Bug-Fixer | 
+
+Marcel Hufgard | 8 | 4 | 4 | 0 | Geringe Sichtbarkeit | 
+
+4 weitere | 4 | 0-5 | — | 0 | Kaum sichtbar (je 0-1 Issues) | 
+
+Team CIB (Backend) — 16 Personen, 905 Issues/12M
+Bug-Rate sinkt dramatisch (36% Jan → 9% April). Backend stabilisiert sich. Positiver Trend.
+
+Person | Total | Done | Open | Bugs | Bewertung | 
+
+Bishara Jaser | 73 | 68 | 5 | 16 | ⭐ Top-Performer: 93% Done, solide Bug-Rate | 
+
+Saurav Kumar | 48 | 45 | 3 | 4 | ⭐ 94% Done, nur 8% Bugs | 
+
+Jonas Köhler | 34 | 34 | 0 | 14 | 100% Done, 41% Bugs | 
+
+Dong-Won Han | 20 | 16 | 4 | 2 | Solide | 
+
+Hans-Henning Ramberger | 16 | 16 | 0 | 0 | 100% Done, 0 Bugs — Enabler/Infra? | 
+
+Vasileios Dimitriadis | 11 | 9 | 2 | 5 | 45% Bugs | 
+
+Christian Meins | 9 | 6 | 3 | 7 | 78% Bugs! | 
+
+Harry Braun | 5 | 0 | 4 | 0 | ⚠ Spring Boot 4 SV — alles offen | 
+
+5 weitere | 1-6 | — | — | — | Geringe Sichtbarkeit | 
+
+Team Zero (TAF/TAP) — 9 Personen, 1409 Issues/12M
+
+Person | Total | Done | Open | Bugs | Bewertung | 
+
+Steven Meixner | 64 | 63 | 1 | 21 | ⭐ 98% Done, auch 27 OPs-Issues — Allrounder | 
+
+Bing Shi | 63 | 52 | 11 | 4 | ⭐ Hoher Output, nur 6% Bugs | 
+
+Frank Lemke | 49 | 43 | 6 | 6 | Solide, auch OPs-Beitraege | 
+
+Kathrin Schleich | 27 | 26 | 1 | 7 | 96% Done | 
+
+Michael Weisberg | 23 | 11 | 12 | 0 | ⚠ 52% offen — Backlog-Problem? | 
+
+Bernd Klebl | 16 | 6 | 10 | 6 | ⚠ 63% offen | 
+
+Norbert Maurer [X] | 12 | 2 | 10 | 0 | ⚠ 83% offen, [X] = extern/ausgeschieden? | 
+
+DevOps — 7 Personen, 719 Issues/12M
+Jan Lubenow: 114 von 289 Issues (39%). Kritische Personenabhängigkeit.
+
+Person | Total | Done | Open | Bugs | Bewertung | 
+
+Jan Lubenow | 114 | 82 | 32 | 13 | ⚠ 39% aller DevOps-Issues! Single Point of Failure | 
+
+David Steinkopff | 18 | 9 | 9 | 2 | 50% offen | 
+
+Henrik Scholl | 10 | 10 | 0 | 0 | 100% Done | 
+
+4 weitere | 6-8 | — | — | — | Geringe Sichtbarkeit | 
+
+Zusammenfassung: Kritische Erkenntnisse
+
+Erkenntnis | Details | Handlungsbedarf | 
+
+Jan Lubenow = DevOps SPOF | 39% aller DevOps-Issues, 32 offen | Wissenstransfer, zweite Person aufbauen | 
+
+Team 404 Bug-Rate steigt | 33% im Maerz, Portal ist Kundenfacing | Qualitätsmaßnahmen, mehr Testing | 
+
+Norbert Maurer [X] — 83% offen | 12 Issues, 10 offen, markiert mit [X] | Klären: Ausgeschieden? Issues umverteilen | 
+
+Michael Weisberg — 52% offen | 23 Issues in Zero, 12 offen | Backlog prüfen, ggf. umpriorisieren | 
+
+Harry Braun — SB4 SV alles offen | 5 Issues, 0 Done, 4 offen | Spring Boot 4 SV-Upgrade blockiert? | 
+
+Ana Cvitkovic = 404 MVP | 78 Issues, 71 Done, nur 3 Bugs | Anerkennung, Wissenstransfer foerdern | 
+
+CIB stabilisiert sich | Bug-Rate 36% → 9% | Positiver Trend, beibehalten | 
+
+Steven Meixner = Zero+OPs Allrounder | 64 Zero + 27 OPs = 91 Issues | Wertvoll, aber Überlastungsrisiko |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/25-Team-Reorganisation-Optionen.md

@@ -0,0 +1,172 @@
+# 25. Team-Reorganisation (Optionen)
+
+Version: 3 | Last modified: 2026-05-07T14:47:08.689+02:00
+Source: confluence page ID 586386850
+
+---
+
+Team-Reorganisation pathOS — Optionen und Bewertung
+Stand: 2026-04-30 | Status: Entwurf zur Diskussion
+
+Dieses Dokument analysiert Optionen fuer die Neuaufstellung der pathOS-Teams. Ziele: Schnellere Umsetzung, weniger Komplexitaet, bessere Qualitaet und Verantwortlichkeit.
+
+Ausgangslage
+
+Team | Personen | Verantwortung | Services | Problem | 
+
+Team 404 | ~10 | Portal UI + Middleware | 2 (68K LoC) | 33% Bug-Rate, steigend | 
+
+Team CIB | ~13 | Prozesse, Backend, Camunda | ~15 (122K LoC) | SV-Monolith (93K, 2214 Smells) | 
+
+Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 (38K LoC) | OPs-Rotation belastet | 
+
+OPs Squad | 2 fest + rot. | Infrastruktur, Betrieb | Infra-Repos | Nur 2 feste Mitglieder | 
+
+DevOps | ~7 | CI/CD, Tooling | Pipelines | Jan Lubenow = 39% SPOF | 
+
+Ziele
+
+Primaer | Nachrangig | 
+
+Schnelle Umsetzungsgeschwindigkeit | Staerkenorientierter Einsatz | 
+
+Weniger Komplexitaet | Wissen breiter verteilen | 
+
+Weniger Abhaengigkeiten | Flexibilitaet bei Prioritaetswechsel | 
+
+Bessere Qualitaet | | 
+
+Bessere Verantwortlichkeit | | 
+
+Option A: OpsDev + Feature-Pool
+Modell
+OpsDev Team (permanent, ~8-10): Betrieb, Bugs, kleine Features. Lead OpsDev ohne PO.
+
+Feature-Pool (~20-25): Entwickler + BAs + Feature-POs. Bilden temporaere Feature-Teams (3-5 Pers.) fuer grosse Features. Nach Abschluss: 1 Dev → OpsDev (Hypercare).
+
+Vorteile | Nachteile | 
+
+Feature-Team ownt end-to-end | Kontextwechsel, Onboarding-Aufwand | 
+
+Keine Cross-Team-Deps fuer Features | Kein stabiles Team, Teambildung leidet | 
+
+Flexibel nach Prioritaet | OpsDev wird Muellhalde fuer Bugs | 
+
+Wissenstransfer durch Hypercare | PO-Overhead (3-4 POs parallel) | 
+
+Option B: Fachlicher Schnitt (4 Varianten)
+
+B1: Bestellen vs. Abwickeln
+
+Team "Bestellen" | Team "Abwickeln" | 
+
+Portal UI + MW, Common Interface, Stammdaten, Kundendaten, TAF/TAP-Konverter | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector, Vertragsdaten, Archivierung, Abrechnung | 
+
+Fokus: Was der Kunde sieht | Fokus: Was nach der Bestellung passiert | 
+
+✔ Klarer Kundenfokus | ✘ NAÄ betrifft beide, SV ist Monolith
+
+B4: Trasse vs. Vertrag (bester fachlicher Schnitt)
+
+Team "Trasse" | Team "Vertrag" | 
+
+Trassenanmeldung (Portal+CI), Trassenkonstruktion (IFP), Stammdaten, TAF/TAP | Angebot + Vertrag (SV), Abrechnung, Stornierung, Rahmenvertraege, Vertragsdaten | 
+
+Vom Kundenwunsch bis Konstruktionsauftrag | Vom Angebot bis zur Rechnung | 
+
+✔ Sauberster Schnitt entlang Geschaeftsprozess, Abrechnung hat eigenes Team | ✘ SV muesste aufgeteilt werden, Portal zeigt beides
+
+Option C: Hybrid — EMPFOHLEN
+
+Empfohlenes Modell: OpsDev (permanent) + 2 fachliche Teams (permanent) + temporaere Feature-Squads fuer grosse Themen.
+
+OpsDev (~6 Pers.) | Team "Bestellen" (~12) | Team "Verarbeiten" (~12) | 
+
+Betrieb, Deployment
+Monitoring, Infrastruktur
+Bug-Triage
+Lead: OpsDev-Lead | Portal UI + MW
+Common Interface
+Stammdaten, Kundendaten
+TAF/TAP Konverter
+Click&Ride
+PO + BA + Devs | Steuerung Vertrieb
+Auftrags-Verwaltung
+IFP-Connector
+Archivierung
+Vertragsdaten, Abrechnung
+PO + BA + Devs | 
+
+Bugs: Infrastruktur | Bugs: Portal, CI, STB | Bugs: SV, AV, IFP | 
+
+Fuer grosse Features (GelV, ujBau, NAÄ): Temporaer 2-3 Personen aus beiden Teams zusammenziehen. Nach Abschluss: zurueck + 1 Person Hypercare in OpsDev.
+
+Gesamtbewertung
+
+Option | Speed | Komplexitaet | Deps | Qualitaet | Ownership | 
+
+A: OpsDev + Pool | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 
+
+B1: Bestellen/Abwickeln | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | 
+
+B4: Trasse/Vertrag | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 
+
+C: Hybrid (empfohlen) | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 
+
+D: Spotify | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 
+
+Noch zu klaeren
+
+SV aufteilen? — Ist der Monolith (93K LoC) technisch teilbar?
+
+NAÄ als Querschnitt — Dediziertes Feature-Team oder feste Zuordnung?
+
+Portal-Ownership — Portal zeigt Daten aus allen Services. Eigener Querschnitt?
+
+Abrechnung — Eigenes Team wert? Oder bei "Verarbeiten"?
+
+Personelle Passung — Staerken-Mapping der 35 Personen
+
+Uebergangsphase — Dauer, Produktivitaetsverlust?
+
+PO-Struktur — 1 PO pro Team oder uebergreifend + Feature-POs?
+
+Metriken — Bug-Rate, Durchlaufzeit, Deployment-Frequenz als Erfolgsmessung
+
+Fehlende Daten fuer Entscheidung
+
+Git-Contributions pro Person/Service (wer kennt welchen Code?)
+
+Abhaengigkeits-Graph zwischen Services (Kafka-Topics, REST-Calls)
+
+Kundenfeedback: Welche Features werden am meisten nachgefragt?
+
+Camunda-Prozess-Instanzen: Wie oft laeuft welcher Prozess?
+
+Faktor TrassenOrder (Team TraPo) — NEU
+
+TrassenOrder ist ein neues Produkt innerhalb SAB (gleiche Einheit wie pathOS), das den Bestellprozess fuer Gelegenheitsverkehr modernisiert. Entwicklungsstart Jan 2026, Livegang vsl. Q4 2026.
+
+Aspekt | TrassenOrder | pathOS (Click&Ride) | 
+
+Fokus | GelV medienbruchfrei, attraktiver Workflow | GelV kurzfristig (<5 Arbeitstage), Gueterverkehr | 
+
+Phase | EXPLORE (seit Jan 2026) | Produktiv (seit Dez 2025) | 
+
+Livegang | Q4 2026 | Bereits live | 
+
+Team | TraPo (eigenes Team in SAB) | CIB (ADR-72) | 
+
+Jira | TRAPO (systelone) | O2CCIB / O2C404 | 
+
+Implikationen fuer Reorganisation
+
+Abgrenzung klaeren: Was macht TrassenOrder, was macht pathOS/Click&Ride?
+
+Integration: Frontend fuer pathOS-Backend? Oder separates System?
+
+GelV-Ownership: Gehoert GelV kuenftig zu TraPo oder pathOS?
+
+Vereinfachung: Wenn TraPo GelV uebernimmt, kann pathOS sich auf Netzfahrplan + ujBau konzentrieren — vereinfacht den fachlichen Schnitt erheblich
+
+Empfehlung: Vor Reorg-Entscheidung unbedingt mit TraPo-Team abstimmen (Roadmap-Abgleich, Schnittstellen, langfristige Vision).

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/26-Teams-inkl-TrassenOrder.md

@@ -0,0 +1,114 @@
+# 26. Teams inkl. TrassenOrder
+
+Version: 1 | Last modified: 2026-05-07T16:51:18.183+02:00
+Source: confluence page ID 586388763
+
+---
+
+Team-Landschaft pathOS + TrassenOrder
+Stand: 2026-04-30 | Kontext: Reorganisations-Planung
+
+TrassenOrder (TraPo) ist ein Testballon, um zu pruefen ob eine andere Herangehensweise (entkoppelt, UX-first, klein) schneller, besser und sicherer funktioniert als der pathOS-Ansatz (Microservice-Monolith, 167 Repos, 35+ Personen).
+
+Aktuelle Team-Landschaft
+
+Team | Personen | Fokus | Services | Deployment | Besonderheit | 
+
+Team 404 | ~10 | Portal UI + Middleware | 2 (68K LoC) | pathOS Release-Zug | 33% Bug-Rate, kundenseitig | 
+
+Team CIB | ~13 | Prozesse, Camunda, Backend | ~15 (122K LoC) | pathOS Release-Zug | SV-Monolith, Abrechnung | 
+
+Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 (38K LoC) | pathOS Release-Zug | Beste Qualitaet, OPs-Rotation | 
+
+OPs Squad | 2 fest + rot. | Betrieb, Infrastruktur | Infra-Repos | pathOS Release-Zug | Seit PI 39 (ex-STeam) | 
+
+DevOps | ~7 | CI/CD, Tooling, Pipelines | Pipelines, Helm | pathOS Release-Zug | Jan Lubenow = 39% SPOF | 
+
+TrassenOrder (TraPo) | ~5 (klein) | GelV-Portal (UX-first) | 1 (neu) | Unabhaengig! | Testballon, Discovery-Phase | 
+
+TrassenOrder vs. pathOS — Vergleich der Ansaetze
+
+Dimension | pathOS (aktuell) | TrassenOrder (Testballon) | 
+
+Architektur | Microservice-Monolith (synchrone Releases, 167 Repos) | Externes System, eigene Schnittstellen, unabhaengig deploybar | 
+
+Teamgroesse | ~35+ Personen, 5 Teams | ~5 Personen, 1 Team | 
+
+Zielgruppe | Alle EVUs (Experten + Anfaenger) | Kleine EVUs, Ein-Mann-Betriebe ("WhatsApp-Nutzer") | 
+
+UX-Ansatz | 240+ Formularfelder, Experten-Tool | 3 Angaben fuer eine Bestellung, radikal vereinfacht | 
+
+Deployment | Release-Zug (alle Services zusammen) | Unabhaengig, eigener Rhythmus | 
+
+Abhaengigkeiten | Hoch (Kafka, Camunda, 15+ Services) | Minimal (nur API-Schnittstellen zu Primaerquellen) | 
+
+Geschwindigkeit | PI-getaktet (10 Wochen) | Kontinuierlich, Feature-basiert | 
+
+Scope | Netzfahrplan + GelV + ujBau + Abrechnung | Nur GelV (Gelegenheitsverkehr) | 
+
+Phase | Produktiv seit Dez 2025 | Discovery seit Jan 2026, Livegang Q4 2026 | 
+
+Was testet der Testballon?
+Hypothesen
+
+Schneller: Kann ein kleines, entkoppeltes Team schneller liefern als ein grosses im Release-Zug?
+
+Besser: Fuehrt UX-first + radikale Vereinfachung zu besserer Nutzerzufriedenheit?
+
+Sicherer: Reduziert Entkopplung das Risiko (kein Dominoeffekt bei Fehlern)?
+
+Wenn der Testballon erfolgreich ist: Das Modell koennte auf weitere Bereiche uebertragen werden (Netzfahrplan, ujBau). Langfristig koennte TrassenOrder das pathOS-Portal abloesen.
+
+Schnittstellen zwischen pathOS und TrassenOrder
+
+Schnittstelle | Richtung | Zweck | 
+
+Trassenanmeldung API | TraPo → pathOS | Bestellung absetzen | 
+
+Stammdaten API | TraPo ← Primaerquelle | Direkt, NICHT ueber pathOS | 
+
+Angebots-Rueckmeldung | pathOS → TraPo | Ergebnis der Konstruktion | 
+
+Trassenfinder | TraPo ← BVU | Routing, Validierung (Fernziel) | 
+
+Architekturentscheidung: TrassenOrder greift auf Primaerquellen direkt zu — nicht ueber eine pathOS-Zwischenschicht. Das vermeidet Abhaengigkeiten vom pathOS Release-Zug.
+
+Implikationen fuer Team-Reorganisation
+
+Szenario | Auswirkung auf pathOS-Teams | 
+
+TraPo erfolgreich → GelV wandert zu TraPo | pathOS kann sich auf Netzfahrplan + ujBau + Abrechnung konzentrieren. Vereinfacht den fachlichen Schnitt erheblich. Click&Ride (ADR-72) wird obsolet. | 
+
+TraPo erfolgreich → Modell wird uebertragen | Weitere kleine Teams fuer spezifische Domaenen. pathOS wird zum API-Backend-Layer. Portal-Team (404) wird langfristig obsolet. | 
+
+TraPo scheitert → GelV bleibt bei pathOS | Keine Aenderung. Click&Ride Anbindung (ADR-72) wird weiter von CIB gebaut. | 
+
+Offene Fragen
+
+Wann ist der Testballon "erfolgreich"? Welche Metriken? (Time-to-Market, Nutzerzufriedenheit, Bug-Rate?)
+
+Wie wird die Schnittstelle zwischen TraPo und pathOS-Backend definiert und versioniert?
+
+Wer pflegt die Schnittstelle langfristig? (API-Vertrag)
+
+Kann das TraPo-Modell auf Netzfahrplan skaliert werden? (Komplexitaet ist dort 10x hoeher)
+
+Was passiert mit Team 404 wenn TrassenOrder das Portal langfristig abloest?
+
+Team-Kennzahlen (Vergleich)
+
+Metrik | pathOS gesamt | TrassenOrder | Faktor | 
+
+Personen | ~35 | ~5 | 7x | 
+
+Services | ~40 aktiv | 1 | 40x | 
+
+Lines of Code | ~260K | ~0 (Discovery) | — | 
+
+Jira-Projekte | 6 (O2C*, TTTI) | 1 (TRAPO) | 6x | 
+
+Release-Frequenz | ~2x/Monat (KTU) | Kontinuierlich (Ziel) | — | 
+
+Bug-Rate | 20-33% | 0% (noch kein Code) | — | 
+
+Deployment-Abhaengigkeiten | Hoch (17+ Umgebungen) | Keine | — |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/30-Team-Reorganisation-Update-PI-41.md

@@ -0,0 +1,149 @@
+# 30. Team-Reorganisation Update PI 41
+
+Version: 1 | Last modified: 2026-06-15T17:18:56.876+02:00
+Source: confluence page ID 603275583
+
+---
+
+Team-Reorganisation pathOS — Update PI 41
+Stand: 2026-06-15 | Status: Umgesetzt (PIP letzte Woche)
+
+Vorherige Analyse: team-reorganisation.md (Optionen A-D)
+
+Die Reorg ist umgesetzt. CIB+Zero fusioniert zu Backend, 404→Frontend, neues ProF-Team (Produkt & Fachlichkeit), OPs verstärkt durch SubP-Personen zu OPs/DevOps.
+
+Neue Teamstruktur (ab PI 41)
+
+Team | Zusammensetzung | Fokus | Jira-Boards | 
+
+Backend | CIB + Zero fusioniert, ~20+ Pers. | Services, Prozesse, Schnittstellen, Pilot Feature-Teams | O2CCIB + O2CZERO | 
+
+Frontend | ehem. 404, ~10 Pers. | Portal UI + Middleware | O2C404 | 
+
+ProF (NEU) | BA/BE-Menschen | Fachlichkeit abbilden, übergreifend | ? | 
+
+OPs/DevOps | inkl. ex-SubP, ~10+ Pers. | Betrieb, Deployment, Monitoring, CI/CD | O2COS + O2CDEVOPS | 
+
+Vergleich: Alt → Neu
+
+Vorher (PI 39-40) | Nachher (PI 41) | Änderung | 
+
+Team 404 (Portal) | Frontend | Umbenennung, Fokus bleibt | 
+
+Team CIB (Backend) | Backend (fusioniert) | Fusion mit Zero | 
+
+Team Zero (Schnittstellen) | Backend (fusioniert) | Aufgegangen in Backend | 
+
+OPs Squad (2 feste + Rotation) | OPs/DevOps (inkl. SubP) | Verstärkt durch SubP-Menschen | 
+
+DevOps (~7) | OPs/DevOps (konsolidiert) | Teil des verstärkten OPs | 
+
+— | ProF (NEU) | BA/BE für Fachlichkeit | 
+
+Feature-Team Pilot (Backend)
+Das Backend-Team testet als Pilot die Feature-Team-Arbeitsweise:
+
+Statt permanenter Zuständigkeit pro Service werden temporäre Feature-Teams gebildet
+
+Ein Feature-Team arbeitet end-to-end an einem Thema
+
+Nach Abschluss: Wissen teilen, nächstes Feature-Team bilden
+
+Aktuelle Feature-Team-Kandidaten:
+
+NAÄ (Netzausgelöste Änderungen)
+
+Abrechnung
+
+Benachrichtigungen (E-Mail)
+
+Dies entspricht Elementen aus Option A (Feature-Pool) kombiniert mit der Stabilität eines permanenten Backend-Teams.
+
+PI 41 Objectives
+
+Objective | Verantwortlich | Inhalt | 
+
+O2CBS-1306 | OPs/DevOps | Betrieb + Support stabil | 
+
+O2CBS-1307 | Backend | Verkehre ermöglicht + Abrechnung zuverlässig | 
+
+O2CBS-1308 | Alle (Qualität) | Höhere Qualität, weniger Aufwand | 
+
+O2CBS-1309 | Übergreifend | KI-Enablement | 
+
+Backend PI-Plan (O2CBS-1307)
+PI-Ziele:
+
+pathOS kann Kundenrückmeldungen aus VNP und ENP erfassen und verarbeiten
+
+pathOS kann kundenausgelöste Vertragsänderungen zu neuen Vertragsständen führen
+
+Aktive Arbeitspakete
+
+Thema | Tickets | Status | 
+
+NAÄ (Netzausgelöste Änderungen) | O2CCIB-5050 bis -5063 | In Formulierung/Arbeit | 
+
+VNP/ENP Race Condition Fix | O2CCIB-8169, -8206 | Gefixt + Test | 
+
+E-Mail-Benachrichtigungen (NEU!) | O2CCIB-8208 bis -8215 (7 Tickets) | Zu erledigen | 
+
+Abrechnung Anmeldungs-/Vertragsinformationen | O2CBS-1304 | Funnel | 
+
+Stornierungen >20h nach Abfahrt | O2CBS-1255 | Funnel | 
+
+VNP_REVISION Status | O2CBS-1186 | Implementation | 
+
+Zurückgezogene Angebote | O2CBS-783 | Implementation | 
+
+Verkehrstageweise Stornierung | O2CBS-254 | Funnel | 
+
+Identifier-Handling | O2CCIB-4537 | Highest, Zu erledigen | 
+
+AV Mapping-Fehler | O2CZERO-6803 | Highest, Zu erledigen | 
+
+LuP Neo (Neukonzeption) | O2CZERO-6186 | In Formulierung | 
+
+Bewertung gegenüber unserer Analyse
+
+Was sich bestätigt hat
+
+Aspekt | Status | 
+
+OPs-Rotation beendet (feste Zuordnung durch SubP-Integration) | ✅ Bestätigt | 
+
+DevOps + OPs konsolidiert | ✅ Bestätigt | 
+
+Feature-Team-Ansatz als Pilot (unser Vorschlag aus Option A) | ✅ Bestätigt | 
+
+Fachlicher vs. technischer Schnitt (ProF = fachliche Brücke) | ✅ Bestätigt | 
+
+Was anders gelaufen ist als empfohlen (Option C)
+
+Aspekt | Bewertung | 
+
+Kein „Bestellen/Verarbeiten“-Schnitt → stattdessen technischer Schnitt (Frontend/Backend) | ❌ Anders | 
+
+Kein OpsDev mit Bug-Triage-Funktion → OPs bleibt Infra-fokussiert | ❌ Anders | 
+
+ProF-Team als eigene Einheit für Fachlichkeit (war nicht in unseren Optionen) | ➕ Zusätzlich | 
+
+CIB+Zero Fusion (wir hatten separate Teams vorgeschlagen) | ➕ Zusätzlich | 
+
+Implikationen
+
+Aspekt | Bewertung | 
+
+SPOF Jan Lubenow | Sollte durch SubP-Verstärkung entschärft sein | 
+
+SPOF Steven Meixner | War Zero + OPs — jetzt nur noch Backend. Besser. | 
+
+Bug-Rate 404/Frontend | Team bleibt gleich, Problem bleibt bestehen | 
+
+NAÄ als Querschnitt | Jetzt komplett im Backend (CIB+Zero) — besser! | 
+
+Abrechnung | Komplett im Backend — Ownership klar | 
+
+Portal zeigt Backend-Daten | Weiterhin Abhängigkeit Frontend→Backend | 
+
+Erstellt im Rahmen des pathOS Portfolio-Audits. Stand: 2026-06-15.

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Ansprechpartner-Teams.md

@@ -0,0 +1,24 @@
+# Ansprechpartner & Teams
+
+Version: 4 | Last modified: 2023-11-10T18:33:37.788+01:00
+Source: confluence page ID 284535064
+
+---
+
+Person | Geschäftsbereich | Funktion | Team | 
+Carolin Grüßner | DB Netz | Betrieb & Benutzermanagement MyNet | I.NBV4 | 
+Jörg Kuhnke | DB Netz | Anwendungsverantwortlich La-Portal (bis 31.10.2023) | I.NBF42 | 
+Björn Tober | DB Netz | Anwendungsverantwortlich La-Portal (ab 01.11.2023) | I.NA-MI-N-FFM-B | 
+Holger Kehm
+ | DB Netz | Serverbetrieb (MyNet) + Beschaffung bei DB Netz | I.NVI 71 | 
+Marcel Apricio-Garcia | DB Systel | Inhaltliche Betreuung, Wartung und Weiterentwicklung La-Portal | Team colab365 | 
+Achim Oswald | DB Systel | PO im Team colab365 | Team colab365 | 
+Sebastian Hesse | DB Systel | Betriebsteam La-Portal
+ | Team MACS
+ | 
+Stephan Gogoll | DB Systel | Ehemaliger Projektleiter La-Portal, PO Team CoPAS
+ | Team CoPAS
+ | 
+Volker Grabowski | DB Netz | Enterprise Architekt im Bereich I.NVI 41
+ | I.NVI 41
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Das-Einfachbahn-Team-bietet-sich-gegenseitig-UnterstÃ-tzung-an.md

@@ -0,0 +1,143 @@
+# Das #Einfachbahn Team bietet sich gegenseitig Unterstützung an
+
+Version: 12 | Last modified: 2023-11-20T10:28:56.496+01:00
+Source: confluence page ID 290167936
+
+---
+
+Du brauchst schnelle Hilfe? 
+
+Du hattest gerade ein richtiges sch... Erlebnis/Gespräch/Termin?
+Du stehst vor einer Herausforderung, bei der du Unterstützung brauchst?
+Du bist alleine in deinem Homeoffice oder brauchst im Büro einen Ansprechpartner?
+Dann findest du hier schnelle und unkonventionelle Unterstützung, die dir die Kolleg:innen von Herzen gern anbieten.
+
+Spielregeln: 
+Beachte bei der Kontaktaufnahme bitte folgende Regeln und sei dir bewusst, dass du damit eine Abkürzung nimmst und das ganze Team Zeit spart. 
+Der/die Gesprächspartner:in ist grün - Frage kurz per Chat an ob der/die diejenige Zeit hat
+Sage zu Beginn des Gesprächs ob du 5 oder 15 min Zeit brauchst – falls ihr am Ende des Gesprächs feststellt, dass ihr doch mehr Zeit braucht, vereinbart eine Woche später einen weiteren Termin. 
+nutze den #Einfachbahn-Chat/oder schreibe eine:n der Anbietenden direkt an und beginne deine Nachricht mit den definierten Begriffen, damit sich die richtigen Menschen angesprochen fühlen
+Hemmungen ablegen, trau dich!
+Wir schauen beim übernächsten Teamtag, ob es genutzt wurde
+die Anbietenden dürfen sagen: "Nein, ich habe jetzt keine Zeit"
+
+Wer bietet was? 
+
+ | André 
+ | Claudia
+ | Eva
+ | Hai
+ | Jacqueline
+ | Lena
+ | Marven
+ | Moritz
+ | SAm
+ | Sarah
+ | Sebastian R.
+ | Simone
+ | Thea
+ | Willy
+ | 
+gute Laune | X | X | X | 
+ | 
+ | X | 
+ | 
+ | 
+ | 
+ | 
+ | X | 
+ | 
+ | 
+Ruhe im Sturm | X | X | 
+ | 
+ | 
+ | 
+ | 
+ | X | 
+ | 
+ | X | 
+ | X | 
+ | 
+Sicherheit (Bestärkung) | X | X | 
+ | 
+ | 
+ | 
+ | X | 
+ | 
+ | 
+ | X | X | X | 
+ | 
+Persönliches Aufbauen  | X | X | X | 
+ | 
+ | X | X | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+Zuhören | 
+ | X | 
+ | 
+ | X | X | X | 
+ | 
+ | X | 
+ | 
+ | 
+ | X | 
+Motivation (in den Hintern treten) | X | X | X | 
+ | X | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+Begeisterung  | X | 
+ | X | 
+ | X | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | X | 
+ | 
+ | 
+Spiegelung (coachen) 
+ | 
+ | X | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | X | X | X | X | X | 
+Blick auf Ganze  | X | 
+ | 
+ | 
+ | 
+ | 
+ | X | X | 
+ | 
+ | 
+ | X | 
+ | 
+ | 
+Strukturierung  | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | X | 
+ | X | X |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Deine-Praxisphase-im-Team-Kleine-LÃ-sungen.md

@@ -0,0 +1,36 @@
+# Deine Praxisphase im Team Kleine Lösungen
+
+Version: 2 | Last modified: 2025-03-05T12:39:21.734+01:00
+Source: confluence page ID 345055448
+
+---
+
+Kleine Lösungen: Mögliche Arbeitspaketvorschläge für Julian
+
+Hallo lieber Julian,
+im Bereich "Kleine Lösungen" beschäftigen wir uns hauptsächlich mit dem DB NetzCockpit (NeCo).
+Bei uns ist der Aufbau derzeit wie folgt:
+Niklas und Willy: PO Kleine Lösungen
+Marven: Betriebsführer NeCo & zuständig für BAPSI-Themen
+Mögliche ArbeitspaketeTeilprojekt | Arbeitspaketvorschlag | Einschätzung | Beschreibung | Ansprechpartner:innen | Dringlichkeit | Zeitbudget | 
+NeCo | Neues Konzept zur Zusammenarbeit entwickeln | Für besseres Verständnis von agilem Arbeiten sehr interessant, beinhaltet auch die Kommunikation mit dem Entwicklungsteam => Verschiedene Bedürfnisse zusammenbringen | Aktuell arbeiten wir bei Kleine Lösungen mit wenigen Artefakten aus den agilen Methoden (bspw. keine wirklichen Sprints, kein echtes Pull-Prinzip, keine Retros, Dailies, Refinement, etc.)
+Wir haben lediglich 2 Termine pro Woche (1 mit Schwerpunkt Review der letzten Woche und Planning dieser Woche, 1 mit Schwerpunkt Arbeit am Backlog) und arbeiten mit einem Kanban-Board.
+Aufgabe: Neues Konzept entwickeln, wie wir Zusammenarbeit besser und effizienter gestalten können und dabei auch mehr auf die Bedürfnisse der Einzelnen eingehen können.
+Beispiel Scrum:
+
+ | Willy, Niklas | bis Ende Praxisphase | 2 Wochen | 
+NeCo | Test eines Tools | Tool verstehen und dabei konkret lernen, wie Test eines Tools funktioniert und wie mit evtl. Fehlern im Test umzugehen ist | Wir entwickeln konsequent unsere Tools im NeCo weiter. Dabei muss natürlich auch jede Änderung von uns getestet werden. Hier fallen immer wieder Aufgaben an, die relativ unabhängig übernommen werden können. Die Tickets zum Testen sind im Jira Kanban-Board vorhanden und können jederzeit übernommen werden - sowohl bestehende als auch neue.
+Beispiel-Tools könnten Formula, IKAs und NeCo Plattform sein.
+ | Willy, Niklas | Jederzeit | 2 Wochen | 
+NeCo / Support | Jira Dashboards erstellen | Eigenständiges Erarbeiten von Wissen über Jira, großer Nutzen für Team | Unser Jira hat sowohl im Support als auch im Team Kleine Lösungen derzeit nur wenige und nur schnell erstellte Auswertungen. Um unsere Arbeit immer weiter optimieren zu können, brauchen wir bessere und mehr Auswertungen, die uns die Schwerpunkte und Optimierungsmöglichkeiten besser aufzeigen.
+Dafür braucht es eine Person, die sich Zeit nimmt und wirklich einmal mit den Jira Berichten (was ist möglich, was ist sinnvoll) beschäftigt.
+Hier sind die bisherigen Berichte für den Support zu finden: https://arija.jaas.service.deutschebahn.com/projects/IIBV31/reports/workload
+ | Willy | Jederzeit | 3 - 4 PT | 
+NeCo | Betriebsführung optimieren | Verständnis für Betriebsführung erlangen und dabei gleichzeitig diese deutlich zu vereinfachen für das Team | Unsere Betriebsführung im NeCo ist aktuell noch stark ausbaufähig. Wir kriegen nachts eine Monitoring Mail, die sehr technisch aufgebaut ist und bei jeder neuen Meldung zu Rückfragen beim Entwicklungsteam führt. Es wäre gut, wenn wir sofort erkennen würden, was für uns relevant ist und wo wir ein To-Do haben. Dafür sollte die heutige Betriebsführung kritisch analysiert werden und Maßnahmen definiert werden.
+ | Niklas, Willy | Jederzeit | 2 Wochen | 
+Support
+ | Jira API | Eigenständige Einarbeitung in eine für uns alle neue API mit großem Nutzen für Support und damit dem ganzen Team | API anschauen zur Nutzung in NiCo und NuR und Salesforce:
+Wir wollen unser Support Jira nicht nur für Anfragen aus dem Postfach und Hotline nutzen, sondern auch für die über das Salesforce Ticketsystem eingehenden Anfragen sowie Registrierungen in NuR und NiCo.
+Dafür müssen wir die von Jira bereitgestellte API kennenlernen und Nutzungsmöglichkeiten evaluieren.
+Ziel: Automatisierte Ticketerstellung durch externe Systeme (NiCo, NuR, Salesforce)
+ | Willy | bis September | 5 - 7 PT |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Einfachbahn-Startseite.md

@@ -0,0 +1,15 @@
+# #Einfachbahn
+
+Version: 63 | Last modified: 2023-12-14T15:08:55.475+01:00
+Source: confluence page ID 256707496
+
+---
+
+#FFCC03Ich suche nur schnell was:
+
+attachment102845392621000coverflex-startcenter left
+
+1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#ffcc03"},"link":{"type":"link","value":"https://einfachbahn.dbnetze.com/einfachbahn-de#","target":"_blank"}},"headline":{"text":{"text":"wir bieten","color":"#344563","textAlign":"left","fontWeight":"bold","fontSize":18},"alignment":{"horizontal":"start"}},"base":{"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.2)","x":0,"y":0,"blur":6,"spread":0},{"color":"rgba(0, 0, 0, 0.4)","x":0,"y":20,"blur":10,"spread":-15}]},"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":2,"bottom":true,"top":false,"left":false,"right":false},"borderRadius":{"radius":20},"size":{"width":700}}}<p><ac:image ac:height="400"><ri:attachment ri:filename="ebbk.png" /></ac:image></p>
+
+Unsere aktuellen Themen
+icon-center20elevate0[{"title":"große Lösungen","body":"","color":"#ffcd00","icon":"faFortAwesome","image":"","imageType":"","href":"284533853","hrefType":"page","hrefTarget":"_blank"},{"title":"kleine Lösungen","body":"Mit den \"kleinen Lösungen\" unterstützen wir Mitarbeitende und Kunden durch die Digitalisierung schnell umsetzbarer Fragestellungen.","color":"#ffcd00","icon":"faHouseUser","image":"","imageType":"","href":"270410898","hrefType":"page","hrefTarget":"_blank"},{"title":"Fahren","body":"","color":"#ffcd00","icon":"faTrain","image":"","imageType":"","href":"265529001","hrefType":"page","hrefTarget":"_blank"},{"title":"Kundenportal","body":"Im Rahmen des DPV wird ein zentrales Kundenportal umgesetzt, an dem Kunden mit einem einmaligem SingleSignOn Zugang zu allen IT-Anwendungen der DB Netz AG erhalten.","color":"#ffcd00","icon":"faArchway","image":"","imageType":"","href":"284528836","hrefType":"page"},{"title":"Planen","body":"","color":"#ffcd00","icon":"faRoute","image":"","imageType":"","href":"265531027","hrefType":"page","hrefTarget":"_blank"},{"title":"Verbindungsteam","body":"\n","color":"#ffcd00","icon":"faPeopleCarry","image":"https://images.unsplash.com/photo-1520242279429-1f64b18816ef?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1650&q=80","imageType":"link","href":"290169594","hrefType":"page"}]5topaura-accenticon25100%

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/How-to-E-Mails-an-das-SalesForce-Team-weiterleiten.md

@@ -0,0 +1,11 @@
+# How to: E-Mails an das SalesForce-Team weiterleiten
+
+Version: 2 | Last modified: 2024-04-22T15:00:46.566+02:00
+Source: confluence page ID 329715405
+
+---
+
+Supportfall
+Intern wird gefragt, warum Unternehmensdaten falsch sind oder unlogisch.
+Lösung
+Intern verweisen an SalesForce-Team: salesforce.dbinfrago@deutschebahn.com

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Organisatorisches.md

@@ -0,0 +1,9 @@
+# Organisatorisches
+
+Version: 3 | Last modified: 2024-06-28T16:15:50.482+02:00
+Source: confluence page ID 276892894
+
+---
+
+Allgemein:
+Beim Teilen in Teams Fenster wegbekommen: Auf "Bildschirm teilen" Banner oben klicken und dann auf STRG + W klicken.

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Reports-Coruscant-2026.md

@@ -0,0 +1,25 @@
+# Reports Coruscant 2026
+
+Version: 5 | Last modified: 2026-05-26T22:10:54.167+02:00
+Source: confluence page ID 537655943
+
+---
+
+Nach Fixversion Lieferung → Was ist Live gegangen: Sprint | Datum | Ersteller | PDF | Link | 
+2026-02
+ |  
+ | Andreas Wenske
+ | 250
+ | Coruscant Dashboard nach Fixversion Lieferung 2026-02 | 
+2026-04
+ |  
+ | Andreas Wenske
+ | 250
+ | Coruscant Dashboard nach Fixversion Lieferung 2026-04
+ | 
+2026-06
+ |  
+ | Andreas Wenske
+ | 250
+ | Coruscant Dashboard nach Fixversion Lieferung 2026-06
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Reports-Rogue-One-2026.md

@@ -0,0 +1,23 @@
+# Reports Rogue One 2026
+
+Version: 5 | Last modified: 2026-05-26T22:17:19.075+02:00
+Source: confluence page ID 537655996
+
+---
+
+Nach Fixversion Lieferung → Was ist Live gegangen: Sprint | Datum | Ersteller | PDF | Link | 
+2026-02
+ |  
+ | Andreas Wenske
+ | 250
+ | Rogue One Dashboard nach Fixversion Lieferung 2026-02 | 
+2026-04
+ |  
+ | Andreas Wenske
+ | 250
+ | Rogue One Dashboard nach Fixversion Lieferung 2026-04 | 
+2026-06
+ |  
+ | Andreas Wenske
+ | 250
+ | Rogue One Dashboard nach Fixversion Lieferung 2026-06 |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Retro-MaÃ-nahmen-Rogue-One-vom-21-01-2026.md

@@ -0,0 +1,72 @@
+# Retro-Maßnahmen Rogue One vom 21.01.2026
+
+Version: 4 | Last modified: 2026-02-18T10:21:18.332+01:00
+Source: confluence page ID 537654728
+
+---
+
+Wer macht es?
+ | Was machen?
+ | Warum machen wir es?
+ | Bis wann wird es gemacht?
+ | erledigt
+ | 
+ 
+ | Daily auf 9:15 Uhr legen
+ | Damit wir ggf die Dailies der anderen Teams besuchen können, die ansonsten parallel laufen.
+ | asap
+ | x | 
+ 
+ | Termine nach Möglichkeit ab 13:30 Uhr
+ | Kollidiert mit der Mittagspause
+ | asap
+ | x | 
+ 
+ | KickOff mit Christian Metzner organisieren
+ | Offene Fragen zum Thema Architektur klären
+ | asap
+ | 
+ | 
+ 
+ | In Confluence eine Architektur Seite anlegen
+ | Wir wollen hier unsere Fragen rund um das Thema Architektur sammeln um sie gemeinsam mit Christian Metzner zu klären. | asap
+ | x | 
+ 
+ | Termin für Releaseplanung organisieren
+ | Hinsichtlich des Releaseprozesses gibt es offene Fragen, die hier geklärt werden sollen. | asap
+ | x
+ | 
+
+ 
+
+ | Jira Template für Tickets
+ | Schnelleres Anlegen von Tickets und Abfrage aller für relevant erachteten Infos
+Storytemplate: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CEX-103
+Releasetemplate: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CEX-108
+ | 26.01.26
+ | ok
+ | 
+ 
+ | Termin für Demo-Tests organisieren
+ | damit Stefan beim Testing so schnell wie möglich entlastet werden kann | asap
+ | x
+ | 
+Sebastian
+ | Meilensteinplanung
+ | Um einen Überblick zu bekommen
+ | Laufender Prozess
+ | x
+ | 
+Dirk Lukas
+ | PoC Preisauskunft
+ | Um notwendige Vorarbeiten durchführen zu können
+ | asap
+ | x
+ | 
+Ünal
+ | Onboarding Programm im ART hinterfragen
+ | Es wird der Sinn des Umfangs in Frage gestellt
+ | Bis zum nächsten Coach Synch
+ | 
+
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Rogue-One-KickOff-Ergebnisse.md

@@ -0,0 +1,42 @@
+# Rogue One KickOff Ergebnisse
+
+Version: 4 | Last modified: 2026-01-08T14:40:52.596+01:00
+Source: confluence page ID 533400455
+
+---
+
+KickOff vom 07.01.2026 vie Teams
+Anwesend:
+Dirk Wagner
+Fred Flügge
+Jonas Monecke
+Stefan Werner
+Ünal Dogdu
+
+Agenda:  
+Vorstellungsrunde
+Vorstellung des Teamziels
+Abstimmung über notwendige Regeltermine
+
+ | 
+ | 
+ | 
+Daily | Di-Fr | Teams Meeting
+ | 
+Refinement | alle 14Tage Dienstags (nur bei Bedarf) | Teams Meeting | 
+Estimation | machen wir im Rahmen des Refinements | 
+ | 
+Planning | Jeden Montag im Rahmen eines Statusmeetings  | Teams Meeting | 
+Review | kein extra Format benötigt
+ | 
+ | 
+Retro | alle 14 Tage Dienstags (ggf. später alle 3 Wochen) | Teams Meeting | 
+fachlicher Austausch | kein Regeltermin notwendig | 
+ | 
+
+Das Team einigt sich auf einen Mix aus denMethoden Scrum und Kanban - Scrumban. 
+Srumban ist eine agile Methode, in der die festen Rollen und Meetings aus Scrum mit der Flexibilität und Visualisierung von Kanban verbunden werden. (weitere Infos: https://www.atlassian.com/de/agile/project-management/scrumban)
+Gemeinsame Ablage / Dokumentation. Sebastian Göndör nimmt sich des Themas an. () 
+Kanban Board Rogue One
+DoR/DoD
+WIP Limit (noch zu definieren)

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Sprint-Reports-XWING-2024.md

@@ -0,0 +1,77 @@
+# Sprint Reports XWING 2024
+
+Version: 20 | Last modified: 2025-01-08T09:26:33.769+01:00
+Source: confluence page ID 362611077
+
+---
+
+Nach Fixversion Lieferung → Was ist Live gegangen: Sprint | Datum | Ersteller | PDF | Link | 
+2024-07
+ |  
+ | Andreas Wenske
+ | 250
+ | 
+ | 
+2024-08
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2024-08
+ | 
+2024-09
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2024-09
+ | 
+2024-10 |  
+ | Andreas Wenske | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2024-10
+ | 
+2024-11 |  
+ | Andreas Wenske | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2024-11
+ | 
+2024-12 |  
+ | Andreas Wenske | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2024-12
+ | 
+Sprint Inhalt:Sprint | Datum | Ersteller | PDF | Link | 
+2024-06
+ |  
+ | Andreas Wenske |  PDF
+ | XW & EW Dasboard nach Fix Version 2024-06 Plan | 
+PI 33 O2CAP - S2 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 33 O2CAP - S2 - O2CXW | 
+PI 33 O2CAP - S3 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 33 O2CAP - S3 - O2CXW | 
+PI 33 O2CAP - S4 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 33 O2CAP - S4 - O2CXW
+ | 
+PI 34 O2CAP - S1 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 34 O2CAP - S1 - O2CXW
+ | 
+PI 34 O2CAP - S2 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 34 O2CAP - S2 - O2CXW
+ | 
+PI 34 O2CAP - S3 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 34 O2CAP - S3 - O2CXW
+ | 
+PI 34 O2CAP - S4 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 34 O2CAP - S4 - O2CXW
+ | 
+PI 34 O2CAP - S5 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 34 O2CAP - S5 - O2CXW
+ | 
+PI 34 O2CAP - S6 |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 34 O2CAP - S6 - O2CXW
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Sprint-Reports-XWING-2025.md

@@ -0,0 +1,150 @@
+# Sprint Reports XWING 2025
+
+Version: 37 | Last modified: 2025-12-04T18:49:23.288+01:00
+Source: confluence page ID 397847194
+
+---
+
+Nach Fixversion Lieferung → Was ist Live gegangen: Sprint | Datum | Ersteller | PDF | Link | 
+2025-02
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-02 | 
+2025-04
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-04 | 
+2025-05
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-05 | 
+2025-06
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-06 | 
+2025-07
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-07 | 
+2025-08
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-08 | 
+2025-10
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-10 | 
+2025-11
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-11 | 
+2025-12
+ |  
+ | Andreas Wenske
+ | 250
+ | X-Wing Dasboard nach Fixversion Lieferung 2025-12 | 
+Sprint Inhalt:Sprint | Datum | Ersteller | PDF | Link | 
+PI 35 O2CAP – S1 
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S1 | 
+PI 35 O2CAP – S2
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S2 | 
+PI 35 O2CAP – S3
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S3 | 
+PI 35 O2CAP – S4
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S4 | 
+PI 35 O2CAP – S5
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S5 | 
+PI 35 O2CAP – S6
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S6 | 
+PI 35 O2CAP – S7
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 35 O2CAP - S7 | 
+PI 36 O2CAP – S1
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 36 O2CAP - S1 | 
+PI 36 O2CAP – S2
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 36 O2CAP - S2 | 
+ PI 36 O2CAP – S3
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 36 O2CAP - S3 | 
+ PI 36 O2CAP – S4
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 36 O2CAP - S4 | 
+ PI 36 O2CAP – S5
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 36 O2CAP - S5 | 
+ PI 36 O2CAP – S6
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 36 O2CAP - S6 | 
+ PI 37 O2CAP – S1
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 37 O2CAP - S1 | 
+ PI 37 O2CAP – S2
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 37 O2CAP - S2 | 
+ PI 37 O2CAP – S3
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 37 O2CAP - S3 | 
+ PI 37 O2CAP – S4
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 37 O2CAP - S4 | 
+ PI 37 O2CAP – S5
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 37 O2CAP - S5 | 
+ PI 37 O2CAP – S6
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 37 O2CAP - S6 | 
+PI 38 O2CAP – S1
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 38 O2CAP - S1 | 
+PI 38 O2CAP – S2
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 38 O2CAP - S2 | 
+PI 38 O2CAP – S3
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 38 O2CAP - S3 | 
+PI 38 O2CAP – S4
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 38 O2CAP - S4 | 
+PI 38 O2CAP – S5
+ |  
+ | Andreas Wenske | 250
+ | X-Wing Sprint Board - PI 38 O2CAP - S5 |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Team-Coruscant.md

@@ -0,0 +1,9 @@
+# Team Coruscant
+
+Version: 14 | Last modified: 2026-05-15T10:37:18.400+02:00
+Source: confluence page ID 537643941
+
+---
+
+MitgliederDie Mitglieder des Teams Coruscant verteilen sich auf die folgenden Gruppen.
+Siehe Roadmap: Feature Gruppen Roadmap.pptx

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Team-Rogue-One.md

@@ -0,0 +1,132 @@
+# Team Rogue One
+
+Version: 16 | Last modified: 2026-05-06T13:22:22.709+02:00
+Source: confluence page ID 533429844
+
+---
+
+Termine:
+ | Montag | Dienstag | Mittwoch | Donnerstag | Freitag | 
+09:15 | 
+ | Daily | Daily | Daily | Daily | 
+09:30 | Status Meeting  | 
+ | 
+ | 
+ | 
+ | 
+13:00 | 
+ | Refinement | 
+ | Teammeeting | 
+ | 
+15:00 | 
+ | Retro | 
+ | 
+ | 
+ | 
+
+Teammitglieder:Sebastian.Goendoer@deutschebahn.com (PO)
+Uenal.Dogdu@deutschebahn.com (SM)
+martin.stieglitz@deutschebahn.com (FO)
+Dirk.Di.Wagner@deutschebahn.com (DEV)
+Stefan.St.Werner-extern@deutschebahn.com (DEV)
+Jonas.Monecke-extern@deutschebahn.com (DEV)
+Lukas.Schmiedgen-extern@deutschebahn.com (DEV)
+Fred.Fluegge-extern@deutschebahn.com (DEV)
+
+DoR - Definition of Ready für Feature und Enabler Owner des Feature/Enabler ist bestimmt (Hinweis: Feld Bearbeiter/Assignee des Feature/Enabler in ariJa)
+ Feature/Enabler ist einer Capability zugeordnet
+ Risiken sind dokumentiert und mögliche Maßnahmen definiert
+ Abhängigkeiten sind, soweit bekannt, beschrieben und innerhalb von ariJa verlinkt (ART interne). Externe Abhängigkeiten sind im Feature/Enabler dokumentiert und abgestimmt.
+ Relevante Dokumente sind verlinkt oder angehängt
+ Das Feature/Enabler wurde allen Teams vorgestellt, besprochen und von allen verstanden
+ Feature/Enabler ist innerhalb eines PIs umsetzbar und möglichst unabhängig zu anderen Feature
+ Die Bewertungen zur WSJF Berechnung (Business Value, Time Criticality, RROE) sind eingetragen
+ Feature ist in T-Shirt Sizes geschätzt
+ NEU: Testing ist berücksichtigt.
+DoD - Definition of Done (User Stories, Bugs, Enabler)(Stand: April 2025)
+Akzeptanzkriterien sind erfüllt: die Entwicklung deckt die Akzeptanzkriterien vollständig ab. Falls diese nicht aktuell sein sollten, ist eine Anpassung in Absprache mit dem Ticketersteller erfolgt.
+Reviewer-Approval: der Code wurde gereviewed, einschließlich der Einhaltung von SonarQube-Grenzen, Unit Tests, Sicherheits-Scans und Conventional Commits. Bei Liquibase-Skripten ist ein zusätzliches Review durch Björn oder bei Abwesenheit durch Christian/Adrian erfolgt.
+Tester-Approval: die Regressionstests wurden überprüft und angepasst, progressive Tests auf der EU sind erfolgreich und die Testdurchführung ist dokumentiert.
+Code-Merge: Codeänderungen sind in den Zielbranch (Master- oder Featurebranch für Release Bundles) gemerged.
+Nachtest auf TU: bei Bedarf wurde ein Nachtest auf der Testumgebung durchgeführt.
+Releaseinformationen: Die Lösungsversion im Jira-Ticket und die Deployment-Anmerkungen in Confluence sind gepflegt.
+Die Storie wurde vom PO bzw FO abgenommen
+
+Abstimmung hinsichtlich zukünftiger Tests:                
+Testdriven Development → Bereits im Refinement soll darauf geachtet werden was später getestet werden soll. Teile des Testdesigns würden sich daraus bilden lassen.
+Unit Tests werden von den Entwicklern durchgeführt.
+manuelle Tests sollen von jemandem vorgenommen werden, der an der Entwicklung der Story nicht beteiligt
+Bereits bei der Erstellung der Story werden KI generierte Testszenarien aufgezeigt
+fehlende xray Skills sollen aufgebaut werden → Schulung oä
+Abstimmung zur zukünftigen Releaseplanung            Releasetermine werden im Refinement in´s Ticket geschrieben
+Stories dürfen nur dann gemerged werden, wenn sie bis zum Release noch getestet werden können
+Die Kommunikation was released wird, kommuniziert der PO im ART Sync
+...
+Abstimmung zur Nutzung des KANBAN Boards          Erstellung von Tickets & PriorisierungGrundsätzlich ist der Feature Owner für das Schreiben der Tickets zuständig. Es kann jedoch jedes Teammitglied Tickets erstellen
+Die Nummerierung der Features entspricht der aktuellen Priorität. Bei Bedarf werden auch Stories nummeriert
+Grundsätzlich stellt  die Reihenfolge der Tickets die Priorität dar
+die Priorität wird auch im Ticket selbst hinterlegt. S.h. Abbildung unten
+
+Hierarchie im BoardEbene 1: Feature
+Ebene 2: Story, Enabler, Bug
+Ebene3: Aufgabe
+
+Aktuelle Lanes im KANBAN BoardBlocked | Open | Fachlich geklärt | In Progress | Ready4Test | In Test | Ready4TU | Ready4AU | 
+enthält alle Tickets, die bereits "In Progress" waren und aktuell nicht weiter bearbeitet werden können. | Stellt das Sammelbecken für alle Tickets dar. | Als fachlich geklärt gilt ein Ticket wenn es folgende Eigenschaften erfüllt:
+erfüllt die DoR Kriterien 
+Akzeptanzkriterien sind vollständig
+enthällt eine Beschreibung
+Refinement hat stattgefunden
+enthält Testszenarien
+ | alle Tickets in Bearbeitung
+als Richtlinie gilt: WIP-Limit = 3
+ | Akzeptanzkriterien sind erfüllt
+ | Tests am Laufen
+ | Tests waren erfolgreich, Bugs wurden behoben
+fachliche Bewertung ist erfolgt
+ | alle bisherigen Tests waren erfolgreich
+das Ticket ist fertigentwickelt (done)
+ | 
+
+Offene Todos:
+
+4
+c53c64d8-4a8a-4a70-a57c-c01a5b741410
+incomplete
+Erstellung eines Templates für eine Checkliste
+
+5
+d047a4a8-29ae-42c6-812c-cbf7ee820379
+complete
+Kommunizieren, dass das Team sein Commitment aus dem letzten PI nicht wird halten können.
+
+6
+b165b729-cfb5-44e4-9d56-481c5aab018e
+incomplete
+ 
+
+Der Refinement Prozess   
+Verantwortlichkeiten
+Product Owner / Feature Owner
+Wählt Stories aus dem Backlog für das Refinement aus. Bis spätestens zum Statusmeeting.
+Stellt sicher, dass jedes Ticket die Definition of Ready (DoR) erfüllt
+Team
+Sichtet die Tickets vor dem Refinement
+Notiert offene Fragen und Unklarheiten
+Gibt eine Aufwandsschätzung ab in der sowohl Aufwand als auch Komplexität berücksichtigt werden
+
+Ablauf
+PO/FO wählt relevante Stories aus dem Backlog
+PO/FO priorisiert die Tickets (Top-Ticket ganz oben)
+PO/F prüft die Definition of Ready
+→ nicht erfüllt: Ticket nachschärfen
+Team bereitet sich vor und sammelt Fragen
+Refinement-Meeting:
+Akzeptanzkriterien werden geprüft
+Testszenarien werden ergänzt
+
+Ergebnis des Refinements
+✔ Klar verstandene Tickets
+✔ Vollständige Akzeptanzkriterien
+✔ Ergänzte Testszenarien
+✔ Gute Basis für verlässliche Schätzungen

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Teams-Kanal-Meldungs-App-Support.md

@@ -0,0 +1,37 @@
+# Teams-Kanal Meldungs-App/Support
+
+Version: 5 | Last modified: 2026-05-11T19:31:16.269+02:00
+Source: confluence page ID 577046559
+
+---
+
+Feedbackgeber*in: Steffen.AC.Herrmann@deutschebahn.com
+Datum: 01.05.2026
+Hallo!
+Neues Feedback aus der ZAB-Ap
+Ich habe mit der App einige Meldungen selbst erstellt und auch Kollegen die zur Ausbildung waren damit arbeiten lassen. Der Grund eindruck ist positiv aber besonders von jüngeren Kollegen wird die "Weblastigkeit" bemängelt. Also muß die Ergonometrie der App verbessert werden. Mein Vorschlag: bei der Standortauswahl - wenn der Standort feststeht dann doppeltippen oder ein Feld am Rand der Karte mit einem Haken. Auch zum Beenden und Abschicken wäre so ein Feld präsenter. Die Jugend ist an sowas gewöhnt und alle Anderen werden damit klarkommen. Besser als rechts oder links oben nach einer Schaltfläche zu suchen. Das "Bildergröße" Problem wurde ja bereits bearbeitet.
+Viele Grüße Steffen Herrmann
+ App 
+Meldungserstellung
+
+2. Feedbackgeber*in: joerg.muthers@deutschebahn.com
+Datum: 06.05.2026
+Hallo!
+Neues Feedback aus der ZAB-App 
+Wenn man Bilder hochgeladen hat und sich diese später in der Meldung anschaut, fehlt die Zoom-Funktion, das heißt, die Bilder werden nur in Originalgröße angezeigt. Zur Detailerkennung ist ein Zoomen auf 300 % oder mehr aber teils nötig.
+ App
+Komponente (Meldungsübersicht, Meldungsdetails )
+
+3. Feebackgeber: joerg.muthers@deutschebahn.com
+Hallo!
+Neues Feedback aus der ZAB-App 
+Bisher drei Meldungen erstellt, welche alle drei in der Bearbeitung sind. Wenn ich die Startseite der ZAB anklicke, sieht es so aus, als wenn ich bisher nur eine Meldung erstellt hätte, siehe Screenshot der Startseite. West unter Meldungsübersicht werden die weiteren Meldungen angezeigt. Da es ja die Meldungsübersicht gibt, macht es wenig Sinn, auf der Startseite die Meldungen anzuzeigen, zumal wenn das nicht vollständig ist.
+
+4. Feedbackgeber: joerg.tittelbach@deutschebahn.com:
+Hallo!
+Neues Feedback aus der ZAB-App
+Bei der genauen Lokalisierung in Rangiergleisen gibt es Probleme. (Prio:Bezug auf Streckengleise) Da müsste eine zusätzliche Funktion aufgenommen werden. Mehrere Fotos werden nicht versendet. Datenmenge zu groß. Insgesamt dauert der Vorgang zu lange und ist erfolglos,da plötzlich alle eingegebenen Daten verschwinden. Besonders bei schwachen Internetverbindungen von unterwegs.
+----------------------------------------------------------------------------------------
+[1] joerg.tittelbach@deutschebahn.com?subject=Re:%20Feedback%20ZAB
+App 
+Meldungserstellung

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Teams-Kanal-Portal-und-Support.md

@@ -0,0 +1,12 @@
+# Teams Kanal Portal/- und Support
+
+Version: 3 | Last modified: 2026-05-11T19:29:37.632+02:00
+Source: confluence page ID 577046183
+
+---
+
+Hallo!
+Neues Feedback aus dem ZAB-IH-Portal von [1]joerg.pera@deutschebahn.com:
+Das exportieren der Meldung mit allen Informationen zu einer PDF funktioniert nicht.
+----------------------------------------------------------------------------------------
+[1] joerg.pera@deutschebahn.com?subject=Re:%20Feedback%20ZAB

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Teams-und-Velocity.md

@@ -0,0 +1,9 @@
+# Teams und Velocity
+
+Version: 1 | Last modified: 2026-04-24T08:33:52.208+02:00
+Source: confluence page ID 581025756
+
+---
+
+Teams und VelocityTeam-Struktur, Jira-Analyse, Durchsatz und Personenanalyse.
+true

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Themenbloecke.md

@@ -0,0 +1,10 @@
+# Themenblöcke
+
+Version: 31 | Last modified: 2024-03-01T12:03:06.266+01:00
+Source: confluence page ID 287523827
+
+---
+
+Themen im ART FunnelNobwRAlgJmBcYGcAuBDJBXBYA0YB2KAtgKZxgDKqGWuAxgDYqbEByRp8yamOYDTCYgEkYnKj1wJaAC2KEUccEgCeABw6JxNRMuRyyXamAC+xgLpAMICQggSgKkAFIRQMkAAoJw9gVgpgxgLgAgLwIEQHkBMBhBAfBAUQEsA7AMwEMYALAI0ptPwQEEAlAFVTYDkARBMQDOwgK5Q4ATwAOUZAgBiUSnDEh5fQak4qAtsIQBJUgDcwAG1NQAJjzIIAFJkwA2AAwBGADQIXHzF9-dwBmILd3ABYgyIAOKKCAVnj3JPjPAEoEdHZ+QnYEACEATQQAaygpNgBlbCAN4IgxgFghgTgLgIQJ4EkAmIBcIDOcpwCuOIANLgKYDmAthQHZw4DCA9vQGYCWVhMBXdllAA3APoAxQvXoUANsJBd6aCgA8sABnI5qdRiUwBtUFwzZxUmfLIgRUOYQpYQV2QvL0odF25sBfAF1yMFY5VhgXAGIAIw4AJgA2TU1bES4cLhi5Z0w4GCd-cnEAQS85JEzDUxV1LABGHT0GJiwTJXM7MTKHSoy0hycXHoqq2y8fbBG+kiCQsIjogBYAdhiwAA4oNIysnKx8wuLJCngeRWVVDUx4ptoWw3azF0tTuHPiwdzXN4+QCe+El+VBAc3AC0i2CiHA4GxiKR2mWyuUOFCKXRQNAADjl9Ph3kJMDUrlgAMx3PGPUydcSYnEUPECISfRzfOm4lpM+jjbxs7Ecxhc0HBcHhSEgaEUGKJJKIvYogpo9E0AiQADKvIkXHkaEMHAcunIVBgrEIWOYUBwYCgqi1Or1Boo5GIFDYYsMqPIEVUMGUIOwqitDDQftsOAgrAA7gAtU6sNjSVqYfVyQ2iiIAGVYYAA1lgU7p-EAOwNgQsCMAcQNoXSAQNobwRALgngDgpmAXGAwgeQKoDkAqYA0YAhgOYkBOcJREcAQlEmAJIDKrGAoq2AL4C6QAfalse1N4IgzgFg9g7gQlATgEwKaJALgGYEMA2YqANONDACq4BG+qACugMaoB2ALmFu4gK4llYVWqgCSYMPy6Ye-UpFgAtdFABqBfgBkaqQljyEBCylHYEAwlF4dufI+QqmLUfLwC2rW3MEwA4oisABzgATy97WE1UAHM2ZHD5cgANAEEADwBLMG1qXQSfAE10rJy8mTtEoSgXdgzAgHlWOFxEAAkoADd0fNxedigAJVRsRFRIfQIiUgJ8WHrA2qhWMABZNl4e-FmYAFE0wKR2fONi7Ji4y2sj8u8TzLPY1mRGRBYbHEmBJggW9goQwKoLAgeiiHYgUiA15sdgAESygXwuDCmBAqhSmgAquDpvcAMrkF5va4GKY+ZQBIkw0p6D6GSHMGHwsCI5EUDJ0YHorE7AD69B2A3MOwAchQISAocTmayQvQMkDUdzsfzBcKxRKpUyEUiQqcuRiVQKhaLxaQmAQmLwkewGIyOLhYvVsMCKPUKBiJXRHs8oGAMotPKiUn0oF7zk9tCErNcQCH+hLauw6Cl8Bloqw3DDgeqKIKJWgwExEHVA-Q-QGMktgQh2P03BLjJiiIhRG4oWAlrhA-kmGmmABrCgQAK8aIQfLeuIDSIZNwBrAAVlItTo5h+iHYoltbjALxnMCXpD193Xv1aqHTEHYmjnC8wACYAGwABkqMFhY2LparQdkERgGlpH-d8RXcXJEEsVwPGOchxEkVB-kBCZ6RAVhwPQfwggyVhomBEV6l5XwBnqTFQRFXwJXQtwIPoUYmCyX8sAARgZaEHViOjUAY-1q0wViQEdaJRmibtf3ZLNMVYe8QFaUiBjxCUhJEsSlgk1B2l4RABlUrAAA5zXca0xK6RwzHwFCyWQFoBxWKA0EsgDHBqOpGhFXAs3aLoMDpMljEsGicNQZAACkAEcLN8gQTyyKSZMuGxSGs20ADEkDcbtgVhFICl5FLRAUiheTxOSBjNHx2hLAAvJZzNvVgxkc99VHQWoLXwLz0HqxUQJ8bqz03SxWAaphalw7rgIqEBkCyGg6FaAF0DTVgB2kUkvisDg4rC-h4KkfIYFQVABzxMxN1hZEWIAXyAA 
+
+Hieran arbeiten die TeamsNobwRAlgJmBckGcEFcCmAXAngB1WANGAHYCGAtnvAGoD2ATgOYlEMJbYFgDGANicglQA5cpTDs8hXv0EBJGPAhI0Ezgi4ALVGRJxwqxcow5JYBJjba4iFMdxgAvg-zho1pbYDWqTJ1IVrAGVNHgAfpFQeTmkBYVF3I2i+WPl3GGdXBTNkMh06X0J-MQAtAXIKIgAzEmUWJJk4gPgUXJJ8+pSslryCs01tXVh9E2s2Ogg6wnNLMlGcnscMyC70EnQBP3j4QNX1hA7BESazXY2pZLkVtbO+rR09cRHm0-2pi3QrZ+v9pxdl6xqCAgDCIqFMRWsACFUG0AEaoCAfOgHRpiQHA0GmGKXAFIDFgtT9e5DR72eCxZFvGa4oEggm-TLWZDYKBrVAwQpbMAAQU86xIPCUEFQdHQKKOYmZrI+UAAImyUalySy2RzbgMHgYwNKMBAAlSPrNlTr0g4ALpAAMICQggSgKkAN4IgDgTg9gVgpgYwC4GcQC4DaBdANCFJCAV2WIjjSzxCQE8w4MQApARQBkR8BHYuCHWYAFaPGQACALwSAOiADyAJgDCEgD4SAogEsAdgDMAhggAWAIyOm9GiQEEASgBV59gHIARCTpQp+9RmkJADE4IyRyOAl3L3knMIBbFAkAST0ANygAG3S4ABNXfQkACiUlADYABgBGXAkyqqU6hsqAZmaKyoAWZq6ADm7mgFYByuGB6oBKCQUHDy0HCQAhAE0JAGs4OnsAZRUQAF8gAN4IgZglgNgLgpgJwM4gFwG0C6AaEB7AB0QEMYI8A7NEAQQDkAREAXyANoXSADIUQYgKkAEIdgLArAIsQNobwRAlgJmBckGcEFcCmAXAngB1WANGAMbILoD2AtgHICGle8YAvvuNHIiqgNaqYs2kGPBSVKtAE4DW7EWDK10pQXM60kEAOYA7VHlnDOybFCWoYhBulpwQzZgF0gAQfalse1N4IgJgpgzgxgTgSwA4BcEHsB2AFdUFpYgBcIAQuiiugLYgA0IUAFugO4VyRwkBmAhgBsoERi3YARaPGSFMJFHACuopqzYBVEXACSMIsUUrGYfnADWAWXSQ+QkYzjQlglFGwQ42fgHMIJAFYABkZMJRoAI08AcTh0JSQETB8SEB0AFQBBABkdTIA5AH1ogCUAeQ1sHXzohhAwyM9sJxgEfAMQ8H4UCAAxdDgabtSJTIBNQt6dEoBldMKZgAkykvS68U1tHRokTygsbox5Q2VVGEEEGHN05jilH2YFU8Z+JWoSiF4nFjthVSFBOwyqgjlBLBAwk9jCAAewAKIADyQAxQUNUG0yrk8mEOyRK7AAwuhAXAoGixOp8uEonAiYJwscBH8Xj4fE4fIcsOkEDQIBpMARUssNLM6r42RAOXJubzFvE4CVOSQABwU9gy6Aofg7KBlTASboQDW9BAQQRgMknaFgNr8CKCCCLACeuzgF0w5ktTJEAF8gA

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Trio.md

@@ -0,0 +1,19 @@
+# #Trio
+
+Version: 2 | Last modified: 2024-07-01T13:54:52.665+02:00
+Source: confluence page ID 345055775
+
+---
+
+Themen: 
+CRM + InfraPortal
+ZAB
+Trassenfinder + strecken.info + Bestellportal 
+Baukommunikation (Zeithorizont 3-6 Jahre)
+AC-Trasse
+
+Diskussionspunkte:
+werden die Einzeltools aufgelöst und voll ins InfraPortal integriert (inhaltliche Zusammenhänge)?
+APIisierung muss verstärkt werden, sodass Plug&Play-Lösungen für EVU entstehen
+auf welche Themen fokussieren wir uns? Wir lassen uns nicht in ein ValueTeam/Stream quetschen → wir bilden eine Klammer über alles
+#Einfachbahn als Beratung? Beauftragt durch Mmgt (z.B. Arnhold), konkrete Suche nach Verbesserungen und reingehen

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Workflow-Testing-Team-XWing.md

@@ -0,0 +1,16 @@
+# Workflow: Testing - Team XWing
+
+Version: 37 | Last modified: 2026-01-13T09:54:01.027+01:00
+Source: confluence page ID 431628888
+
+---
+
+INLINEWorkflow (Siehe Confluence Workflow: Testing - Team XWing - O2C | Order2Cash - ariJa Confluence)
+Entwickler hat Entwicklung abgeschlossen → Entwickler hat Unit Tests geschrieben -> Entwickler schiebt Ticket auf "ReadyForTest" -> Tester testet erfolgreich auf EU -> Tester dokumentiert Test und approved den MR -> MR Review findet durch zweiten Entwickler erfolgreich statt -> Merge erfolgt durch Entwickler auf TU -> (Ggf. je nach Ticket: Tester testet erfolgreich integrativ auf TU (ggf. über UI) und dokumentiert den Retest ->) Tester schiebt Ticket auf "Done"
+Die Rolle des Testers kann natürlich auch von einem Entwickler erfüllt werden hier, aber den Workflow sollten wir hier definitiv beachten. Und es ist essentiell, dass die 3 genannten Rollen von 3 verschiedenen Personen erfüllt werden.
+Dokumentation
+Stories werden durch einen dedizierten Test in XRay samt Execution abgedeckt. Beispiel hier: O2CXW-6485 mit dem Test O2CAP-2911 und der Execution O2CAP-2912. (In diesem Fall ist der Test direkt in O2CAP erstellt worden, weil er direkt als Regressionstest konzipiert wurde. Im Normalfall erstellen wir den Test im selben Projekt der Story)
+Bei Bugs, Enablern und Co. reicht eine Dokumentation in Form von Kommentaren. Dort beschreiben wir das Vorgehen, das Ergebnis und hinterlegen möglichst noch die Testdaten. Manchmal ergibt es auch Sinn, den Bug einmal auf einer betroffenen Umgebung zum Vergleich zu reproduzieren und das nochmal aufzuzeigen. Beispiel hier: O2CXW-6690 (siehe Bild)
+Das folgende Diagramm zeigt den optimalen Ablauf einer Testdurchführung für eine reguläre Feature-Story bzw. einen Bug.
+Der gezeigte Workflow ist rein aus Testersicht gestaltet. Zur Einordnung ist auf den generellen Feature Workflow in  zu verweisen.
+trueMerge Workflow Testingfalseautotoptrue2491113125

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/abgeschlossen_Dorothea_Deine-Monate-im-Team-Infraportal-NuR.md

@@ -0,0 +1,59 @@
+# abgeschlossen_Dorothea_Deine Monate im Team Infraportal/NuR :-)
+
+Version: 9 | Last modified: 2025-05-08T13:51:51.838+02:00
+Source: confluence page ID 345052971
+
+---
+
+Infraportal/NuR: Mögliche Arbeitspaketvorschläge für Dorothea
+
+Hallo liebe Dorothea,
+wir haben uns etwas feines überlegt. 3/4 Arbeitspakete bauen aufeinander auf. Es wäre aber sicherlich auch möglich, nur einzelne Arbeitspakete zu bearbeiten. 
+Bei uns ist es recht bunt - wir arbeiten mit eigenem agilen Verständnis, Eva hat die Felder Politik, Recht und Projektmanagement bei sich, Sebastian die Nutzer-und Rechteverwaltung und die Zusammenarbeit mit dem coolen BVU-Entwicklungsteam und Sarah hat die Nutzersicht im Blick und improvisiert gerne Lösungen, wenn sich grade mal wieder VUCA von seiner besten Seite zeigt 
+
+Weiteres zum ProjektteamRollen im Team Infraportal:
+
+Der Confluence-Bereich des Infraportals:
+
+FYI: Früher hieß das Projekt Kundenportal, mittlerweile hat das Produkt den Namen "Infraportal" bekommen.
+
+Mögliche ArbeitspaketeTeilprojekt | Arbeitspaketvorschlag | Einschätzung | Beschreibung | Ansprechpartner:innen | Dringlichkeit | Zeitbudget | 
+NuR
+ | 1/3
+Anschluss der neuen Tools vorbereiten: Anweisungen und Dokumentation 
+ | gutes Thema, um in NuR einzusteigen
+"NuR verstehen"
+Interne technische Sicht auf NuR
+ | Anweisungen und Dokumentation für Anschließende verstehen und verbessern
+
+ | Sebastian R., Sarah | bis Ende Juli
+07/24 | 3-4 PT | 
+NuR | 2/3
+NuR-Dashboard konzipieren | Politisch-technische Sicht auf NuR | Befragung von André, Eva, Sebastian R., Sarah, Moritz, Willy, Marven und ggf. Yvonne.
+Vorschlag: 15 Minuten pro Person mit 3-4 gezielten Fragen
+Was muss ein Dashboard können? Welche Anwendungsfälle gibt es? Was möchtest du (Befragter) wissen? Welche KPIs helfen dir?
+Hinweis: Hier gibt es einen Synergie-Effekt mit dem "80%-Ziel erreichen" (3/3, siehe untern), um KPIs zu entwickeln: Mit welchen Stellschrauben können wir das 80%-Ziel erreichen?
+
+Dieses Arbeitspaket beinhaltet überdies die Erstellung eines Konzepts, das an die BVU (Entwicklerteam für NuR) zur Entwicklung übergeben werden kann.
+
+Aktueller Prototyp: https://app.mural.co/t/einfachbahn1103/m/einfachbahn1103/1712835047905/8d70aa3cd51f6399461bf39adad618bc4ac113b2?sender=sebastianreinig5949
+Aktuelle Version:
+
+Die Zahl für Aktivierte 2FA ist noch "falsch". Mittels Excel kann aber die korrekte Zahl erzeugt werden.
+Beispiel:
+
+Das Konzept kann hier dokumentiert werden:
+
+ | Eva, Sebastian R. | bis Ende August
+08/24 | 5 PT | 
+NuR | 3/3
+80%-Ziel erreichen | Nutzer-orientierte Sicht auf NuR | 80% der Nutzer:innen (die keine Deutschebahn.com-E-Mail-Adresse haben, also B2B-Nutzer:inenn sind) sollen den SSO-Status "Accepted" haben.
+Accepted = Der User hat die Einladung angenommen, d.h. er hat sich zmd. versucht einzuloggen.
+PendingAcceptance = Der User wurde eingeladen
+Aktuell haben wir 45%.
+ | Eva, Sarah, Sebastian R. | bis Ende September
+09/24 | 2 PT | 
+Infraportal | a/a
+Power-App für das Kommunikationsteam in Zusammenspiel mit dem Infraportal-Team entwickeln | Zusammenarbeit Abteilungsübergreifend und Nutzung einer bereits vorhandenen Kompetenz | Unser Nachbarteam plant Kommunikationsformate. Dazu gibt es gewisse Abläufe, die das ganze Unternehmen betreffen. Aktuell gestalten sich diese Abläufe (Stichwort: KundenInformation, KI) recht aufwändig über Formulare, die in DB Planet heruntergeladen werden können, um dann Dateien zu versenden über E-Mail oder Chat mit etlichen Beteiligten; hier könnten wir sicherlich gut unterstützen. | Sarah, Moritz, KT Louis W. | bis Ende August (könnte auch in September fließen)
+08/24
+ | 9 PT |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/fachliche-Aspekte-vom-Team-GrundsÃ-tze-CRM.md

@@ -0,0 +1,38 @@
+# fachliche Aspekte vom Team Grundsätze-CRM
+
+Version: 8 | Last modified: 2026-06-01T11:15:08.936+02:00
+Source: confluence page ID 593812535
+
+---
+
+Wichtige Maßnahmen zur datenschutzkonformen Gestaltung sind:
+Rechtmäßigkeit: Jede Verarbeitung personenbezogener Daten benötigt eine Rechtsgrundlage (z.B. Einwilligung, Vertragserfüllung oder überwiegendes berechtigtes Interesse). Im Falle von Einwilligungen müssen diese aktiv eingeholt und dokumentiert werden.
+Datensparsamkeit & -minimierung: Nur Erhebung von Daten, die absolut notwendig sind.
+Löschkonzepte: Automatisieren der Löschung oder Anonymisierung von Daten, wenn der Zweck der Speicherung entfällt oder gesetzliche Aufbewahrungsfristen enden.
+Sicherheit & Zugriffskontrolle: Umsetzen von dedizierten Zugriffsrechten, damit Mitarbeiter nur auf benötigte personenbezogene Daten im Rahmen ihrer eigenen Rolle und Aufgabenstellung zugreifen können; technisch organisatorische Maßnahmen zur Gewährleistung des Schutzes der personenbezogenen Daten (Vertraulichkeit, Integrität, Verfügbarkeit)
+
+Status Quo:
+1. Es ist nicht bei allen Kontakten klar und auf den ersten Blick die Rechtgrundlage der Speicherung ersichtlich bzw. dokumentiert. Der Zweck der Speicherung ergibt sich teilweise aus verschiedenen einzelnen Feldern in Salesforce, z.B. weil es Vertragskontakte sind. 
+2. Es ist nicht bei allen Feldern der Zweck der Verarbeitung / der Erhebung dieser Daten ersichtlich. Es ist eher zu vermuten, dass einige Felder keinen Zweck (mehr) haben. (Datensparsamkeit!)
+3. Bisher erfolgt das auf-ausgeschieden-setzen und die Löschung von Kontakten manuell. Zudem ist nicht immer klar erkennbar, wenn der Verarbeitungszweck entfällt, da ja schon der Verarbeitungszweck nicht immer klar erkennbar ist (siehe auch Punkt 1. und 2.).
+4. Es fehlt eine 2FA für das Profil-Center
+5. Duplikate haben keinen Einblick in ihr Profil-Center und können sich dort daher auch nicht löschen lassen. 
+Alle Kontakte würden sich aber in vier Gruppen einteilen lassen: DSGVO, Art. 6 1 a), b), c), f)
+
+Zielbild:
+Bei jedem Kontakt ist ersichtlich, was a. die Rechtsgrundlage der Speicherung ist und b) was passiert, wenn Rechtsgrundlage entfällt oder sich ändert (gleich löschen oder x Jahre speichern).
+Bei jedem Feld ist ersichtlich, was der Zweck der Verarbeitung / der Erhebung dieser Daten ist.
+Die Kontakte haben Transparenz über die Daten, die wir über sie speichern (auch die Duplikate), sowohl statisch (=Profil-Center) als auch dynamisch (E-Mail, wenn sich Zweck der Speicherung ändert). 
+Kontakte werden auf Basis des Verarbeitungszwecks automatisiert behandelt (aus ausgeschieden setzen, löschen, bei Änderungen informieren)
+
+Schritte, um Ziel zu erreichen
+Genau definieren welche Kontaktarten mit welchen Feldern welchen Verarbeitungszweck haben und diese dann in die vier Gruppen einteilen.
+Genau definieren, zu welchem Zweck einzelne Felder für welche Kontaktarten erhoben werden. 
+Verschiedene E-Mails formulieren und definieren, welche bei Änderungen rausgeschickt werden, sowie bei Kontaktanlage, um Einwilligung der Speicherung einzuholen
+In Salesforce die Zuordnung der Kontakte umsetzen.
+Anpassungen an Profil-Center und Marketingcloud für die angepassten Journeys. 
+
+Entscheidungen, die noch offen sind:
+Welche Schritte, wann gemacht werden sollen. Wie ist die Prio einzelner Aufgaben bzgl. Weiterentwicklung von Salesforce?
+Wie gehen wir mit den Duplikaten um? Vorschlag: Das Profil-Center so umbauen, dass Duplikate per Drop-Down ihr Unternehmen auswählen können und ihre Daten pflegen. 
+Prüfen, ob und welche Kontakte direkt gelöscht werden können.

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Ã-bung-Ein-Jahr-ein-Team-ein-Ziel.md

@@ -0,0 +1,95 @@
+# Übung - Ein Jahr, ein Team, ein Ziel
+
+Version: 3 | Last modified: 2026-04-02T13:36:54.513+02:00
+Source: confluence page ID 566005410
+
+---
+
+Ziel der Übung: Die Gemeinsamkeit der Arbeitspakete und der verschiedenen Teammitglieder sichtbar machen und in einem Satz zusammen zu fassen.
+Betrachtete Arbeitspakete für die ÜbungAP1 Strukturplanung Zeitrahmen laut Antrag: Februar 2026 bis August 2026
+·         Ein Datenpflegeprozess vom Endnutzer bis zum Data-Steward
+·         Strukturplan für den gesamten Prozess
+·         Analyse und Entwicklung einer Schnittstellenvereinbarung
+·         Make or Buy Analyse Dataspace
+·        Verankerung in der DB InfraGO AG Data Governance 
+AP2 Business- und Use-CasesZeitrahmen laut Antrag: April 2026 bis Januar 2027
+·         Sammlung der Nutzerbedürfnisse und Use-Cases
+·         Analyse und Validierung der Use-Cases
+·         Initiale Auswertung einzelner vielversprechender Business-Cases
+·         Priorisierung der Cases
+·         Abstimmung der Top 3 Pilot Cases
+AP3 Aufsetzen der Basis Zeitrahmen laut Antrag: Mai 2026 bis Juli 2027
+·         Planung der IT-Umsetzung in Epics
+·         Aufsetzen und Bereitstellen der Entwicklungsumgebung inkl. Deployment Pipeline
+·         Entwicklung des initialen Feature-Backlogs
+·         Make or Buy Analyse für die UX//UI Komponenten (MDS Service)
+·         Umsetzung des API Portal MVPs
+·         Entwicklung des Metadatenkatalogs
+·         Umsetzung der Basisversion InfraSpace
+Rahmen der ÜbungSMART ZieleS - Spezifisch 
+M - Messbar
+A - Akzeptier/Attraktiv
+R - Realistisch
+T - Terminiert
+VorgabenTool: Ein Notiz-Tool eurer Wahl
+Zeit: 3 min
+A (Akzeptiert) = Das Ziel muss auf die 3 oben vorgestellten Arbeitspakete gesetzt sein.
+T (Terminiert) = Stichtag 31. Januar 2027
+Beispiel:Angelina Bieler-Schöfer: Minispiele für den InfraSpace, um die Problemstellungen Bahn darzustellen.
+Zum 31. Januar 2027 wird Infraspace:
+[ AP1 ] definierte Anforderungen, die einem studentischen Projekt eine Entwicklung ermöglichen, für 8 Minispiele haben; 
+[ AP2 ] mindestens 3 dieser Minispiele in der Veranstaltung Frontend Development des Studiengangs Medieninformatik als Kunde in Auftrag gegeben haben
+[ AP3 ] und den jeweiligen Fortschritt von etwa 80% auf Verwendbarkeit für die Plattform reviewed haben.
+Zusammensetzung der Ziele
+
+Teilnehmer | AP 1 Strukturplanung
+(MS: August 26) | AP 2 Business- und Use Cases
+(MS: Januar 27) | AP 3: Aufsetzen der Basis
+(MS: Juli 27) | 
+Daniela Brünig | Zum 31.Januar 2027 wird InfraSpace...
+Wir sollten im ersten Jahr ein Konzept und eine Struktur erarbeitet eine Design entwickelt eine Website auf gebaut haben.
+Vorher müssen wir anhand unserer Erkenntnisse eine Make or Buy Entscheidung getroffen haben.
+ | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Gerd Brünig | Zum 31.Januar 2027 wird InfraSpace...
+klare Anforderungen an die Struktur und die Möglichkeit des Datenraums, Auswahl der technischen Umsetzung und der regulatorischen Rahmenbedingungen
+ | Zum 31.Januar 2027 wird InfraSpace...
+eine inspirierende Sammlung an UseCases und BetPractices, die uns bei der Etablierung einer Masterclass geholfen haben, die Vorteile anschaulich zu machen und zum Mitmachen zu motivieren
+ | Zum 31.Januar 2027 wird InfraSpace...
+Die Planung der IT-Umsetung ist so weit fortgeschritten, dass die Basis steht und die Metadaten als Struktue abschließen ermittelt wurden. Ein MVP des Portals liegt vor
+ | 
+André Knie | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Thea Lochmann | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Christof Müller | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Jörg Pfister | Zum 31.Januar 2027 wird InfraSpace...
+abschätzung der kapazitätssteigerung bei infrastruktur maßnahmen 
+ | Zum 31.Januar 2027 wird InfraSpace...
+Checkliste bzgl. möglicher Bewertungsaspekte ist erstellt
+ | Zum 31.Januar 2027 wird InfraSpace...
+Datenzugriff für Studierende ist für ausgewählte Parameter etabliert.
+ | 
+David Promies | Zum 31.Januar 2027 wird InfraSpace...
+alle im AP1 geplanten Arbeitsschritte bis zum August 2026 durchgeführt worden sein haben. Die Business- und Use Cases weerden bis zum Januar 2027 ermittelt worden sein.
+Ebenfalls bis Jan. 27 werden alle Vorarbeiten (Epics, Entwicklungsumgebung, Entscheidung Framework) bis auf die Umsetzung der Basisversion durchgeführt worden sein.
+
+ | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Matthias Schorsch | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Atze van Sorgen | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Simone Tautz | Zum 31.Januar 2027 wird InfraSpace...
+Wir haben kein vollumfängliches Zielbild aber entschiedungsreife Grundlagen für erste Umsetzungsschritte geschaffen.
+ | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+Angelina Bieler-Schöfer | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | Zum 31.Januar 2027 wird InfraSpace... | 
+
+ | 
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/â-beteiligte-Value-Teams-I-IB.md

@@ -0,0 +1,17 @@
+# ✅ beteiligte Value Teams I.IB
+
+Version: 3 | Last modified: 2025-07-01T14:43:56.480+02:00
+Source: confluence page ID 455056891
+
+---
+
+O2C (Order2Cash)Ansprechpartner:innen:Holger Wiese
+Mark Stockenhofen
+Robert Kahl
+Robert Arnold
+
+25.06.2025-26.06.2025 PI-Planning - entweder Thea oder Eva hin
+
+C2S (Capacity2Schedule)Ansprechpartner:innen::
+
+18.06.2025 PI-Planning

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/â-ï-hier-bitte-einordnen-Rollen-im-Team-Zugriff-Projekt-Infraportal.md

@@ -0,0 +1,73 @@
+# ⚠️ hier bitte einordnen! --- Rollen im Team Zugriff (Projekt Infraportal)
+
+Version: 25 | Last modified: 2025-07-01T14:48:06.256+02:00
+Source: confluence page ID 444014920
+
+---
+
+Offen:
+Umbenennung von Infraportal in Zugriff
+Was ist mit dem Review und Planning? → bald 
+
+PM Infraportal / Projektleitung InfraportalVerantwortung:
+Vermarkten das Produkt intern und extern (z.B. Vorträge)Gesicht DB InfraGO AG für das Infraportal
+
+Erste Abstimmung mit Anwendungenkönnte direkt an PO NuR?
+
+Projektplanung (z.B. Zeitpläne erstellen)für wen? wo ist der aktuelle Zeitplan? 
+Abstimmungen im Vorfeld zum Planning
+
+Überblick behaltenAnfragen verorten können
+Ansprechpartner für alle Fragen bzw. wissen wer der AP ist
+
+Abstimmungen mit der Regulierung (z.B. Änderungen in INB)Frau Karalus
+Simon Weber
+
+KPI melden und trackenHolger Wiese
+Anzahl angeschlossene Anwendungen
+
+Übergreifende Maßnahmen einleiten (z.B. ADR)ADR und Jan-Sören Papp
+
+Stakeholdermanagement- und Kommunikation (u.a. Management, Portfoliomanagement, Betriebsrat, SAFe-Struktur (Holger Wiese), IT-Security ...)APs sind...Robert Arnhold
+Holger Wiese, Jan-Sören Papp, ...
+Berthold Hillebrand
+Johannes Schmidt
+
+Eskalationsinstanz bei Übergreifende ProblemeClaudia, Helena usw
+
+Projektberichte und Statusupdatesz.b. O2C und C2S Marktstand?
+
+Übergreifendes Anforderungsmanagementwas bedeutet das?
+Bevor wir den Funnel hatten, haben wir das Anforderungsmanagement komplett im Team verantwortet. Auch mit dem Funnel, wird die Übergreifende Verantwortung für Anforderungen in die Produkte bzw. in das Projekt notwendig sein, denn der Funnel übernimmt nicht die Priorisierung in einzelnen Teams. 
+
+Infraportal "Marke" statt Infraportal Produkt
+
+2nd Level Support mittwochs
+
+Infraportal und DisKo.pptx
+PO InfraportalVerantwortung:
+Betreuung des Designs und Mitgestaltung des Infraportal-Aufbaus
+Organisation und Betreuung des Kundenkontakt-Teams
+Information und Austausch mit den beteiligten Teams im Infraportal (Ticketsystem, Einladungsmanagement, Kommunikation und Change, Support, NeCo, NiCo, Anschließende)
+Kooperation mit Partnertool NuR mit PO NuR
+tbc
+Confluence:
+
+Als Co-PO NuR eingesetzt
+Unterstützung 2nd und 3rd lvl NuR
+Begleitung Weiterentwicklung des Systems
+
+PO NuR
+
+Verantwortung:
+Betrieb NuR
+Anschluss neuer Anwendungen
+Unterstützung 2nd und 3rd lvl NuR
+Weiterentwicklung des Systems
+Unterstützung der Anwendungsanschließer
+Kommunikation mit Anwendungsanschließer
+Confluence:
+
+Als Co-PO Infraportal eingesetzt
+Unterstützung und Begleitung der Einführung des Infraportals
+API-Connector