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-APN/APN-Architektur.md

@@ -0,0 +1,95 @@
+# APN Architektur
+
+Version: 44 | Last modified: 2024-05-27T13:28:35.191+02:00
+Source: confluence page ID 244623148
+
+---
+
+ThemenradarNeue Funktionen:
+LuLP - IDeadline Start GLV Vorbereitung ab 21.10.2024 (letztes Release also nach PI 34 Sprint 1, mit Puffer also letztes sinnvolles Release nach PI33 Sprint 5).
+Rückwärtsgerechnet 2 Sprints für Performanceverbesserung, 1 Sprint  für Lasttests, d.h. LuLP Grundlagen müssen Einsatzfähig sein nach PI33 Sprint 2)
+
+TracingAufbau eines eigenen Grafana Stacks
+
+AuroraDB Abzüge und genereller PU Support - M
+Messaging abziehen, neu aufsetzen? Initial Load?ggf Kafka betrachten?
+ 
+
+Health Dashboard + Alerting multistage 1173Prio Low, vielleicht erhöht mit TS3
+
+TS3Prio Low
+
+Vereinfachung bestehender Prozesse:
+zentrales Rollout - I (nur bis Tags funktionieren)npm Version/Tag setzen
+Pipelines umbauen/reparieren
+triggern der Pipelines
+Ergebnis transparent machen
+(Volldeployments+Kompatibilitätsnetze)
+
+Renovate
+
+Nutzung bestehender Tools
+Sonarcube - alle (auf 30% selektiv)min Coverage erhöhen
+
+WhitesourceFunktionsfähigkeit prüfen (Pipeline Konfig)
+Dual Lizenzen prüfen
+
+zentrales API Repository
+
+Wartung der Platform:
+Versionsupdates (Spring, Java, CNP, EIP, ...?) - G2 CNP Upgrades von der CNP Platform
+2 MoqAP Upgrades einpflegen
+5.15 Tibco BW PU Upgrade betreuen (26.6.?)
+SAG Patches für Pentest Findings einspielen
+US1204 Technische User über zentrale Authentifizierung anmelden
+
+Pentest & ScannerMedium/Low Findings
+
+KarpenterPrio High
+Deadline nicht genau spezifiziert, wir erwarten aber PI33/34
+
+SDLC Reifegradwir hatten bis Ende 2023 die Pflicht Reifegrad 1 zu erreichen
+für Reifegrad 1 fehlt noch: DAST Scanner (z.b. OWASP Zap Scanner oder ggf Invictus Scanner),
+Reifegrad 2 hat keine uns bekannte Deadline 
+
+Renamingeigene Konventionen weiterhin nicht 100% eingehalten
+
++ Restarbeiten PI32
+npm zentral rollout
+(karpenter)
+central rest API 
+Wie ist das Architektur Backlog aufgebaut?Es gibt einen Haupt-Anker, das sogenannte Architektur Backlog. Das ist der Enabler O2CAAPN-16.
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-16 ← hier gehts los, das ist der Haupt-Anker. Das sogenannte Architektur Backlog.
+
+truedarstellungfalseautotoptrue6034
+
+Die Architekten nutzen nur die relates to Beziehung, um Stories zu verwalten. Andere Beziehungen, vor allem die parent / child of Beziehung, werden von den Produkt Owner genutzt um Stories z.b. in Features einzuteilen.
+
+Sammelbecken (sowohl PI als auch Themen Sammelbecken) beginnen mit "APN-A: ", damit schnell ersichtlich ist, dass es sich um etwas handelt, was die Architekten erstellt haben.
+Prioritäten?Die Architekten nutzen die Prioritäten bereits im Architektur Backlog, und zwar wie folgt:
+critical / very high → muss sofort, also im laufenden PI, abgearbeitet werden
+high → muss ins nächste PI
+medium → kann ins nächste PI, muss aber nicht
+low → ist explizit nicht für das nächste PI geeignet
+very low → muss vielleicht garnicht gemacht werden → neu betrachten und bewerten
+Sobald Stories in ein Feature wandern kann und sollte die Prioritär neu gesetzt werden um dann eine Abarbeitungsreihenfolge im Sprint wiederzuspiegeln.
+
+AB HIER GGF VERALTETVersuch einer Ordnung alter Storys, Enabler und Features (ab hier ggf. verwaltet)PI spezifische Aufgabenplanungdas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-308 (leer)
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-307 (leer)
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-306 (leer)
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-289 (10+ stories)
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-108 (3+ Stories)
+
+Aufgabenspezifische SammelbeckenAlle mit APN-A im Summary
+das I.NVI IT Lifecycle Management Toolproject = O2CAAPN AND resolution = Unresolved AND summary ~ APN-A ORDER BY priority ASC, updated DESCd1143f0d-33c0-3f1c-b44b-7720150f306e
+
+Reine Mig Backlogs??das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-209
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-199
+
+Reaktives Incidentmanagementdas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-286
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-186
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-312
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-164
+
+Securitydas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-286
+das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-294

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/APN-Roadmap-Epics.md

@@ -0,0 +1,27 @@
+# APN Produktvision, Roadmaps, EPICS, PI Plannings
+
+Version: 62 | Last modified: 2025-07-25T10:00:56.568+02:00
+Source: confluence page ID 341222189
+
+---
+
+Produktziel:
+
+"APN 2.0 deckt Ende 2026 die notwendigen Funktionen ab" (siehe Roadmap)
+
+LEAN Portfolio-Management:
+
+Im LEAN Portfolio-Management des ITD Boards sind die Epics für die ARTS aufgehangen. 
+
+Hier sind die EPICS von O2C bzw. APN
+
+APN ART-Programm-Kanban-Board:
+Auf unserem ART-Programm-Kanban-Board finden sich die Features & Enabler
+
+APN ART-Programm-Backlog
+
+APN Program Kanban Board - O2C | APN | ART - Agile Board - DB InfraGO ITD Lifecycle Management Tool (deutschebahn.com)
+
+Weiterführende Links:
+
+Confluence Seite vom Lean-Portfolio-Management

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

@@ -0,0 +1,421 @@
+# APN
+
+Version: 60 | Last modified: 2026-03-15T23:37:25.422+01:00
+Source: confluence page ID 175079641
+
+---
+
+Das Produkt:
+
+Infrastruktur-Nutzungsbedingungen (INB 26) ganz:
+
+Infrastrukturnutzungsbedingungen der DB InfraGO AG (INB) 2026 
+
+DoR + DoD auf Value Team Ebene:
+
+Definition of Ready und Definition of Done - O2C | Order2Cash - ariJa Confluence
+
+Zuständigkeiten + Ansprechpartner:
+
+APN interne Stakeholder-Kommunikations-Matrix (Zuständigkeiten + Ansprechpartner) - O2C | Order2Cash - ariJa Confluence
+
+Betriebshandbücher der Kernprozesse:
+
+APN Classic (auf dem Portal unter "Hilfe"): My webMethods: Betriebshandbuecher
+
+Alle aktuellen Betriebshandbücher des Systems APN auf einen Blick zum Downloaden:
+Modul. 1 - Allgemeines
+Modul 2a - Anlagenportal Netz: Netzkarte
+Modul 2b - Anlagenportal Netz: SucheSE
+Modul 3 - Persönlicher Bereich
+Modul 4a - Benutzerverwaltung (extern)
+Modul 4b- Benutzerverwaltung (intern)
+Modul 5 - Kundenmanagement
+Modul 6 - Faktura
+Modul 8 - VOV
+
+APN 2.0 im Sharepoint: APN - Dokumente - Unterlagen zu APN Migration (APN 2.0) - Alle Dokumente
+
+Portalzugänge:
+
+Klassik: My webMethods: Startseite (db.de)
+APN 2.0: APN Anlagenportal Netz (db.de) 
+ 
+
+1{"body":{"text":{"color":"#465671","textAlign":"left","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faTrain","color":"#fff"}},"headline":{"text":{"text":"APN - Anlageportalnetz","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":20},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Mit dem Anlagenportal Netz (APN) ...… werden Serviceeinrichtungen aus Infrastrukturdaten zur Vermarktung aufbereitet, zur Bestellung angeboten, bei Konflikten koordiniert und die Abrechnung vorbereitet. Im Vermarktungsbereich wurde ein Online Shop zur Suche und zur Buchung von Serviceeinrichtungen auf Grundlage der individuellen Bedürfnisse bereitgestellt, in dem Eisenbahnverkehrsunternehmen Gleise und Zusatzausstattungen bestellen können.​
+… werden aus den Infrastrukturdaten des SAP R3 Netz vermarktungsfähige Nutzungsobjekte erzeugt und von den Regionen konfiguriert.​
+… werden jährlich ca. 16.500 Gleise (Abstellung, Zugbildung, Ladegleis, etc.) und 17.000 Zusatzausstattungen (z.B. Wasserfüllständer, Elektranten, Innenreinigungsanlagen, etc.) vermarktet.​
+… wird die Koordinierung und das Entscheidungsverfahren von konfliktbehafteten Anmeldungen durchgeführt.​
+… werden Angebote an den Kunden verschickt und die Verträge erstellt.​
+… werden Abrechnungspositionen zu Verträgen erstellt und zur Rechnungslegung an das Abrechnungscockpit ​
+    (AC) übergeben.
+Parallel arbeitet aktuell ein weiteres Team an einem neueren, modernen und nutzerfreundlicherem APN. Hierbei steht die Technologieumstellung hin zu Angular + CNP und weg von TIBCO und S-AG. 
+Die Vision ist es eine Anwendung  zu entwickeln, die einfach zu benutzen, robust und sicherer sein wird. 
+ 
+
+{"generalSettings":{"tabSpacing":0,"tabWidth":100,"tabHeight":80,"direction":"horizontal"},"activeSettings":{"backgroundColor":{"color":"#0052cc"},"text":{"fontSize":18,"color":"#fff","textAlign":"left","fontWeight":"lighter"}},"inactiveSettings":{"backgroundColor":{"color":"#f4f5f7"},"text":{"fontSize":18,"color":"#5e6c84","textAlign":"left","fontWeight":"lighter"}},"contentSettings":{"backgroundColor":{"color":"#fff"},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","is":"drop-shadow","x":0,"y":0,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":3,"blur":2,"spread":-2}]},"border":{"style":"solid","width":1,"top":false,"bottom":true,"left":true,"right":true,"color":"#0065ff"},"padding":{"top":10,"right":10,"bottom":10,"left":10}},"hoverSettings":{"backgroundColor":{"color":"#dfe1e6"},"text":{"fontSize":18,"color":"#5e6c84","textAlign":"left","fontWeight":"lighter"}}}1
+
+faBookOpenGlossar 
+
+Begriff | Erklärung | 
+Logistikgleise (Vorsystem) | Unter Logistikgleise aus dem VOV verstehen wir, dass das "Logistikgleisanfragen" von technischen Anmeldern sind. | 
+Kombimodul | Produkteinführung: Das Kombimodul ist eine Zusatzausstattung (ZA), die aus einer WC-Entsorgungsanlage hervorgeht. Wird das Kombimodul der regionalen Vermarktung manuell gewählt, so ist dies eine Kombination aus einer WC-Entsorgungsanlage und einem Wasserfuellstaender. Das Kombimodul kann in drei unterschiedlichen Ausprägungen vorkommen: T-System, Schrank, Unterflur | 
+fiddeln / gefiddel | Sachen zusammen suchen; "make it work" | 
+Moini | Grußformel, Betonung auf dem zweiten I
+ | 
+reinwurschteln/hinwurschteln | Ein Werb für eine unprofessionelle Arbeitsweise - etwas machen, etwas umsetzen. Wird bei APN defaultmäßig bei allem verwendet, auch wenn die Arbeiten fachgerecht und professionell ausgeführt wurden/werden.
+ | 
+
+faListAbkürzungen
+
+Abkürzung | Begriff | Weiteres Feld Erklärung? Kategorie? | 
+ABM | Arbeitsbeschaffungsmaßnahme | 
+ | 
+AC | Abrechnungscockpit | 
+ | 
+AIO | Aufbereitete Infrarstrukturobjekte | 
+ | 
+AnDI | Anlagedisponent|innen | 
+ | 
+APN | Anlageportalnetz (Ehemals VMSE) | 
+ | 
+APS | Anlagepreissystem | 
+ | 
+APS Team - | 
+ | 
+ | 
+ART | Agile Release Train | 
+ | 
+AU | Abnahmeumgebung | 
+ | 
+BAE | 
+ | 
+ | 
+BAKO | Baukommunikation (Tool für Baustellenplanung) | 
+ | 
+BAPSI | Bauinformation Anlagenpreissystem-Anlagen und Infrastrukturanschlüsse | 
+ | 
+BBP Neo | Baubetriebsplanung | 
+ | 
+BBZR | Baumaßnahmen und baubetriebliche Zugregelungen | 
+ | 
+BNetzA | Bundesnetzagentur | 
+ | 
+BOA | Verordnung über den Bau und Betrieb von Anschlussbahnen | 
+ | 
+BS / Bst | Betriebsstelle | 
+ | 
+bve | 
+ | 
+ | 
+BW | BusinessWorks (Software von TIBCO mit der die Backendservices in der alten Welt implementiert sind) | 
+ | 
+C&R | Click & Ride | 
+ | 
+CI/CD | Continuous Integration / Continuous Delivery | 
+ | 
+CNP | Cloud Native Plattfrom | 
+ | 
+Da ViT | Datenverarbeitung und Trassenmanagement | 
+ | 
+DaViT | Datenverarbeitung im Trassenmanagement | 
+ | 
+DB FV | Fernverkehr | 
+ | 
+DB-RIL | DB Richtlinie | 
+ | 
+DeBI | Deutsche Bahn Identity | 
+ | 
+DLT | Dead Letter Topic (Kafka Fehlerbehandlung) | 
+ | 
+EB | Eigenbedarf | 
+ | 
+EBA | Eisenbahnbundesamt | 
+ | 
+EBO | Eisenbahn Bau- & Betriebsordnung | 
+ | 
+EBSÜ | Übersichtsschaltpläne für die elektrischen Betriebsstellen | 
+ | 
+EBuLa | Elektronischer Buchfahrplan und Lagsamfahrstellen | 
+ | 
+EMS | Enterprise Messaging Service (Enterprise Implementierung von JMS) | 
+ | 
+ENKO | Energiekorridore | 
+ | 
+EU | Entwicklungsumgebung | 
+ | 
+EV | Entscheidungsverfahren | 
+ | 
+EVU | Eisenbahnverkehrsunternehmen | 
+ | 
+FANSE | Fahrdienstleiter Aufschreibungen ANDI und SEBA | 
+ | 
+FAT | Fachlicher Abnahmetest | 
+ | 
+FBN | Fahrplanbearbeitungsbereiche | 
+ | 
+FDL | Fahrdienstleiter (Aufschreibung) | 
+ | 
+FPLO | Fahrplananordnung | 
+ | 
+FPP | Fahrplanperiode | 
+ | 
+FV-NE | Fahrdienstvorschrift Nichtbundeseigene Eisennahn | 
+ | 
+GeKo | Geschwindigkeitskonzeption | 
+ | 
+GF | Geschäftsfelder | 
+ | 
+GFD-I | Gemeinsame Fahrplandaten Infrarstruktur | 
+ | 
+GFD-Z | Gemeinsame Fahrplandaten Zugdaten | 
+ | 
+GLAD | Gleisanschlussdatenbank | 
+ | 
+GLV | Gelegenheitsverkehr | 
+ | 
+IAK | Invest auf Kundenwunsch | 
+ | 
+IAV | Infrarstruktur Anschlussverträge | 
+ | 
+IAVEN | 
+ | 
+ | 
+IAV DB |  Infrarstruktur Datenbank | 
+ | 
+IAV mit IPS | 
+ | 
+ | 
+IDA | Infrarstrukturdatenaktualisierung | 
+ | 
+INB (früher NBN) | Infrastrukturnutzungsbedingungen | 
+ | 
+IRE |  Innenraumreinigung | 
+ | 
+IO | Infrastrukturobjekt (SAP-Datensatz) | 
+ | 
+IU | Integrationsumgebung | 
+ | 
+JMS | Java Messaging Service | 
+ | 
+KatAna | Kapazitäts- und Analysetool | 
+ | 
+KDV | Kundendatenversorgung (Service)     | 
+ | 
+KV | Koordinierungsverfahren | 
+ | 
+KVDB - Nr. | Kundenvertriebsdatenbank - Nummer? | 
+ | 
+LGA | Logistikgleisanfrage | 
+ | 
+LGK | Langfristige Gebundenen Kapazitäten (dazu gehören LV, MV und IAK) | 
+ | 
+LKD | Logisch kompletter Datensatz | 
+ | 
+LV | Langlaufender Vertrag | 
+ | 
+MV | Mehrjahresvertrag | 
+ | 
+NBN | Nutzungsbedingung Netz der DB Netz AG | 
+ | 
+NBS | Nutzungsbestimmungen | 
+ | 
+NFP | Netzfahrplan | 
+ | 
+Nfpl | Netzfahrplan | 
+ | 
+NO / NOs | Nutzungsobjekt (vermarktbares APN-Objekt) | 
+ | 
+NSS | Normierte Schnittstelle | 
+ | 
+NV | Nichtverfügbarkeit | 
+ | 
+O2C | Order 2 Cash | 
+ | 
+PU | Produktivumgebung | 
+ | 
+RB | Regionalbereich | 
+ | 
+RIS  | Reisendeninformationssystem | 
+ | 
+RUT-K | Rechnerunterstüztes Trassenmanagement Konstruktion | 
+ | 
+SAG | Software AG  (Softwarehersteller von Webmethods, mit der das Frontend von APN implemtiert ist) | 
+ | 
+SAT | System und Abnahmetest | 
+ | 
+SE | Serviceeinheiten | 
+ | 
+SE | Serviceeinrichtung | 
+ | 
+SEAZ | Serviceeinrichtungen-Anreizsystem (Abrechnungspositionen) | 
+ | 
+SEBA | Sichere Ermittlung beim Abstellen auf Trassengleisen | 
+ | 
+SEVEN | 
+ | 
+ | 
+SGV | Schienengüterverkehr | 
+ | 
+Soap UI | Soap User Interface | 
+ | 
+SOS
+ | 
+ | 
+ | 
+SPV
+ | Schienenpersonenverkehr | 
+ | 
+SPFV | Schienenpersonenfernverkehr | 
+ | 
+SPNV | Schienenpersonennahverkehr | 
+ | 
+Spurplan | 
+ | 
+ | 
+SSO | Single-Sign-On | 
+ | 
+SST | Schnittstelle (SAP-Datenlieferung) | 
+ | 
+TabuFa | Tageaktueller Buchfahrplan | 
+ | 
+TAT | Technischer Abnahmetest | 
+ | 
+TBF | Technische Betriebsführung | 
+ | 
+TFZ | Triebfahrzeug | 
+ | 
+TIBCO | The Information Bus Company (Softwarehersteller von BusinessWorks und EMS | 
+ | 
+TP | Technischer Platz | 
+ | 
+TPN | Trassenportal Netz | 
+ | 
+TPS | 
+ | 
+ | 
+Trafo | Transformation | 
+ | 
+TS | Teamserver | 
+ | 
+tVe | technische Verfügbarkeitseinschränkung | 
+ | 
+VMSE | Vermarktung Serviceeinrichtungen | 
+ | 
+VOV | Vorsystem | 
+ | 
+VTS | Verkehrstagesschlüssel | 
+ | 
+VzG | Verzeichnis der örtlich zulässigen Geschwindigkeiten | 
+ | 
+WIP | Work in progress | 
+ | 
+ZA | Zusatzausstattung | 
+ | 
+ZB | Zugangsberechtigte | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+faInfoCircleZusätzliche Quellenhttp://www.bahnseite.de/purespace/Abkuerzungen.html
+https://db-planet.deutschebahn.com/pages/konzeptionen-aim-fuer-dsd/apps/wiki/abkuerzungen/list/view/6c2f7157-c87f-45b8-83d1-2a9a9d8bdb23?currentLanguage=NONE
+
+Bereich APN durchsuchen:

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/10-2-Team-Migration.md

@@ -0,0 +1,29 @@
+# 10.2 Team Migration
+
+Version: 9 | Last modified: 2026-01-29T07:11:53.943+01:00
+Source: confluence page ID 525205609
+
+---
+
+Team Migration ab 2026:
+
+  | Team Migration | Status | 
+1
+ | Markus Fritzsche (BA) 
+ | Extern angestellt | 
+2 | Jonas Spiegel (ScM) | DB Systel | 
+3 | Michael Mats (BA) | DB Systel Team DigiSec | 
+4 | Feyzi Erden (RE)  | DB Systel Team HEROS | 
+5 | Georgios Chatziefstratiou (Dev) | DB Systel Team DAS (ab 2026) | 
+6 | Sebastian Menrath (Dev) | Extern angestellt | 
+7 | Hüseyin Korkut (Dev) | Extern angestellt | 
+8 | Alexandra Thöne (UX) | Extern angestellt | 
+9 | Anais Casanova (Test) | Extern angestellt | 
+10 | Gael Tchatchou (Dev) | Extern angestellt | 
+11 | Khalid Aaliuate (Dev) | DB Systel Team TPT | 
+12 | Mads Kristian Hansen (Dev) | DB Systel Team Tops | 
+13 | N.N. (Dev) | - | 
+14 | Kouassi Sepenou Klousseh (QA) | DB Systel Team A4DB | 
+15 | Kenan Esau (Dev) | Extern angestellt | 
+16 | Michael Haslauer (Dev) | Extern angestellt | 
+17 | Rainer Schuster (Dev) | Extern angestellt |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/2-2-APN-Beteiligte-Teams.md

@@ -0,0 +1,12 @@
+# 2.2 APN Beteiligte Teams
+
+Version: 5 | Last modified: 2026-01-15T14:43:31.872+01:00
+Source: confluence page ID 513446330
+
+---
+
+DB InfraGO ART Order2Cash (O2C)Team NEO
+Team Migration
+Team Fachliche Betriebsführung
+Team Technische Betriebsführung (fällt ab November 2026 weg)
+Diverse Schnittstellenpartner

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Migration-Team.md

@@ -0,0 +1,19 @@
+# APN Migration - Team
+
+Version: 54 | Last modified: 2025-06-04T13:41:14.131+02:00
+Source: confluence page ID 178881227
+
+---
+
+ProduktvisionWir stellen APN auf moderne Technologien um, damit es in Zukunft ohne die Produkte von Tibco und Software AG auskommt.
+Die Anwendung soll einfach zu benutzen, robust und sicher sein. 
+Umgebungen APN 2.0Infrastruktur | Stage | URL | 
+Entwicklung | DEV (TS1) | https://apn-dev.apn-iat.cnp-test.comp.db.de | 
+Feature Abnahme | TEST (TS2, Wartung) | https://apn-wartung.apn-iat.cnp-test.comp.db.de | 
+
+ | Common GUI | https://apn-dev.apn-iat.cnp-test.comp.db.de/apn-gui-common | 
+Integration | IU | https://apn-iu.apn-iat.cnp-test.comp.db.de | 
+Abnahme | AU  | https://apn-au.apn-abn.cnp-test.comp.db.de | 
+Produktion | PU  | https://apn-prod.apn-prod.cnp.comp.db.de | 
+RoadmaptrueRoadmap V2falseautotoptrue16425
+Sprint AblaufSprint Ablauf11069446841343

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Team-Neo-DoR-DoD.md

@@ -0,0 +1,12 @@
+# APN Team Neo DoR + DoD
+
+Version: 3 | Last modified: 2025-12-17T19:11:32.627+01:00
+Source: confluence page ID 528160381
+
+---
+
+Erster Entwurf von Marius - auf Basis diverser DoDs von O2C, anderen Teams und Vorgaben der I.IVI 12 der DB InfraGO 8.2 APN Aktuelle Orgathemen - O2C | Order2Cash - ariJa Confluence
+
+DoR
+
+DoD

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Wartung-Weiterentwicklung-Teams.md

@@ -0,0 +1,8 @@
+# APN Wartung & Weiterentwicklung - Teams
+
+Version: 13 | Last modified: 2023-12-19T15:45:58.776+01:00
+Source: confluence page ID 290164572
+
+---
+
+1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faBolt","color":"#fff"}},"headline":{"text":{"text":"APN Wartung & Weiterentwicklung Roadmap","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Roadmap APN Weiterentwicklung und Wartung.xlsx

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Wartung-Weiterentwicklung.md

@@ -0,0 +1,8 @@
+# APN Wartung & Weiterentwicklung - Teams
+
+Version: 13 | Last modified: 2023-12-19T15:45:58.776+01:00
+Source: confluence page ID 290164572
+
+---
+
+1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faBolt","color":"#fff"}},"headline":{"text":{"text":"APN Wartung & Weiterentwicklung Roadmap","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Roadmap APN Weiterentwicklung und Wartung.xlsx

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Arbeitsweisen-im-Team-Migration.md

@@ -0,0 +1,10 @@
+# Arbeitsweisen im Team Migration
+
+Version: 2 | Last modified: 2026-02-24T09:32:30.725+01:00
+Source: confluence page ID 553944594
+
+---
+
+Allgemeiner Überblick über wie arbeiten wir als Team.
+
+Â

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/ITERATIVES-TESTING-FÃ-R-TEAM-MIGRATION.md

@@ -0,0 +1,88 @@
+# ITERATIVES TESTING FÜR TEAM MIGRATION
+
+Version: 40 | Last modified: 2026-02-03T10:40:59.868+01:00
+Source: confluence page ID 301350453
+
+---
+
+TESTCOVERAGE ZIELBILD
+(Team Migration)
+
+> Präsentiert in der MiKo am 21.2.2025
+
+BAUSTEINE DES QA-IMPLEMENTIERUNGSKONZEPTS
+Präsentiert im PIP 37 (25.6.2025) und PIP 38 (17.9.2025)
+(in Umsetzung seit März 2024 in Team Migration)
+
+AGILES TESTING
+Vorgestellt PIP 34 (11.9.2024)
+
+Wir wollen APN2.0 Workflows abbilden und anhand der Workflows Test Repository aufbauen.
+
+TESTKONZEPT
+Vorgestellt PIP 33 (12.6.2024, extra Folie), siehe Folien PIP 34 als Rückblick 11.9.2024
+
+trueTestingfalseautotoptrue8205
+
+Offene Fragen : 
+X-Ray über 3 Teams = 3 x Jira aktuell, die Testfälle sind aber übergreifend (Vorschlag : eigenes Jira und von dort aus verknüpfen)
+Branching Konzept für die Cypress Tests
+Konzept, wann welche Tests ausgeführt werden
+
+IMPELENTATION STEPS FOR END2END TESTING 
+(gehört zum obigen Schaubild (Implementierungsanleitung), wurde in Einzelevents POs + SCMs vorgestellt)
+
+Pipelines Testing APN Migration 
+e2e Test: 
+- Belegungsplan 
+Voraussetzungen 
+- Ein Projekt in GitLab, für das Sie CI/CD verwenden möchten. 
+- Die Rolle Maintainer oder Owner für das Projekt. 
+Schritte 
+1.Stellen Sie sicher, dass Sie über Runner verfügen, die Ihre Aufträge ausführen können. (Wenn Sie GitLab.com verwenden, können Sie diesen Schritt überspringen. GitLab.com stellt Instanz-Runner für Sie bereit.) 
+2.Erstellen Sie eine Datei .gitlab-ci.yml im Stammverzeichnis Ihres Repositorys. In dieser Datei definieren Sie die CI/CD-Jobs. 
+Stellen Sie sicher, dass Runners verfügbar sind 
+- Gehen Sie zu Einstellungen > CI/CD und erweitern Sie Runners. 
+Wenn Sie keinen Runner haben 
+1.Installieren Sie GitLab Runner auf Ihrem lokalen Rechner. 
+2.Registrieren Sie den Runner für Ihr Projekt. Wählen Sie den Shell-Executor. 
+Erstellen Sie eine .gitlab-ci.yml-Datei 
+1.Wählen Sie in der linken Seitenleiste Code > Repository. 
+2.Wählen Sie oberhalb der Dateiliste den Zweig aus, an den Sie die Datei übergeben möchten. 
+3 Geben Sie als Dateinamen .gitlab-ci.yml ein. 
+ wählen Sie Änderungen festschreiben.
+Anzeigen des Status Ihrer Pipeline und Aufträge 
+1.Gehen Sie zu Build > Pipelines. Es sollte eine Pipeline mit drei Stufen angezeigt werden. 
+2.Zeigen Sie eine visuelle Darstellung Ihrer Pipeline an, indem Sie die Pipeline-ID auswählen. 
+3.Zeigen Sie Details zu einem Auftrag an, indem Sie den Auftragsnamen auswählen. Zum Beispiel: deploy-prod 
+ 
+
+SHORTENING TEST CYCLE 
+Wurde im PI Anfang (März / April) 2024 umgesetzt und in diversen Einzelrunden: Janne, Andrea, Masut, mit allen Testern vorgestellt.
+
+How to handle features once it reaches testing phase:
+Run test cycle for one feature repeatedly until test is sucessfull: test, fix, deliver
+One feature with all its test cycles should be finalized in one sprint
+
+TEST CASES ERSTELLEN UND AUTOMATISIEREN
+TBD
+
+API Testing
+
+> Präsentiert im PIP XX und Präsentiert in der MiKo am 21.2.2025
+
+SIT - System Integration Test (Automation Pipeline)
+> Präsentiert im PIP 38, 17.9.2025
+
+Der Testautomatisierer liefert Code.
+GitLab übernimmt das Bauen, Testen und Paketieren.
+Das fertige Paket landet in der Registry.
+Von dort aus wird es automatisch in die SIT-Umgebung deployt.
+Dort läuft es in Pods und tauscht sich mit allen angebundenen Systemen aus.
+Damit haben wir einen durchgängigen, weitgehend automatisierten Prozess, der sicherstellt, dass Änderungen schnell, reproduzierbar und konsistent in eine Testumgebung gebracht werden.
+
+Regression Testing
+> Präsentiert im PIP 37, 25.6.2025
+
+Manuelles Testing in Sprints
+> Präsentiert im PIP 38, 17.9.2025

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Retrospektiven-Team-Neo.md

@@ -0,0 +1,54 @@
+# Retrospektiven Team Neo
+
+Version: 5 | Last modified: 2026-03-03T08:15:03.294+01:00
+Source: confluence page ID 551029606
+
+---
+
+Themensammlung:
+
+31
+42dbae4d-d569-42c3-856b-4be6687c55a4
+incomplete
+Zusammenarbeit im Team
+
+32
+ae2c4a9a-f548-40a8-b642-99f5eba0f2c2
+incomplete
+Zusammenarbeit mit Team Migration / Zusammenarbeit im ART (Richtung Ende des PI - bei I&A)
+
+33
+6ccfabb7-d393-4aa1-96fe-482b575ff71c
+incomplete
+Retro auf das Retro Vorgehen
+
+34
+d2ce8d56-8ee8-4ce2-8cc4-c2a32fd9b46a
+incomplete
+Retro auf weitere Meetings
+
+35
+e7444ea1-d4d2-47dc-bb1a-cf586be65b2b
+complete
+Retro zum Stories schätzen: wie werden wir besser, was sind unsere Problemfelder
+
+39
+8a1e56be-7a39-4b80-a660-73da7a41c09c
+complete
+Review zu Story-Umfang: sind unsere Stories zu groß, da sie immer nur am Ende des Sprints fertig werden
+
+Wir wollen keine Stories >5 pro Sprint angehen - diese werden kleiner geschnitten.
+Wir wollen konservativer Schätzen
+Wir wollen mehr explizit die Komplexität mit betrachten / einschätzen
+
+36
+1f16aace-2eeb-4633-bfc4-be321a423af0
+incomplete
+Retro zum Story Review: wie bekommen wir das „smoother“ und pro-aktiver hin: Verweildauer „in Review“ weniger
+
+37
+ff5bb4e0-ed39-4fdc-8662-e36d54f13a0e
+incomplete
+
+Learnings aus unseren Retros (werden den Team-Regeln hinzugefügt)Wir benennen einen "Schreiber", sollten wir technisch / fachlich in unseren Meetings diskutieren, um die Erkenntnisse daraus nicht zu verlieren
+Wir validieren Story Points im Review

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Story-Template-Team-OnePiece.md

@@ -0,0 +1,83 @@
+# Story Template - Team OnePiece
+
+Version: 3 | Last modified: 2025-09-05T10:38:01.964+02:00
+Source: confluence page ID 485040169
+
+---
+
+TitelAPN (Komponente): Titel 
+Titel: Was gemacht wird -> ähnlich zu Git-Commits (Imperativ)
+
+AkzeptanzkriterienDie Akzeptanzkriterien sollen einen bestimmten Zustand oder ein bestimmtes Verhalten der Komponente beschrieben. Im idealen Fall ist jedes einzelne AK unabhängig voneinander testbar und erfüllbar.
+Akzeptanzkriterien sollten möglichst in Gherkin-Schreibweise als testbares Szenario beschrieben sein. Die Formulierung sollte immer im positiv geschrieben sein, selbst bei einem Szenario mit negativem Ausgang. Das hat gleich mehrere Vorteile:
+Bessere Verständlichkeit
+Positive Aussagen sind für Fachbereiche und Nicht-Entwickler leichter zu lesen.
+
+Beispiel:
+Negativ: Then the user is not logged in
+
+Positiv: Then the user stays on the login page
+→ Die zweite Variante beschreibt klarer, was tatsächlich passiert.
+
+Eindeutigkeit
+Negative Formulierungen führen oft zu Interpretationsspielraum („nicht eingeloggt“ – heißt das: Fehlermeldung? Zurück zur Loginseite? Einfach nichts passiert?).
+
+Positive Formulierungen beschreiben ein beobachtbares Ergebnis.
+
+Bessere Testautomatisierung
+Tests lassen sich einfacher prüfen, wenn ein klarer Zustand überprüft wird.
+
+Positiv: Then I see an error message "Invalid credentials"
+
+Negativ: Then I do not see the dashboard
+→ Beim negativen Test könnte der Test "bestehen", auch wenn etwas völlig anderes angezeigt wird (z. B. eine leere Seite).
+
+Weniger kognitive Belastung
+Menschen müssen bei Negationen öfter gedanklich „um die Ecke denken“.
+
+Positiv formulierte Szenarien sind intuitiver nachzuvollziehen.
+
+Eine Schablone dafür wäre:
+Scenario: Komponente XYZ macht etwas
+Given ein bestimmter Input 
+Given eine mögliche Bedingung
+When eine bestimmte Aktion oder Situation geschieht
+Then wird ein bestimmtes Verhalten beobachtet
+Then ist eine bestimmtes Ergebnis eingetreten
+
+Es sollte immer mindestens ein Positiv- und ein Negativ-Beispiel vorhanden sein.
+
+DetailbeschreibungZu klärende Fragen:
+Was soll in der Story geschehen?
+Welche Vorbedingung soll erfüllt sein?
+Was ist der Nutzen, den diese Story kreiert?
+
+Fachliche BeschreibungFachliche Einordung der Anforderung in den Business Kontext
+Gerne auch eine grafische Übersicht mit Figma:
+
+Technische InformationenFür die Umsetzung hilfreiche Informationen, Links etc.
+SST-Beschreibung
+
+Beispiel-Datenset
+AusblickGibt es Auswirkungen auf andere Komponenten?
+
+Out-of-ScopeWas soll nicht getan werden?
+
+NFAVerfügbarkeit?
+Umgang mit Daten?
+Monitoring?
+Skalierbarkeit?
+ReminderDefinition of Ready:Vor Refinement von PO/BA's zu klären:* Die USER-Story ist ins Gesamtprojekt eingeordnet ("Als ... möchte ich, dass..., WEIL..."). Motivation wird erklärt und These über Nutzen der Story aufgestellt.
+* Akzeptanzkriterien sind formuliert (wünschenswert: konkretes BDD given/when/then, Example-Mapping)
+* Zusammenstellung verfügbarer fachlicher Dokumentation (verlinkt oder direkt in der Story)
+* Verfügbarkeit der Testdaten ist geklärt
+* Abhängigkeiten zu anderen Teams im Projekt oder extern sind geklärt
+* Story kann nicht fachlich sinnvoll kleiner geschnitten werden
+
+Vor Schätzung einer Story von den Entwicklern zu klären* Identifikation der betroffenen (Software)-Komponenten (intern und extern)
+* Aktueller Zustand der betroffenen Software-Komponenten
+* Testbarkeit ist abgeklärt
+* Notwendige Zugangsdaten/Tools sind bekannt
+* Abhängigkeiten zu anderen Stories oder Teams
+* Verfügbare technische Dokumentation ist bekannt
+* Story kann nicht technisch sinnvoll kleiner geschnitten werden

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Teams-Chat-Teams-KanÃ-le.md

@@ -0,0 +1,28 @@
+# Teams-Chat / Teams-Kanäle
+
+Version: 3 | Last modified: 2024-02-15T11:36:02.611+01:00
+Source: confluence page ID 314182207
+
+---
+
+Wofür benötigen wir einen eigenen Kanal?Für Announcements (keine Diskussion)Wer reported: PM, PO (SCM), SysArch
+Wer hört zu: Alle Teams
+Wer reagiert: Keine Interaktion vorgesehen über diesen Channel. Bei Diskussionsbedarf PM
+
+Für Prod-Issues/Incidents:Wer reported: FB, PO, PM
+Wer hört zu: PO's, SCM!? Fachbereich, Value-Ops'ler
+Wer reagiert: PO's deligieren/verteilen und informieren Issuebezogen über den Stand
+Welche Inhalte werden gepostet;Fehler in Produktion
+Systemausfälle
+Schwerlast
+
+Staging Issues:Wer reported: Tester, Fachbereich, Devs (app, Infrastruktur)
+Wer hört zu: TO BE DISCUSSED
+Wer reagiert: jeweils ein Verantwortlicher(PO?) antwortet auf die initiale Info-Messsage, deligiert und informiert über Stand
+
+APN All Stars:Wer
+.
+.
+Welche Inhalte:
+
+Monitoring Board Serviceübersicht (eigene App)Weiteren Ausbau gestalten und planen

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/deprecated-ask-Team-Neo-APN-Arch-Eigenbedarf-Backend-2-0.md

@@ -0,0 +1,106 @@
+# <deprecated?->ask Team Neo> APN Arch: Eigenbedarf-Backend 2.0
+
+Version: 68 | Last modified: 2025-10-17T15:13:03.693+02:00
+Source: confluence page ID 361137191
+
+---
+
+Diese Seite Beschreibt das Migration des Services eigenbedarf-backend ins APN 2.0
+Die Empfehlung ist das Migration in zwei Iterationen durchzuführen.
+Iteration 1: enthaltet die für die Migration unbedingt notwendige Schritte: Umzug ins Aurora DB im Rahmen eines neues Services eigenbedarf-backend-2.0 und das dazugehörige Frontend Umleitung im Rahmen des eigenbedarf-frontend 2.0
+Iteration 2: kann nur später durchgeführt werden, wenn die im jeweiligen Iteration genannten Voraussetzungen erfüllt sind. Das beinhaltet die Ausbau der Datenquelle VOV und die Umsetzung als neues Feature, die Anlage der Anmeldungen/Verträgen
+Das Migration soll erstmal nur für 1 Stage (ts1/apn_dev) durchgeführt werden, und nach erfolgreichen Test für die andere Umgebungen.
+Iteration 1
+1. DB Umzug: Oracle -> AuroraDie EB-Tabellen sollen aus Oracle ins Aurora DB inklusive Inhalt umgezogen werden.
+Notwendige Tools/Clients einrichten: Anbindung zum Aurora. Die notwendige Schritte befinden sich an der folgende Seite: Howto Einrichtung APN Migration-Services mit Aurora DB - O2C | Order2Cash - ariJa Confluence (deutschebahn.com) (Story-1: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7161)
+Neues Schema anlegen für Eigenbedarf - neue Schema für jede Services (Story-2: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7162)
+2 neue technische Benutzern anlegen: (Story-2)
+Für die Regelbetrieb analog zu Oracle, sowie apn_iu_betrieb
+Für Schema Migration mit erweiterte Rechte, sowie apn_iu_owner
+
+Neue Benutzern im Kubernetes Secrets hinterlegen. Das erfolgt sich im Rahmen des Secret Managements - Setup Secret für jede notwendige Benutzern, wie folgt: (Story-2)
+1. Ein Secret ins lokale Datei "activemqconnection--apn-wartung" herunterladen: kubectl get secret activemqconnection--apn-dev -o yaml > activemqconnection--apn-wartung
+   Beispiel secret yaml files: .\OpenLens\beispiel_secret_yaml_files\activemqconnection--apn-wartung, .\OpenLens\beispiel_secret_yaml_files\auroraconnection--apn-wartung 
+2. Editieren heruntergeladene Date "activemqconnection--apn-wartung"
+3. Neues Secret hochladen: kubectl apply -f activemqconnection--apn-wartung
+   Rückmeldung: secret/activemqconnection--apn-wartung created
+4. Füge das entsprechende secret-claim (zum Beispiel: activemqconnection) zur Datei
+   https://git.tech.rz.db.de/cnp/apn/apn-ops/-/blob/develop/apn-iat/cnp-api-iat-v4/secret-claims.yml?ref_type=heads
+5. Merge ins develop. 
+   secret-claim holt das Secret und schreibt ins AWS Secret Manager (AWS-SM) und fügt Berechtigungen hinzu.
+6. secret-claim wird via ArgoCD geladen.
+   Prüfe die neu hochgeladene secret-claim in ArgoCD (zum Beispiel: https://argocd.cnp.comp.db.de/applications/argocd/apn-iat-v4-claims?view=tree&node=cnp.comp.db.de%2FSecret%2Fapn-iat%2Fauroraconnection--apn-wartung%2F0&resource=)
+   Die Name des secret-claim wird erstellt aus die folgende Attributewerte:
+   apiVersion: cnp.comp.db.de/v1alpha1
+   kind: Secret
+7. Hole die secret claims: kubectl get secret.cnp.comp.db.de
+8. Es muss danach der secret-provider angelegt werden, der auf das AWS-SM secret verweist. (den hash im Namen kann man aus der secret-claim-Ressource ablesen, via kubectl oder OpenLens):
+   Hole das secret claim für Aurora connection: kubectl get secret.cnp.comp.db.de auroraconnection--apn-wartung 
+9. Wenn der Secret-Provider steht und richtig konfiguriert ist, sollte man das Service neu deployen können. Dieser packt dann das secret via secret-provider automatisch aus und mounted es in den zugehörigen Applikations-Pod
+DDL migration via Liquibase (Story-3: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7163)
+Liquibase Module ins EB-Backend integrieren
+Liquibase DDL ins maven Module integrieren
+
+Hinweis: Dieser Ansatz ist schon beim Migration-Services Umgesetzt, wodurch die relevante Logik dementsprechend übernommen werden soll.
+Laden der Daten - Das Ladeprozess soll sich mit Event-getriebene Datensynchronisation, basierend auf das Outbox Pattern (Pattern: Transactional outbox (microservices.io)) erfolgen.
+Team Migration hat schon ähnliche Logik bzgl. der Anmeldungen Implementiert. (Story-4: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7164, Story-5: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7165)
+Da bei allen Eigenbedarf-Änderungen die Tabelle EIGENBEDARF_REVINFO gefüllt wird, für die Oracle Tabelle EIGENBEDARF_REVINFO einen Trigger hinzufügen, der die betroffene (neue/geänderte/gelöschte) Rekord in einer sogenannte Outbox Tabelle schreibt
+Beispiel Trigger, der die Anmeldenummer ins Outbox Tabelle EVENT schreibt: DB/db_skripte/release320700/APN_EDIT_TRIGGER_SYNC_ANMELDUNG.sql · master · apn-eip / src / DatenbankDevelopment · GitLab (Story-4)
+Initial Laden Implementieren. Dazu gibt es 2 Möglichkeiten: (Story-4)Bevorzugt: Logik für das initiale Laden zu Implementieren, die die schon existierende Rekorde zur Outbox Tabelle hinzufügt. Diese Logik soll via eine Rest-Endpunkt zur Verfügung gestellt werden.
+Beispiel: src/test/java/com/dbnetz/apn/event/service/messaging/initialload · develop · apn / common / spring / modules / event-classic-backend · GitLab
+
+Zusätzliche Spalte (zum Beispiel mit der Name "status" und mit dem Wert "updated") zur Tabelle EIGENBEDARF hinzufügen, um das Trigger für alle schon existierende Rekorde zu initiieren. Daher wird der Trigger für alle schon existierende Zeilen gefeuert. Andere Tabelle im Bezug eigenbedarf muss nicht geändert werden, da die alle eine Verknüpfung zum Tabelle EIGENBEDARF haben.
+
+Trigger schreibt die Daten in der Outbox Tabelle (Story-4)
+Das schon existierende Eventing Service event-classic-backend zieht das ganze eigenbedarf Struktur zusammen (dazu muss das Service erweitert werden oder alternativ neue Service erstellt werden) und fügt zu einem Queue hinzu. Klären mit Team Mig. ob die verarbeitete Zeilen in der EVENT Tabelle gelöscht werden können. (Story-5)
+neue Version von eigenbedarf-backend 2.0 mit Aurora DB wird mit Event Topic Abarbeitung erweitert und arbeitet die Queue Elemente ab (Story-5)
+
+Das Ladeprozess muss nur in die hier beschriebene Richtung implementiert werden: Oracle DB → Aurora DB
+Frontend auf eigenbedarf-backend 2.0 umleiten (siehe nächste Punkt 2) (Story-6: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7166, Analyse Story-7: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7167 → Story-8)
+Prüfen ob und wann eigenbedarf-backend 1.0 abgebaut werden kann (Analyse Story-7 → Story-8)
+2. Anpassung der Suchen im Frontend auf die Aurora Datenbankeigenbedarf-frontend-2.0 mit neue Endpunkt Aufrufe Richtung eigenbedarf-backend 2.0 anzulegen (Story-6)
+eigenbedarf-frontend-2.0 testen und Fehlerbehebung, während damit parallel eigenbedarf-frontend weiterhin lauft. Es ist möglich zwischen die 2 Frontends umzuschalten (Story-6)
+Prüfen ob und wann eigenbedarf-frontend 1.0 abgebaut werden kann (Analyse Story-7 → Story-8)
+Iteration 21. Ausbau Zugriff zum externen Datenquellen bzgl. VorsystemAnhängigkeit: das Migration des Services, die die notwendige Daten (Nutzungsobjekte, Steurende Attribute, usw.) liefern (VOV - vorsystem-persistence, usw.).
+Auf Grund dessen, in der Erste Iteration des Migration, diese Logik kann unverändert so bleiben wie es aktuell ist, erweitert mit der Aurora Zugriff. Daher das Service eigenbedarf-backend 2.0 wird zuerst auf drei Datenquellen zugreifen: VOV (SteuerndeAttributen), Oracle, CNP (Aurora)
+Klären, ob die Funktionalität 1-1 so wie es aktuell ist, übernommen werden kann?
+IST StandDas aktuelle eigenbedarf-backend holt direkt die notwendige Daten (Nutzungsobjekte, Steurende Attribute, usw.) aus zwei Oracle Schemata: Oracle VOV (Steuerndeattribute) und Oracle APN.
+SOLL StandIm Gegensatz dazu, in APN 2.0 es wird pro Domäne ein Service laufen, und die notwendige externen Daten sollen anstatt Direkt DB Zugriff bei der Verwendung das Outbox Pattern abgeholt sein.
+VorgehenEs sollen die Services migriert werden, die Daten für das Service eigenbedarf-backend 2.0 produzieren. → Abhängigkeit zum Team Mig.
+Als alternative Lösung die notwendige Services können selber migriert werden.
+Wenn das Migration des betroffenen Services sowie VOV - vorsystem-persistence durch sind, dann wird es möglich sein bei der eigenbedarf-backend 2.0 die Daten zu holen.
+Für die Umsetzung diese zwei Punkte, siehe nächste Punkt "Allgemeine Konzept für Outbox Pattern".
+Allgemeine Konzept für Outbox PatternNeben eigenbedarf, es gibt andere Services, die externen Daten von anderen Services benötigen. Im System existieren also mehrere Services in der Rollen Producer und Consumer. Ziel ist es, die Producer und Empfänger Services zu entkoppeln. Daher in einem Separatem Konzept (Konzept Story-11) eine Systemübergreifende Lösung bzgl. der Verwendung des Outbox Patterns notwendig ist. In diesem Konzept die Umsetzung der folgende Funktionalität soll näher Beschrieben werden:
+Die Services, die Daten für andere Services zur Verfügung stellen, schicken bei allen Änderungen via event-service (z.B. event-classic-backend) die Steuernde Attribute, Nutzungsobjekte in einem Queue/Topic in ActiveMQ. Klären (ggf. ADR erstellen): kann dafür event-classic-backend verwendet werden, oder sollte mehrere event-service existieren?
+Die Services, die Daten von andere Services benötigen, subscriben auf die Topics, woher die benötigte daten kommen, und diese Daten dann verarbeiten.
+Das Service eigenbedarf-backend 2.0 soll auch dieses Vorgehen realisieren, und anschließend die relevante Daten in der Aurora DB ablegen (Story 12).
+2. Anlegen von Anmeldungen/Verträgen aus APN 2.0 ins Altsystem/Tibco (in Abstimmung mit Migration)Abhängigkeit (nur Punkt 3): eigenes Konzept wurde erstellt, wie die TIBCO Logik bzgl. des Anlegens der Anmeldungen/Verträgen in APN 2.0 umgesetzt werden kann.
+TIBCO verfügt schon die Logik bzw. SSt., die Ermöglichen Anmeldungen/Verträgen anzulegen. Diese SSt. ist bei MWS verwendet. MWS verfügt aber keine SSt., via es - bei der eigenbedarf-frontend - möglich ist, diese TIBCO Funktionalität zu nutzen, und Anmeldungen/Verträgen anzulegen. Seit die neuere MWS Versionen es ist auch nicht möglich solche SSt. zu definieren.
+Daher hier es um eine neue Feature handelt.
+VorgehenGenerell gilt, das neue APN 2.0 und das Altsystem zu entkoppeln, daher es Event basierte Ansatz mit der Benutzung Outbox Pattern verwendet werden soll:
+Bzgl. des Anlegens von Anmeldungen/Verträgen, das neue eigenbedarf-frontend 2.0 ruft das Service eigenbedarf-backend 2.0 auf, das dann diesbezüglich ein Event in einem Queue ablegt. MWS abarbeitet die Event und ruft die TIBCO SSt. auf (Story 13)
+Im Altsystem (TIBCO) die neu angelegte Anmeldungen/Verträgen werden ins Event Queue geworfen. APN 2.0 liest anschließend die Elemente aus und legt die Anmeldungen/Verträgen in der Aurora DB an. (Story 14)
+Umsetzung des Anlegens der Anmeldungen/Verträgen (die aktuell nur in TIBCO vorhanden ist) direkt in APN 2.0 → eigenes Konzept ist notwendig. (Konzept Story 15)
+
+truekonzept-eigenbedarf-backend-2.0falseautotoptrue14918
+
+Das APN - Datenmodell für Eigenbedarfe:
+
+Das Fachdatenmodell
+ Versionierung/Bearbeitungshistorie (HibernateEnvers):
+Datenbanktabellen inklusive Versionierung/Bearbeitungshistorie (HibernateEnvers):
+
+Hilfreiche Ressourcen für den KontextSteuernde Attribute publizieren:Screenshots und Beispiele kann man sehen anhand des  
+
+Datenbank-Trigger an einem Beispiel:
+Event-Tables:
+Zur Erklärung:
+Die Spalte Eventtyp ist ein Enumeration (siehe Javacode oder Typ-Tabelle).
+Die Spalte EventValue ist typspezifisch. Allgemein wird hier die Referenz auf das Root-Aggregate des zu übermittelnden Datensatzes referenziert.Für Anmeldungen ist das die Anmeldenummer
+Für Eigenbedarfe müsste das hier entsprechend die Eigenbedarf_ID sein.
+
+Der Eventservice nimmt den Eventvalue, um daraus den Payload der einzustellenden Nachricht zu berechnen (und als JSON zu serialisieren).
+
+Bestehende Topics/Queues/CompositeTopics:https://git.tech.rz.db.de/cnp/cnp-managed/apn-iat/-/blob/master/cnp-api/activemq/config/broker-config.xml?ref_type=heads
+Message Producing-Example:https://git.tech.rz.db.de/apn/common/spring/modules/event-classic-backend/-/blob/develop/src/main/java/com/dbnetz/apn/event/service/messaging/ApnAnmeldungEventPollingService.java?ref_type=heads#L54-58
+Migrations-Fahrplan und Kontext zum zeitlich geplanten Ablauf einer Migrationsstrategie:

bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Ã-bergabeprotokoll-â-Testautomatisierung-QualitÃ-tssicherung-im-APN-Team-NEO.md

@@ -0,0 +1,116 @@
+# Übergabeprotokoll – Testautomatisierung & Qualitätssicherung im APN Team NEO
+
+Version: 8 | Last modified: 2026-01-14T11:49:29.717+01:00
+Source: confluence page ID 533416420
+
+---
+
+Dieses Dokument beschreibt die durchgeführten Test- und Automatisierungsaktivitäten im Rahmen der Projektübergabe.
+Aktuell werden zwei Frontends parallel durch das Testteam betrieben und getestet (alte Welt APN-Classic auf der EIP-Plattform / neue Welt APN 2.0).Aufgaben im Bereich EIP / APN-Classic
+Selenium-Testfälle AllgemeinDas Projekt wurde ursprünglich von einer externen Automatisierungsexpertin aufgebaut. Die Testfälle wurden in Java mit Selenium und Cucumber implementiert.
+Repository URL: https://git.tech.rz.db.de/apn/quality-assurance/apntestsuite
+
+Die Tests werden in 8 Threads parallel ausgeführt. Laufzeit ± 1 Stunde.
+
+Secret-Handling (CNP):Die Secrets des Automatisierungsprojekts werden zur Job-Laufzeit aus dem AWS Secretmanager geladen. Der Zugriff erfolgt je nach Job und Umgebung (Stage).
+TS1: /run/secrets/testautomation--apn-dev/gitlabrunner--testautomation--apn-dev
+TS2: /run/secrets/testautomation--apn-wartung/gitlabrunner--testautomation--apn-wartung
+IU: /run/secrets/testautomation--apn-iu/gitlabrunner--testautomation--apn-iu
+AU: /run/secrets/testautomation--apn-abn/gitlabrunner--testautomation--apn-abn
+
+Testfallmanagement & Reporting (Jira / Xray) Die Testfälle werden in Jira (Xray) gemanaged.
+Insgesamt sind ca. 150 Testfälle in Jira angelegt
+
+Das Xray-Reporting erfolgt automatisiert über die CI/CD-Pipeline
+
+Nach jeder Ausführung wird der Report im folgenden Test-Plan-Ticket hochgeladen: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7935
+
+Fehlgeschlagene Testfälle werden lokal auf dem Rechner nachgetestet. Bei erfolgreichem Retest wird der Status im Test-Plan auf PASS gesetzt.
+Für den Upload der Reports nach Jira wird ein persönlicher API-Token verwendet, der 365 Tage gültig ist. Nach Ablauf muss ein neuer Token erstellt und in CNP deployt werden. Dazu bitte im Team fragen.
+Zusätzlich steht der Cucumber-Report auch in den Job-Artifacts der Pipeline zur Verfügung.
+CI/CD-Konfiguration & TestjobsDie gitlab-ci.yml ist so aufgebaut, dass pro Umgebung ein eigener Stage definiert ist. Ist abgelegt unter: Pipelinetemplates Projekt
+Innerhalb jedes Stages sind die jeweiligen Ausführungsjobs hinterlegt. Ausnahme: TS1, da dort überwiegend vollständige Regressionstests ausgeführt werden.
+Verfügbare Jobs pro Stage:Smoke Tests
+Test der Grundfunktionalitäten
+Geplant über Pipeline Schedule täglich um 07:45 Uhr auf allen Umgebungen
+
+Security Tests
+Aufruf bestimmter webMethods-Seiten mit Anmeldung
+Prüfung, ob angemeldete Benutzer Zugriff haben
+
+Durchstich Tests
+Ausführung der Durchstich-Testfälle
+Ebenfalls täglich um 07:45 Uhr auf allen Umgebungen
+
+Security Tests (Anonym)
+Aufruf bestimmter webMethods-Seiten ohne Anmeldung
+Prüfung, dass nicht angemeldete Benutzer keinen Zugriff haben
+
+Full Regression Tests
+Werden nach jeder erfolgreichen Lieferung ausgeführt
+(z. B. nach Deployment auf AU)
+
+Hotfix Tests
+Nach jedem Hotfix werden folgende Jobs ausgeführt:
+Security
+
+Security Anonymous
+
+Smoke Tests
+
+Hotfix Tests
+
+Selektiv
+Ermöglicht die gezielte Ausführung einzelner Testfälle, die entsprechend getaggt sind
+
+Manuelle Tests & Bug-RetestsDurchführung manueller Tests bei:
+Bugfixes
+
+neuen Feature-Implementierungen
+
+Die Tests werden als Unteraufgabe mit dem Titel „Test“ im Jira-Board zugewiesen
+
+Bei Fragen oder Auffälligkeiten erfolgt eine direkte Abstimmung mit dem jeweiligen Entwickler
+
+Aufgaben im Bereich APN 2.0Testautomation Dashboard: https://arija.jaas.service.deutschebahn.com/secure/Dashboard.jspa?selectPageId=37600Testautomatisierung & ReportingIntegration von Cypress inklusive Xray-Reporting
+
+Cypress-Projekt-Repository:
+https://git.tech.rz.db.de/apn/quality-assurance/apn-cypress
+
+Verwendung von Pipeline-Modulen des PipelineTeams der MoQ-AP
+
+Einbindung und Nutzung von AWS Secret Keys
+
+Xray-Reporting:
+Bei jeder Ausführung wird das Ergebnis in den entsprechenden Jira Test-Plan hochgeladen:  das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-8281
+
+Wichtig: Der Upload der Testergebnisse nach Jira (Xray) erfolgt derzeit nicht automatisch, sondern wird über einen manuell auszulösenden CI/CD-Job (rule: manual) gesteuert.
+Für eine automatische Ausführung muss diese Rule entfernt werden.
+
+Ressourcen für die Testfall ErstellungAnlage der Testfällen in Jira auf Basis von:
+Definierter Workflows: https://arija-confluence.jaas.service.deutschebahn.com/spaces/BES/pages/464844624/Workflows+Logistkgleise+und+GLAD
+
+Bestehender Diagramme und Konzepte: 
+
+Figma: https://www.figma.com/file/qq3zIZ7ZCvGGw0lOZ3n8DV/apn
+4-Augen-Prinzip
+Review der angelegten Testfälle gemeinsam mit TestManager und BusinessAnalyst
+
+Ablage der Testfälle in JiraGLAD: https://arija.jaas.service.deutschebahn.com/secure/XrayTestRepositoryAction!default.jspa?entityKey=O2CAPN&path=APN%202.0%2FGLAD
+
+Logistikgleise: https://arija.jaas.service.deutschebahn.com/secure/XrayTestRepositoryAction!default.jspa?entityKey=O2CAPN&path=APN%202.0%2FLogistikgleise
+
+Manuelle Tests & Bug-RetestsDurchführung manueller Tests bei:
+Bugfixes
+
+neuen Feature-Implementierungen
+
+Zuweisung über Jira-Unteraufgabe mit dem Titel „Test“
+
+Abstimmung bei Fragen direkt mit dem jeweiligen Feature-Entwickler
+
+Hinweis für die ÜbergabeSelenium wird ausschließlich für die Regression der alten Welt genutzt
+
+Cypress ist das strategische Zielsystem für die neue Welt (APN 2.0)
+
+Weitere Erweiterungen der Testabdeckung sollten ausschließlich in Cypress erfolgen für die neue Welt, da EIP zum 12/2026 abgeschaltet wird.Â

bahn/Analyse-O2C-C2S/sources/o2c/O2C-ART-Abrechnung/ART-Abrechnung-Startseite.md

@@ -0,0 +1,14 @@
+# ART Abrechnung
+
+Version: 60 | Last modified: 2026-05-08T09:33:21.018+02:00
+Source: confluence page ID 174031921
+
+---
+
+#000000left2828Demo Titleh1bold
+
+link10#000038400coverflex-startcenter centericon-center14elevate1[{"title":"Projekt AC Trasse","body":"Architekturinformationen zu AC Trasse\n\nZielgruppe: Entwickler, Tester und Business Analysten\n\nAnsprechpartner: Christian C Metzner ","color":"#F8AD11","icon":"faProjectDiagram","image":"https://images.unsplash.com/photo-1540979388789-6cee28a1cdc9?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=934&q=100","imageType":"link","href":"196749815","hrefType":"page","hrefTarget":"_blank"},{"title":"Schulungen AC Trasse","body":"Unterlagen und Schulungsvideos zur Einführung von AC Trasse \n\nZielgruppe: Abrechner und FoM-Team\n\nAnsprechpartner: Wolfgang Raddatz und Mounir Benmeuraiem\n\n ","color":"#0385E7","icon":"faChalkboardTeacher","image":"https://images.unsplash.com/photo-1571254531817-83275b6b6411?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=881&q=100","imageType":"link","href":"174031940","hrefType":"page"},{"title":"Fachliche Betriebsführung","body":"Wichtige Infos, Unterlagen und Prozesse.\n\nZielgruppe: Fachliche Betriebsführung\n\nAnsprechpartner: Jan Achtmann","color":"#E13566","icon":"faPaperPlane","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":"199819445","hrefType":"page"},{"title":"Bedienungsleitfäden AC Trasse","body":"In diesem Bereich sind Handbücher zu verschiedenen IT-Anwendungen hinterlegt. \n\nZielgruppe: Abrechner und FoM-Team\n\nAnsprechpartner: Nadine Augsten ","color":"#02B4C1","icon":"faBookReader","image":"https://images.unsplash.com/photo-1483683804023-6ccdb62f86ef?ixlib=rb-1.2.1&auto=format&fit=crop&w=975&q=100","imageType":"link","href":"174031937","hrefType":"page"},{"title":"Datenauswertungen / - analysen","body":"Informationen zur Ausführung von regelmäßigen Auswertungen der in AC-Trasse verwalteten Abrechnungsdaten per SQL, Qlik-Report oder Export aus der UI","color":"#20493C","icon":"faPaperPlane","image":"https://images.unsplash.com/photo-1476231682828-37e571bc172f?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1567&q=80","imageType":"link","href":"412549931","hrefType":"page","hrefTarget":"_blank"},{"title":"TTTNeo","body":"In diesem Bereich ist die Umsetzung von TTTNeo in AC-Trasse beschrieben","color":"#225568","icon":"faPaperPlane","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":"424284922","hrefType":"page"}]2topaura-accenticon40100%
+
+1{"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#FFC021","width":10,"top":false,"right":false,"bottom":false,"left":true,"style":"solid"},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}},"body":{"text":{"fontSize":14,"color":"#030b16","fontWeight":"normal","textAlign":"left"}},"header":{"icon":{"name":"faExclamationCircle","color":"#FFC021","size":26}},"headline":{"text":{"text":"Änderungswünsche, Fragen, Bemerkungen","color":"#2d2d2d","fontSize":18,"fontWeight":"bold","textAlign":"left"}}}Solltet ihr Fragen oder Anmerkungen zu den einzelnen Seiten haben, hinterlasst bitte einen Kommentar auf der jeweiligen Seite. Die Administratoren werden sich dann dem Thema annehmen und entsprechende Änderungen vornehmen oder antworten. 
+
+1{"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#2888F8","width":10,"top":false,"right":false,"bottom":false,"left":true,"style":"solid"},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}},"body":{"text":{"fontSize":14,"color":"#9d9d9d","fontWeight":"normal","textAlign":"left"}},"header":{"icon":{"name":"faInfoCircle","color":"#2888F8","size":26}},"headline":{"text":{"text":"Noch keinen Zugriff auf AC Trasse?","color":"#2d2d2d","fontSize":18,"fontWeight":"bold","textAlign":"left"}}}flat#FFFFFFfaPaperclipAC Trasse Antrag in DEBI: Eine Anleitung für Besteller und Genehmiger 1regular14medium#0065ffleft_selfpage249536344left

bahn/Analyse-O2C-C2S/sources/o2c/O2C-ART-Abrechnung/Team-Uebersicht-ART-Abrechnung.md

@@ -0,0 +1,243 @@
+# Team Übersicht: ART Abrechnung
+
+Version: 70 | Last modified: 2026-06-12T14:11:56.285+02:00
+Source: confluence page ID 395093930
+
+---
+
+Farblegende | 
+Product Owner | Scrum Master | Business Analyst | Entwickler:in | Tester:in | 
+*externer Mitarbeiter
+
+Siehe auch:
+O2C Value Team - O2C Organigramm – Power BI
+
+ART Abrechnung - O2C Organigramm – Power BI
+
+Team AC - übergreifende Rollen
+
+Product Manager
+ | PM Support
+ | Release Train Engineer
+ | System Architect
+ | Anwendungsmanager
+ | Testmanager
+ | Datenbank Spezialist
+ | FBF
+ | 
+
+Tobias Gehrmann
+ | 
+Patrick Deuter
+ | 
+Cara Czech
+ | 
+Christian C Metzner
+ | 
+Kay König
+ | 
+Andreas Wenske*
+ | 
+Björn Kiesbye*
+ | 
+Jan Achtmann
+ | 
+Sven Milde
+ | 
+Patrick Khajehali
+ | 
+Team AC
+
+ | Coruscant
+ | Rogue One
+ | Taskforce Wookies
+ | Externes SAP Team
+ | 
+
+Product Owner
+ | 
+Jenny J Freitag
+ | 
+Sebastian Göndör
+ | 
+Daniel Bose
+ | 
+Wolfgang Raddatz
+ | 
+
+Scrum Master
+ | 
+Roman Delaveaux 
+ | 
+Ünal Dogdu
+ | 
+Janne Franca Dörge
+ | 
+
+ | 
+
+Dev Team
+
+ | 
+Alexander Harms*
+ | 
+Dirk Di Wagner 
+ | 
+Björn Kiesbye* (tlw.)
+ | 
+Bellinda Willschrey*
+ | 
+
+Alexander A Schwartz*
+ | 
+Fred Flügge* 
+ | 
+Carolin Leicht (tlw.)
+ | 
+Yussri Tarkhani*
+ | 
+
+Andrei Serban*
+ |  Jonas Monecke*
+ | 
+David Viljoen*
+ | 
+
+ | 
+ Andrei-Costel Basescu*
+ | 
+Martin Stieglitz 
+ | 
+
+Eyk Rösner (tlw.)
+ | 
+ | 
+
+Anna Nötzel*
+ | 
+Lukas Schmiedgen* 
+ | 
+Ingo I Olbrich*
+ | 
+ | 
+
+Bhanja Kishore Patel* 
+ | 
+Stefan St Werner*
+ | 
+Lukas Ehl (tlw.) - Qlik
+ | 
+ | 
+
+Catrin Radeck
+ | 
+
+ | 
+
+ | 
+
+ | 
+
+Emanuel Mihai*
+ | 
+
+ | 
+ | 
+
+ | 
+
+Gabriel Mansour* 
+ | 
+
+ | 
+ | 
+ | 
+
+ Jan-Paul Hucka*
+ | 
+
+ | 
+ | 
+ | 
+
+Melih M Özden* 
+ | 
+
+ | 
+ | 
+ | 
+
+Michael Gold
+ | 
+
+ | 
+ | 
+ | 
+
+Mounir Benmeuraiem
+ | 
+
+ | 
+
+ | 
+ | 
+
+Naim Yousifzai* 
+ | 
+
+ | 
+ | 
+ | 
+
+Ning Li* 
+ | 
+
+ | 
+ | 
+ | 
+
+Patrick P Adler*
+ | 
+ | 
+ | 
+ | 
+
+Pia Knape
+ | 
+ | 
+ | 
+ | 
+
+ | 
+Timo Remus*
+ | 
+ | 
+ | 
+ | 
+
+ | 
+Walery Strauch*
+ | 
+ | 
+ | 
+ | 
+
+ | 
+Yannick Hochstuhl*
+ | 
+ | 
+ | 
+ | 
+
+ | 
+Thomas Arand
+ |  
+ |  
+ |  
+ | 
+
+ |  
+ |  
+ |  
+ |  
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-DB-Xtra/Anwendungsfaelle-Domaenenmodell.md

@@ -0,0 +1,12 @@
+# Anwendungsfälle und Domänenmodell
+
+Version: 32 | Last modified: 2026-06-09T11:40:38.630+02:00
+Source: confluence page ID 505160728
+
+---
+
+Bestellberechtigte Kunden (Kunden mit GINV, IAV oder Basisvertrag) können Zusatz- und Nebenleistungen über das Bestellportal DB Xtra bestellen. 
+Voraussetzung ist die vorherige Registrierung im Infraportal. Eine Übersicht der wesentlichen Anwendungsfälle in DB Xtra ist in folgender Abbildung dargestellt:
+trueUse Case Diagram DB Xtrafalse600autotoptrue7285915
+
+Domänenmodell trueDomänendiagramm DB Xtrafalseautotoptrue10565744

bahn/Analyse-O2C-C2S/sources/o2c/O2C-DB-Xtra/DB-Xtra-Startseite.md

@@ -0,0 +1,27 @@
+# DB Xtra
+
+Version: 7 | Last modified: 2026-06-09T10:37:42.484+02:00
+Source: confluence page ID 503112447
+
+---
+
+Ziel und NutzenDB Xtra ist ein Webportal zur Verwaltung von Zusatz- und Nebenleistungen der DB InfraGo AG.
+Zugangsberechtigte haben die Möglichkeit, verschiedene Produkte zu bestellen, zu verwalten und den Status ihrer Bestellungen zu verfolgen.
+Das System ermöglicht eine vollständige Verwaltung des Bestellzyklus von der Anfrage über die Genehmigung bis zur Abrechnung und Kündigung.
+KernfunktionalitätenNeubestellung, Änderungsbestellung, Kündigung von Zusatz- und Nebenleistungen
+Transparente Übersicht aller Zusatz- und Nebenleistungen der DB InfraGo
+Übersicht der Bestellungen aller Kunden zu allen Produkten
+Verwaltung von Kundenfreigaben für Zusatz- und Nebenleistungen
+Erstellung der Leistungspositionen für die automatisierte Abrechnung
+
+Was kann DB Xtra nicht?
+Keine Bereitstellung der Produkte an sich (bspw: man bestellt über DB Xtra das Produkt Statistiken, die Leistung selbst wird dann aber durch den Betrieb bereitgestellt)
+ NutzerkreisZugangsberechtige Kunden (DB intern und extern)
+Produktmanagement
+Fachbereiche 
+Abrechnung
+Kundenbetreuung
+Verantwortlichkeiten & KontaktFachliche Ansprechpartner: 
+IBV 2, Produktmanagement, Katja Heuermann, Christoph Diemerling
+Interne Support-Prozesse: 
+IBV 42, Carolin Leicht, Eyk Rösner, Daniel Stapp

bahn/Analyse-O2C-C2S/sources/o2c/O2C-DB-Xtra/DB-Xtra-Systemkontext.md

@@ -0,0 +1,16 @@
+# DB Xtra Systemkontext
+
+Version: 2 | Last modified: 2026-06-08T14:56:30.549+02:00
+Source: confluence page ID 599956921
+
+---
+
+Der Zugang zu DB Xtra wird von Zugangsberechtigten über das Infraportal bestellt. Bestellbar sind folgende Rollen: 
+Besteller (Auslösen von Bestellungen für die zugewiesene Kundennummer)
+Lesen (Nur Lesezugriff auf vorhandene Bestellungen)
+In DB Xtra können Kunden Neubestellungen, Änderungsbestellungen, Kündigungen, etc. von Zusatz- und Nebenleistungen durchführen.
+Rollen und Rechte werden in der zentralen Nutzer und Rechteverwaltung (NuR) administriert. DB Xtra ist über eine Schnittstelle an das NuR angebunden, 
+so dass die Anzahl an bestellter Lizenzen für ein Produkt mit der Anzahl an verwendeten Lizenzen abgeglichen werden kann.
+Die Abrechnung von Zusatz- und Nebenleistungen erfolgt zentral über DB Xtra per Anbindung an das SAP-System.
+
+trueSystemkontext DB Xtrafalseautotoptrue7914145

bahn/Analyse-O2C-C2S/sources/o2c/O2C-DB-Xtra/Produktsteckbriefe.md

@@ -0,0 +1,134 @@
+# Produktsteckbriefe
+
+Version: 9 | Last modified: 2026-01-26T12:09:25.615+01:00
+Source: confluence page ID 533417001
+
+---
+
+Zweck des DokumentsDieser Produktsteckbrief dient der strukturierten und effizienten Erhebung produktspezifischer Anforderungen für die Integration in DB Xtra.
+Er kann vorab vom Fachbereich ausgefüllt und im Workshop gemeinsam geschärft werden.
+
+Vorlage
+Produktübersicht | 
+Produktname
+ | 
+ | 
+Kurzbeschreibung (1–2 Sätze):
+Was ist das Produkt? 
+Welchen Mehrwert bietet es? | 
+ | 
+Zielgruppe
+Wer nutzt das Produkt? | 
+ | 
+Ansprechpartner für DB Xtra
+Bei fachlichen Rückfragen, Testing/Abnahme, etc.
+ | 
+ | 
+
+Produkt Stammdaten | 
+Bestellbar für GINV
+Ja/Nein
+ | 
+ | 
+Bestellbar für Basisvertrag
+Ja/Nein
+ | 
+ | 
+Mindestlaufzeit
+In Monaten
+ | 
+ | 
+Kündigungsfrist
+In Monaten
+ | 
+ | 
+Kündigung zum
+Monatsende / Quartalsende/ Jahresende
+
+ | 
+ | 
+Kundenfreigabe (Einwilligung) möglich
+Ja/Nein
+
+ | 
+ | 
+Bestellebene 
+Hauptkundennummer / Kundennummer
+ | 
+ | 
+
+Bestellgegenstand | 
+Was genau wird bestellt?
+(z. B. Accounts, Lizenzen, Services, etc.)
+ | 
+ | 
+Besonderheiten
+(Abhängigkeiten, Varianten, Optionen, etc.)
+ | 
+ | 
+
+Bestellprozess & Workflows | 
+Neubestellung
+ | 
+Ablauf/Prozessbeschreibung der (Neu-)Bestellung
+ | 
+ | 
+Genehmigung/Prüfung der Bestellung erforderlich?
+ | 
+ | 
+Änderungsbestellung
+ | 
+Welche Änderungen am bestehenden Vertrag sind möglich?
+ | 
+ | 
+Genehmigung von Änderungen erforderlich?
+ | 
+ | 
+Kündigung
+ | 
+Ablauf/Prozessbeschreibung der Kündigung
+ | 
+ | 
+Sonderfälle / Risiken / Offene Punkte
+ | 
+ | 
+Zustimmung Nutzungsbedingungen bei Bestellung erforderlich? Im PDF-Format verfügbar?
+ | 
+ | 
+
+Bestellmaske - Produktspezifische Felder | 
+Produktspezifische Felder Bestellkopf
+(Feldname, Datentyp, Pflichtfeld, Validierungen, Abhängigkeiten, etc. )
+ | 
+ | 
+Produktspezifische Bestellpositionen
+(Bezeichnung der bestellbaren Positionen, Abhängigkeiten, etc.)
+ | 
+ | 
+
+Abrechnung | 
+Abrechnungszeitpunkt
+ | 
+ | 
+Beschreibung des Abrechnungsworkflows
+ | 
+ | 
+Preismodell
+ | 
+ | 
+Offene Fragen für den Workshop# | Autor | Datum | Frage | 
+
+ | 
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+ |

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

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/architektur/Architektur-Bestellsystem.md

@@ -0,0 +1,10 @@
+# Architektur Bestellsystem
+
+Version: 13 | Last modified: 2025-03-31T11:24:23.275+02:00
+Source: confluence page ID 267687106
+
+---
+
+Architektur-DokumentationpathOS pflegt und aktualisiert seine Architekturbeschreibung im Runbook. Sie ist über den Link für jeden einsehbar. 
+  
+Architektur-RundeIm zweiwöchentlichen Rhythmus findet die Architektur-Runde von pathOS mit Teilnehmern aus jedem Team statt. Die Protokollierung findet sich hier.  Auch im Confluence dokumentiert werden alle betriebliche Themen, die die Architektur betreffen. Diese können unter der Kategorie Betrieb eingesehen werden. Â

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-404.md

@@ -0,0 +1,34 @@
+# Team 404
+
+Version: 38 | Last modified: 2026-02-11T15:05:44.233+01:00
+Source: confluence page ID 267686841
+
+---
+
+Entwickler
+
+ | Entwickler
+
+ | Entwicklerin
+ | 
+Entwickler 
+
+ | Entwickler
+
+ | Entwickler
+
+ | 
+Business Engineer 
+
+ |  Scrum Master/Team Coach
+
+ | Product Owner
+
+ | 
+Entwickler
+ 
+ | 
+
+ |  
+
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-CIB.md

@@ -0,0 +1,34 @@
+# Team CIB
+
+Version: 8 | Last modified: 2025-10-10T12:31:53.349+02:00
+Source: confluence page ID 267686850
+
+---
+
+Product Owner
+
+ | Entwickler
+
+ | Entwickler
+
+ | 
+Scrum Master
+
+ | Entwickler
+
+ | Entwickler
+
+ | 
+Scrum Master
+
+ | Entwickler
+
+ |  Entwickler
+
+ | 
+Business Engineer 
+
+ 
+ |  
+ |  
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-FbF-PathOS.md

@@ -0,0 +1,148 @@
+# Team FbF-PathOS
+
+Version: 68 | Last modified: 2026-06-03T10:40:33.107+02:00
+Source: confluence page ID 362612824
+
+---
+
+Wer sind wir?
+Wir sind die fachliche Betriebsführung (FbF) für den Nachfolger von TPN → PathOS. 
+Wir sind das Bindeglied zwischen all den Teams auf Order to Cash (O2C) Seite, sowie das Bindeglied zur Solution Capacity to Schedule (C2S).
+Außerdem sind wir das Sprachrohr zum Kunden (Portal & CI). 
+IT-Service Manager
+
+ | Change Manager
+(nur noch bis 23.04.2026 im Konzern)
+
+ | IT-Service Managerin(Bis voraussichtlich einschließlich 2027 nicht verfügbar)
+ | 
+Aktuell mit Unterstützung durch:
+
+Zu unseren Aufgaben gehört:
+Themen/Personen | Ben | Martin | Jun | Peter | Thomas | Heiko | Holger | Sven | Harram | 
+Kommunikation nach außen & Innen (Mail, Teams, Tickets, Newsletter)
+ | Ja | vertretend | vertretend | Ja | Ja | Ja | Ja | Ja | vertretend | 
+Wissens-Management (Erstellen von Schulungsinhalten + Handbuch, FAQ, Lernvideos)
+ | Ja
+ | review+ | review+ | review+ | review+ | vertretend | 
+ | Ja
+ | review+ | 
+Planung von Schulungen (extern & intern)
+ | review+
+co-Mod
+ | 
+ | 
+ | 
+ | 
+ | zukünftig Ja | 
+ | Ja
+ | 
+ | 
+Planung und Durchführung von Testsessions (Intern & Extern)
+ | Ja | Ja | Ja | zukünftig Ja | zukünftig Ja | 
+ | 
+ | Ja
+ | 
+ | 
+Zertifizierung / Onboarding von Schnittstellen Partnern (mit Bernd Klebl)
+ | 
+ | 
+ | 
+ | Ja
+ | review+
+ | vertretend
+ | 
+
+ | 
+ | review+
+ | 
+Konzeptionierung von bestehenden und neuen Prozessen
+ | Ja
+ | review+ | review+ | 
+ | zukünftig Ja | 
+ | 
+ | 
+
+ | 
+ | 
+Reporting, SLA's & Dashboards verwalten | Ja
+ | Ja | 
+ | review+ | review+ | review+ | 
+ | 
+ | 
+ | 
+QA & Testmanagement Unterstützung (1-Analysen + Ticket Retests)
+ | Ja
+ | Ja | Ja | zukünftig Ja
+ | zukünftig Ja
+ | zukünftig Ja
+ | 
+
+ | 
+ | 
+
+ | 
+Defect Management (Anlegen und Bearbeiten von Issues im BSSUPPORT Projekt)
+ | Ja
+ | Ja | Ja | zukünftig Ja | zukünftig Ja | zukünftig Ja | 
+
+ | 
+ | vertretend
+ | 
+Userverwaltung im BSSUPPORT Projekt
+ | Ja
+ | vertretend | vertretend | vertretend | vertretend | vertretend | 
+ | 
+ | 
+ | 
+Userverwaltung im DeBi
+ | vertretend
+ | 
+ | 
+ | 
+ | 
+ | vertretend | 
+ | Ja | 
+ | 
+Userverwaltung im NUR
+ | vertretend
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+ | 
+Automatismen bauen und nachhaltig pflegen
+ | Ja, mit Hilfe von Willy Schreiter
+ | 
+ | 
+ | 
+ | vertretend | 
+ | 
+ | 
+ | 
+ | 
+1 - Level Unterstützung 
+ | Ja
+ | 
+ | 
+ | Ja | Ja | Ja | 
+ | Ja | 
+ | 
+2 - Level Unterstützung (Ticket Tiefenanalyse in allen erforderlichen O2C Systemen)
+ | Ja
+ | Ja | Ja | zukünftig Ja | zukünftig Ja (PROD) | zukünftig Ja | 
+ | 
+ | vertretend | 
+
+Hinweis: Kunden Ticket Kommunikation für den Test unserer Schnittstellen Partner läuft derzeit hauptsächlich über das Markttest-Team (siehe).
+
+Legende:
+Ja = Diese Person kümmert sich um diese Aufgaben Schwerpunkte
+Nein = Sie ist kein Ansprechpartner für diese in der Zeile genannten Themen
+vertretend = Diese Person kümmert sich primär um andere Themen und bei Bedarf (Urlaub/Krankheit anderer) unterstützt sie hierbei
+review+ = Nicht federführend bei dieser Person, jedoch hilft sie beim Review und macht auch Ergänzungen.
+zukünftig = Für Kollegen die aktuell neu im onboarding sind aber geplant dieses Thema mal mit unterstützen.

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-ProF.md

@@ -0,0 +1,8 @@
+# Team ProF
+
+Version: 1 | Last modified: 2026-06-12T09:36:02.934+02:00
+Source: confluence page ID 603261100
+
+---
+
+Menschen und Inhalte: tbd

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-STeam.md

@@ -0,0 +1,28 @@
+# Team STeam
+
+Version: 10 | Last modified: 2025-10-10T12:55:00.178+02:00
+Source: confluence page ID 267686816
+
+---
+
+Wir sind das System Team (SAFe) und enablen und supporten die anderen Teams im Arbeiten. Wir sind Ansprechpartner für technische- und infrastrukturelle Themen in PathOS.
+
+Entwickler
+
+ | Entwickler
+
+ | 
+Product Owner
+
+ | Entwickler
+
+ | 
+Entwickler
+
+ | 
+
+ | 
+Scrum Master / Team Coach
+
+ |  
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-SUBP.md

@@ -0,0 +1,21 @@
+# Team SUBP
+
+Version: 2 | Last modified: 2026-01-19T16:09:43.908+01:00
+Source: confluence page ID 498672418
+
+---
+
+Entwickler
+
+ | Entwickler
+
+ | Entwickler
+
+ | 
+Entwickler
+
+ | Entwickler
+
+ | Entwickler
+
+ |

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/Team-Zero.md

@@ -0,0 +1,31 @@
+# Team Zero
+
+Version: 31 | Last modified: 2025-10-10T12:54:20.807+02:00
+Source: confluence page ID 178880687
+
+---
+
+Willkommen bei Zero
+Wer wir sind...Wir sind ein hochmotiviertes Team in dem ART Order2Cash. Wir unterstützen den Aufbau eines kundenfreundlichen Bestellsystems, das den Kunden TAF/TAP-TSI kompatibel bei der Planung aller Zugfahrten weitgehend unterstützt, die Anmeldung dieser ermöglicht sowie Informationen über Anmeldestatus und bestehende Trassenverträge und deren Verwaltung bereithält. Unser agiles Team deckt folgenden Rollen ab:
+
+ Product Owner
+
+ | Entwickler 
+
+ | Entwickler
+ | 
+Scrum Master
+
+ | Entwickler
+
+ | Entwicklerin
+
+ | 
+Business Engineer
+
+ | Tester
+
+ | 
+ | 
+
+In diesem Umfeld sind wir zuhaus ...

bahn/Analyse-O2C-C2S/sources/o2c/O2C-pathOS/teams/pathOS-Operations-Squad.md

@@ -0,0 +1,54 @@
+# pathOS Operations Squad
+
+Version: 34 | Last modified: 2026-03-20T16:26:06.988+01:00
+Source: confluence page ID 525217130
+
+---
+
+Hinweis zur Seitenaktualität: Diese Seite befindet sich derzeit im regelmäßigen Update, sobald wir neue Erkenntnisse zum Operations Squad haben werden wir diese über die bekannten Kanäle in Teams und per Mail mit allen teilen.
+Die hier genutzten Infos wurden am 23.01.2026 zusammengestellt und sollen einen Überblick geben. Alle sind eingeladen, diese Seite mit neuen Infos und Erkenntnissen weiter zu entwickeln.
+
+Die Ansprechpartner im Operations Squad:Squad Guides: 
+ 
+ 
+
+Das Operations Squad in unserem Runbook:Das Operations Squad im pathOS Runbook
+
+Was ist das Squad - ZielsetzungQuerschnittliche Wissensverteilung: Zur Gewährleistung einer Handlungsfähigkeit während der Rufbereitschaft und im produktiven Betrieb muss ein gutes übergreifendes Verständnis für die verschiedenen Komponenten und deren Zusammenspiel in PathOS hergestellt werden.
+Planungsfähigkeit: Parallel zum Betrieb muss die Weiterentwicklung von PathOS voranschreiten. Hier sollen klare Aufgaben und Zuständigkeiten entstehen, um einerseits betriebliche Themen abzudecken und andererseits eine valide Planungsgrundlage für die Weiterentwicklung zu ermöglichen.
+
+Was macht das Squad - Aufgaben:1. Wartung
+◦ Infrastrukturupgrades
+◦ Regelmäßiger Austausch von Zertifikaten und Secrets
+
+2. Monitoring
+◦ Grafana
+◦ Systemstatuscheck
+◦ Reagieren auf Alerts
+◦ Rufbereitschaft
+
+3. Priorisieren und Beheben von Fehlern und Schwachstellen
+◦ Analyse von Bugs und Schwachstellen hinsichtlich ihrer Priorität (Bug Klasse + Bug Priorität)
+◦ Hoch priorisierte Bugs und Schwachstellen werden direkt im Team behoben
+◦ Niedriger priorisierte Bugs und Schwachstellen werden an die jeweiligen Teams zwecks zeitnaher Einplanung weitergegeben
+
+4. Technische Durchführung von Releases und Hotfixes
+◦ Übernahme der technischen Verantwortung für Releases und Hotfixes
+◦ Fachliche Durchführung liegt weiterhin bei den POs
+
+Wie arbeiten wir zusammen - Aspekte der Zusammenarbeit:Wissensverteilung ist wichtiger Aspekt in der täglichen Arbeit
+Es muss aktiv vermieden werden, dass Wissensinseln innerhalb vom Operations Squad fortgeführt werden (z.B. durch Aufgaben-Tandems)
+tbd.
+
+Wie organisieren wir uns - Zusammensetzung des Squad:Das Operations Squad besteht aus je 2 Vertretern pro Team (404, CIB, Zero, SUPB), um alle Themen und Komponenten des Bestellsystems abdecken zu können
+Die Squad-Teilnehmer werden von ihrem Team in das Squad entsendet und rechtzeitig gemeldet
+Bei der Zusammensetzung des Squad muss darauf geachtet werden, dass ausreichen Mitglieder dabei sind, die Rufbereitschaft übernehmen können
+Startpunkt des Squad  in der 07.01.2026 mit  Sprint 2 von PI 39. Ein Kick-Off wird an diesem Tage mit allen Beteiligten durchgeführt
+
+Abb. Grafische Abbildung der Squadzusammenstellung
+Wie organisieren wir uns - Rotation der Teilnehmer im Squad:Die Teammitglieder des Operations Squad werden regelmäßig passend zu den Sprintwechseln rotiert
+Rotation erfolgt pro Ursprungsteamvertreter alle 4 Wochen - zeitversetzt um 2 Wochen zum anderen Vertreter des Ursprungsteams (404, CIB, Zero, SUPB)
+Dadurch Sprint-Planbarkeit in den Ursprungsteams und eine gewisse Stabilität im Operations Squad (2 Wochen stabile Zusammensetzung, danach werden 50% des Teams ausgetauscht)
+
+Abb. Abbildung der Rotation
+Wer macht mit -  Die Mitglieder des Squad nach Sprints: Â