BLOG
Model to Execution: Warum das alte Phasenmodell plötzlich wieder funktioniert
September 30 | Sharam Dadashnia
Fachkonzept. DV-Konzept. Implementierung.
Drei Begriffe, die viele noch aus Ausbildung, Studium oder den ersten großen Einführungsprojekten kennen. Und drei Begriffe, die lange als Sinnbild einer zu langsamen IT galten.
Die Kritik war oft berechtigt. Zwischen Fachbereich und Entwicklung entstanden dicke Dokumente. Bis das DV-Konzept abgestimmt war, hatte sich das Geschäft längst weiterbewegt. Die Umsetzung startete mit einem Modell, das schon beim ersten Release nicht mehr vollständig stimmte. Später wusste niemand mehr, ob das BPMN-Diagramm, das Wiki oder der laufende Code den Prozess wirklich beschrieb.
Das Problem war aber nicht die Trennung von Fachlichkeit und Technik.
Das Problem war, dass die Mitte Papier blieb.
Mit agentischen Prozessen bekommt diese mittlere Ebene eine neue Aufgabe. Sie beschreibt nicht nur, was ein Prozess tun soll. Sie legt fest, welche Schritte deterministisch laufen, welche Aufgaben ein KI-Agent übernimmt, auf welche Systeme er zugreifen darf, wann ein Mensch entscheidet und wie ein Vorgang über Wochen hinweg steuerbar bleibt.
Damit wird aus einem DV-Konzept wieder das, was es hätte sein sollen: die ausführbare Verbindung zwischen Geschäftsanforderung und Betrieb.
Warum das Phasenmodell in Verruf geraten ist
Das klassische Modell versprach eine klare Aufgabenteilung:
- Der Fachbereich beschreibt Ziel, Ablauf und Regeln.
- Die IT übersetzt das in eine technische Spezifikation.
- Entwicklung und Betrieb setzen die Spezifikation um und halten das System am Laufen.
In der Praxis brach die Verbindung meist an der zweiten Stufe ab.
Der Fachbereich arbeitete mit Prozessgrafiken, Tabellen und Freitext. Die Entwicklung schrieb Code, Datenbankskripte und Schnittstellenlogik. Zwischen beiden Welten lagen Übergaben, Rückfragen, Versionskonflikte und oft mehrere Tools. Nach der ersten Prozessänderung fehlte die Zeit, sämtliche Dokumente mitzuziehen.
So entstand ein bekanntes Muster: Das Fachkonzept war verständlich, aber nicht ausführbar. Der Code war ausführbar, aber für Fachbereiche kaum lesbar. Und das DV-Konzept lag irgendwo dazwischen, meistens als Dokument mit veraltetem Änderungsstand.
Agile Entwicklung hat einen Teil dieses Problems gelöst. Teams liefern in kleineren Schritten, stimmen sich häufiger ab und testen früher. Was sie nicht automatisch löst: die dauerhafte Verbindung von fachlicher Prozesslogik, Integrationen, Berechtigungen, Agenten und Betrieb.
Diese Verbindung wird jetzt wieder wichtiger. Denn ein KI-Agent lässt sich schnell bauen. Ein produktiver Geschäftsprozess mit KI-Agenten ist etwas anderes.
Das DV-Konzept hat heute mehr Inhalt als vor drei Jahren
Ein technisches Prozesskonzept beschrieb früher vor allem Datenmodelle, Schnittstellen, Benutzeroberflächen, Regeln und Fehlerbehandlung. Diese Themen bleiben. Doch für Agentic Process Orchestration kommen weitere Fragen hinzu.
Ein heutiges Konzept muss mindestens beantworten:
- Welche Schritte sind fest geregelt?
Beispielsweise eine Pflichtfeldprüfung, eine Freigabegrenze oder eine Eskalation nach fünf Arbeitstagen.
- Welche Schritte brauchen Kontext und Urteil?
Etwa das Auslesen einer Reklamation, die Klassifizierung einer technischen Anfrage oder die Prüfung, ob ein Dokument vollständig wirkt.
- Welcher Agent ist für welche Aufgabe zuständig?
Ein Agent für Dokumentenanalyse hat einen anderen Auftrag, andere Daten und andere Rechte als ein Agent, der eine Kundenkommunikation vorbereitet.
- Welche Daten darf der Agent sehen?
Nicht jeder Prozessschritt braucht Zugriff auf alle Kundendaten, Verträge oder internen Wissensquellen.
- Welche Systeme werden angesprochen?
Dazu gehören ERP, CRM, Dokumentenmanagement, Fachanwendungen, APIs und Ereignisquellen.
- Wo entscheidet ein Mensch?
Besonders bei rechtlich relevanten, finanziellen oder fachlich strittigen Entscheidungen muss der Kontrollpunkt Teil des Ablaufs sein – mit Rolle, Frist und Eskalation.
- Was wird protokolliert?
Ein späterer Prüfpfad muss zeigen können, welcher Vorgang wann welchen Schritt durchlaufen hat, welche Daten verwendet wurden und wer eine Freigabe erteilt hat.
Das ist kein Zusatzkapitel für KI-Projekte. Es ist die technische Beschreibung des Prozesses selbst.
Ein Prozessmodell kann dabei die führende Struktur bleiben. Bei Scheer PAS wird die Prozesslogik mit BPMN modelliert, durch Integrationslogik an Anwendungen und Datenquellen angebunden und von der Process Engine ausgeführt. Agenten werden in diesen Ablauf eingebettet, statt als isolierte Automatisierungen nebenher zu laufen.
Der Regelweg: Anforderungen in natürlicher Sprache beschreiben
Der Einstieg kann heute deutlich direkter sein als früher.
Ein Fachbereich muss nicht mit einem 60-seitigen Pflichtenheft beginnen. Er kann beschreiben, was passieren soll:
Wenn eine Kundenanfrage per E-Mail eingeht, sollen Anhänge und E-Mail-Inhalt geprüft werden. Fehlende technische Angaben müssen erkannt werden. Vollständige Anfragen gehen an die Arbeitsvorbereitung. Bei unvollständigen Angaben soll der Vertrieb einen Antwortentwurf zur Freigabe erhalten. Nach drei Arbeitstagen ohne Rückmeldung wird der Vorgang eskaliert.
In diesem kurzen Text steckt bereits viel Prozesslogik:
- ein Ereignis, das den Vorgang startet,
- Dokumente und E-Mail-Inhalte als Eingaben,
- eine Prüfung auf Vollständigkeit,
- eine Entscheidung mit zwei Wegen,
- verschiedene Verantwortlichkeiten,
- ein menschlicher Freigabepunkt,
- eine Frist,
- eine Eskalation.
Sprachmodelle können helfen, aus einer solchen Beschreibung einen ersten Entwurf zu erzeugen: Prozessschritte, offene Fragen, mögliche Datenobjekte oder einen Vorschlag für ein BPMN-Modell. Der Nutzen liegt nicht darin, dass die KI den Prozess „weiß“. Sie zwingt Anforderungen früh in eine prüfbare Form.
Der erste Entwurf ist allerdings nie die Freigabe zur Umsetzung.
Er ist der Beginn des fachlichen Dialogs: Was bedeutet „vollständig“ genau? Welche Angaben sind Pflicht? Kann ein Agent die technische Relevanz beurteilen oder nur fehlende Informationen erkennen? Darf er eine Rückfrage versenden oder nur einen Entwurf erstellen? Welche Fälle gehen sofort an einen Menschen?
Diese Klärung war früher auch nötig. Sie fand nur oft zu spät statt – nachdem sich Fachbereich und IT bereits auf unterschiedliche Interpretationen festgelegt hatten.
Ein BPMN-Modell ist kein Screenshot für ein Sprachmodell
Hier liegt ein wichtiger Unterschied zwischen einer ernsthaften Umsetzung und einer netten Demo.
Ein BPMN-Diagramm als Bild in einen Chat zu laden und zu fragen, ob der Prozess besser werden kann, kann für einen Workshop nützlich sein. Für produktive Prozesse reicht es nicht. Ein Bild enthält keine belastbare technische Semantik: keine Version, keine verbindlichen Datenstrukturen, keine Berechtigungen, keine verknüpften Schnittstellen und keinen Laufzeitstatus.
Entscheidend ist das bidirektionale Mapping zwischen Modell und Umsetzung.
Das bedeutet:
- Das fachliche Prozessmodell beschreibt Schritte, Entscheidungen, Rollen und Ereignisse.
- Die technische Ebene verknüpft diese Elemente mit APIs, Datenobjekten, Nutzeroberflächen, Geschäftsregeln und Agenten.
- Änderungen am Modell werden nicht nur dokumentiert, sondern können gezielt in die Ausführung überführt werden.
- Erkenntnisse aus dem laufenden Betrieb fließen zurück in die Modellierung.
Ein Beispiel: Im Angebotsprozess wird ein Agent ergänzt, der technische Anhänge auswertet. Im Modell ist er kein anonymes Kästchen mit der Aufschrift „KI“. Er hat einen klaren Platz im Ablauf.
Es ist definiert:
- wann er aufgerufen wird,
- welche Eingaben er erhält,
- welches strukturierte Ergebnis er zurückgeben muss,
- welche Datenquellen zulässig sind,
- was bei Unsicherheit geschieht,
- ob er nur eine Empfehlung erzeugt oder eine Aktion auslösen darf,
- und welcher Folgeprozess startet.
Damit wird die Agentenlogik Teil des Prozesssystems. Sie lässt sich testen, überwachen, versionieren und im Zusammenhang mit dem gesamten Vorgang prüfen.
Aktuelle Ansätze für agentische Prozessausführung gehen in dieselbe Richtung: Ein vorab definierter Ablauf gibt Struktur und Kontrollpunkte vor, während Agenten die variablen oder unstrukturierten Aufgaben bearbeiten. Das „Plan-then-Execute“-Muster trennt beispielsweise Planung und Ausführung, um Verhalten besser steuer- und prüfbar zu halten. SAP beschreibt dieses Muster für verantwortliche agentische KI. Auch die Forschung rund um Agentic Business Process Management beschäftigt sich mit der Verbindung aus Prozessregeln, Agenten und kontextabhängiger Ausführung. Ein Beispiel ist der Ansatz mit getrennten Rollen für Prozessrahmen und operative Bearbeitung in einer wissenschaftlichen Untersuchung zu LLM-Agenten in Geschäftsprozessen.
Agenten entstehen nicht neben dem Prozessmodell
In vielen Unternehmen beginnt Agentenentwicklung anders: Ein Team identifiziert eine interessante Aufgabe, verbindet ein Modell mit ein paar Tools und stellt den Nutzen unter Beweis. Das kann ein sinnvoller Anfang sein.
Problematisch wird es, wenn dieser Prototyp anschließend unbemerkt zum Teil eines kritischen End-to-End-Prozesses wird.
Dann fehlen meistens genau die Informationen, die ein Prozessmodell sichtbar macht:
- In welchem Vorgang arbeitet der Agent?
- Was passiert, wenn sein Aufruf fehlschlägt?
- Welche Daten dürfen den Prozess verlassen?
- Wer kann sein Ergebnis überstimmen?
- Was passiert, wenn der Prozess drei Wochen auf eine Kundenantwort wartet?
- Wie wird der Agent ersetzt, wenn Modell, Prompt oder Datenquelle geändert werden?
- Welche Prozessversion galt, als der Agent eine Entscheidung vorbereitet hat?
Agenten sollten deshalb aus dem Prozessmodell abgeleitet werden, nicht daran vorbeigebaut werden.
Ein gut modellierter Prozess macht sichtbar, wo ein Agent tatsächlich Mehrwert bringt. Nicht jeder Schritt braucht einen. Eine Bonitätsgrenze, ein Freigabewert oder eine Eskalation nach Ablauf einer Frist bleiben besser als feste Regel implementiert. Sie sind vorhersehbar, testbar und günstig.
Der Agent gehört dorthin, wo Sprache, Dokumente, Kontext oder fachliche Einordnung benötigt werden:
Prozesssituation | Passendes Mittel |
Rechnungssumme über einem definierten Betrag | Regel oder Entscheidungstabelle |
Unstrukturierte Anfrage erkennen und kategorisieren | KI-Agent |
Fehlende Informationen aus E-Mail und Anhängen identifizieren | KI-Agent mit strukturiertem Ergebnis |
Kundenfreigabe nach zehn Tagen anmahnen | Prozessregel und Timer |
Preisnachlass verbindlich bestätigen | Menschliche Entscheidung im Prozess |
Angebotsdaten in ERP und CRM übertragen | Integration und Prozesslogik |
Technische Ausnahme bewerten und begründen | KI-Agent, bei Risiko mit Human-in-the-Loop |
Diese Aufteilung ist kein Kompromiss zwischen alter und neuer Welt. Sie ist die Grundlage für einen Prozess, der im Betrieb beherrschbar bleibt.
Der Rückweg: Was der Betrieb über das Prozessmodell verrät
Model to Execution endet nicht mit dem Deployment.
Wenn ein Prozess läuft, produziert er Informationen, die in einem Dokument nie auftauchen würden: Wo warten Vorgänge? Welche Ausnahme tritt am häufigsten auf? Welcher Agent liefert besonders oft unsichere Ergebnisse? An welcher Schnittstelle entstehen Fehler? Wie viele Bearbeitungsschritte brauchen tatsächlich einen Menschen?
Die Process Engine hält dabei nicht nur den Status eines einzelnen Agentenaufrufs. Sie hält den Zustand des gesamten Vorgangs – auch dann, wenn zwischen zwei Schritten fünf Wochen liegen.
Nehmen wir wieder die Angebotsanfrage. Nach drei Monaten zeigt sich vielleicht: Der Dokumenten-Agent erkennt fehlende technische Angaben zuverlässig. Trotzdem bleibt fast jede vierte Anfrage zu lange liegen, weil die interne Machbarkeitsprüfung keine definierte Frist hat. Der Engpass ist also nicht die Dokumentenanalyse. Es ist ein unklarer Übergang zwischen Vertrieb und Arbeitsvorbereitung.
Diese Erkenntnis führt zurück ins Prozessmodell. Die Lösung könnte eine Frist, ein klarer Verantwortlicher, eine Eskalation oder eine andere Verteilung der Arbeit sein. Vielleicht braucht es auch keinen weiteren Agenten.
Das ist der entscheidende Punkt: Prozessintelligenz entsteht nicht aus der Anzahl eingesetzter Modelle. Sie entsteht aus der Verbindung von Modell, Ausführung und beobachtbarem Betrieb.
Das Phasenmodell war nie das Problem
Fachkonzept, DV-Konzept und Implementierung funktionieren wieder, wenn sie nicht als drei getrennte Dokumente verstanden werden.
Das Fachkonzept beschreibt den geschäftlichen Zweck und die Regeln. Die technische Ebene übersetzt diesen Zweck in einen ausführbaren Prozess: mit Integrationen, Daten, Rollen, Agenten, Kontrollpunkten und Nachweisen. Die Implementierung bringt ihn in den Betrieb. Und der Betrieb liefert Erkenntnisse zurück an Modell und Fachbereich.
So wird aus einem Modell kein Diagramm für die Projektablage, sondern eine Grundlage für Ausführung, Steuerung und Veränderung.
Genau darin liegt Model to Execution: Der Weg von der fachlichen Absicht bis zum laufenden Prozess bleibt verbunden. Agenten beschleunigen Teile dieses Wegs. Die Process Engine hält ihn zusammen.
