PROCESS AUTOMATER
Prozesse ändern, ohne das Backend umzubauen
Der Process Automater legt Geschäftsprozesse als Konfiguration über ein bestehendes Backend. Phasen, Bedingungen, Pflichtfelder, Validatoren und Aktionen leben an einer Stelle, statt verteilt im Tool-Customizing. Die Daten bleiben dort, wo sie ohnehin liegen. Produktiv eingesetzt für ein Stage-Gate-Modell in einer regulierten Konzern-Umgebung; offen für andere Backends und Prozesse.
Prozess als YAML, nicht als Customizing
Geschäftsprozesse haben Phasen, Übergangs-Bedingungen, Pflichtfelder und Verantwortliche. Im Process Automater leben diese Bausteine in einer Konfiguration, die der Server zur Laufzeit lädt. Eine neue Phase, ein zusätzliches Pflichtfeld oder eine geänderte Bedingung ist eine Modell-Anpassung, kein Klick-Marathon im Tool-Customizing. Varianten, gemeinsame Definitionen und Abweichungen werden im selben Artefakt gepflegt, das später ausgeführt wird. Dadurch reden Fachseite, Betrieb und Entwicklung über denselben Prozess — nicht über drei auseinanderlaufende Versionen.
Validatoren, Aktionen, Watcher
Beim Übergang in eine neue Phase läuft eine konfigurierte Kette: Validatoren prüfen Pflichtfelder, Berechtigungen und Konsistenz; Aktionen schreiben Attribute, setzen Labels, posten Kommentare, lösen Webhooks aus oder benachrichtigen Drittsysteme. Watcher reagieren zusätzlich auf Änderungen einzelner Felder, auch außerhalb klassischer Phasen-Übergänge. Neue Regel- und Aktionstypen lassen sich ergänzen, ohne bestehende Prozesse umzubauen. Was vorher als fachliche Prüf-Anforderung dokumentiert war, wird zur ausführbaren Regel — nachvollziehbar, wiederholbar und an einer Stelle gepflegt.
Auf dem Backend, das Sie schon nutzen
Der Process Automater legt sich als Schicht über Ihr System of Record — er hält keine eigene Datenkopie. Sources lesen Business-Attribute, Targets schreiben das berechnete Ergebnis zurück. Aktuell produktiv eingesetzt mit Jira als Backend, technisch offen für andere Backends: Confluence, ein ERP, eine Datenbank oder ein Mix mehrerer Systeme. Business-Attribute lassen sich aus unterschiedlichen Quellen lesen, fachliche Regeln darauf definieren und Ergebnisse in unterschiedliche Targets zurückschreiben — ein Prozess kann also über Backend-Grenzen hinweg gespannt werden. Hauptanwendungsfall heute: ein Stage-Gate-Modell für Produktinitiativen in einer regulierten Konzern-Umgebung, in der die zentrale Jira-Instanz bewusst dünn konfiguriert bleiben soll. Eine eigene Wizard-UI legt neue Vorgänge an, OIDC/SSO ist eingebunden, REST- und Webhook-Schnittstellen binden Drittsysteme an. Wer mit einem anderen Backend einsteigen möchte, fängt nicht bei Null an — die Erweiterung passiert über zusätzliche Source- und Target-Typen, nicht über einen Refactor des Kerns.
Vorab simulieren, sauber prüfen
Destruktive Aktionen lassen sich vorher trocken durchspielen. Im DryRun-Modus rechnet der Server den vollständigen Phasen-Übergang inklusive Validatoren und Targeting durch, schreibt das Ergebnis aber nicht zurück ins Backend. Was wäre passiert, ist sichtbar; was passiert ist, bleibt aus. Berechtigungen prüft die Anwendung an drei Stellen: am Process-Zugang, am Lese-Zugriff auf den Vorgang und an konfigurierbaren Gruppen pro Bedingung. Pro Schritt entsteht ein Audit-Eintrag im OperationStore, der DryRun-Läufe explizit markiert. Wer einen Bulk-Schritt fährt, sieht das Ergebnis pro Vorgang einzeln — Erfolge und Fehler getrennt, nichts bricht den Lauf am ersten Stolperer ab.
Bedienbar auch für LLM-Clients
Eine MCP-Schicht öffnet die Domänen-Operationen direkt für LLM-basierte Clients — Claude Desktop, interne Agents, eigene Custom-Integrationen. Statt die REST-API zu wrappen, rufen Clients dedizierte Tools auf: getFeature liefert den aktuellen Zustand inklusive Phase, Attribute und Bedingungs-Status; bulkConfirm setzt Bestätigungs-Marker für eine Liste von Vorgängen. Authentifizierung und Berechtigungen kommen aus derselben Quelle wie für die REST-API; ein Tool-Aufruf wird genauso geprüft wie ein normaler Web-Request. Schreibende Tools akzeptieren einen DryRun-Schalter, sodass ein Agent eine geplante Wirkung dem Nutzer in echter Tool-Semantik vorrechnen kann, bevor sie tatsächlich ausgelöst wird.