Ein europäischer Energie-Konzern mit 14 rechtlich eigenständigen Töchtergesellschaften musste ein gruppenweites IT-Kontrollrahmenwerk aufbauen — regulatorisch getrieben durch DORA und NIS2, strategisch notwendig wegen einer geplanten externen Prüfung in zwölf Monaten.

Die Ausgangslage: fragmentierte Kontrolllandschaft, keine einheitliche LOD2-Funktion, elf verschiedene Reporting-Formate, kein gemeinsames Verständnis von Kontrolleigentümerschaft. Das Risiko war real — nicht nur regulatorisch, sondern operativ.

• Design eines IT Control Frameworks nach DORA- und NIS2-Anforderungen
• Gruppenweiter Rollout über 14 Töchtergesellschaften mit lokalen CISO-Workshops
• Aufbau der LOD2-Funktion: Struktur, Mandat, Arbeitsweise, Schnittstellen
• Steuerungskomitee redesign — von 6-Schicht-Approval auf schlankes Board-Format
• Monatliches Group-Reporting mit Executive Dashboard (Power BI)
• Audit-Vorbereitung: Evidenzmanagement, Gap-Analyse, Mängelkatalog

Eingebettet im IT Risk & Compliance Team — mit vollem Kontext und direktem Zugang zu den relevanten Stakeholdern. Das Framework wurde von den vorhandenen Kontrollen aufwärts entwickelt, nicht vom Template heruntergebaut.

CISO-Workshops in den Töchtergesellschaften sorgten dafür, dass lokale Kontrolleigentümer das Framework verstehen und mitgestalten konnten. Jede Kontrollformulierung wurde gemeinsam validiert. Verantwortung wurde explizit übertragen, nicht implizit angenommen.

Framework in Produktion — zwölf Monate vor regulatorischem Deadline. LOD2-Funktion operational mit klarem Mandat und monatlichem Rhythmus. Externe Prüfer bestätigten Design-Adequacy ohne wesentliche Befunde. Steuerungskomitee reduziert von 6 auf 2 Eskalationsstufen.

Ein international führendes Unternehmen der Baustoffbranche transformierte seine gesamte ERP-Landschaft auf SAP S/4HANA — gruppenübergreifend, mit 6+ Entwicklungsteams und 95 beteiligten Personen. Eine zentrale Governance-Struktur fehlte: Teams arbeiteten parallel, ohne abgestimmte PI-Kadenz, ohne übergreifendes Dependency-Management, ohne einheitliche Reportingstandards.

Die Herausforderung war nicht die Technologie. Die Herausforderung war Steuerbarkeit: Wie bringt man ein Programm dieser Größe in einen Rhythmus, der Transparenz schafft ohne Overhead zu produzieren?

• Aufbau eines skalierbaren PMO-Frameworks für die gruppenweite SAP S/4HANA-Transformation
• Einführung von SAFe 6.0: ART-Setup, PI-Kadenz, Rollendefinitionen (SM, PO, RTE)
• Operative Verantwortung für PI Planning, System Demos, Scrum of Scrums und Inspect & Adapt
• Jira Plans: crossteam-Mapping von Epics, Features, Abhängigkeiten und Velocity
• Multi-Projekt-Backlog-Management mit WSJF-Priorisierung und Transformation-Leadership-Reporting
• Standardisierung von Artefakten: PI Backlogs, Team Objectives, WSJF-Matrix
• Integration von SAP Activate (Fit-to-Standard) in die agile Governance-Struktur

Start innerhalb des Programms — nicht darüber. Governance wurde nicht von einem Framework heruntergebaut, sondern von den vorhandenen Teams aufwärts entwickelt. Was brauchen die Teams wirklich, um effektiv zu arbeiten? Das war die Leitfrage, nicht: Welche Artefakte sieht SAFe vor?

Jira Plans wurde als zentrales Steuerungstool etabliert — nicht als Bürokratie, sondern als gemeinsame Sicht auf Abhängigkeiten und Lieferfähigkeit. Das Ergebnis: Programm-Leadership konnte fundierte Entscheidungen treffen, ohne in Detaildaten zu versinken.

SAFe-Framework operativ über 6+ Teams. Konsistente Sprint-Kadenz über alle Workstreams hinweg. PI Planning als etabliertes Programmevent mit vollständiger ART-Beteiligung. SAP Activate-Phasen mit agilen Inkrementen synchronisiert — Blueprint- und Build-Phase ohne Informationsbrüche gesteuert.

Ein global agierendes Automobilunternehmen führte SAP S/4HANA Greenfield ein — über mehrere Agile Release Trains, mit Teams auf verschiedenen agilen Reifegraden. Agile war neu in dieser Organisation. Die Herausforderung: SAFe als Operating Model verankern, ohne die Lieferfähigkeit zu gefährden.

Community Scrum Master für zwei SAP-Teams (EDI & Innovation) im Rahmen des übergreifenden ART-Programms — mit direkter Anbindung an das LACE (Lean Agile Center of Excellence) für Governance-Alignment und methodische Qualitätssicherung.

• Community Scrum Master für 2 SAP-Teams (EDI & Innovation) innerhalb eines globalen SAFe-Rollouts
• Aktive Mitgestaltung des SAFe Operating Models: ART-Strukturen, Value Streams, Rollendefinitionen, Event-Kadenz
• Enablement und Coaching von Product Owners und Product Managern zu SAFe-Grundlagen, PI Objectives und WSJF
• Einführung von Agile Hive für SAFe-konforme Governance von Capabilities, Features, Enablern und PI Backlogs
• Integration von Jira und SAP Focused Build für End-to-End-Mapping der Delivery Pipeline über alle SAFe-Ebenen
• Facilitation von SAFe-Zeremonien: PI Planning, System Demo, Scrum of Scrums, Inspect & Adapt
• Agile Reporting: Velocity, Burndown, Defect Escape Rate, Business Value — standardisiert über beide Teams

Eingebettet im ART, nicht darüber. Enge Zusammenarbeit mit dem LACE stellte sicher, dass lokale Teamentscheidungen mit der programmseitigen Governance kompatibel blieben — ohne dass Bürokratie die Teamautonomie einschränkte.

SAFe wurde schrittweise eingeführt: zuerst die Zeremonien, dann die Artefakte, dann das Mindset. Agile Hive und SAP Focused Build wurden so konfiguriert, dass Teams vom ersten Tag produktiv damit arbeiteten.

Konsistente PI-Lieferung über beide Teams. SAFe-Zeremonien in Eigenverantwortung der Teams etabliert. Agile Hive operativ für Capability- und Feature-Tracking auf ART-Ebene. Standardisiertes agiles Reporting als Grundlage für ART-Performance-Tracking und Impediment-Management gegenüber dem Release Train Engineer.