Delivery & Architecture · Entscheidung, Umsetzung, Betrieb
In jeder regulierten Transformation liegt eine Entscheidung zwischen den Beteiligten: welcher Prozess über welche Systeme läuft, welche Schicht welche Entscheidung hält, an welcher Stelle der Nachweis entsteht. Die Strategieberatung endet am Zielbild, der Implementierungspartner beginnt am Werkzeug, die Qualitätssicherung prüft das Ergebnis. Significon übernimmt diese Entscheidung — und bleibt, bis der Prozess läuft und im Betrieb hält.
Das Problem
Keiner der drei handelt falsch. Jeder arbeitet innerhalb seines Auftrags. Die Lücke liegt genau dort, wo die Aufträge aneinanderstoßen — und sie fällt erst auf, wenn der Prozess produktiv ist oder ein Inspektor fragt, wer entschieden hat.
Die Entscheidung in der Mitte ist keine Zwischenaufgabe. Sie bestimmt, ob der Prozess später prüfbar ist, ob ein Werkzeugwechsel eine Systemfrage bleibt und ob eine Änderung im Betrieb bewertet werden kann. Vier Muster folgen daraus, und sie stehen in fast jeder Landschaft, die über Jahre gewachsen ist.
01
Standardsoftware wird von der Funktion her eingeführt: aus den verfügbaren Transaktionen wird ein Systemprozess abgeleitet. Der Geschäftsprozess über Systemgrenzen ist danach nirgends ausführbar modelliert. Er existiert in Präsentationen, in Arbeitsanweisungen und in den Köpfen — nur nicht an der Stelle, an der er ausgeführt und geprüft wird.
02
Integrationsmiddleware übernimmt schleichend Routing und Bedingungen — weil es dort am schnellsten geht. Sie wird damit zum zweiten Akteur im Prozess, dessen Entscheidungen in keinem Modell stehen. Im Audit zählt nicht, ob das Ergebnis stimmt, sondern woraus hervorgeht, wer es entschieden hat.
03
Annex 11 verlangt, dass eine qualitätsrelevante Entscheidung in einem computergestützten System nachvollziehbar bleibt. Das setzt einen spezifizierten Ablauf voraus. Wird der erst nach der Inbetriebnahme betrachtet, muss die Dokumentation dem System hinterherlaufen, statt es zu bestimmen — und jede Lücke zwischen beiden ist eine Frage im nächsten Audit.
04
Das Vorhaben endet mit der Freigabe, die Landschaft läuft weiter. Jede Änderung, jeder Incident, jede Konfigurationsanpassung entscheidet neu darüber, ob der validierte Zustand hält. Wer das Vorhaben verlässt, sobald es produktiv ist, hinterlässt dieselbe Lücke ein zweites Mal — jetzt im Betrieb.
Drei Situationen
Alle drei Situationen treten Jahre nach dem Vorhaben ein. Das ist der Grund, warum die Entscheidung so selten getroffen wird: sie kostet am Anfang Zeit und zahlt sich zu einem Zeitpunkt aus, an dem niemand mehr nach ihr fragt.
Der Inspektor fragt nicht, ob der Freigabeschritt stattgefunden hat, sondern woraus hervorgeht, dass er stattfinden musste. Steht diese Bedingung in einem Skript der Integrationsschicht statt im Prozessmodell, ist die Antwort eine Codelesung: sie dauert Tage, sie braucht die zwei Leute, die das Skript kennen, und sie überzeugt niemanden. Ein ausführbares Modell antwortet mit einem Diagramm und einem Protokoll.
Ein Hersteller stellt ein Modul ab, ein Vertrag läuft aus, zwei Standorte konsolidieren ihre Systeme. Liegt der Ablauf in den Systemen und nicht über ihnen, wird aus dem Werkzeugwechsel ein Prozessvorhaben mit neuer Spezifikation und neuer Validierung. Diese Kosten stehen in keinem Lizenzvergleich — sie entstehen aus einer Architekturentscheidung, die vor Jahren nicht getroffen wurde.
Zwei Jahre nach dem Go-Live soll ein Feld ergänzt werden. Ob das revalidierungspflichtig ist, hängt daran, was dieses Feld im Prozess bewirkt: welche Entscheidung es beeinflusst, welchen Nachweis es trägt. Findet sich die Antwort nicht in einem Modell, wird sie geschätzt. Und geschätzt wird im Zweifel zu weit — der Umfang wächst, weil die Grundlage fehlt, ihn zu begrenzen.
Der Ansatz
Wir treffen sie an zwei Schnitten: dem Prozess über die Domänengrenzen und der Landschaft, in der er läuft — beide weiter unten als eigene Karten ausgeführt. Beide gehören vor die Werkzeugauswahl, weil jedes Werkzeug sonst einen Teil der Entscheidung an sich zieht.
Die Reihenfolge ist nicht verhandelbar: Prozess vor System vor KI. Wird sie getauscht, bestimmt das Werkzeug den Prozess, und der Nachweis muss hinterher konstruiert werden. Das ist keine Geschmacksfrage — es ist der Unterschied zwischen einem Modell, das man im Audit zeigt, und einem Skript, das man im Audit vorliest.
KI tritt in diesen Abläufen nur als gerahmter Schritt auf: festgelegte Eingabemenge, technisch erzwungene menschliche Freigabe, Audit Trail. Der verbindliche Rahmen dafür ist heute Annex 11. Der Annex-22-Entwurf vom 7. Juli 2025 gibt eine Richtung an; eine finale Fassung liegt nicht vor.
Der Ablauf über Systemgrenzen läuft als ausführbares Prozessmodell in einer Orchestrierungsschicht. Sie hält den Lebenszyklus und die Freigabe-Gates. Was dort nicht modelliert ist, ist nicht entschieden — es passiert.
Sie ruft Systeme auf und liefert Ergebnisse zurück. Verzweigungen und Bedingungen gehören eine Schicht höher, wo sie im Modell sichtbar sind. Das ist eine Baupflicht und kein Detail der Umsetzung.
ERP, MES, eQMS, LIMS und das Modell hinter einem KI-Schritt lassen sich ersetzen, ohne den Prozess neu zu denken. Die Zuordnung von Autorität lässt sich nicht ersetzen, ohne den Nachweis zu verlieren.
Das Architekturbild
Das Bild unten ist die Entscheidung, aufgeschrieben. Links steht, welcher Schnitt welche Schicht betrifft; rechts steht die Antwort, um die es geht: welche Schicht entscheidet und welche nicht.
Der KI-Schritt steht nicht neben dem Ablauf, sondern in ihm: mit einer festgelegten Eingabemenge davor und einem Freigabe-Gate dahinter, das nicht übergehbar ist. Das gestrichelte Rechteck um ihn ist der Punkt der Architektur — das Risiko des nicht-deterministischen Schritts wird durch den Rahmen begrenzt, bevor gebaut wird, und nicht durch eine Prüfung danach.
Schnitt 1
Welche Schritte gehören zum Ablauf, wo fällt eine Entscheidung, wer gibt frei, welche Daten wechseln die Systemgrenze. Das Ergebnis ist ein Modell, das ausgeführt werden kann — und an dem sich die Anforderung an jedes beteiligte System ablesen lässt.
E2E-Architektur
Schnitt 2
Welche Schicht hält die Entscheidungshoheit, welche führt Daten, welche ist austauschbar. Das Ergebnis ist eine Zuordnung von Autorität, in der jede Verzweigung an einer Stelle steht, an der sie im Audit gezeigt werden kann.
Enterprise-Architektur
Schnitt 3
Eine KI-Funktion sitzt an einem abgegrenzten Schritt: davor eine festgelegte Eingabemenge, danach eine menschliche Freigabe, die technisch erzwungen ist und nicht vereinbart. Der Schritt trägt den Prozess nicht weiter, solange die Freigabe fehlt.
KI als Schritt, nicht als Schicht
Der Beleg
Die erste Art ist eine Präsentation. Die zweite ist ein laufendes System, in dem das Prinzip entweder trägt oder auffällt. Significon baut das zweite: einen Showcase zur prozesszentrischen Orchestrierung über Systemgrenzen im GxP-Kontext — Camunda 8 als Orchestrierungsschicht mit der Entscheidungshoheit, n8n als Integrationsschicht ohne eigene Entscheidungslogik, KI-Schritte jeweils mit einem Freigabe-Gate dahinter. Wir bauen ihn selbst und intern, und er ist im Bau.
Das ist ein schwächerer Beleg als eine Referenz und ein stärkerer als ein Versprechen: er ist nachprüfbar. Wer ihn sehen will, sieht ihn in dem Stand, in dem er ist, mit den Stellen, an denen noch gearbeitet wird.
Was der Showcase zeigt
Die Lösung
Die Entscheidung allein ändert nichts. Sie zählt, wenn sie durch die Umsetzung getragen und im Betrieb gehalten wird. Deshalb hört unsere Arbeit nicht an der Stelle auf, an der eine Architektur normalerweise übergeben wird.
Entscheidung
Wir treffen die Entscheidung, die zwischen Zielbild und Werkzeug liegt: den Ablauf über die Domänengrenzen und die Zuordnung von Autorität in der Landschaft, in der er läuft. Am Anfang steht dabei ein abgegrenzter Schritt an einem echten Prozess, nicht ein Programm über die gesamte Landschaft.
Umsetzung
Eine Architekturentscheidung, die niemand durch die Umsetzung trägt, bleibt eine Empfehlung. Wir führen das Vorhaben in der regulierten Umgebung: mit den Fachmethoden, die daran hängen, und mit der Übergabe, die am Ende steht.
Betrieb
Mit der Freigabe zum produktiven Betrieb endet das Vorhaben, nicht die Bedingung. Der validierte Zustand hält nur, solange jede Änderung, jeder Incident und jede Konfigurationsanpassung durch einen Prozess läuft, der die GxP-Relevanz erkennt.
Werkzeuge und Rahmenwerke, in denen die Prozesse laufen
Die Werkzeuge sind die, in denen die Prozesse laufen — nicht das Ergebnis. Welches im Einzelfall steht, folgt aus der Landschaft und nicht aus unserem Portfolio. Der ausführliche Stand zum Betrieb steht auf der Seite zu Enterprise Service Management.
Warum Significon
Ein Zielbild, das niemand durch Umsetzung und Betrieb trägt, kostet Zeit und ändert nichts. Wir übernehmen die Architekturentscheidung, führen das Vorhaben, in dem sie umgesetzt wird, und bleiben in dem Betrieb, in dem sie Bestand haben muss.
Wir verkaufen keine Software. Welche Systeme unter der Orchestrierungsschicht stehen, ist eine Frage Ihrer Landschaft und nicht unseres Portfolios. In der Auswahl sitzen wir auf Ihrer Seite des Tisches — und die Frage, die wir stellen, ist nicht, welches Werkzeug mehr kann, sondern welche Entscheidung es an sich zieht.
Was wir über diese Architektur sagen, bauen wir selbst und intern — den Showcase zur Orchestrierung, im Bau und in dem Stand einsehbar, in dem er ist. Und was außerhalb liegt, sagen wir im ersten Gespräch: eine Anfrage, die nicht passt, ist für beide Seiten billiger als ein Angebot, das passend gemacht wurde.
Wer entscheidet bei Ihnen, wie Prozess, System und Compliance zusammenpassen?
Ein Gespräch, in dem wir einen Ablauf einmal durchgehen — kein Angebot.