Skip to content

Chapter 11 · Case Studies

What we discuss in this chapter: Four transformation projects from highly regulated contexts (public administration, rolling stock engineering, aviation MRO, and biologics manufacturing) demonstrate how the OI ladder takes hold in practice: each presenting starting situation, intervention, measurement, result, and transferable pattern.

Your leverage as a decision-maker: You compare four phases—ongoing deployment, validation, initiation, and structured proof of concept—and take away transferable consolidation patterns rather than a promised success rate.


Four Cases at a Glance

Four industries, one framework: baseline, intervention, measurement, result, transferable pattern.

The organizations remain anonymous; sector profile, scale, and regulatory environment suffice for you to mirror the case against your own situation. The reported project status is honest: a rollout remains a rollout, a proof of concept remains a proof of concept. Metrics tie directly to the catalog in Chapter 10; maturity classification follows in Chapter 12.

CaseIndustryProject StatusCore Pattern
AGerman state capital · Public sectorOngoing deploymentSovereignty as an audit-verified architecture
BGlobal rolling stock manufacturer · Regulated engineeringValidationConsolidate process variants rather than merely modeling them
CLeading aviation MRO · Regulated service businessInitiation/ValidationUndetected duplicate descriptions as audit risks
DEuropean biologics manufacturer · GMPStructured POCClarify SOPs and actual practice prior to ERP migration

Case A — A German State Capital (Public Sector)

Segment
Scale
Region
Project Status
Timeline

Baseline Situation. A state capital requires a collaboration and process platform that holds up in crisis situations: available, traceable, and independent of non-European operator decisions. Existing tools meet either the sovereignty or collaboration requirement, rarely both. Problem Pattern (OI Ladder): Resilience without reliable organizational memory and sovereign infrastructure remains a declaration of intent; Memory and Governance are missing as foundations. Prior Maturity Level: Stage 1–2.

Intervention. Building a sovereign platform on EU infrastructure. The primary artifact is an iteratively updated IT security concept: requirement catalog, mitigation measures, and evidence tracking maintained across versioned states. The project runs across 30–50 work packages over multiple cycles; security, operational, and functional requirements are managed as versioned, auditable knowledge units. The project thus applies the core concept of this book to itself.

Measurement. (Preliminary benchmarks from ongoing projects)

  • Security requirement compliance rate (verified): Baseline 62% → current 84%
  • Time from requirement to verifiable implementation: Median 18 business days
  • Adoption: Approximately 2,400 active users across 12 departments

Result. Security requirement fulfillment rate increases from 62 to 84 percent; proof management is versioned throughout. Qualitative feedback: "For the first time, our security concept is not a binder on a shelf, but a living asset that we can show to any auditor with daily accuracy." Next steps: Expansion to additional specialized IT procedures; transition from platform resilience to organizational resilience (Chapter 9). Subsequent Maturity Level: Stage 3 target corridor during ongoing deployment.

Transferable Pattern. Sovereignty is not a procurement clause, but an architectural property materialized through auditable proof management. Public organizations do not achieve resilience through redundancy alone, but through auditable, versioned self-knowledge regarding their security and procedural posture.

Chapter Reference. Chapter 14 (Governance/Audit), Chapter 9 (Resilience), Chapter 13 (Sovereignty Options).


Case B — A Global Rolling Stock Manufacturer (Regulated Engineering)

Segment
Scale
Region
Project Status
Timeline

Baseline Situation. The engineering process landscape is modeled in a SPEM 2.0-based process management tool: technically deep, but fragmented into variants across programs and sites. Which variant applies where is known by only a few key experts; audits and program onboarding depend entirely on them. Problem Pattern (OI Ladder): Memory exists, Self-Understanding is missing—the organization cannot query its process landscape as a consistent whole. Prior Maturity Level: Stage 2.

Intervention. Extraction of the SPEM-based process architecture via an adapter interface into a governed, versioned ontology—operating in coexistence, not replacing existing legacy tools. Consolidation of program variants with systematic conflict detection: Where do variants contradict each other, where are deviations justified, where are they historical coincidence? Review of the conflict list with domain leads using the four-zone procedure. Corpus: approximately 1,400 process elements across three program variants.

Measurement. (Preliminary benchmarks from ongoing projects)

  • Conflict Density per 100 Claims between program variants: 14
  • Time-to-Context for engineering onboarding: Median 5 business days → under 1 business day within pilot scope
  • Harmonization rate: Approximately 43% of deviations technically justified (Zone 3), the remainder resolvable editorially or via domain decision

Result. Time-to-Context in the pilot scope drops from five business days to under one day; 14 conflicts per 100 Claims are uncovered, more than half previously unnoticed. Qualitative feedback: "We were able to query our process landscape as a whole for the first time. The conflict list was uncomfortable, but it turned a years-long harmonization debate into an actionable task list." Next steps: Expansion to additional program families; integration of audit proof management. Subsequent Maturity Level: Stage 3 within pilot scope.

Transferable Pattern. Modeling richness is not understanding: organizations with mature process models fail not at documentation, but at consolidating their variants. The conflict report turns harmonization from a political debate into an actionable task list; legacy tools remain productive (adapter pattern, Chapter 13).

Chapter Reference. Chapter 7 (Formal Core/Conflict Semantics), Chapter 13 (Coexistence Architecture), Chapter 4 (Differentiation from pure modeling).


Case C — A Leading Aviation MRO Provider (Regulated Service Business)

Segment
Scale
Region
Project Status
Timeline

Baseline Situation. Process and quality knowledge is scattered across at least two legacy systems—a proprietary process portal and an integrated quality management system—plus the tacit knowledge of experienced inspectors and mechanics. The same procedure is documented multiple times, not always congruently; in a regulated environment, every deviation is a potential audit finding. Problem Pattern (OI Ladder): Fragmented Memory across competing source systems; self-understanding exists primarily in people's heads. Prior Maturity Level: Stage 1–2.

Intervention. Multi-source consolidation of both system landscapes into a governed ontology; conflict report covering identical, conflicting, and unilaterally documented content; four-zone review with quality and functional departments; auditability (who approved what and when) as a core requirement of the regulated environment. Corpus: approximately 3,800 documents and 240 process descriptions from two source systems.

Measurement. (Preliminary benchmarks from ongoing projects)

  • Audit Preparation Time per audit domain: Baseline approx. 320 person-hours → Target range 120–160
  • Conflict Density per 100 Claims between source systems: 19, roughly 70% previously unnoticed
  • Reuse rate of consolidated content in new procedures: Approximately 40%

Result. 19 conflicts per 100 Claims between source systems are uncovered, roughly 70 percent previously unnoticed. Qualitative feedback: "The majority of duplicate descriptions uncovered by consolidation were simply unknown to us. In our environment, that is precisely the difference between an audit finding and a calm audit." Next steps: Expansion to additional locations; linking with training and qualification records. Subsequent Maturity Level: Stage 2–3 within validation scope.

Transferable Pattern. In regulated service organizations, the most expensive contradiction is the undetected one: two "valid" descriptions of the same procedure constitute a latent audit finding and a safety risk. Consolidation with explicit conflict semantics transforms compliance from document maintenance into controlled contradiction elimination.

Chapter Reference. Chapter 6/7 (Memory & Formal Core), Chapter 14 (Audit & Trust), Chapter 10 (Metric Audit Preparation Time).


Case D — A European Biologics Manufacturer (GMP Environment)

Segment
Scale
Region
Project Status
Timeline

Baseline Situation. An upcoming ERP transformation (SAP S/4HANA) encounters an SOP landscape in which documented and actual processes risk diverging—a dual risk in a GMP environment: for migration (false process assumptions) and for compliance (deviation as a finding). Value stream knowledge is distributed across SOPs, systems, and key individuals. Problem Pattern (OI Ladder): Memory formally present, but lacking consolidated Self-Understanding as a foundation for migration. Prior Maturity Level: Stage 2.

Intervention. Structured proof of concept across 10–15 work packages over three cycles: value stream documentation as a consolidated reference for migration; knowledge graph mapping processes, systems, and responsibilities; conflict detection between documented SOP status and actual practice; handover format for the transformation program.

Measurement. (Preliminary benchmarks from ongoing projects)

  • Coverage rate of documented value streams in migration scope: Approx. 80%
  • Conflict Density SOP ↔ actual practice per 100 Claims: 12
  • Time-to-Context for migration teams: Median 3 business days → under 4 hours within POC scope

Result. Approximately 80 percent of value streams in the migration scope are consolidated and documented; 12 conflicts per 100 Claims between SOP status and actual practice are uncovered. Qualitative feedback: "The knowledge graph pinpointed where SOPs and lived processes diverged: exactly the spots we needed to know before migration, not after." Next steps: Expansion from migration scope to ongoing operations—transitioning from project memory to organizational memory. Subsequent Maturity Level: Stage 2–3 within POC scope.

Transferable Pattern. ERP transformations rarely fail due to the target system, but frequently due to self-image: what gets migrated is the documented process, whereas what gets executed is different. A consolidated, conflict-aware self-understanding before migration is cheaper than any correction afterwards—and serves as an immediate compliance contribution in a GMP environment.

Chapter Reference. Chapter 15 (Deployment/First 90 Days), Chapter 10 (Metrics), Chapter 5 (Ladder Logic: Memory first, then Understanding, then Transformation).

💡 What We Discussed

Four industry cases demonstrate the same logic under varying regulatory pressures: consolidate knowledge, surface contradictions, and maintain versioned proof.

Transparent reporting of project status makes the cases comparable—from ongoing rollouts to focused proofs of concept.

Key metrics currently serve as preliminary benchmarks from ongoing projects; what matters most for you are the transferable patterns, not the exact percentages.

You can mirror each pattern directly against your own initiative: prove sovereignty, harmonize variants, resolve duplicate descriptions, and clarify SOPs vs. practice before migration.

Next, Chapter 12 categorizes these developmental stages into a four-stage maturity model.