Impact

Four organizations, four sectors, the same gap.

Public administration, rail vehicle manufacturing, aviation maintenance, biopharmaceuticals — four regulated environments in which an undertaking was due and the organization could not give a dependable account of its own procedures. What stands here is anonymized and named at its project status: what is a proof of concept is called a proof of concept.

Where it gets stuck.

Nobody commissions an undertaking because the documentation is incomplete. It is commissioned because something is due — and only then does it emerge that the basis for it does not hold.

  • An ERP migration is due, and the documented process differs from the one actually run.
  • An audit is due, and the same activity is described differently in two systems.
  • A programme starts at another site, and nobody can say which process variant applies there.
  • A platform has to hold up in a crisis — traceably, and independently of operator decisions taken outside Europe.
  • Long-serving inspectors and foremen retire, and what they knew is written down nowhere.

The problem is not missing documentation.

In all four cases there was documentation in abundance — process models, SOPs, quality manuals, security concepts. What was missing was the ability to give an account of one's own holdings: which version applies, where two equally valid descriptions contradict each other, and which of those deviations is justified and which is a historical accident. No modeling standard answers that question.

ConsolidationSeveral source systems grown over time are brought together into one picture — without any of them having to be switched off.
Conflict detectionContradictions are named rather than smoothed over. A political debate about the right version becomes a work list.
CoexistenceThe incumbent tool stays in production. Replacing it is a project of its own and must not be the precondition.
EvidenceWho approved what, and when. In regulated environments that is not an added feature but the condition under which a result counts at all.

Four starting positions.

The order within each case is deliberate: first the pressure the undertaking stood under, then the approach — and last what of it transfers to other organizations. Which tool was in use is not stated; that is decided by the number of sources and recipients, not by the sector.

  1. A German state capitalRollout under way

    Public administration · digital sovereignty · procurement law · Large city administration, five-figure headcount

    Starting position

    What was sought was a collaboration and process platform that would hold up in a crisis as well: available, traceable and independent of operator decisions outside Europe. The available tool landscapes each met either the sovereignty requirement or the collaboration requirement — none met both.

    Approach

    Building a sovereign platform on EU infrastructure, with the IT security concept as the leading artefact rather than an appendix: requirement catalogue, measures and evidence are carried and maintained as versioned, auditable units. Structured into 30–50 work packages across several cycles.

    Transferable pattern

    Sovereignty is not a procurement clause but a property of the architecture — and it only becomes tangible in the evidence. Public organizations reach resilience not through redundancy alone, but through auditable, versioned self-knowledge of their own security and procedural position.

  2. A global rail vehicle manufacturerProof of concept

    Safety-critical engineering · ISO/TS 22163 · Five-figure headcount · programmes on several continents

    Starting position

    The engineering process landscape was modeled in great technical depth, but had diverged into variants across programmes and sites. Which variant applied to what was known to a few key people — audits and the start of new programmes hung on their availability.

    Approach

    The process architecture was transferred through an adapter interface into a governed, versioned ontology, expressly as coexistence and not as a replacement of the incumbent tool. The programme variants were then consolidated and checked systematically for conflicts: where do variants of the same process contradict each other, where is the deviation justified, where is it a historical accident? The conflict list went into a review with the process owners.

    Transferable pattern

    Richness of models is not understanding. Organizations with mature process models do not fail at documenting, but at consolidating their variants. A conflict report turns harmonization into a work list instead of a political debate — and the incumbent tool stays in operation throughout.

  3. A leading provider of maintenance, repair and overhaul in aviationInitial talks

    Aviation maintenance · EASA Part-145 environment · high audit frequency · Five-figure headcount · international network of sites

    Starting position

    Process and quality knowledge was spread across two system worlds grown over time, and on top of that across the experience of long-serving inspectors and mechanics. The same activity was described more than once, not always congruently — in a regulated environment every such deviation is a potential audit finding.

    Approach

    Bringing both system worlds together into a governed ontology, with a conflict report covering congruent, deviating and one-sidedly documented content. Review with the quality and specialist departments; the ability to evidence — who approved what, and when — as a base requirement from the outset rather than a later addition.

    Transferable pattern

    In regulated service organizations the most expensive contradiction is the undetected one: two equally valid descriptions of the same activity are a latent audit finding and a safety risk at once. Consolidation with explicit conflict semantics turns compliance from document upkeep into managed removal of contradictions.

  4. A European manufacturer of biopharmaceutical productsProof of concept

    Pharma and biologics · EU-GMP · processes requiring validation · Four-figure headcount

    Starting position

    An impending ERP transformation met an SOP landscape in which the documented and the lived process can drift apart. In a GMP environment that is a double risk: for the migration, because it builds on wrong process assumptions, and for compliance, because every deviation is a finding.

    Approach

    A structured proof of concept in 10–15 work packages across three cycles: a value stream documentation as a consolidated reference for the migration, a knowledge graph covering processes, systems and responsibilities, conflict detection between the state of the SOPs and the practice as surveyed — and a handover format the transformation programme can carry on with.

    Transferable pattern

    ERP transformations rarely fail at the target system and often at the self-image: what gets migrated is the documented process, what gets lived is a different one. A consolidated, conflict-aware self-understanding before the migration is cheaper than any correction afterwards — and in a GMP environment it is a contribution to compliance at the same time.

What stands here — and what does not.

Cases from regulated organizations can only be told under conditions. Those conditions apply internally in any case; writing them down here costs nothing and saves the question of how dependable any of this is.

Sector, regulation and order of magnitude are stated.The customer is not. Every label above admits at least five plausible organizations — that is the condition under which a case becomes public at all.
The project status stands on every card.A proof of concept is never told here as production use. At present none of the four cases is in production, and that is exactly what it says.
Sizes are given as ranges.Exact headcounts, corpus sizes and periods are not. An exact figure is a fingerprint.
Norms and open standards are named.Internal system, project and programme names are not. A norm describes the class, a portal name describes the customer.
The transferable pattern is stated in full.Figures on the effect appear here only once they have been surveyed and released by the customer. Until then they are absent rather than estimated.
Every case is submitted before publication.The anonymized one too. Anyone who does not agree does not appear here — not even where nobody would recognize them.

Which tool carries which case.

There is deliberately no product name on this page. The four starting positions differ neither in sector nor in company size, but in the number of sources and recipients — and that is what decides which of the tools applies.

How this is meant

Let us talk.

Twenty minutes in which the starting position gets described — and then an assessment of whether it resembles one of the patterns above or not. A no is a result too.