Das folgende sind lose Überlegungen über eine moderne BPM Architektur im Umfeld von KI und großen Sprachmodellen – LLMs. Welche Auswirkungen hat künstliche Intelligenz auf klassische BPM Systeme und wie kann eine moderne BPM Architektur in Unternehmen in Zukunft aussehen.
Klassische Unternehmensanwendungen sind Modelle der Realität. Wir bilden Kunden, Verträge, Abläufe, Prozesse als Daten und Operationen darauf ab. Dies gilt für BPM Anwendungen ebenso wie für ERP Systeme. Der gesamte Stack einer Unternehmensanwendung — von der Datenbank über das Domänenobjekt bis hin zu einem BPMN-Diagramm — dient dazu, die Realität in eine maschinenlesbare Form zu bringen, damit deterministische Maschinen darauf operieren können.
KI-native Software hat einen starken Einfluss auf diese klassiche Sicht der IT. Und evtl. sollte man vielleicht aufhören, die Realität zu modellieren, und stattdessen anfangen, in ihr zu navigieren. Das ist eine fundamentale Verschiebung, weil sie das primäre Artefakt von „Schema“ zu „Kontext“ verlagert.
Vier Thesen, wie KI Unternehmensanwendungen verändert
1. Von Prozess zu Intention: BPMN modelliert typischer Weise das „Wie“. Eine KI-native Architektur sollte jedoch primär das „Was“ und die „Constraints“ modellieren. Die Ausführung wird emergent. Ein Auftrag wird nicht mehr durch eine Prozessdefinition geführt, sondern durch ein Ziel das durch Tools und Compliance-Grenzen bestimmt wird. Der Pfad entsteht zur Laufzeit. Dieses Prinzip stellt das klassische BPM-Denken auf den Kopf — interessanterweise jedoch nicht den Kern davon: Auditability wird retrospektiv statt präskriptiv.
2. Von Schema zu semantischem Zustand: Eine Datenbank zwingt uns, im Voraus zu wissen, was wichtig wird. Sprache hingegen ist schemafrei — und LLMs operieren nativ darauf. Was wäre, wenn der Geschäftszustand primär als sich entwickelnde Erzählung existierte (multimodal, episodisch), aus der strukturierte Daten abgeleitet werden, wenn man sie braucht — statt umgekehrt? Retrieval-Augmented Generation (RAG) ist bereits ein Versuch mit Hilfe von KI in diese Richtung zu denken. Aber meistens wird dies nur als zusätzlicher Search-Layer behandelt, weniger als primärer Speicher.
3. Von Anwendung zu Fähigkeit: Das Konzept „Anwendung“ mit Bildschirmen, Menüs und Modulen ist ein Artefakt menschlicher Bedienung. Wenn die Schnittstelle zwischen Mensch und System Sprache wird — und zwischen System und System ebenfalls — dann lösen sich Anwendungsgrenzen auf. Was bleibt, sind Capabilities (Werkzeuge), Kontext (Memory) und Agenten (Reasoner). Eine BPMN-Engine reduziert sich hier von einer „Plattform“ auf eine Capability unter vielen.
4. Determinismus als Insel statt als Ozean: Heute ist alles deterministisch außer den paar KI-Inseln mit denen gerade versucht wird neue Möglichkeiten zu erschaffen. Künftig könnte es umgekehrt sein: Das System reasoned probabilistisch, aber ruft an kritischen Punkten deterministische Inseln auf — für Compliance, Buchung, regulatorische Schritte. BPMN könnte genau dort überleben, wo Determinismus gefordert ist.
Was bedeutet das für klasische BPM Systeme?
Wenn man diese 4 Thesen als Grundlage für eine neue Archiektur versteht, dann führt das schlichte ‚einweben‘ von KI in BPMN-Prozesse lediglich zu einem lokalen Optimum. Der Durchbruch käme nicht durch bessere Integration, sondern nur durch eine Inversion zustande: Nicht das LLM ist Werkzeug im Prozess — der Prozess (und alles andere) wird Werkzeug des reasoning Agenten.
Aber was bedeutet dies für eine BPM Plattform und die Auditability als Kernfunktion klasischer BPM Systeme?
Zunächst sollte man hier in Primitiven und nicht in Features denken. Wie TCP/IP, nicht wie eine bestimmte Anwendung. Ein neues BPM Architekturkonzept muss klein, orthogonal und kombinierbar sein — sonst entsteht keine Ökosystem-Dynamik. Das ist eine harte Restriktion, aber auch eine produktive: Sie zwingt zu Klarheit.
Auditability als Kern ist vermutlich ein zentrale Aspekt. Denn naive KI-Architekturen verlieren genau das. Wenn ein Agent autonom reasoned und Werkzeuge wählt, ist der „Prozesspfad“ nicht mehr vorab dokumentiert — er entsteht. Das ist kein Widerspruch zur Auditability, aber es verändert ihre Natur fundamental: von präskriptiv (das Diagramm sagt, was passieren wird) zu deskriptiv (das Logbuch sagt, was passiert ist und warum). Dies entspricht eher dem Konzept eines Flugschreibers als dem eines Bauplans.
Und das öffnet die Architektur: BPMN verschwindet nicht — es wird zur post-hoc-Materialisierung. Der Agent handelt; aus seinem Handeln lässt sich rückwirkend ein BPMN-Diagramm generieren, das exakt zeigt, was passiert ist. Das ist sogar besser als heute, weil es die tatsächliche Ausführung dokumentiert, nicht die intendierte.
Eine architektonischen Primitive
Zerlegen wir wir diesen Ansatz in fünf Schichten — bewusst sparsam, weil jede zusätzliche Schicht Kombinatorik kostet:
1. Der Kontext-Layer: Nicht eine Datenbank, sondern ein append-only semantisches Gedächtnis. Jede Interaktion, jedes Dokument, jede Entscheidung wird als immutable Episode gespeichert (Snapshots) — multimodal, mit Zeitstempel, mit Urheber (Mensch/Agent/System). Strukturierte Sichten (das, was heute „die Datenbank“ wäre) sind Projektionen daraus, nicht der primäre Speicher. Event Sourcing kennt diese Idee — aber hier ist das Event nicht ein typisiertes Domain-Event, sondern ein semantischer Eintrag, abfragbar via Embedding und via strukturierter Projektion.
2. Der Capability-Layer: Werkzeuge mit klaren Verträgen — Input, Output, Vor-/Nachbedingungen, Compliance-Klassifikation (lesend/schreibend/regulatorisch/irreversibel). MCP geht in diese Richtung, ist aber noch zu sehr „Tool-Aufruf“ und zu wenig „Capability mit semantischem Vertrag“. Eine Capability sollte sich selbst beschreiben können — nicht nur syntaktisch, sondern semantisch und regulatorisch.
3. Der Intent-Layer: Ein Auftrag ans System ist nicht „starte Prozess X“, sondern eine Intention mit Constraints: das Ziel, die zulässigen Mittel, die Compliance-Grenzen, die Eskalationspunkte. Hier liegt der Wert einer BPM Engine — sie kann Prozessgrenzen formal beschreiben. Nur wird daraus keine Ausführungsvorschrift, sondern ein Möglichkeitsraum.
4. Der Reasoning-Layer: Hier sitzt das LLM (oder mehrere). Es bekommt Intent + Kontext + verfügbare Capabilities und entscheidet den nächsten Schritt. Aber — und das ist kritisch — jede Entscheidung wird mit Begründung ins Kontext-Gedächtnis zurückgeschrieben, bevor sie ausgeführt wird. Reasoning ist Teil des Audit-Trails, nicht nur sein Vorgänger.
5. Der Determinismus-Layer: Die „Inseln des Determinismus“. Buchungen, Vertragsabschlüsse, regulatorische Schritte gehen nie direkt durch das LLM, sondern durch klassische, getestete, deterministische Routinen. Der Agent triggert sie, aber er führt sie nicht aus. Hier wird eine BPMN-Engine als deterministische Insel-Engine zum tragenden Faktor — sie führt die kritischen, regulierten Sequenzen aus, die der Agent anfordert.
Wo Auditability sich neu konstituiert
In einem klassischen BPM System ist der Audit-Trail das Ausführungslog gegen das Diagramm. In der neuen BPM Architektur entsteht Auditability aus drei zusammenwirkenden Quellen: dem Reasoning-Log (warum wurde was entschieden, mit welchem Modell, gegen welchen Kontext), dem Capability-Log (was wurde aufgerufen, mit welchen Parametern, mit welchem Ergebnis) und dem Context-Log (welche Episoden waren zum Zeitpunkt der Entscheidung im abgerufenen Kontext). Aus diesen drei Strömen lässt sich jede Entscheidung rekonstruieren — und genau aus ihnen lässt sich auch das post-hoc-BPMN materialisieren, das ein Compliance-Officer lesen kann.
BPMN bietet hierfür das Vokabular um Compliance zu beschreiben. KI-native Systeme brauchen solche Systeme die dieses Vokabular zurück in die generierte Realität übersetzen können.
Das Unternehmen wird zu Anwendung
Das hier beschriebene System ist auf einer gewissen Ebene immer noch konservativ. Es folgt immer noch dem mentale Modell von „System tut etwas im Auftrag von jemandem“. Eine radikalerere Lesart wäre: Das Unternehmen selbst wird zur Anwedung — als Organismus aus Menschen, Agenten, Capabilities, Kontext! Dann gibt es keine „Unternehmensanwendung“ mehr, sondern nur noch ein Substrat, in dem Arbeit stattfindet, und Menschen und Agenten gleichberechtigt darin agieren.
Es stellen sich hier zwei zentrale Fragen:
- Die Idee des Kontext-Layers als primärer Speicher (mit Datenbanken nur als Projektionen) ist die teuerste, riskanteste, aber auch radikalste der fünf Primitive. Wie kann solch eine Architektur realisiert werden?
- Wo zieht man die Grenze zwischen „Plattform-Primitiven“ (das System) und „Domänenwissen“ (die Anwendung)?
Der Kontext-Layer – als semantische Gedächtnis – ist hier eine zentrale Komponente. Im Grunde ist dies ein generisches Event Log (z.b. RAG)
Auf der anseren Seite gibt es die Notwendigkeit Regeln als Grenzen und Richtlienen zu setzen. Ein Beispiel: Wenn am Ende ein Angebot oder eien Rechnung geschrieben werden muss folgt dies meist Compliance Richtlinien und gesetzlichen Vorgaben. Hier kann und darf ein LLM nicht seinen Freigeist ausleben. Also bleiben dertiministitsche ‚Inseln‘ ein ganz entscheidender Faktor.
Die deterministischen Inseln sind nicht nur „ein wichtiger Faktor“, sondern bilden die strukturelle Bedingung, unter der das ganze Konzept überhaupt erst akzeptabel wird.
Warum Determinismus-Inseln das Fundament sind
Wenn man die Architektur ernst nimmt — Agent reasoned, Capabilities werden frei gewählt, Pfad entsteht zur Laufzeit — dann hat ein Unternehmen genau einen Hebel, um das überhaupt zu verantworten: die Gewissheit, dass bestimmte Dinge nur auf bestimmte Weise passieren können. Eine Rechnung wird nie vom LLM „geschrieben“. Eine Rechnung wird von einer geprüften, versionierten, getesteten Routine erzeugt, die der Agent anfordert — und die ihre eigenen Validierungen hat, unabhängig davon, was der Agent meint, getan zu haben.
Das ist mehr als nur „Sicherheit“. Das ist die Vertragsfähigkeit des Systems gegenüber der Außenwelt. Eine Rechnung mit falscher Steuernummer ist nicht „ein Bug, den wir fixen“ — es ist ein Rechtsrisiko. Ein Angebot mit halluzinierten Konditionen kann ein Unternehmen in Haftung bringen. Die deterministische Insel ist dort, wo das System aufhört, zu interpretieren, und anfängt, zu erklären: dies ist der Akt, dies sind seine Bedingungen, dies sind seine Konsequenzen — und sie sind unabhängig vom Reasoning-Pfad reproduzierbar.
Unterschiedliche Formen von Determinismus
Man kann hier zwischen drei Arten von Determinismus unterscheiden die jeweils unterschiedlich behandelt werden müssen:
1. regulatorischer Determinismus: Rechnung, Angebot, Vertrag, GoBD-relevante Buchung, DSGVO-Auskunft. Hier ist der Output gesetzlich oder vertraglich gebunden. Das System darf den Akt anstoßen, aber Form und Inhalt folgen einer Vorlage + Validierung, die unabhängig vom LLM existiert. Das LLM kann zuliefern (Textbausteine, Zusammenfassungen), aber die finale Erzeugung passiert deterministisch, mit deterministischer Prüfung.
2. transaktionaler Determinismus: Geld bewegen, Bestand reservieren, Identitäten ändern, Daten löschen. Hier geht es um Konsistenz und Irreversibilität. Klassische ACID-Welt. Der Agent darf nicht „ungefähr“ überweisen. Diese Inseln sind oft schon da — Banking-Backends, ERP-Buchungslogik — und müssen sauber gekapselt bleiben.
3. prozessualer Determinismus: bestimmte Sequenzen müssen in bestimmter Reihenfolge mit bestimmten Freigaben ablaufen. Vier-Augen-Prinzip, Eskalationsketten, Genehmigungsworkflows. Genau hier hat eine BPMN-Engine ihre stärkste Zukunft. Nicht als Gesamtorchestrator, sondern als prozessuale Insel-Engine: Wenn das System erkennt, dass wir jetzt im Bereich „Investitionsfreigabe ab 50.000 €“ sind, ruft es einen BPMN-Prozess auf, der diese Sequenz garantiert korrekt ausführt — mit allen Freigaben, Logs, Eskalationen, die heute schon funktionieren.
Die Konsequenz
Damit wird die Architektur zweischichtig in einer sehr klaren Weise: außen probabilistisch, innen deterministisch. Das System navigiert frei im Möglichkeitsraum, aber jeder Akt mit Außenwirkung — alles, was Geld kostet, Recht erzeugt oder Daten verändert — geht durch eine Insel, die nicht verhandelbar ist.
Das System muss in die Lage versetzt werden diese Inseln finden zu können. Das heißt, sie müssen sich im Capability-Layer mit ihren Bedingungen selbst beschreiben. Eine Rechnungs-Capability sagt nicht nur „ich erzeuge eine Rechnung“, sondern „ich erzeuge eine Rechnung gemäß §14 UStG, ich brauche diese Pflichtfelder, ich verweigere die Ausführung bei diesen Fehlern, mein Output ist signiert und unveränderlich, mein Aufruf wird in der Buchhaltung protokolliert“. Das System sieht das, der Auditor sieht das, der Compliance-Officer sieht das — alle drei lesen denselben Vertrag.
Capabilities – Semantik vs. Tool
Die meisten KI-Plattformen, die heute entstehen, denken Capabilities als „Tools“ — flach, technisch, ohne Compliance-Semantik. Durch den Einsatz von BPMN existiert aber ein Vokabular, eine Semantik, um Capabilities regulatorisch reichhaltig zu beschreiben. Das ist das Differenzierungsmerkmal: Eine KI-Plattform, in der Capabilities ihre gesetzlichen und prozessualen Verpflichtungen mitführen, wäre für den europäischen Markt — wo Compliance kein Nachgedanke ist — extrem wertvoll. Vor allem unter dem AI Act, wo Nachvollziehbarkeit und Risikoklassifikation zur Pflicht werden.
Denkt man hier weiter, dann ist die zentrale Designarbeit der Plattform nicht der Reasoning-Layer, sondern der Capability-Vertrag. Die Sprache, in der eine Capability sich beschreibt — semantisch, regulatorisch, transaktional, prozessual. Wenn diese Sprache stimmt, kann das Ökosystem sich darauf einlassen. Wenn sie nicht stimmt, wird die Plattform entweder zu eng (nur für Ihre Use Cases) oder zu lax (kein Verlass).
Der Capability-Vertrag ist das eigentliche Designproblem.
So entsteht die eigentliche Veränderung in der Sicht auf Softwarearchitektur: Bisher war der Ansatz einen Unternehmensprozess per BPMN vollständig abzubilden. Mitarbeiter müssen sich an diesen halten (und verstehen es oft nicht – gerade jüngere Menschen). Anstatt nun diese überregulierten Monster-prozesse zu modellieren kann man dazu üergehen micro-modelle zu bauen. Das ist etwas ganz anderes als etwa ‚Skill Cards‘ in denen man beschreiben kann wie etwas gemacht wird und diese dem LLM als erweiterten Kontext zur Verfügung stellt. Aber man kann das sogar noch radikaler denken: man baut z.b. einen Micro Workflow für eine Finanzfreigabe, oder für das Erstellen einer Rechnung, oder der Vorbereitung einer Zahlung abbildet. Das sind keine Skill Cards sondern definierte „Vereinbarungen“ innerhalb unseres Unternehmens – das Unternehmen wird die Anwendung!
Von der Anweisung zur Vereinbarung
Die bis hier gemachten Überlegungen führen zum eigentlichen begrifflichen Durchbruch der mehr als nur eine Verfeinerung darstellt. Es ist eine andere Sicht auf das, was Software in einem Unternehmen überhaupt ist. Es geht darum von einer Anweisung zu einer Vereinbarung zu gelangen.
Eine BPMN-Prozessdefinition ist eine Anweisung: „So wird das gemacht, jeder hält sich daran.“ Sie ist top-down, präskriptiv, oft entkoppelt von der Lebenswirklichkeit der Mitarbeiter — daher das, was Mitarbeiter an solchen Lösungen stört, die das nicht mehr verstehen oder nicht mehr akzeptieren wollen. Eine Skill Card wiederum ist nur Wissen: „So macht man das gut.“ Sie ist beschreibend, hilfreich, aber nicht verbindlich.
Eine Vereinbarung ist etwas Drittes. Sie sagt: „Im Bereich X haben wir uns als Unternehmen darauf geeinigt, dass wir es so tun — weil das Gesetz es verlangt, weil wir es so wollen, weil unsere Risikobereitschaft es so vorsieht, weil unsere Werte das fordern.“ Eine Vereinbarung ist verbindlich und begründet. Sie ist nicht „der Prozess, den du befolgen musst“, sondern „der Konsens, an den wir uns halten — und an den auch unsere Agenten gebunden sind“.
Das ist eine völlig andere ontologische Kategorie als BPMN heute. Und sie löst ein Problem, das BPM seit zwanzig Jahren hat: die Akzeptanzfrage. Vereinbarungen kann man verhandeln, weiterentwickeln, hinterfragen. Anweisungen kann man nur befolgen oder umgehen.
Warum das die Mikro-Modellierung erst sinnvoll macht
Mikro-Flows ohne dieses Konzept wären nur kleinere BPMN-Prozesse — also dieselbe Krankheit in kleineren Tabletten. Mit dem Vereinbarungsbegriff verändert sich aber die ganze Modellierungsphilosophie:
Ein Vereinbarungs-Mikromodell kapselt genau die Stellen, an denen Beliebigkeit nicht akzeptabel ist. Alles dazwischen — wie man zum Anlass kommt, in welcher Reihenfolge, mit welchen Hilfsmitteln, wer wen fragt — das ist offener Raum, in dem Menschen und Agenten frei agieren. Die Vereinbarung greift nur dort, wo wir uns als Unternehmen binden. Und dort greift sie hart.
Das hat eine schöne Konsequenz: Vereinbarungen werden kleiner und schärfer, statt größer und weicher. Statt eines 47-Schritte-BPMN-Prozesses für „Auftragsabwicklung“ haben Sie vielleicht acht klar umrissene Vereinbarungen — Kreditprüfung, Preisfreigabe, Vertragsschluss, Rechnungsstellung, Zahlungsfreigabe, Skonto-Regel, Mahnstufe, Storno. Jede einzelne ist präzise modelliert, getestet, geprüft. Was zwischen diesen Vereinbarungen passiert, ist Reasoning-Raum — für den Mitarbeiter, für den Agenten, für beide gemeinsam.
Die strukturelle Eleganz
Schauen wir uns genauer an, was hier passiert: die fünf Schichten von vorhin bekommen plötzlich eine organische Verbindung zur Unternehmensrealität.
Vereinbarungen sind die deterministischen Inseln aus dem vorangegangenen Gedanken — aber nicht mehr nur als technische Notwendigkeit, sondern als organisatorisches Konstrukt. Sie sind die Stellen, an denen das Unternehmen explizit gemacht hat: „Hier ist Konsens, hier ist Verbindlichkeit, hier ist die Grenze unseres kollektiven Versprechens.“ Damit wird der Capability-Vertrag, über den wir vorhin sprachen, plötzlich kein technisches Schema mehr — er wird zur kodifizierten Vereinbarung. Etwas, das ein Compliance-Officer, ein Geschäftsführer, ein Mitarbeiter und ein Agent gleichermaßen lesen können, weil es in einer Sprache geschrieben ist, die organisatorisch existiert, nicht nur technisch.
Und der Reasoning-Layer agiert in dem Möglichkeitsraum zwischen den Vereinbarungen — frei zu reasonen, frei zu navigieren, aber gebunden, sobald er eine Vereinbarungs-Insel betritt.
Eine Folge für Mitarbeiter
Was bedeutet dies für Mitarbeiter in einem Unternehmen? Dieses Modell verändert die Beziehung der Mitarbeiter zur Software fundamental. Heute bedienen Mitarbeiter ein System, das ihren Prozess vorschreibt. Morgen partizipieren sie an einem Substrat, in dem Vereinbarungen die Stellen markieren, an denen das Unternehmen verbindlich wird — und alles andere ist Spielraum. Das passt zu der Lebenswirklichkeit die sich gerade durch KI neu bildet: Jüngere Mitarbeiter wollen verstehen, warum etwas verbindlich ist, nicht dass es verbindlich ist. Eine Vereinbarung trägt ihre Begründung mit; eine Anweisung nicht.
Der Gedanke „das Unternehmen wird die Anwendung“ bekommt jetzt eine konkrete Form. Ein Unternehmen ist in dieser Sicht die Summe seiner Vereinbarungen plus dem Kontext, in dem es operiert, plus den Capabilities, die ihm zur Verfügung stehen, plus den Menschen und Agenten, die darin handeln. Die Software ist nicht mehr ein Werkzeug, das das Unternehmen benutzt — sie ist die Form, in der das Unternehmen sich selbst manifestiert. Vereinbarungen sind das Gerüst, an dem es sich erkennt.
Und das ist, beiläufig, auch eine Antwort auf eine alte BPM-Frage: Warum scheitern so viele BPM-Projekte? Weil sie versuchen, das ganze Unternehmen zu modellieren, statt nur die Stellen, an denen Modellierung Sinn ergibt. Vereinbarungs-Mikromodelle modellieren genau dort, wo Verbindlichkeit gefordert ist — und lassen den Rest in Ruhe.