Leistungen /Prozessautomatisierung

Prozesse, die heute Personal binden, als laufende Anwendung

Mehrstufige Genehmigungen, Bearbeitungsketten über Abteilungsgrenzen, Fristen und Eskalationen: Das lässt sich modellieren, automatisieren und messen, mit BPMN-Workflow-Engines wie Camunda oder Cibseven.

BPMN-Workflow-Engine (Camunda, Cibseven) Spring Boot REST CI/CD

Kommt Ihnen das bekannt vor?

Der Prozess lebt in einer Excel-Liste, einer Confluence-Seite, einer Mailkette und in den Köpfen von drei Leuten.
Niemand kann sagen, wie viele Vorgänge gerade offen sind und wo sie hängen.
Fristen werden gerissen, weil die Erinnerung daran an einer Person hängt.
Bei Urlaub oder Krankheit steht der Vorgang still.
Für Audits muss die Bearbeitungshistorie mühsam rekonstruiert werden.
Es gibt bereits ein BPMN-Modell, aber es beschreibt nur und steuert nichts.
Ein erster Versuch steht im Low-Code-Tool: Er trägt die einfachen Fälle, aber nicht die Ausnahmen.
Was im No-Code-Werkzeug entstanden ist, lässt sich weder testen noch versionieren noch auf eine zweite Umgebung bringen.
Die Vorgänge hängen in einem Ticket-System, das für etwas anderes gedacht war: Fristen und Vertretungen kennt es nicht.
Was im Fehlerfall zu tun ist, steht nirgends. Es weiß nur, wer den Fall schon einmal ausgebadet hat.
Wie es um den Prozess steht, beantwortet jeder anders.

Vorgehen

Vom Modell zur laufenden Anwendung

Ein Prozessmodell ist erst dann etwas wert, wenn die Engine danach tatsächlich Vorgänge steuert.

01

Prozess aufnehmen, wie er wirklich läuft

Gemeinsam mit den Leuten, die ihn täglich bearbeiten, inklusive der Sonderfälle und Abkürzungen, die im Soll-Prozess nie auftauchen, in der Praxis aber die Hälfte der Vorgänge ausmachen. Was in Confluence oder im Handbuch steht, ist dabei nur der Ausgangspunkt.
02

Modellieren, was automatisierbar ist

BPMN-Modell, das Fachbereich und Entwicklung gleichermaßen lesen können. Entschieden wird bewusst, welche Schritte automatisch laufen und welche eine menschliche Entscheidung bleiben. Dazu gehört der oft vergessene Teil: das Verhalten im Fehlerfall zu ermitteln und festzulegen. Was wird wiederholt, wer übernimmt, wann wird eskaliert? Auch dieses Wissen steckt bisher meist in den Köpfen einzelner.
03

Anwendung bauen

Eine BPMN-Workflow-Engine (etwa Camunda oder Cibseven) als Herzstück, dazu Aufgabenlisten, Formulare, Fristen, Eskalationen und die Anbindung an die Systeme, die ohnehin schon die Daten haben.
04

Messen und nachschärfen

Nach ein paar Wochen im Echtbetrieb zeigen die Zahlen, wo es klemmt. Dann wird nachgeschärft. Das ist der Vorteil gegenüber einem Prozess, den niemand beobachten kann.

Immer mit drin

Architektur, Umsetzung und DevOps — nicht getrennt bestellbar.

Ein Prozessmodell allein steuert nichts. Damit aus dem Modell eine Anwendung wird, die in Produktion trägt, arbeiten alle drei Ebenen zusammen:

Architektur

Wo die Prozesslogik hingehört: ins BPMN-Modell, in die Fachanwendung oder in die angebundenen Systeme. Diese Grenze entscheidet, wie änderbar der Prozess in zwei Jahren noch ist.

Umsetzung

Engine, Aufgabenlisten, Formulare, Fristen und die Anbindung der Systeme, die die Daten ohnehin haben. Gebaut von uns, nicht als Konfiguration zugekauft.

DevOps

Modelle und Code gehen über dieselbe Pipeline in Produktion, laufende Vorgänge sind im Monitoring sichtbar. Durchlaufzeiten zu messen setzt genau das voraus.

Was am Ende dasteht

Was sich am Tag danach ändert

Ein Vorgang hat einen Ort

Jeder Fall ist auffindbar, mit Status, Zuständigkeit und Historie.

Fristen und Fehler laufen nicht ins Leere

Erinnerungen, Eskalationen, Vertretungen und das Verhalten im Fehlerfall stecken im Prozess selbst, wo sie vorher an der Disziplin einzelner hingen.

Ein definierter Report

Durchlaufzeiten, Liegezeiten, Engpässe: ein vereinbarter Bericht statt des Bauchgefühls einzelner.

Nachvollziehbarkeit

Wer wann was entschieden hat, ist protokolliert. In regulierten Umgebungen ist das der eigentliche Gewinn.

Angebundene Systeme

Der Prozess holt Daten dort, wo sie stehen, statt sie erneut eintippen zu lassen.

Änderbare Modelle

Ändert sich der Prozess, wird das Modell angepasst. Der Code bleibt davon unberührt.

Belege

Schon geliefert, nicht nur skizziert.

Hinter jedem Punkt steht mindestens ein System, das in Produktion läuft.

Telekommunikation

Workflow-Middleware für einen Mobilfunkbetreiber; Massendatenverarbeitung von Call-Detail-Records im selben Umfeld.

Öffentliche Verwaltung

Mehrstufige Erstellungs- und Genehmigungsprozesse als Workflow-Anwendung, eingebettet in bestehende Fachverfahren.

Kundenbetreuung

Prozessgestützte Betreuung: Der Vorgang führt durch die Bearbeitung, statt dass die Bearbeitung den Vorgang sucht.

Open Source

Wir haben die Spring-Boot-Starter für Camunda BPM erfunden. Sie sind heute der Standardweg, Camunda in Spring-Boot-Anwendungen zu betreiben. Dieses Engine-Wissen tragen wir auch in andere BPMN-Workflow-Engines wie Cibseven.

Die Fragen, die jetzt kommen.

?Lohnt sich das für unseren Prozess?

Faustregel: Wenn viele Vorgänge durch mehrere Hände gehen und Termine eine Rolle spielen, ja. Bei zehn Vorgängen im Jahr ist eine gute Checkliste billiger, und auch das sagen wir Ihnen.

?Warum nicht einfach im No-/Low-Code-Tool zusammenklicken?

Für einen linearen Ablauf mit überschaubarer Menge ist das oft die richtige Antwort. Die Grenze ist erreicht, sobald Ausnahmen, Fristen, Vertretungen und Nachweispflichten dazukommen oder der Prozess getestet, versioniert und über mehrere Umgebungen ausgerollt werden muss. BPMN ist an der Stelle selbst der Low-Code-Anteil: Der Fachbereich liest das Modell, aber darunter läuft eine Engine, die das aushält.

?Müssen wir dafür unsere Prozesse erst aufräumen?

Nein, das passiert unterwegs. Die Aufnahme deckt die Sonderfälle ohnehin auf; wir automatisieren dann bewusst den Teil, der stabil ist, und lassen den Rest als Entscheidung stehen.

?Bindet uns das an eine bestimmte Engine?

Sie setzen auf BPMN, einen offenen Standard, und auf eine Engine mit Open-Source-Kern, etwa Camunda oder Cibseven. Die Fachlogik liegt in Ihrer Anwendung, nicht in einem proprietären Werkzeugkasten.

?Wer pflegt die Modelle danach?

Ihr Team. Genau deshalb modellieren wir so, dass der Fachbereich mitlesen kann, und schulen die Leute, die es später ändern müssen.

Weitere Leistungen

Modernisierung

Monolithen und Host-Batches Schritt für Schritt in wartbare Architekturen überführen, während das System weiterläuft.

Mehr dazu →

APIs, Schnittstellen & Integration

APIs als belastbarer Vertrag und die Anbindung all der Systeme, die schon miteinander reden sollten, auch als Grundlage für No- und Low-Code.