Wirkung

Vier Häuser, vier Branchen, dieselbe Lücke.

Öffentliche Verwaltung, Schienenfahrzeugbau, Luftfahrt-Instandhaltung, Biopharmazie — vier regulierte Umgebungen, in denen ein Vorhaben anstand und die Organisation über ihr eigenes Verfahren nicht belastbar auskunftsfähig war. Was hier steht, ist anonymisiert und im Projektstatus benannt: Was ein Proof of Concept ist, heißt hier Proof of Concept.

Woran es hängt.

Niemand beauftragt ein Vorhaben, weil die Dokumentation unvollständig ist. Beauftragt wird, weil etwas ansteht — und erst dann fällt auf, dass die Grundlage dafür nicht trägt.

  • Eine ERP-Migration steht an, und der dokumentierte Prozess weicht vom gelebten ab.
  • Ein Audit steht an, und dieselbe Tätigkeit ist in zwei Systemen unterschiedlich beschrieben.
  • Ein Programm startet an einem weiteren Standort, und niemand kann sagen, welche Prozessvariante dort gilt.
  • Eine Plattform muss in Krisenlagen tragen — nachvollziehbar und unabhängig von außereuropäischen Betreiberentscheidungen.
  • Langjährige Prüfer und Meister gehen in den Ruhestand, und was sie wussten, steht nirgends.

Das Problem ist nicht die fehlende Dokumentation.

In allen vier Fällen war reichlich dokumentiert — Prozessmodelle, SOPs, Qualitätshandbücher, Sicherheitskonzepte. Was fehlte, war die Auskunftsfähigkeit über den eigenen Bestand: welche Fassung gilt, wo widersprechen sich zwei gleichermaßen gültige Beschreibungen, und welche dieser Abweichungen ist begründet und welche historischer Zufall. Diese Frage beantwortet kein Modellierungsstandard.

KonsolidierungMehrere gewachsene Quellsysteme werden zu einem Bild zusammengeführt — ohne dass eines davon abgeschaltet werden muss.
Konflikt-ErkennungWidersprüche werden benannt statt geglättet. Aus einer politischen Debatte über die richtige Fassung wird eine Arbeitsliste.
KoexistenzDas Bestandswerkzeug bleibt produktiv. Eine Ablösung ist ein eigenes Projekt und darf nicht die Voraussetzung sein.
NachweisführungWer hat wann was freigegeben. In regulierten Umgebungen ist das keine Zusatzfunktion, sondern die Bedingung, unter der ein Ergebnis überhaupt zählt.

Vier Ausgangslagen.

Die Reihenfolge je Fall ist bewusst: erst der Druck, unter dem das Vorhaben stand, dann das Vorgehen — und zuletzt das, was sich davon auf andere Häuser übertragen lässt. Welches Werkzeug im Einsatz war, steht nicht dabei; das entscheidet sich an der Zahl der Quellen und Empfänger, nicht an der Branche.

  1. Eine deutsche LandeshauptstadtLaufende Einführung

    Öffentliche Verwaltung · digitale Souveränität · Vergaberecht · Großstadtverwaltung, fünfstellige Beschäftigtenzahl

    Ausgangslage

    Gesucht war eine Kollaborations- und Prozessplattform, die auch in Krisenlagen trägt: verfügbar, nachvollziehbar und unabhängig von Betreiberentscheidungen außerhalb Europas. Die verfügbaren Werkzeuglandschaften erfüllten jeweils die Souveränitäts- oder die Kollaborationsanforderung — keine beide.

    Vorgehen

    Aufbau einer souveränen Plattform auf EU-Infrastruktur, mit dem IT-Sicherheitskonzept als führendem Artefakt statt als Anhang: Anforderungskatalog, Maßnahmen und Nachweise werden als versionierte, prüfbare Einheiten geführt und fortgeschrieben. Strukturiert in 30–50 Arbeitspaketen über mehrere Zyklen.

    Übertragbares Muster

    Souveränität ist keine Beschaffungsklausel, sondern eine Architektureigenschaft — und sie wird erst in der Nachweisführung greifbar. Öffentliche Organisationen erreichen Resilienz nicht durch Redundanz allein, sondern durch prüfbares, versioniertes Selbstwissen über die eigene Sicherheits- und Verfahrenslage.

  2. Ein globaler SchienenfahrzeugherstellerProof of Concept

    Sicherheitskritisches Engineering · ISO/TS 22163 · Fünfstellige Mitarbeiterzahl · Programme auf mehreren Kontinenten

    Ausgangslage

    Die Engineering-Prozesslandschaft war fachlich tief modelliert, aber über Programme und Standorte in Varianten zerlaufen. Welche Variante wofür gilt, wussten wenige Schlüsselpersonen — Audits und der Start neuer Programme hingen an deren Verfügbarkeit.

    Vorgehen

    Die Prozessarchitektur wurde über eine Adapter-Schnittstelle in eine governte, versionierte Ontologie überführt, ausdrücklich als Koexistenz und nicht als Ablösung des Bestandswerkzeugs. Anschließend wurden die Programmvarianten konsolidiert und systematisch auf Konflikte geprüft: Wo widersprechen sich Varianten desselben Prozesses, wo ist die Abweichung begründet, wo ist sie historischer Zufall? Die Konfliktliste ging in ein Review mit den Prozessverantwortlichen.

    Übertragbares Muster

    Modellreichtum ist nicht Verstehen. Organisationen mit ausgereiften Prozessmodellen scheitern nicht am Dokumentieren, sondern an der Konsolidierung ihrer Varianten. Ein Konflikt-Report macht aus der Harmonisierung eine Arbeitsliste statt einer politischen Debatte — und das Bestandswerkzeug bleibt dabei in Betrieb.

  3. Ein führender Anbieter für Wartung, Reparatur und Überholung in der LuftfahrtAnbahnung

    Luftfahrt-Instandhaltung · EASA-Part-145-Umfeld · hohe Audit-Taktung · Fünfstellige Mitarbeiterzahl · internationales Standortnetz

    Ausgangslage

    Prozess- und Qualitätswissen verteilte sich auf zwei historisch gewachsene Systemwelten und zusätzlich auf die Erfahrung langjähriger Prüfer und Mechaniker. Dieselbe Tätigkeit war mehrfach beschrieben, nicht immer deckungsgleich — im regulierten Umfeld ist jede solche Abweichung ein potenzielles Audit-Finding.

    Vorgehen

    Zusammenführung beider Systemwelten in eine governte Ontologie, mit einem Konflikt-Report über deckungsgleiche, abweichende und nur einseitig dokumentierte Inhalte. Review mit Qualitäts- und Fachbereich; die Nachweisfähigkeit — wer hat wann was freigegeben — von Anfang an als Grundanforderung und nicht als spätere Ergänzung.

    Übertragbares Muster

    In regulierten Serviceorganisationen ist der teuerste Widerspruch der unentdeckte: Zwei gleichermaßen gültige Beschreibungen derselben Tätigkeit sind ein latentes Audit-Finding und ein Sicherheitsrisiko zugleich. Konsolidierung mit expliziter Konflikt-Semantik verwandelt Compliance von Dokumentenpflege in gesteuerte Widerspruchsbeseitigung.

  4. Ein europäischer Hersteller biopharmazeutischer ProdukteProof of Concept

    Pharma und Biologika · EU-GMP · validierungspflichtige Prozesse · Vierstellige Mitarbeiterzahl

    Ausgangslage

    Eine anstehende ERP-Transformation traf auf eine SOP-Landschaft, in der dokumentierter und gelebter Prozess auseinanderlaufen können. Im GMP-Umfeld ist das ein doppeltes Risiko: für die Migration, weil auf falschen Prozessannahmen gebaut wird, und für die Compliance, weil jede Abweichung ein Finding ist.

    Vorgehen

    Ein strukturierter Proof of Concept in 10–15 Arbeitspaketen über drei Zyklen: eine Wertstrom-Dokumentation als konsolidierte Referenz für die Migration, ein Wissensgraph über Prozesse, Systeme und Verantwortlichkeiten, Konflikt-Erkennung zwischen SOP-Stand und erhobener Praxis — und ein Übergabeformat, mit dem das Transformationsprogramm weiterarbeiten kann.

    Ü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.

Was hier steht — und was nicht.

Fälle aus regulierten Häusern lassen sich nur unter Auflagen erzählen. Diese Auflagen gelten intern ohnehin; sie hier hinzuschreiben kostet nichts und erspart die Rückfrage, wie belastbar das Gelesene ist.

Branche, Regulierung und Größenordnung stehen da.Der Kunde nicht. Jedes Label oben lässt mindestens fünf plausible Häuser zu — das ist die Bedingung, unter der ein Fall überhaupt öffentlich wird.
Der Projektstatus steht an jeder Kachel.Ein Proof of Concept wird hier nie als Produktivbetrieb erzählt. Derzeit ist keiner der vier Fälle im Produktivbetrieb, und genau das steht dort auch.
Größen stehen als Spanne.Exakte Beschäftigtenzahlen, Korpusgrößen und Zeiträume nicht. Ein exakter Wert ist ein Fingerabdruck.
Normen und offene Standards werden genannt.Interne System-, Projekt- und Programmnamen nicht. Eine Norm beschreibt die Klasse, ein Portalname beschreibt den Kunden.
Das übertragbare Muster steht vollständig da.Zahlen zur Wirkung stehen erst hier, wenn sie erhoben und vom Kunden freigegeben sind. Bis dahin fehlen sie, statt geschätzt zu werden.
Jeder Fall wird vor Veröffentlichung vorgelegt.Auch der anonymisierte. Wer nicht zustimmt, steht hier nicht — auch dann nicht, wenn ihn niemand erkennen würde.

Welches Werkzeug welchen Fall trägt.

Auf dieser Seite steht bewusst kein Produktname. Die vier Ausgangslagen unterscheiden sich nicht in der Branche und nicht in der Firmengröße, sondern in der Zahl der Quellen und der Empfänger — und daran entscheidet sich, welches der Werkzeuge greift.

Wie das gedacht ist

Reden wir.

Zwanzig Minuten, in denen die eigene Ausgangslage geschildert wird — und danach eine Einschätzung, ob sie einem der Muster oben ähnelt oder eben nicht. Auch ein Nein ist ein Ergebnis.