Prozessautomatisierungssoftware
Prozessautomatisierung Engineering Suite
End-to-End-Workflow-Engineering
Wir bauen den gesamten Workflow auf Ihrem Stack — Eingangsformular, Zustandsautomat, rollenbasierte Prüfoberfläche, Aktualisierung des Folgesystems. Das Ergebnis ist ein laufender Prozess statt eines Workflow-Diagramms in einer Folie. Jeder Schritt wird protokolliert, der Audit-Trail wird mit dem Projekt geliefert, nicht als Nachfolgeprojekt.
Zustandsautomat-gesteuerte Workflows
Jeder Prozess wird als expliziter Zustandsautomat modelliert: Initialisierung, Verarbeitung, prüfbereit, Folgerolle, abgeschlossen, plus explizite Fehlerzustände. Übergänge sind der einzige Weg, wie Arbeit vorankommt, damit nichts in einem E-Mail-Thread versickert. Dieses Muster läuft in Schweizer Back-Office-Operationen und in BPMN-Code-Generation-Projekten.
Rollenbasierte Prüfung und Freigabe
Wer welche Felder sieht und welchen Übergang freigeben darf, wird im Code erzwungen, nicht in einem Wiki beschrieben. Einkauf, Finanzen, Compliance und Operations sehen jeweils nur ihren Ausschnitt. Eskalationen werden automatisch ausgelöst, wenn ein Schritt seine SLA überschreitet. Dasselbe Rollenmodell läuft in unseren Schweizer PIM- und Versicherungs-Deployments.
BPMN zu lauffähigem Code
Wenn ein Prozess bereits in BPMN dokumentiert ist, nutzen wir es. Unser Team hat ein Code-Generation-Tooling gebaut, das BPMN-Flussdiagramme in ausführbare Workflow-Skelette umwandelt — Zustandsautomat, Rollenrechte, Übergangshandler. Engineers erweitern den generierten Code; das Diagramm bleibt die Quelle der Wahrheit für das Business.
Dokumenten-KI im Workflow
Beginnt ein Prozess mit einem eingehenden Dokument — Lieferanten-PDF, Schadenformular, Vertrag — setzen wir unsere Mistral-OCR- plus OpenAI-JSON-Mode-Extraktion als ersten Zustand ein. Die strukturierten Daten fliessen ohne separates Integrationsprojekt in den Workflow. Prozessautomatisierung und Dokumenteneingang werden zu einem Projekt.
Schweizer Datenhoheit und Audit
Workflows laufen auf EU- oder Schweizer Infrastruktur, beim Kunden vor Ort wenn FINMA oder MDR es verlangen. Jeder Übergang, jede Freigabe, jede Feldänderung wird in Audit-Qualität protokolliert. Für Souveränitätskunden läuft die Dokumenten-KI über unseren Apertus-Track, damit Inhalte die Schweizer Jurisdiktion nie verlassen.
Wie wir es bauen
Workflow-Discovery
Wir beginnen mit dem Prozess, der heute die meiste Operator-Zeit kostet — dem mit dem grössten Rückstau oder den lautesten Beschwerden. Gemeinsam mit Operations kartieren wir aktuelle Zustände, Rollen, Übergaben und das Folgesystem, das aktualisiert werden muss. Das Resultat ist ein Zustandsdiagramm, keine Wunschliste.
Zustandsautomat-Lock
Vor jeder Zeile Code wird der Zustandsautomat festgezurrt — jeder Zustand, jeder erlaubte Übergang, jede Rolle pro Übergang. Edge Cases und Fehlerzustände werden vorab benannt. Diese Spezifikation ist das, wogegen das Team baut, und das Business gibt sie frei, bevor das Engineering startet.
Pilot-Workflow-Build
Wir bauen den ersten Workflow End-to-End auf Ihrem Stack: Eingang, Zustandsautomat, rollenbasierte UI, Folge-Integration. Engineers erweitern das Scaffolding statt aus einem leeren Repo zu starten. Der Pilot erreicht für einen Workflow die Produktion in einem definierten Sprintfenster statt in einem Quartals-Rollout.
Operator-Oberfläche feintunen
Sobald Operatoren den Workflow täglich nutzen, justieren wir die Prüfoberfläche — Feldgruppierung, Eskalations-Trigger, Massenaktionen — basierend darauf, wie das Team tatsächlich arbeitet. Hier hört der Workflow auf, sich nach Software anzufühlen, und wird zu einem Werkzeug, das das Team besitzt.
Horizontaler Roll-Out
Sobald der erste Workflow stabil läuft, erweitern wir den nächsten Prozess auf derselben Engine — neuer Zustandsautomat, neue Rollen, gleiches Scaffolding. Workflow Nummer zwei und drei werden zu Konfigurations-Sprints in Wochen statt zu Engagements in Quartalen.
Übergabe und Support
Wir übergeben die Zustandsautomat-Definitionen, Rollenleitfäden, das Prompt-Register (wo Dokumenten-KI im Spiel ist) und ein Ops-Runbook. Ein leichtes Support-Engagement deckt Accuracy-Drift und Edge Cases ab. Die meisten Kunden übernehmen den Tagesbetrieb innerhalb von sechs Monaten nach Go-Live in-house.
Wir beginnen mit dem Prozess, der heute die meiste Operator-Zeit kostet — dem mit dem grössten Rückstau oder den lautesten Beschwerden. Gemeinsam mit Operations kartieren wir aktuelle Zustände, Rollen, Übergaben und das Folgesystem, das aktualisiert werden muss. Das Resultat ist ein Zustandsdiagramm, keine Wunschliste.
Vor jeder Zeile Code wird der Zustandsautomat festgezurrt — jeder Zustand, jeder erlaubte Übergang, jede Rolle pro Übergang. Edge Cases und Fehlerzustände werden vorab benannt. Diese Spezifikation ist das, wogegen das Team baut, und das Business gibt sie frei, bevor das Engineering startet.
Wir bauen den ersten Workflow End-to-End auf Ihrem Stack: Eingang, Zustandsautomat, rollenbasierte UI, Folge-Integration. Engineers erweitern das Scaffolding statt aus einem leeren Repo zu starten. Der Pilot erreicht für einen Workflow die Produktion in einem definierten Sprintfenster statt in einem Quartals-Rollout.
Sobald Operatoren den Workflow täglich nutzen, justieren wir die Prüfoberfläche — Feldgruppierung, Eskalations-Trigger, Massenaktionen — basierend darauf, wie das Team tatsächlich arbeitet. Hier hört der Workflow auf, sich nach Software anzufühlen, und wird zu einem Werkzeug, das das Team besitzt.
Sobald der erste Workflow stabil läuft, erweitern wir den nächsten Prozess auf derselben Engine — neuer Zustandsautomat, neue Rollen, gleiches Scaffolding. Workflow Nummer zwei und drei werden zu Konfigurations-Sprints in Wochen statt zu Engagements in Quartalen.
Wir übergeben die Zustandsautomat-Definitionen, Rollenleitfäden, das Prompt-Register (wo Dokumenten-KI im Spiel ist) und ein Ops-Runbook. Ein leichtes Support-Engagement deckt Accuracy-Drift und Edge Cases ab. Die meisten Kunden übernehmen den Tagesbetrieb innerhalb von sechs Monaten nach Go-Live in-house.
Warum diese Engine, nicht generische Automatisierung
Zustandsautomaten statt Happy-Path-Skripte
Generische Automatisierungstools setzen den Happy Path voraus und brechen an Ausnahmen. Jeder Workflow, den wir ausliefern, ist ein expliziter Zustandsautomat — jeder Übergang, jeder Fehlerzustand, jede Eskalation wird vorab benannt. Wenn Operations im sechsten Monat auf einen Edge Case stösst, ist er bereits ein definierter Zustand mit definiertem Verantwortlichen.
Rollen-Gating im Code, nicht im Wiki
Wer einen Workflow von einem Zustand in den nächsten bewegen darf, wird serverseitig erzwungen, nicht in Onboarding-Dokumenten beschrieben. Einkauf, Finanzen, Compliance und Operations sehen und editieren nur ihren Ausschnitt. Dasselbe Rollenmuster läuft in unseren Schweizer PIM-, Versicherungs- und Anwalts-Deployments.
BPMN-Diagramme, die tatsächlich ausführen
Wenn Ihr Business bereits BPMN-Diagramme pflegt, nutzen wir sie. Unsere Code-Generation erzeugt aus einem BPMN-Flow ein ausführbares Workflow-Skelett — Zustandsautomat, Rollenrechte, Übergangshandler. Das Diagramm bleibt die Spezifikation, Engineering erweitert den generierten Code, beide bleiben synchron.
Dokumenten-KI dort, wo Prozesse mit Papier beginnen
Viele Workflows starten mit einem eingehenden Dokument — Schaden, Rechnung, Vertrag. Wir setzen Mistral OCR plus OpenAI-JSON-Mode-Extraktion als ersten Zustand ein, damit der Workflow ab Übergang eins strukturierte Daten hat. Prozessautomatisierung und Dokumenten-Eingang werden zu einem Engagement, nicht zu zwei Integrationen.
Audit-fähig per Konstruktion
Jeder Übergang, jede Freigabe, jede Feldänderung wird protokolliert. Der Audit-Trail wird mit dem Projekt geliefert, nicht als Nachfolgeprojekt. Für FINMA-, MDR- und IVDR-sensitive Kunden sind GDPR-Posture und Schweizer Datenhoheit Teil des Deployment-Templates, inklusive signierter Übergangshistorie.
Schweizer Delivery, kein US-Automatisierungs-Reseller
Das Team, das Ihren Workflow baut, ist dasselbe Team, das Schweizer PIM-, Schadens- und Anwalts-Workflow-Plattformen entwickelt hat. EN und DE sind in jeder Operator-Oberfläche eingebaut; FR und IT erweitern ohne Code-Änderung. Dieselbe Engineering-Disziplin, drei produktive Vertikalen.
Häufig gestellte Fragen
Back-Office-Prozesse mit mehreren Rollen, expliziten Übergaben und einem Folgesystem, das aktualisiert werden muss — Lieferanten-Onboarding, Schadeneingang, Vertragsprüfung, Produktdaten-Veröffentlichung. Wir fokussieren auf Workflows, in denen der Engpass Koordination ist, nicht Kreativität, und in denen eine falsche Übergabe Stunden pro Fall kostet.
Beides. Wenn Sie Camunda oder n8n bereits betreiben, ergänzen wir sie um rollenbasierte UI, Dokumenten-KI und Folge-Konnektoren. Wenn nichts vorhanden ist, bauen wir eine Custom-State-Machine-Engine auf Ihrem Stack — Laravel, Node oder .NET — sodass der Workflow im selben Codebase liegt wie die Daten. Beide Optionen sind produktiv.
Ein einzelner Pilot-Workflow — Discovery, State-Machine-Lock, Build, Operator-Tuning — erreicht innerhalb von 8 bis 12 Wochen die Produktion. Gleiche Engineering-Qualität und gleiche Prüfoberfläche wie im vollen Rollout. Folge-Workflows auf derselben Engine gehen in 3 bis 6 Wochen live, sobald das Scaffolding steht.
Zustände, Rollen und Feldrechte sind in einem Admin-Modell definiert, sodass Operations einen bestehenden Workflow erweitern kann — Zustand hinzufügen, Approver wechseln, Eskalation justieren — ohne Release. Ein komplett neuer Workflow ist ein Konfigurations-Sprint von 1 bis 2 Wochen statt eines Neubaus.
Wenn Sie BPMN-Diagramme pflegen, speisen wir sie in unseren Code-Generator ein, der ein Workflow-Skelett produziert — Zustandsautomat, Rollenrechte, Übergangshandler — das Engineers anschliessend erweitern. Das Diagramm bleibt Quelle der Wahrheit, Änderungen pendeln ohne manuelle Neuschreibung. Pilot-Output liefert in 2 bis 4 Wochen.
EU-gehostet als Standard für GDPR. Für FINMA-, MDR- oder IVDR-Workloads deployen wir auf Schweizer Servern, on-premises oder beim Kunden, und routen jeden KI-Schritt über unseren Apertus-Souveräne-LLM-Track, damit Dokumenten-Inhalte keine öffentlichen Endpunkte erreichen. Audit-Logs bleiben standardmässig in der Jurisdiktion.
Jeder Zustand hat eine SLA und einen expliziten Fehlerzustand. Überschreitet ein Schritt seine SLA, eskaliert der Workflow automatisch zur nächsten Rolle oder zu einem konfigurierten Supervisor. Fehlgeschlagene KI-Extraktionen landen in einer Human-in-the-Loop-Queue. Nichts wartet stumm in einem Posteingang; jede Ausnahme hat Verantwortlichen und Frist.
Nein. Zustandsautomat-Definitionen, Rollenmodelle, Integrationen und (wo eingesetzt) das Prompt-Register werden mit einem Runbook an Ihr Team übergeben. Die meisten Kunden halten uns auf einem leichten Support-Retainer für Accuracy-Drift und Edge Cases; die Workflow-Engine selbst bleibt in Ihrem Repository und Ihrer Jurisdiktion.
Über SAPIENTROQ
Sind Sie an einer Lösung interessiert?
Wir freuen uns, Ihnen die Möglichkeiten unverbindlich aufzuzeigen.
Roland Kurmann
CEO, SAPIENTROQ
