Kapitel 11 · Fallstudien
Was wir in diesem Kapitel diskutieren: Vier Transformationsvorhaben aus stark regulierten Kontexten (öffentliche Verwaltung, Schienenfahrzeug-Engineering, Luftfahrt-MRO und Biologika-Fertigung) zeigen, wie die OI-Leiter in der Praxis greift: jeweils mit Ausgangslage, Intervention, Messung, Ergebnis und übertragbarem Muster.
Dein Hebel als Entscheider: Du vergleichst vier Phasen — laufende Einführung, Validierung, Anbahnung und strukturierter Proof of Concept — und nimmst die übertragbaren Konsolidierungsmuster mit, nicht eine versprochene Erfolgsquote.
Vier Fälle im Überblick
Vier Branchen, ein Schema: Ausgangslage, Intervention, Messung, Ergebnis, übertragbares Muster.
Die Organisationen bleiben unbenannt; Branchenschnitt, Größenordnung und Regulierungsrahmen reichen, damit Du den Fall auf Deine Situation spiegeln kannst. Der ausgewiesene Projektstatus ist ehrlich: Eine Einführung bleibt Einführung, ein Proof of Concept bleibt Proof of Concept. Die Metriken knüpfen an den Katalog aus Kapitel 10 an; die Reifegrad-Einordnung folgt in Kapitel 12.
| Fall | Branche | Projektstatus | Kernmuster |
|---|---|---|---|
| A | Deutsche Landeshauptstadt · öffentlicher Sektor | Laufende Einführung | Souveränität als nachweisgeführte Architektur |
| B | Globaler Schienenfahrzeughersteller · reguliertes Engineering | Validierung | Prozessvarianten konsolidieren statt nur modellieren |
| C | Führender Luftfahrt-MRO · reguliertes Servicegeschäft | Anbahnung/Validierung | Unentdeckte Doppelbeschreibungen als Audit-Risiko |
| D | Europäischer Biologika-Hersteller · GMP | Strukturierter POC | SOP und gelebte Praxis vor der ERP-Migration klären |
Fall A — Eine deutsche Landeshauptstadt (öffentlicher Sektor)
| Segment | Öffentliche Verwaltung · digitale Souveränität · BSI-Grundschutz-Logik · Vergaberecht |
| Größenordnung | Großstadtverwaltung, fünfstellige Beschäftigtenzahl |
| Region | Deutschland |
| Projektstatus | Laufende Einführung (Plattformaufbau) |
| Zeitraum | Mehrquartalsprojekt, laufend |
Ausgangslage. Eine Landeshauptstadt braucht eine Kollaborations- und Prozessplattform, die in Krisenlagen trägt: verfügbar, nachvollziehbar und unabhängig von außereuropäischen Betreiberentscheidungen. Bestehende Werkzeuge erfüllen entweder die Souveränitäts- oder die Kollaborationsanforderung, selten beides. Problemmuster (OI-Leiter): Resilienz ohne belastbares organisationales Gedächtnis und ohne souveräne Infrastruktur bleibt Absichtserklärung; Memory und Governance fehlen als Fundament. Reifegrad vorher: Stufe 1–2.
Intervention. Aufbau einer souveränen Plattform auf EU-Infrastruktur. Führendes Artefakt ist ein iterativ fortgeschriebenes IT-Sicherheitskonzept: Anforderungskatalog, Maßnahmen und Nachweisführung in Versionsständen. Das Vorhaben läuft in 30–50 Arbeitspaketen über mehrere Zyklen; Sicherheits-, Betriebs- und Fachanforderungen werden als versionierte, prüfbare Wissenseinheiten geführt. Das Projekt wendet damit die Kernidee dieses Buchs auf sich selbst an.
Messung. (Orientierungswerte aus laufenden Vorhaben)
- Erfüllungsgrad Sicherheitsanforderungen (nachweisgeführt): Baseline 62 % → aktuell 84 %
- Zeit von Anforderung bis nachweisbarer Umsetzung: Median 18 Arbeitstage
- Adoption: rund 2.400 aktive Nutzende in 12 Fachbereichen
Ergebnis. Der Erfüllungsgrad der Sicherheitsanforderungen steigt von 62 auf 84 Prozent; die Nachweisführung ist durchgängig versioniert. Qualitativ: »Zum ersten Mal liegt unser Sicherheitskonzept nicht als Ordner im Schrank, sondern als lebender Bestand, den wir jedem Prüfer tagesaktuell zeigen können.« Folgeschritte: Ausweitung auf weitere Fachverfahren; Übergang von Plattform-Resilienz zu organisationaler Resilienz (Kap. 9). Reifegrad nachher: Stufe 3 als Zielkorridor der laufenden Einführung.
Übertragbares Muster. Souveränität ist keine Beschaffungsklausel, sondern eine Architektureigenschaft, die sich in Nachweisführung materialisiert. Öffentliche Organisationen erreichen Resilienz nicht durch Redundanz allein, sondern durch prüfbares, versioniertes Selbstwissen über die eigene Sicherheits- und Verfahrenslage.
Kapitel-Bezug. Kap. 14 (Governance/Audit), Kap. 9 (Resilienz), Kap. 13 (Souveränitätsoptionen).
Fall B — Ein globaler Schienenfahrzeughersteller (reguliertes Engineering)
| Segment | Sicherheitskritisches Engineering · ISO/TS 22163 (Bahn-QM) · normbasierte Entwicklungsprozesse |
| Größenordnung | Fünfstellige Mitarbeiterzahl · Programme und Standorte auf mehreren Kontinenten |
| Region | Global |
| Projektstatus | Validierung |
| Zeitraum | Zwei bis drei Quartale |
Ausgangslage. Die Engineering-Prozesslandschaft ist in einem SPEM-2.0-basierten Prozessmanagement-Werkzeug modelliert: fachlich tief, aber über Programme und Standorte in Varianten zerlaufen. Welche Variante gilt wofür, wissen wenige Schlüsselpersonen; Audits und Programm-Onboarding hängen an ihnen. Problemmuster (OI-Leiter): Memory existiert, Self-Understanding fehlt — die Organisation kann ihre Prozesslandschaft nicht als konsistentes Ganzes befragen. Reifegrad vorher: Stufe 2.
Intervention. Extraktion der SPEM-basierten Prozessarchitektur über eine Adapter-Schnittstelle in eine governte, versionierte Ontologie — als Koexistenz, nicht als Ablösung des Bestandswerkzeugs. Konsolidierung der Programmvarianten mit systematischer Konflikt-Erkennung: Wo widersprechen sich Varianten, wo sind Abweichungen begründet, wo historischer Zufall? Review der Konfliktliste mit den Fachverantwortlichen im Vier-Zonen-Verfahren. Korpus: rund 1.400 Prozesselemente über drei Programmvarianten.
Messung. (Orientierungswerte aus laufenden Vorhaben)
- Konfliktdichte pro 100 Claims zwischen Programmvarianten: 14
- Time-to-Context für Engineering-Onboarding: Median 5 Arbeitstage → unter 1 Arbeitstag im Pilot-Scope
- Harmonisierungsgrad: rund 43 % der Abweichungen fachlich begründet (Zone 3), der Rest redaktionell oder per Fachentscheidung auflösbar
Ergebnis. Time-to-Context im Pilot-Scope sinkt von fünf Arbeitstagen auf unter einen Tag; 14 Konflikte je 100 Claims werden sichtbar, gut die Hälfte davon zuvor unbemerkt. Qualitativ: »Wir konnten unsere Prozesslandschaft zum ersten Mal als Ganzes befragen. Die Konfliktliste war unbequem, aber sie hat eine jahrelange Harmonisierungsdebatte in eine Arbeitsliste verwandelt.« Folgeschritte: Ausweitung auf weitere Programmfamilien; Anbindung der Audit-Nachweisführung. Reifegrad nachher: Stufe 3 im Pilot-Scope.
Übertragbares Muster. Modellreichtum ist nicht Verstehen: Organisationen mit ausgereiften Prozessmodellen scheitern nicht am Dokumentieren, sondern an der Konsolidierung ihrer Varianten. Der Konflikt-Report macht Harmonisierung von einer politischen Debatte zu einer Arbeitsliste; Bestandswerkzeuge bleiben produktiv (Adapter-Muster, Kap. 13).
Kapitel-Bezug. Kap. 7 (Formalkern/Konflikt-Semantik), Kap. 13 (Koexistenz-Architektur), Kap. 4 (Abgrenzung zu reiner Modellierung).
Fall C — Ein führender MRO-Anbieter der Luftfahrt (reguliertes Servicegeschäft)
| Segment | Luftfahrt-Instandhaltung · EASA Part-145-Umfeld · hohe Audit-Taktung |
| Größenordnung | Fünfstellige Mitarbeiterzahl · internationales Standortnetz |
| Region | Europa/global |
| Projektstatus | Anbahnung/Validierung |
| Zeitraum | Ein bis zwei Quartale |
Ausgangslage. Prozess- und Qualitätswissen verteilt sich auf mindestens zwei historisch gewachsene Systeme — ein proprietäres Prozessportal und ein integriertes Qualitätsmanagement-System — plus die Erfahrung langjähriger Prüfer und Mechaniker. Dieselbe Tätigkeit ist mehrfach beschrieben, nicht immer deckungsgleich; im regulierten Umfeld ist jede Abweichung ein potenzielles Audit-Finding. Problemmuster (OI-Leiter): fragmentiertes Memory über konkurrierende Quellsysteme; das Selbstverständnis existiert vor allem in Köpfen. Reifegrad vorher: Stufe 1–2.
Intervention. Multi-Quellen-Konsolidierung der beiden Systemwelten in eine governte Ontologie; Konflikt-Report über deckungsgleiche, abweichende und einseitig dokumentierte Inhalte; Vier-Zonen-Review mit Qualitäts- und Fachbereich; Nachweisfähigkeit (wer hat wann was freigegeben) als Grundanforderung des regulierten Umfelds. Korpus: rund 3.800 Dokumente und 240 Prozessbeschreibungen aus zwei Quellsystemen.
Messung. (Orientierungswerte aus laufenden Vorhaben)
- Audit-Vorbereitungszeit je Prüfungsbereich: Baseline rund 320 Personenstunden → Zielband 120–160
- Konfliktdichte pro 100 Claims zwischen den Quellsystemen: 19, rund 70 % davon zuvor unbemerkt
- Wiederverwendungsquote konsolidierter Inhalte in neuen Verfahren: rund 40 %
Ergebnis. 19 Konflikte je 100 Claims zwischen den Quellsystemen werden aufgedeckt, rund 70 Prozent davon zuvor unbemerkt. Qualitativ: »Die Mehrzahl der Doppelbeschreibungen, die die Konsolidierung gefunden hat, war uns schlicht nicht bekannt. In unserem Umfeld ist genau das der Unterschied zwischen einem Finding und einem ruhigen Audit.« Folgeschritte: Ausweitung auf weitere Standorte; Verknüpfung mit Schulungs- und Qualifikationsnachweisen. Reifegrad nachher: Stufe 2–3 im Validierungs-Scope.
Übertragbares Muster. In regulierten Serviceorganisationen ist der teuerste Widerspruch der unentdeckte: Zwei „gültige“ Beschreibungen derselben Tätigkeit sind ein latentes Audit-Finding und ein Sicherheitsrisiko. Konsolidierung mit expliziter Konflikt-Semantik verwandelt Compliance von Dokumentenpflege in gesteuerte Widerspruchsbeseitigung.
Kapitel-Bezug. Kap. 6/7 (Memory & Formalkern), Kap. 14 (Audit & Vertrauen), Kap. 10 (Metrik Audit-Vorbereitungszeit).
Fall D — Ein europäischer Biologika-Hersteller (GMP-Umfeld)
| Segment | Pharma/Biologika · EU-GMP · validierungspflichtige Prozesse |
| Größenordnung | 1.000–5.000 Mitarbeitende |
| Region | Europa |
| Projektstatus | Strukturierter Proof of Concept |
| Zeitraum | Ein Quartal |
Ausgangslage. Eine anstehende ERP-Transformation (SAP S/4HANA) trifft auf eine SOP-Landschaft, in der dokumentierter und gelebter Prozess auseinanderlaufen können — im GMP-Umfeld ein doppeltes Risiko: für die Migration (falsche Prozessannahmen) und für die Compliance (Abweichung als Finding). Wertstromwissen liegt verteilt in SOPs, Systemen und Erfahrungsträgern. Problemmuster (OI-Leiter): Memory formal vorhanden, aber ohne konsolidiertes Self-Understanding als Migrationsgrundlage. Reifegrad vorher: Stufe 2.
Intervention. Strukturierter Proof of Concept in 10–15 Arbeitspaketen über drei Zyklen: Wertstrom-Dokumentation als konsolidierte Referenz für die Migration; Wissensgraph über Prozesse, Systeme und Verantwortlichkeiten; Konflikt-Erkennung zwischen SOP-Stand und erhobener Praxis; Übergabeformat für das Transformationsprogramm.
Messung. (Orientierungswerte aus laufenden Vorhaben)
- Abdeckungsgrad dokumentierter Wertströme im Migrations-Scope: rund 80 %
- Konfliktdichte SOP ↔ gelebter Prozess pro 100 Claims: 12
- Time-to-Context für Migrationsteams: Median 3 Arbeitstage → unter 4 Stunden im POC-Scope
Ergebnis. Rund 80 Prozent der Wertströme im Migrations-Scope sind konsolidiert dokumentiert; 12 Konflikte je 100 Claims zwischen SOP-Stand und gelebter Praxis werden sichtbar. Qualitativ: »Der Wissensgraph hat uns die Stellen gezeigt, an denen SOP und gelebter Prozess auseinanderlaufen: genau die Stellen, die wir vor der Migration kennen mussten und nicht danach.« Folgeschritte: Ausweitung vom Migrations-Scope auf den laufenden Betrieb — von Projekt-Memory zu Organisations-Memory. Reifegrad nachher: Stufe 2–3 im POC-Scope.
Übertragbares Muster. ERP-Transformationen scheitern selten am Zielsystem und oft am Selbstbild: Migriert wird der dokumentierte Prozess, gelebt wird ein anderer. Ein konsolidiertes, konfliktbewusstes Selbstverständnis vor der Migration ist billiger als jede Korrektur danach — und im GMP-Umfeld zugleich ein Compliance-Beitrag.
Kapitel-Bezug. Kap. 15 (Einführung/die ersten 90 Tage), Kap. 10 (Metriken), Kap. 5 (Leiter-Logik: erst Memory, dann Verstehen, dann Transformation).
💡 Das haben wir diskutiert
Vier Branchenfälle zeigen dieselbe Logik unter unterschiedlichen Regulierungsdrücken: Wissen konsolidieren, Widersprüche sichtbar machen, Nachweise versioniert führen.
Der ehrlich ausgewiesene Projektstatus macht die Fälle vergleichbar — von der laufenden Einführung bis zum fokussierten Proof of Concept.
Die Kennzahlen sind derzeit Orientierungswerte aus laufenden Vorhaben; entscheidend für Dich sind die übertragbaren Muster, nicht die exakten Prozentwerte.
Du kannst jedes Muster direkt auf Dein eigenes Vorhaben spiegeln: Souveränität nachweisen, Varianten harmonisieren, Doppelbeschreibungen auflösen, SOP und Praxis vor der Migration klären.
Als Nächstes ordnet Kapitel 12 diese Entwicklungsphasen in ein vierstufiges Reifegradmodell ein.