Warum wir Workflows in einem Satz bauen — und keinen Low-Code-Designer

Die letzten zwanzig Jahre Workflow-Engines im Enterprise haben ein Werkzeug hervorgebracht, das als Standard gilt: den grafischen Prozess-Designer. Kacheln auf einem Canvas, Pfeile dazwischen, Verzweigungen, Merges. Es sieht gut aus in Sales-Demos. Es hält der Alltagsnutzung selten stand. Dieser Text erklärt, warum wir bei RecordTailor den Designer weggelassen haben — und wie das ohne Feature-Verlust geht.

Was mit grafischen Designern in der Praxis passiert

In der Sales-Demo ist der Designer der Star. Ein Consultant zieht ein „Approve“-Icon aufs Canvas, verbindet es mit einem „Send Email“-Icon, klickt Speichern. Der Kunde nickt. Alles wirkt einfach.

Sechs Monate später steht in der Prozess-Abteilung eine Excel-Tabelle mit 47 Workflow-Definitionen, die jemand entworfen hat, den es nicht mehr gibt. Zwei Workflows machen fast dasselbe. Einer davon hat eine Escalation-Regel, die ins Leere läuft, weil der Zielempfänger seit letztem Jahr in einer anderen Abteilung sitzt. Ein dritter ist deaktiviert, weil er in einer alten Version funktioniert hat und nach dem Upgrade nicht mehr — aber niemand traut sich, ihn zu löschen.

Der Grund ist strukturell: Ein grafischer Designer ist ein Autoren-Werkzeug, kein Lese-Werkzeug. Was auf dem Canvas als schöne Anordnung aussieht, ist als Text schwer zusammenzufassen. Die Klartext-Prüfung eines Workflows („macht das noch, was wir wollten?“) ist im Designer nur mit Klick-Marathon möglich.

Was wir stattdessen tun

Sie schreiben einen Satz. „Eingehende Rechnungen über 5.000 € gehen an die Fachabteilung zur Prüfung, danach an die Geschäftsführung zur Freigabe, Skonto-Frist minus zwei Tage als Deadline.“ RecordTailor parst diesen Satz und erzeugt daraus ein validiertes Workflow-YAML. Danach übersetzt es das YAML zurück in Klartext und zeigt Ihnen: „Ich habe verstanden — Rechnungen mit Betrag > 5000 EUR, Schritt 1: approve durch Rolle Fachabteilung, Schritt 2: approve durch Rolle Geschäftsführung, Deadline: Skontofrist minus 2 Werktage.“

Sie prüfen den Klartext und geben frei. Der Workflow ist ab dann produktiv. Kein Canvas, keine Kacheln, keine Consultant-Session.

Warum das kein Feature-Verzicht ist

Der Einwand lautet: „Ein Satz kann nicht alles ausdrücken, was ein komplexer Prozess braucht.“ Stimmt und stimmt nicht.

Stimmt: Für einen Prozess mit 20 Verzweigungen, drei parallelen Zweigen und einer nachgelagerten Konsolidierung wird der Satz lang. In der Praxis sehen wir das aber selten — die meisten Genehmigungs-, Prüf- und Signatur-Prozesse in DMS-Kontexten haben zwei bis fünf Schritte und eine Verzweigung. Für die 90 % der Fälle reicht ein Satz.

Stimmt nicht: Auch komplexe Prozesse lassen sich in mehreren Sätzen ausdrücken. Die generierte YAML-Definition ist von Zod validiert und bildet die Kern-Konstrukte ab: approve, review, sign, notify, plus Kontrollstrukturen für Vier-Augen-Prinzip, Fristen, Eskalation und bedingte Verzweigung. Wer die YAML-Definition direkt schreiben will, kann das — der Plain-Language-Weg ist Convenience, nicht Zwang.

Der wichtige Nebeneffekt: Reviewbarkeit

Ein Workflow als Text-Definition ist reviewbar. Sie können ihn in eine Pull-Request-Diskussion einbetten, historische Änderungen als Diff sehen, per Code-Search finden. Ein Workflow als grafische Definition ist all das nicht — er ist ein Screenshot, im Zweifel mit einer Legende darunter, die ein anderer aktuell halten müsste.

Workflow-Definitionen liegen in RecordTailor im Repository und nutzen dasselbe Git-Modell wie alle anderen Dokumente. Sie können eine Variante branchen, testen, mergen, zurückrollen — ohne die produktive Version zu stören. Das ist der Punkt, an dem Workflows aufhören, Schamanentum zu sein, und anfangen, wie Software behandelt zu werden.

KI entwirft, sie führt nicht aus

Ein zentraler Design-Punkt: Die KI hilft, den Workflow zu entwerfen. Sie führt ihn nicht frei aus. Die Ausführungs-Engine bleibt regelbasiert, deterministisch, auditiert. Das ist das Compliance-Argument für KI-nahe Workflows — der Prozess selbst ist beweisbar, KI sitzt an den Rändern (Entwurf, Vorschlag für Änderungen, Copilot für stockende Instanzen).

Konkret heißt das: Wenn ein Agent im Workflow als Teilnehmer auftritt (Beispiel: Rechnungs-Agent führt den 3-Way-Match durch), landet seine Aktion als `agent_action` in derselben Struktur wie eine menschliche Freigabe — mit Begründung, Konfidenz, Belegen. Der Workflow selbst weiß nicht, ob der Schritt von einem Menschen oder einem Agenten erledigt wurde; die Governance-Frage stellt sich beim Agent-Auftritt selbst, nicht in der Workflow-Definition.

Was ein Nutzer beim ersten Mal erlebt

Wir haben die Plain-Language-Autoren-UX mit einer Handvoll Buchhaltungen getestet. Der überraschendste Effekt: die Autor:innen schreiben klarere Prozesse als vorher. Der Grund ist einfach — der Satz zwingt zur Klärung. „Wer freigibt, in welcher Reihenfolge, bis wann?“ — wenn die Autorin das nicht in einem Satz sagen kann, ist der Prozess nicht klar genug für die Realität.

Der Klartext-Rückblick vor Freigabe hat einen zweiten Effekt: Auch Nicht-Autor:innen können den Workflow verstehen. In der Praxis heißt das, dass die Compliance-Kollegin nachträglich einen Workflow lesen kann, ohne Consultant-Übersetzung. Das war mit dem grafischen Designer nur mit Aufwand möglich.

Was Sie sehen sollten, bevor Sie das für Ihre Prozesse einschätzen

Ein Text erklärt Plain-Language-Workflows nur bedingt. Was hilft: eine 20-Minuten-Session, in der Sie einen Ihrer typischen Prozesse in einem Satz beschreiben und wir Ihnen die generierte Definition plus Klartext-Rückblick zeigen. Sie merken innerhalb der Session, ob der Ansatz für Ihre Prozessvielfalt trägt oder nicht.

Der ehrliche Zusatz: Für Prozesse mit vielen parallelen Zweigen (typisch in großen Fertigungsketten) ist ein grafischer Designer weiter das bessere Werkzeug. Wir sagen Ihnen das dann. Für die typischen DMS-Workflows — Rechnungsfreigabe, Vertragsprüfung, Personalakten-Freigabe, Aktennotizen mit Zwei-Augen-Prinzip — ist der Ein-Satz-Weg schneller und weniger fehleranfällig.