Workflow-Monitoring: Automatisierungen zuverlässig betreiben

Eine Automatisierung, die einmal eingerichtet und nie wieder angeschaut wird, ist kein Erfolg – sie ist ein Risiko mit Verzögerung. Sie läuft zuverlässig, bis sich eine vorgelagerte Quelle ändert, ein Formularfeld umbenannt wird oder ein Drittanbieter seine Schnittstelle anpasst. Bis dahin hat niemand hingeschaut, weil alles „einfach funktioniert hat”. Genau das ist das Grundproblem von Workflow-Monitoring: Automatisierungen sind unsichtbar, solange sie laufen, und sichtbar erst, wenn Daten fehlen oder Kund:innen betroffen sind.

Dieser Artikel gehört zum Themen-Cluster Prozessautomatisierung und beantwortet die praktischen Fragen zum Betrieb bestehender Automatisierungen: Was muss überwacht werden, welche Metriken zählen, wie funktionieren Alerts sinnvoll, wie dokumentierst du Fehler, und wer ist eigentlich zuständig. Er richtet sich an Geschäftsführung, Operations, IT und Fachbereich in kleinen und mittleren Unternehmen – an alle, die eine oder mehrere Automatisierungen bereits im Einsatz haben oder kurz davor stehen, und die wissen wollen, wie man sie zuverlässig betreibt statt nur einrichtet.

Das Problem: Automatisierungen laufen unsichtbar

Wenn ein Prozess von Menschen ausgeführt wird, fallen Fehler meist auf – jemand merkt, dass eine Rechnung fehlt, eine Kundenanfrage unbeantwortet blieb, eine Zahl nicht plausibel aussieht. Sobald derselbe Prozess automatisiert läuft, verschwindet diese informelle Kontrolle. Niemand liest mehr jede verarbeitete Zeile, niemand prüft mehr jeden versendeten Datensatz. Das ist der ganze Sinn der Automatisierung – und gleichzeitig ihr blinder Fleck.

Drei Muster sehe ich in der Praxis immer wieder:

• Stille Fehlerhäufung. Eine Schnittstelle ändert sich leicht, ein Feld wird künftig anders formatiert, und die Automatisierung verarbeitet ab diesem Zeitpunkt fehlerhafte Daten weiter – oft wochenlang, bis ein Kunde sich meldet oder eine Auswertung nicht aufgeht.
• Der einzige Ansprechpartner ist weg. Die Person, die die Automatisierung eingerichtet hat, hat das Unternehmen verlassen oder die Rolle gewechselt. Niemand sonst weiß, wo man nachsieht, wenn etwas nicht stimmt.
• Alert-Müdigkeit. Es gibt zwar Benachrichtigungen, aber so viele und so unspezifisch, dass sie ungelesen im Postfach landen. Am Ende ist ein System mit zu vielen Alerts genauso blind wie eines ganz ohne.

Workflow-Monitoring ist die Antwort auf alle drei Muster: eine bewusste, wiederkehrende Prüfung, ob eine Automatisierung tut, was sie soll – nicht nur beim Start, sondern über die gesamte Betriebszeit.

Begriffe kurz geklärt

Vier Begriffe werden oft synonym verwendet, meinen aber unterschiedliche Dinge:

• Monitoring ist die laufende Beobachtung des Systemzustands – läuft der Prozess, wie lange dauert er, wie oft schlägt er fehl.
• Logging (Protokollierung) ist die dauerhafte Aufzeichnung einzelner Ereignisse – wer hat wann was ausgelöst, welche Daten wurden verarbeitet, welcher Fehler trat auf. Logging ist die Grundlage, auf der Monitoring aufbaut.
• Alerting ist die aktive Benachrichtigung, wenn ein definierter Schwellenwert überschritten oder ein bestimmter Fehlertyp erkannt wird. Nicht jedes Ereignis im Log muss einen Alert auslösen – sonst kippt es in Alert-Müdigkeit.
• Process Mining ist eine verwandte, aber umfassendere Disziplin: Statt einzelne Automatisierungen zu überwachen, wertet sie Ereignisdaten über einen ganzen Geschäftsprozess hinweg aus, um Engpässe und Abweichungen vom Sollablauf sichtbar zu machen – nützlich, wenn mehrere Automatisierungen und manuelle Schritte ineinandergreifen.

Für die meisten KMU-Automatisierungen reichen solide Protokollierung, gezieltes Monitoring der wichtigsten Läufe und wenige, gut kalibrierte Alerts. Process Mining wird erst relevant, wenn du komplexe, mehrstufige Prozesse mit vielen Beteiligten systematisch analysieren willst.

Was muss überwacht werden?

Die kurze Antwort steht oben in der Direktantwort: drei Ebenen – Lauf, Daten, Wirkung. Im Detail:

Ebene 1 – der Lauf selbst. Ist die Automatisierung überhaupt gestartet? Ist sie ohne Fehlermeldung durchgelaufen? Diese Ebene ist die einfachste zu überwachen, weil die meisten Automatisierungsplattformen sie ohnehin protokollieren – Erfolg, Fehlschlag, Laufzeit pro Ausführung.

Ebene 2 – die Datenqualität. Ein technisch „erfolgreicher” Lauf kann trotzdem falsche Ergebnisse liefern: ein leeres Pflichtfeld wird stillschweigend übernommen, ein Datumsformat falsch interpretiert, ein Datensatz doppelt verarbeitet. Diese Ebene erfordert Prüflogik, die über den reinen Erfolg-oder-Fehler-Status hinausgeht – zum Beispiel Plausibilitätschecks auf Wertebereiche oder Pflichtfelder.

Ebene 3 – die Wirkung nach außen. Wurde die E-Mail wirklich zugestellt oder nur „zum Versand übergeben”? Wurde der Datensatz im Zielsystem wirklich aktualisiert oder ist die Schreiboperation stillschweigend fehlgeschlagen? Diese Ebene ist am aufwändigsten zu prüfen, aber am wichtigsten, weil hier die Fehler entstehen, die tatsächlich bei Kund:innen oder Behörden ankommen.

Ergänzend gilt für alle drei Ebenen: Überwache nicht nur, ob etwas passiert ist, sondern auch, ob etwas nicht passiert ist, das hätte passieren sollen. Ein Workflow, der stillschweigend aufhört, Datensätze zu verarbeiten, weil die Quelle leer bleibt, erzeugt keinen einzigen Fehler – und bleibt trotzdem unbemerkt, wenn niemand das Ausbleiben von Läufen prüft.

Welche Metriken sind relevant?

Nicht jede messbare Größe ist eine gute Metrik für den Betrieb. Relevant sind die, die eine Entscheidung auslösen können – „schauen wir uns das an” oder „das ist normal”. Die folgende Matrix ordnet die wichtigsten Metriken nach Aussagekraft und Aufwand:

Metrik	Was sie zeigt	Erfassungsaufwand	Typischer Auslöser für Alert
Erfolgsquote pro Lauf	Anteil fehlerfreier Ausführungen in einem Zeitraum	Gering – meist von der Plattform mitgeliefert	Deutlicher Abfall gegenüber dem üblichen Wert
Fehlerarten und -häufigkeit	Welche Fehler wiederholen sich, welche sind neu	Gering bis mittel	Neuer, bisher unbekannter Fehlertyp
Laufzeit pro Ausführung	Ob ein Prozessschritt spürbar langsamer wird	Gering	Laufzeit deutlich über dem Normalwert
Ausbleibende Läufe	Ob ein erwarteter Lauf gar nicht stattfindet	Mittel – erfordert eine Erwartungsprüfung, nicht nur Fehlerprüfung	Erwarteter Lauf fehlt im definierten Zeitfenster
Manuelle Eingriffe	Wie oft Menschen korrigierend eingreifen müssen	Mittel – muss aktiv erfasst werden	Anstieg der Eingriffe über mehrere Läufe
Verarbeitungsvolumen	Wie viele Fälle/Datensätze durchlaufen die Automatisierung	Gering	Ungewöhnlicher Ausschlag nach oben oder unten

Eigene Matrix Philogic Labs, aus Beratungs- und Umsetzungsprojekten mit Automatisierungen bei KMU.

Der wichtigste Punkt in dieser Tabelle steht nicht in einer Zelle, sondern zwischen den Zeilen: Jede dieser Metriken braucht einen Referenzwert aus der Normalzeit. Ohne Baseline ist „Fehlerquote 4 %” bedeutungslos – ist das viel oder wenig? Erst der Vergleich mit dem eigenen historischen Normalwert macht eine Metrik zu einer Entscheidungsgrundlage. In der Praxis reicht dafür oft schon ein einfacher Blick auf die letzten vier bis acht Wochen, bevor du Schwellenwerte für Alerts festlegst.

Wie funktionieren Alerts?

Ein gutes Alert-System trifft eine Unterscheidung, die viele Standardkonfigurationen nicht treffen: nicht jeder Fehler verdient eine sofortige Benachrichtigung. Microsoft beschreibt das für Power Automate exemplarisch mit zwei Alert-Typen: Ein Per-Run-Alert wird kurz nach einem fehlgeschlagenen Lauf verschickt, aber nur dann, wenn das System die Fehlerursache kennt und eine konkrete Lösung nennen kann – etwa eine abgelaufene Verbindung oder eine gedrosselte Aktion. Für denselben Workflow gilt danach eine 28-tägige Abkühlphase, bevor der nächste Per-Run-Alert verschickt wird, damit wiederkehrende Fehler nicht zu einer Alert-Flut führen. Parallel dazu gibt es einen wöchentlichen Sammelbericht, der wirklich alle Fehlschläge zusammenfasst – auch die, für die kein sofortiger Alert ausgelöst wurde, weil die Ursache nicht eindeutig war.

Dieses Zwei-Ebenen-Prinzip lässt sich unabhängig vom eingesetzten Tool übertragen:

1. Sofort-Alert nur bei bekannten, klar zuordenbaren Fehlern – an die Person, die unmittelbar reagieren kann und muss.
2. Gebündelte Übersicht in regelmäßigem Abstand für alles andere, damit auch unklare oder seltene Fehler nicht untergehen, ohne dass jeder einzelne eine Unterbrechung erzwingt.
3. Eskalationsstufen definieren, statt jeden Alert gleich zu behandeln: Ein einzelner fehlgeschlagener Lauf ist meist kein Notfall, eine ausbleibende Serie von Läufen oder ein Fehler mit Kundenkontakt schon.

Ohne diese Abstufung passiert eines von zwei Dingen: Entweder es gibt zu viele Alerts, und sie werden nach kurzer Zeit ignoriert – die eigentliche Gefahr von Alert-Müdigkeit. Oder es gibt zu wenige, und echte Probleme bleiben unbemerkt, weil das System „lieber leise” konfiguriert wurde, um niemanden zu stören. Beides führt zurück zum Ausgangsproblem: unsichtbare Fehler.

Wie dokumentiert man Fehler?

Ein Alert ohne Dokumentation verpufft. Wenn dieselbe Fehlerursache in drei Monaten wieder auftaucht, will niemand von vorne anfangen, sie zu verstehen. Ein brauchbares Fehlerprotokoll enthält für jeden Vorfall mindestens:

• Zeitpunkt des Auftretens (nicht der Entdeckung – beides kann weit auseinanderliegen)
• Betroffener Prozessschritt beziehungsweise Workflow und Ausführung
• Fehlerbeschreibung und vermutete Ursache, so konkret wie möglich
• Behebung, die vorgenommen wurde, und ob sie dauerhaft oder provisorisch war
• Verantwortliche Person, die den Vorfall bearbeitet hat

Wichtig ist der Ort: ein durchsuchbares, gemeinsam zugängliches Protokoll – ein einfaches Tabellenblatt oder Ticket-System reicht oft aus – statt verstreuter E-Mails, Chat-Nachrichten oder „das weiß nur Person X”. Der Wert der Dokumentation zeigt sich nicht beim ersten Vorfall, sondern beim dritten: Muster werden erst über mehrere Einträge hinweg sichtbar.

Wer personenbezogene Daten verarbeitet oder sicherheitsrelevante Ereignisse protokolliert, sollte zusätzlich Aufbewahrungsfristen und Löschregeln vorab festlegen. Der BSI-Mindeststandard zur Protokollierung und Detektion von Cyber-Angriffen – zwar für Bundesbehörden verbindlich, aber als Orientierung auch für Unternehmen brauchbar – verlangt explizit, dass Protokoll- und Protokollierungsdaten nach Ablauf einer festgelegten Speicherfrist gelöscht werden, und dass die Zuständigkeiten für Protokollierung und Detektion organisatorisch klar geregelt sind (Stand Juli 2026, keine Rechtsberatung). Die konkrete Frist hängt von Datenart und Rechtsgrundlage ab – das gehört im Zweifel zu Datenschutzbeauftragten oder Rechtsberatung, nicht in eine pauschale Empfehlung.

Wer ist verantwortlich?

Monitoring ohne benannte Zuständigkeit ist Theater. Für den Betrieb einer produktiven Automatisierung reichen in der Regel zwei Rollen, die explizit benannt – nicht implizit vorausgesetzt – werden müssen:

• Der Prozess-Owner (meist im Fachbereich, der den automatisierten Prozess fachlich verantwortet) erhält Alerts, entscheidet, ob ein Fehler dringend, wichtig oder vernachlässigbar ist, und ist Ansprechpartner, wenn Kund:innen oder Kolleg:innen Auffälligkeiten melden.
• Die technische Anlaufstelle (IT oder externe Umsetzungspartner) behebt technische Ursachen – abgelaufene Zugangsdaten, geänderte Schnittstellen, fehlerhafte Logik – und pflegt das Fehlerprotokoll technisch.

Bei sehr kleinen Unternehmen können beide Rollen in einer Person zusammenfallen. Entscheidend ist nicht die Anzahl der Rollen, sondern dass die Frage „wer schaut sich das an, wenn ein Alert kommt” eine klare, dokumentierte Antwort hat – und dass diese Antwort auch gilt, wenn die zuständige Person im Urlaub ist. Eine Vertretungsregelung ist deshalb kein Nice-to-have, sondern Teil einer funktionierenden Zuständigkeit.

Umsetzung: vom ersten Lauf zum stabilen Betrieb

In meiner Arbeit mit KMU-Automatisierungen hat sich ein einfaches Vorgehen bewährt, das ohne zusätzliche Tools startet und erst bei Bedarf ausgebaut wird:

Schritt 1 – Normalzustand erfassen. Bevor du Schwellenwerte für Alerts definierst, beobachte die Automatisierung einige Wochen im laufenden Betrieb und notiere die üblichen Werte für Laufzeit, Fehlerquote und Volumen. Ohne diese Referenz sind Alert-Schwellen reine Schätzung.

Schritt 2 – die eingebauten Bordmittel nutzen. Die meisten Automatisierungsplattformen – von Power Automate über Zapier bis n8n – protokollieren Läufe, Erfolg und Fehler bereits von Haus aus. Bevor du eine separate Monitoring-Lösung aufbaust, prüfe, was die vorhandene Plattform an Run-History, Fehlerdetails und Benachrichtigungen bereits mitliefert.

Schritt 3 – zwei bis drei kritische Alerts definieren. Nicht für jede mögliche Störung, sondern für die, die wirklich Handeln erfordern: Lauf komplett ausgeblieben, Fehlerquote über dem beobachteten Normalwert, bekannter kritischer Fehlertyp. Mehr Alerts bedeuten nicht mehr Sicherheit, sondern mehr Rauschen.

Schritt 4 – Fehlerprotokoll einrichten, wie oben beschrieben, bevor der erste Vorfall eintritt – nicht danach.

Schritt 5 – Verantwortung und Vertretung dokumentieren und beiden beteiligten Rollen bekannt machen.

Ein Praxisbeispiel aus meiner Arbeit: Bei einer automatisierten Rechnungsprüfung, die eingehende Belege kategorisiert und Buchungsvorschläge erstellt, hatten wir anfangs nur den technischen Erfolgsstatus im Blick – der Lauf war fast immer „erfolgreich”. Erst nach Einführung einer einfachen Plausibilitätsprüfung (fehlt ein Pflichtfeld, weicht ein Betrag stark vom historischen Durchschnitt für diesen Lieferanten ab) wurden Fälle sichtbar, die technisch fehlerfrei, aber inhaltlich falsch verarbeitet worden waren. Die Lehre daraus: Der technische Erfolg eines Laufs sagt wenig über die inhaltliche Richtigkeit aus – Ebene 1 und Ebene 2 aus dem Abschnitt oben müssen beide geprüft werden, nicht nur die einfachere von beiden.

Wenn du an dieser Stelle merkst, dass eure bestehenden Automatisierungen ohne systematisches Monitoring laufen, ist das kein Grund, alles neu aufzusetzen – meist reicht es, die vorhandene Plattform-Protokollierung gezielt auszuwerten und die fehlenden Schritte zwei bis vier oben nachzuziehen. Wo diese Lücke systematisch geprüft werden soll, hilft ein Prozess-Audit im Rahmen einer KI-Beratung; für den direkten Einstieg eignet sich ein kurzes Erstgespräch.

Risiken & Grenzen

Workflow-Monitoring löst nicht jedes Problem, und es hat eigene Fallstricke:

• Zu viele Alerts sind so gefährlich wie zu wenige. Wer jede Kleinigkeit meldet, erzieht das Team dazu, Alerts zu ignorieren. Die Kalibrierung braucht Zeit und Nachjustierung, nicht nur Einrichtung.
• Monitoring ersetzt kein gutes Prozessdesign. Ein Workflow, der von Anfang an schlecht gebaut ist – fehlende Fehlerbehandlung, keine Wiederholungslogik, ungeprüfte Eingaben – produziert mit gutem Monitoring nur besser dokumentierte Fehler, nicht weniger davon.
• Wirkungsebene (Ebene 3) ist oft aufwändiger als gedacht. Zu prüfen, ob eine E-Mail wirklich zugestellt oder ein Zieldatensatz wirklich geschrieben wurde, erfordert teils zusätzliche Rückmeldeschritte, die nicht jede Integration von Haus aus liefert. Hier lohnt sich eine bewusste Priorisierung: zuerst die Prozesse mit Kundenkontakt oder finanzieller Wirkung, danach interne Routineaufgaben.
• Personenbezogene Daten in Protokollen sind ein eigenes Thema. Fehlerprotokolle, die Kundendaten enthalten, unterliegen denselben Datenschutzanforderungen wie die Automatisierung selbst – Aufbewahrungsfristen und Zugriffsbeschränkungen gehören von Anfang an mitgedacht, nicht nachträglich.
• Es gibt keine Garantie für Fehlerfreiheit. Auch mit Monitoring, Alerts und Dokumentation werden Fehler passieren – der Unterschied ist, dass sie schneller auffallen und nachvollziehbar sind, nicht dass sie ausbleiben.

Checkliste: Workflow-Monitoring einführen

1. Wir wissen für jede produktive Automatisierung, was ein „normaler” Lauf bedeutet (Laufzeit, Fehlerquote, Volumen).
2. Wir prüfen alle drei Ebenen – Lauf, Datenqualität, tatsächliche Wirkung – nicht nur den technischen Erfolgsstatus.
3. Wir nutzen zuerst die eingebaute Protokollierung der eingesetzten Plattform, bevor wir zusätzliche Tools aufbauen.
4. Wir haben zwei bis drei kritische Alerts definiert – keine Alert-Flut, aber auch keine Blindheit.
5. Ausbleibende Läufe werden erkannt, nicht nur fehlgeschlagene.
6. Es gibt ein durchsuchbares Fehlerprotokoll mit Zeitpunkt, Ursache, Behebung und Verantwortlicher.
7. Aufbewahrungsfristen für Protokolldaten sind festgelegt, insbesondere bei personenbezogenen Daten.
8. Ein Prozess-Owner ist benannt, der Alerts erhält und über Korrekturen entscheidet.
9. Eine technische Anlaufstelle für IT-nahe Fehlerursachen ist definiert.
10. Es gibt eine Vertretungsregelung, falls die zuständige Person nicht erreichbar ist.
11. Wiederkehrende Fehlerursachen werden aus dem Protokoll heraus systematisch behoben, nicht nur einzeln „weggeklickt”.

Wenn ihr mehrere Automatisierungen im Team betreibt und diese Punkte noch nicht dokumentiert sind, ist das ein guter Anlass für ein kurzes Erstgespräch – dort lässt sich in wenigen Minuten einordnen, wo der größte blinde Fleck liegt. Für Teams, die zusätzlich den sicheren Umgang mit KI-gestützten Automatisierungen im Alltag aufbauen wollen, bieten sich passende Schulungen an.