Was ist Geschäftsprozessmonitoring – und warum die meisten Teams die falschen Dinge verfolgen

Hier ist ein Muster, das ich im Support immer wieder sehe. Ein Team erstellt ein Dashboard. Das Dashboard zeigt Grün. Sie sagen sich, sie hätten Transparenz. Dann geht weiter unten im Prozess etwas schief – ein verzögerter Bestellzyklus, ein verpasstes SLA, eine Compliance-Lücke, die sich seit drei Wochen aufgebaut hat – und die erste Frage lautet: Warum haben wir das nicht früher erkannt?

Die Antwort lautet fast immer, dass sie die falschen Dinge beobachtet haben. Die Serververfügbarkeit war grün. Die vorgelagerte Anwendung hat reagiert. Niemand hatte definiert, was für den End-to-End-Prozess tatsächlich „gesund“ bedeutet. Also wurde nichts markiert. Das Dashboard war nicht falsch. Es hat ihnen nur nicht gesagt, was sie wissen mussten.

Diese Lücke zwischen technischem Monitoring und tatsächlicher Prozessgesundheit soll Geschäftsprozessmonitoring schließen. Und die meisten Teams entdecken sie erst, nachdem bereits etwas schiefgelaufen ist.

Was Teams spät lernen

• Prozessmonitoring verfolgt, wie Prozesse im Live-Betrieb funktionieren, nicht wie sie konzipiert wurden.
• Die meisten operativen Ausfälle sind in Prozessdaten sichtbar, bevor sie zu Krisen werden – aber nur, wenn Sie End-to-End-KPIs statt Server-Logs beobachten.
• Monitoring macht Probleme sichtbar. Es behebt sie nicht. Dieses Missverständnis bremst die meisten Teams nach drei Wochen aus.
• Kleine Teams verlieren durch unerkannte Engpässe genauso viel wie große. Das Skalierungsargument, darauf zu verzichten, ist falsch.

Was ist Geschäftsprozessmonitoring?

Geschäftsprozessmonitoring ist die kontinuierliche Verfolgung und Analyse der Ausführung von Prozessen in Echtzeit, gemessen anhand vordefinierter KPIs, um Anomalien zu erkennen, die End-to-End-Prozessgesundheit zu messen und die für Verbesserungen erforderlichen Daten bereitzustellen. Das Schlüsselwort lautet kontinuierlich. Dabei handelt es sich nicht um ein vierteljährliches Audit oder eine einmalige Überprüfung eines Prozessdiagramms. Es ist die laufende Beobachtung von aktiven, noch laufenden Prozessen, während sie tatsächlich ausgeführt werden.

Die BOC Group, die dieses Thema fundiert behandelt, beschreibt es als die Untersuchung von Prozessabläufen, Leistungskennzahlen und Wartezeiten während der Ausführung. Nicht vor der Ausführung, nicht danach – währenddessen. Diese Unterscheidung ist wichtig, denn bis eine Post-Mortem-Analyse ein Problem erkennt, hat der Kunde es bereits gespürt.

Was Prozessmonitoring nicht ist: Es ist keine Überwachung der Systemverfügbarkeit, kein Log-Aggregator und keine statische Prozesslandkarte. Diese Dinge können neben Monitoring existieren, aber keines davon ist Monitoring. Zu beobachten, ob Ihre Server laufen, sagt Ihnen etwas über Ihre Infrastruktur. Zu beobachten, ob Ihr Order-to-Cash-Zyklus innerhalb des SLA abgeschlossen wird, sagt Ihnen etwas über Ihr Unternehmen.

Der Unterschied besteht darin, ob Sie das System oder das Ergebnis messen.

Geschäftsprozessmonitoring im Vergleich zur allgemeinen Prozessdokumentation

Prozessdokumentation zeigt Ihnen, wie ein Prozess funktionieren sollte. Geschäftsprozessmonitoring zeigt Ihnen, wie er tatsächlich abläuft.

Dokumentation ist ein Designartefakt. Sie beschreibt den Sollzustand: Wer macht was, in welcher Reihenfolge und was jeden Schritt auslöst. Sie ist nützlich für das Onboarding, für Audits und als Referenz. Sie ist nicht nützlich, um einen Engpass zu erkennen, der letzten Dienstag entstanden ist, weil ein neuer Genehmigungsschritt hinzugefügt wurde, ohne den nachgelagerten SLA-Timer zu aktualisieren.

Monitoring verfolgt die Prozessausführung, während sie stattfindet. In Anlehnung an die Einordnung der BOC Group untersucht es das tatsächliche Ablaufverhalten, Leistungskennzahlen und Wartezeiten in Echtzeit. Ein dokumentierter Prozess besagt, dass die Rechnungsfreigabe 48 Stunden dauern sollte. Monitoring zeigt Ihnen, dass sie in den vergangenen zwei Wochen durchschnittlich 11 Tage gedauert hat und dass der Engpass an einem bestimmten Genehmigungs-Node liegt. Die Dokumentation macht das nicht sichtbar. Die Analyse von Geschäftsprozessen während ihrer Ausführung schon.

Teams, die diese beiden Dinge verwechseln, aktualisieren häufig ihre Prozesslandkarten, anstatt ihre Prozesse zu beheben. Das ist nicht dasselbe.

Wo Geschäftsprozessmonitoring in BPM einzuordnen ist

Business Process Management hat einen Lebenszyklus: Design, Modellierung, Ausführung, Monitoring, Optimierung. Prozessmonitoring ist der Feedback-Mechanismus in diesem Kreislauf. Ohne ihn ist BPM eine Einbahnstraße. Sie definieren einen Prozess, führen ihn aus und hoffen, dass er wie geplant funktioniert. Mit Monitoring schließen Sie den Kreislauf.

SAP beschreibt dies als Transparenz über die End-to-End-Prozessgesundheit – die Fähigkeit zu bestätigen, dass ein definierter Prozess tatsächlich wie vorgesehen funktioniert, und zu erkennen, wo ein Redesign erforderlich ist, wenn dies nicht der Fall ist. Das macht aus BPM eine kontinuierliche Verbesserungsmaschine statt einer Dokumentationsübung. Monitoring sorgt dafür, dass der „kontinuierliche“ Teil real wird.

Das PMLC-Modell der BOC Group platziert Monitoring direkt zwischen Ausführung und Optimierung. Sie können nicht optimieren, was Sie nicht messen können. Sie können nicht messen, was Sie nicht beobachten. Prozessmonitoring ist der Punkt, an dem Daten in den BPM-Lebenszyklus gelangen, und ohne ihn schließt sich der Kreislauf nie.

Die KPIs, die wirklich etwas über Prozessgesundheit aussagen

Der Fehler, den die meisten Teams machen, besteht nicht darin, zu wenige KPIs zu verfolgen. Sie verfolgen die falschen, meist weil sie auf Kennzahlen zurückgreifen, die bereits verfügbar waren, statt auf Kennzahlen, die Prozessgesundheit tatsächlich beschreiben. Ich sehe immer wieder Dashboards voller Server-Antwortzeiten und Fehlerzahlen, aber ohne Transparenz über Durchlaufzeit oder Durchsatz. Das ist nicht dasselbe.

Hier sind die fünf KPIs, die Forschung zum Prozessmonitoring durchgängig als aussagekräftig für Erkenntnisse zur Prozessleistung identifiziert:

Der KPI Durchlaufzeit verdient bei Geschäfts-Workflows besondere Aufmerksamkeit, weil er direkt mit dem Kundenerlebnis verbunden ist. Ein Prozess, der technisch abgeschlossen wird, aber dreimal länger dauert als vorgesehen, scheitert – selbst wenn jeder einzelne Schritt technisch ausgeführt wurde. Das ist die Art von Ausfall, die nicht in Uptime-Kennzahlen erscheint, aber sechs Monate später in Churn-Daten sichtbar wird.

Beginnen Sie mit zwei oder drei dieser KPIs, nicht mit allen fünf gleichzeitig.

Geschäftsprozessmonitoring in Industrie- und Geschäfts-Workflow-Kontexten

Die Logik des Prozessmonitorings gilt in zwei sehr unterschiedlichen Bereichen. Es lohnt sich, die Mechanik klar zu unterscheiden, weil Menschen sie häufig vermischen oder annehmen, dass nur einer der Bereiche für ihre Situation relevant ist.

Industrielles Prozessmonitoring: Sensoren, SCADA und Echtzeitvariablen

In industriellen Umgebungen basiert Prozessmonitoring auf physischer Messung. Sensoren erfassen Temperatur, Druck, Durchflussrate und andere Prozessparameter in Echtzeit. Steuerungssysteme – SCADA (Supervisory Control and Data Acquisition) und DCS (Distributed Control Systems) – bündeln diese Sensordaten und vergleichen sie mit definierten sicheren Betriebsbereichen. Wenn Prozessbedingungen abweichen, lösen sie Warnungen oder automatisierte Reaktionen aus.

Die Forschung von ATRIA Innovation zum industriellen Prozessmonitoring betont, dass das Ziel eine kontinuierliche Beobachtung ist, um Sicherheit, Qualität und Effizienz in Produktionsumgebungen zu gewährleisten. Die Echtzeitüberwachung physischer Variablen ermöglicht die frühzeitige Erkennung ungewöhnlicher Betriebsbedingungen, bevor sie zu Sicherheitsvorfällen oder Qualitätsmängeln werden. Ein Temperaturanstieg, für dessen Erkennung ein manueller Prüfzyklus 20 Minuten benötigen würde, kann in Sekunden eine Reaktion des Steuerungssystems auslösen, wenn die richtigen Sensoren und Schwellenwerte eingerichtet sind.

Die finanziellen Auswirkungen sind nicht abstrakt. Wiss, unter Bezug auf Deloitte und Siemens, schätzt die Kosten ungeplanter Ausfallzeiten für industrielle Hersteller auf jährlich 50 Milliarden US-Dollar, wobei die Kosten pro Vorfall branchenübergreifend 125.000 US-Dollar pro Stunde übersteigen. Das ist kein Ausfallmodus, den Sie reaktiv steuern sollten.

Geschäfts-Workflows überwachen: Order-to-Cash, Procure-to-Pay und ähnliche Zyklen

Auf der Geschäftsseite gilt dieselbe Monitoring-Logik für Workflows wie Order-to-Cash, Procure-to-Pay und Kunden-Onboarding – nur ohne physische Sensoren. Prozessverantwortliche verfolgen Durchlaufzeit, Durchsatz, Fehlerquoten und SLA-Einhaltung über die gesamte Prozesskette hinweg und nutzen dazu Ereignisdaten aus den Anwendungen, die die einzelnen Schritte ausführen.

Die Herausforderung besteht darin, dass Geschäftsprozesse häufig mehrere Systeme umfassen – CRM, ERP, Abrechnung, Ticketing – und die Übergaben zwischen diesen Systemen dort liegen, wo sich die Engpässe verbergen. Effektives Echtzeitmonitoring von Geschäftsprozessen erfordert, diesen Ereignisstrom in einer einheitlichen Ansicht zusammenzuführen, da keine einzelne Anwendung das End-to-End-Bild sieht. Ein SaaS Operations Manager, der nur sein CRM-Dashboard überprüft, wird den Engpass in der Warteschlange für Abrechnungsfreigaben nicht erkennen.

Hier wird das Konzept der Prozessverantwortlichen wichtig. Jemand muss die End-to-End-Sicht verantworten, nicht nur den eigenen Systembereich. Ohne diese Verantwortung sammeln sich Monitoring-Daten an, ohne dass jemand handelt. Das ist ein Prozessproblem, kein Tooling-Problem.

Warum Prozessmonitoring schwieriger ist, als es aussieht

Drei Wochen nachdem die meisten Teams ihren ersten Monitoring-Rollout eingerichtet haben, fragt jemand: „Okay, das Dashboard markiert Dinge. Und jetzt?“ Diese Frage zeigt den ersten echten Reibungspunkt.

Monitoring macht Probleme sichtbar. Es behebt sie nicht. Das klingt offensichtlich, bis Sie auf einen Bildschirm schauen, der Ihnen zeigt, dass sich die Durchlaufzeit in den letzten zwei Wochen um 40 % verschlechtert hat, und Sie feststellen, dass Ihr Monitoring-Setup keinen Eskalationspfad, keine klaren Verantwortlichkeiten und kein definiertes Reaktionsverfahren für diese Warnung enthält. Das Team von Kognitos dokumentiert dies als eines der häufigsten Missverständnisse: Dass die Einrichtung von Monitoring Geschäftsprozesse automatisch verbessert. Das tut sie nicht. Sie liefert die Daten, die zum Handeln erforderlich sind. Das Handeln selbst ist ein separater Arbeitsbereich.

Der zweite Reibungspunkt ist die Auswahl der richtigen KPIs. Es gibt einen starken Impuls, alles zu verfolgen, was verfolgt werden kann, weil die Daten vorhanden sind. Das Ergebnis ist laut dem BPM-Content von Stanmore UK eine Analyseparalyse – Teams sind so sehr in Monitoring-Daten vergraben, dass sie die wichtigen Signale nicht mehr erkennen. Ich habe Operations-Teams gesehen, die Dashboards mit 14 Panels erstellt und dann aufgehört haben, eines davon anzusehen, weil kein einzelnes Panel klar sagte: „Das ist das Problem, das gerade brennt.“

Der dritte Reibungspunkt ist die systemübergreifende Transparenz. Die meisten Geschäftsprozesse leben nicht in einer einzigen Anwendung. Der Order-to-Cash-Zyklus umfasst ein CRM, ein ERP, ein Abrechnungssystem und wahrscheinlich ein Kommunikationstool. Eine kohärente End-to-End-Sicht zu erhalten, erfordert die Verknüpfung dieser Datenquellen. Teams, die dies überspringen, überwachen nur Fragmente ihrer Prozesse und ziehen aus unvollständigen Bildern falsche Schlüsse. Die Empfehlung von AnyDB dazu ist eindeutig: Fragmentierte Informationen in Tabellenkalkulationen und nicht verbundenen Systemen sind das größte Hindernis für Prozessmonitoring, das tatsächlich funktioniert.

🤔 Moment mal.
Wenn Monitoring Probleme nur sichtbar macht und nicht behebt, was passiert dann, nachdem die Warnung ausgelöst wurde? Die meisten Teams geraten hier ins Stocken. Das Monitoring funktioniert. Der Reaktions-Workflow existiert noch nicht. Das sind zwei unterschiedliche Probleme, und die Lösung des ersten löst nicht das zweite.

Das Skalierungs-Missverständnis: Warum auch kleine Unternehmen Prozessmonitoring brauchen

Die Annahme, Prozessmonitoring sei ein Thema für Konzerne – etwas für Unternehmen mit dedizierten BPM-Teams und großen IT-Budgets – ist auf eine spezifische und teure Weise falsch. Unentdeckte Engpässe summieren sich unabhängig von der Unternehmensgröße. Ein SaaS-Unternehmen mit 15 Mitarbeitenden, bei dem das Onboarding doppelt so lange dauert wie es sollte, verliert Kunden, die es nicht leicht ersetzen kann. Ein kleiner Fertigungsbetrieb, bei dem ein einzelner Maschinenausfall eine Kaskade auslöst, ist nicht vor Ausfallkosten geschützt, nur weil er klein ist.

Kleinere Unternehmen haben oft einfachere Workflows, was eigentlich ein Argument dafür ist, Monitoring dringender einzuführen, nicht weniger dringend. Ein einfacherer Prozess lässt sich leichter systematisch überwachen. Und weil weniger Menschen die Auswirkungen auffangen können, wenn etwas schiefgeht, treffen die Folgen eines übersehenen Signals härter. Erkennen Sie Engpässe frühzeitig, wenn Sie ein kleines Team haben, können Sie sie möglicherweise innerhalb eines Tages beheben. Entdecken Sie sie erst sechs Monate später, wenn sie sich in Ihrem Prozess verfestigt haben, bauen Sie von Grund auf neu.

Auch die Tools haben sich verändert. Effektives Prozessmonitoring erfordert nicht mehr zwingend ein dediziertes Analytics-Team oder Enterprise-Softwarelizenzen. Es erfordert definierte KPIs, eine Möglichkeit zur Erfassung relevanter Daten und jemanden, der für das Handeln auf Signale verantwortlich ist. Das ist in nahezu jeder Größenordnung machbar.

Ausufernder Monitoring-Umfang: Wenn Teams IT-Logs statt Geschäftsergebnisse verfolgen

Das ist der Fehler, den ich am häufigsten bei Teams sehe, die glauben, ihr Prozessmonitoring bereits im Griff zu haben. Sie haben ein Monitoring-System aufgebaut. Es verfolgt Anwendungsfehler, API-Antwortzeiten, Serververfügbarkeit und Deployment-Status. Das Informationssystem wird sorgfältig überwacht. Der Geschäftsprozess nicht.

Technische Verfügbarkeit und Geschäftsprozessgesundheit korrelieren, sind aber nicht identisch. Eine Anwendung kann vollständig betriebsbereit sein, während ein nachgelagertes Geschäftsergebnis unbemerkt scheitert – Bestellungen werden nicht bestätigt, Genehmigungen hängen in einer Warteschlange fest, Kunden erhalten nie ihre Willkommens-E-Mail. Das Dashboard des IT-Teams zeigt Grün. Das Customer-Success-Team bearbeitet Beschwerden. Keine Monitoring- und Steuerungsansicht zeigt beide Probleme an einem Ort, sodass die Verbindung nie hergestellt wird.

Die Lösung beginnt mit einer einfachen Frage: Sagt uns unser Monitoring, ob Kunden den Prozess so erleben, wie er konzipiert wurde? Wenn die Antwort verlangt, mehrere Dashboards zu prüfen und Daten manuell zu korrelieren, wurde der Umfang nicht richtig festgelegt. Kundenzufriedenheit ist eine nachgelagerte Folge der Prozessgesundheit. Monitoring, das letztlich keine Verbindung zu diesem Ergebnis herstellt, beobachtet den Motor und ignoriert, wohin das Auto fährt.

Prozessmonitoring-Techniken, die Sie kennen sollten

Die Mechanik des Prozessmonitorings lässt sich in einige unterschiedliche Ansätze unterteilen. Zu wissen, welche Technik welche Frage beantwortet, verhindert eine unnötige Ausbreitung von Tools.

Echtzeit-Datenerfassung ist die Grundlage. Sie können nicht überwachen, was Sie nicht erfassen. Das bedeutet, Ereignisdaten aus den Anwendungen abzurufen, die Ihren Prozess ausführen – Statusänderungen, Zeitstempel, Feldwerte, Abschlussereignisse – und diese Daten kontinuierlich in eine Monitoring-Ebene einzuspeisen. Die Qualität dessen, was Sie erkennen können, wird direkt durch die Qualität dessen begrenzt, was Sie erfassen.

Ausnahmebasiertes Alerting sorgt dafür, dass Monitoring nicht zu Rauschen wird. Statt jeden Datenpunkt anzuzeigen, konfigurieren Sie Warnungen für Bedingungen, die Aufmerksamkeit erfordern: Eine Durchlaufzeit überschreitet einen Schwellenwert, eine Fehlerquote übersteigt einen definierten Grenzwert oder eine Prozessinstanz hängt an einem bestimmten Schritt länger als erwartet. Hier sind Schwellenwerte entscheidend. Ein praktischer Ausgangspunkt: Markieren Sie jede Prozessinstanz, bei der für einen hochwertigen Account seit 48 Stunden kein Fortschrittsereignis protokolliert wurde, oder lösen Sie eine Warnung aus, wenn die Fehlerquote eines Schritts über ein rollierendes 30-Minuten-Fenster 5 % übersteigt. Das sind illustrative Ausgangswerte – passen Sie sie daran an, wie Ihr Prozess in einem gesunden Zustand historisch aussieht.

KPI-Dashboards übersetzen den Ereignisstrom in Kennzahlen, mit denen Prozessverantwortliche und Operations-Führungskräfte arbeiten können. Trends bei Durchlaufzeiten, Durchsatz nach Zeitraum, Verteilungen von Fehlerquoten, SLA-Einhaltungsraten. Das Dashboard sollte eine Frage schnell beantworten: Verhält sich dieser Prozess gerade so, wie er sollte?

Prädiktives Monitoring verdient eine separate Erwähnung. Die Arbeit von Apromore zum prädiktiven Geschäftsprozessmonitoring beschreibt, wie Dashboards sichtbar machen können, welche laufenden Prozessinstanzen wahrscheinlich gegen SLAs verstoßen werden, bevor dies geschieht – sodass Teams Zeit zum Eingreifen haben, statt nur zu reagieren. Dieser Wechsel von reaktiv zu proaktiv ist der Punkt, an dem sich der Nutzen verstärkt.

Process Mining als Diagnoseschicht unter aktivem Monitoring

Process Mining und aktives Prozessmonitoring lösen unterschiedliche Probleme und funktionieren am besten gemeinsam.

Aktives Monitoring ist vorausschauend. Es beobachtet aktive Prozessinstanzen anhand vordefinierter KPIs und löst Warnungen aus, wenn etwas abweicht. Es sagt Ihnen, was gerade passiert und ob es einen für Sie relevanten Schwellenwert überschreitet. Die überwachten Betriebsbedingungen werden im Voraus definiert.

Process Mining ist retrospektiv. Es analysiert historische Ereignis-Logs, um zu entdecken, wie Prozesse im Zeitverlauf tatsächlich ausgeführt wurden – nicht wie sie konzipiert waren. Process-Mining-Tools erstellen aus Rohereignisdaten die tatsächlichen Prozessabläufe und machen Varianten, Abweichungen und Muster sichtbar, die eine Dokumentation niemals erfassen würde. Process-Mining-Lösungen wie die von Celonis oder Apromore behandeln Prozessdaten als Rohmaterial für Entdeckungen: Sie bestätigen keine Hypothese, sondern finden heraus, was die Logs tatsächlich zeigen.

Die Kombination ist nützlich, weil Process Mining Ihnen zeigt, worauf Sie Ihr aktives Monitoring konzentrieren sollten. Sie führen Process Mining über sechs Monate an Ereignisdaten aus und entdecken, dass 30 % der Bestellungen einem nicht standardmäßigen Pfad folgen, der drei Tage zur Durchlaufzeit hinzufügt. Anschließend richten Sie aktives Monitoring für genau dieses Abweichungsmuster ein. Ohne die Mining-Schicht wüssten Sie möglicherweise nie, dass dieser Pfad existiert. Ohne die Monitoring-Schicht sehen Sie ihn historisch, können ihn aber nicht in Echtzeit erkennen.

Betrachten Sie Process Mining als Diagnose und aktives Monitoring als Überwachung. Beide beobachten denselben Prozess. Sie betrachten ihn über unterschiedliche Zeithorizonte, und die Monitoring-Daten des einen informieren das andere.

Die Rolle der Automatisierung für ein reaktionsfähiges Monitoring-System

Ein Monitoring-System, das eine Warnung an ein gemeinsames Postfach sendet, das am Freitagnachmittag niemand prüft, ist kein Monitoring-System. Es ist ein Logging-System, das gelegentlich E-Mails verschickt.

Automatisierung macht Prozessmonitoring reaktionsfähig statt passiv. Alert-Routing, Eskalationslogik und automatisierte Trigger für Behebungsmaßnahmen wandeln ein Signal in eine Aktion um. Hier verbindet sich Prozessautomatisierung direkt mit Prozessmonitoring-Lösungen: Wenn ein definierter Schwellenwert überschritten wird, protokolliert das System dies nicht nur. Es leitet die Warnung zur richtigen Zeit, mit dem richtigen Kontext an die richtige Person weiter.

In der Praxis könnte das so aussehen: Eine Überschreitung des Durchlaufzeit-Schwellenwerts löst eine Warnung aus, die über Slack an den Prozessverantwortlichen weitergeleitet und um die spezifische Instanz-ID sowie die Dauer der Überschreitung ergänzt wird. Wenn der Prozessverantwortliche die Warnung nicht innerhalb von zwei Stunden bestätigt, eskaliert sie an dessen Manager. Das ist Automatisierung, die den Reaktions-Workflow für Monitoring abwickelt – nicht die menschliche Entscheidung über die Ursache ersetzt, aber sicherstellt, dass das Signal schnell jemanden erreicht, der diese Entscheidung treffen kann.

Ein Latenode Workflow kann diese Routing-Logik verbinden, ohne separate Services aufzubauen: Eine einzelne Ausführung verbindet sich mit der Monitoring-Datenquelle, bewertet die Schwellenwertbedingung und leitet die angereicherte Warnung über den richtigen Kanal weiter. Der JavaScript-Node übernimmt benutzerdefinierte Schwellenwertlogik; die Bibliothek mit mehr als 5.500 Integrationen deckt die meisten Ticketing- und Messaging-Systeme ab. Ein Workflow, ein Ausführungszähler, unabhängig davon, wie viele Schritte die Routing-Logik umfasst. Was ich betonen würde: Die Automatisierung übernimmt das Routing des Signals. Die Ursachenanalyse braucht weiterhin jemanden mit Kontext. Automatisieren Sie die Diagnose nicht, bevor Sie das Muster verstehen.

Automatisierung erweitert die Reaktionsfähigkeit des Monitorings. Sie ersetzt nicht die Prozessverantwortlichen.

So entwickeln Sie eine belastbare Strategie für Geschäftsprozessmonitoring

Die meisten Monitoring-Setups scheitern bei der Implementierung, weil Teams mit Tools statt mit Fragen beginnen. Folgendes tun Teams, die es richtig machen – und Folgendes verhindert jeder Schritt:

• Definieren Sie die Prozessgrenze, bevor Sie KPIs auswählen.

Operations-Verantwortliche sollten Start- und Endpunkte des Prozesses explizit festlegen, nicht nur die Schritte dazwischen, bevor sie entscheiden, was gemessen werden soll. Dadurch wird folgender Fehler vermieden: die Leistung interner Schritte zu verfolgen, während sich die End-to-End-Durchlaufzeit verschlechtert – was Kunden in der Regel tatsächlich wahrnehmen. Prüffrage: Können Sie in einem Satz sagen, wo dieser Prozess beginnt und was einen erfolgreichen Abschluss darstellt?

• Weisen Sie einen Prozessverantwortlichen zu, bevor Sie Warnungen konfigurieren.

Eine Warnung ohne benannte verantwortliche Person ist eine Benachrichtigung, die unbeantwortet bleibt. Für IT- und DevOps-Teams ist dies normalerweise klar. Bei funktionsübergreifenden Geschäfts-Workflows wie Procure-to-Pay wird Verantwortung oft vorausgesetzt statt zugewiesen. Dadurch wird folgender Fehler vermieden: Alert-Müdigkeit durch Signale, auf die niemand reagiert, was dazu führt, dass Teams das Monitoring-Dashboard vollständig ignorieren. Prüffrage: Wer erhält die Warnung um 2 Uhr nachts, wenn dieser Prozess in einer Feiertagswoche ausfällt?

• Verankern Sie Ihre Schwellenwerte im Basisverhalten, nicht in Wunschzielen.

Produktionsleiter in industriellen Umgebungen kennen dies aus dem Anlagenmonitoring: Wenn Sie Ihren Warnschwellenwert auf den idealen Betriebsbereich statt auf den normalen Betriebsbereich setzen, erhalten Sie ständig Warnungen und lernen, sie zu ignorieren. Dasselbe gilt für Geschäfts-Workflows. Messen Sie zunächst zwei bis vier Wochen lang das aktuelle Verhalten, bevor Sie Schwellenwerte für Anomalien festlegen. Dadurch wird folgender Fehler vermieden: Fluten mit Fehlalarmen, die das Team darauf trainieren, Warnungen abzuwerten. Prüffrage: Spiegeln Ihre Schwellenwerte wider, was der Prozess in gesundem Zustand tatsächlich tut, oder was Sie sich wünschen würden?

• Erstellen Sie den Reaktions-Workflow, bevor das Monitoring live geht.

Compliance- und Audit-Teams verstehen dies instinktiv, weil sie dokumentierte Verfahren für Korrekturmaßnahmen benötigen, um die Einhaltung regulatorischer Vorgaben nachzuweisen. Operations-Teams überspringen es häufig. Dadurch wird folgender Fehler vermieden: Monitoring, das Probleme sichtbar macht, aber keinen definierten Lösungsweg hat, sodass Dashboards rote Indikatoren ansammeln, während niemand Verantwortung übernimmt. Prüffrage: Gibt es für jeden Warntyp ein dokumentiertes Reaktionsverfahren mit einer benannten verantwortlichen Person und einem SLA für die Erstreaktion?

• Planen Sie regelmäßige Monitoring-Reviews ein, nicht nur Reaktionen auf Vorfälle.

Effektives Monitoring dient nicht nur dazu, Probleme zu erkennen – es macht auch datengestützte Muster sichtbar, die Prozessverbesserungen vorantreiben. Eine wöchentliche 15-minütige Überprüfung von KPI-Trends ist für kontinuierliche Verbesserung oft wertvoller als die durch Warnungen ermöglichte Reaktion auf Vorfälle. Dadurch wird folgender Fehler vermieden: Monitoring als Feueralarm statt als strategische Informationsquelle zu behandeln. Prüffrage: Wann hat zuletzt jemand die Trendlinie statt des aktuellen Werts betrachtet?

• Begrenzen Sie Ihre anfängliche KPI-Auswahl auf maximal drei oder vier Kennzahlen.

Das ist die praktische Realität, wenn Sie fundierte Entscheidungen treffen wollen, ohne das Team auszubrennen. Beginnen Sie für die meisten Geschäfts-Workflows mit Durchlaufzeit, Fehlerquote und Durchsatz. Ergänzen Sie KPIs, wenn das ursprüngliche Set mindestens ein Quartal lang im Einsatz war und Sie eine konkrete Frage identifiziert haben, die es nicht beantworten kann. Dadurch wird folgender Fehler vermieden: Dashboard-Überlastung, die dazu führt, dass niemand mehr etwas prüft. Prüffrage: Kann jeder im Prozessteam ohne nachzusehen den aktuellen Wert jedes verfolgten KPI nennen?

Teams, die durch Prozessmonitoring operative Exzellenz erreichen, wirken von außen meist unspektakulär. Ihre Workflows laufen. Ihre Dashboards bewegen sich. Ihre Verbesserungen erfolgen schrittweise und datengestützt. Das Drama gehört meist den Teams, die dieses Setup übersprungen haben.

Wer Geschäftsprozessmonitoring tatsächlich nutzt – und wofür

Es gibt vier unterschiedliche Rollengruppen, die Prozessmonitoring ernsthaft nutzen, und jede braucht einen anderen Fokus. Sie als austauschbar zu behandeln, führt zu Monitoring-Setups, die niemandem wirklich dienen.

Operations- und Prozessverantwortliche nutzen Prozessmonitoring, um die End-to-End-Gesundheit von Geschäftsprozessen in Echtzeit zu verfolgen. Ihr Fokus liegt auf Durchlaufzeit, Durchsatz und Engpasserkennung in Workflows wie Auftragsabwicklung, Onboarding oder Beschaffung. Sie müssen den Ablauf optimieren, nicht nur beobachten – ihr Monitoring-Setup muss also sichtbar machen, wo Dinge festhängen, und Verantwortlichkeit für die Behebung zuweisen. Die KPIs, die sie beobachten, sind KPIs für Geschäftsergebnisse: Wie lange dauert dieser Prozess tatsächlich, wie oft wird er erfolgreich abgeschlossen und wo häufen sich Ausnahmen?

IT-, DevOps- und SRE-Teams nutzen Prozessmonitoring, um Anomalien in technischen Workflows zu erkennen, bevor Kunden sie bemerken. Ihr Fokus liegt auf dem Ausführungsverhalten: Fehlerquoten, Wiederholungsversuche, Latenzspitzen und Authentifizierungsfehler. Sie möchten Echtzeitsignale, dass sich etwas verschlechtert, damit sie reagieren können, bevor daraus ein Produktionsvorfall wird. Ihr Monitoring liegt näher an der Systemebene als an der Geschäfts-Workflow-Ebene, aber beide treffen an den Übergaben aufeinander – dort, wo eine Änderung im Anwendungsverhalten eine Änderung des Geschäftsergebnisses verursacht.

Compliance- und interne Audit-Teams nutzen Prozessmonitoring, um die Einhaltung regulatorischer Vorgaben nachzuweisen und Kontrollfehler frühzeitig sichtbar zu machen. Ihr Fokus liegt auf Nachweisen: Können sie zeigen, dass eine definierte Kontrolle am richtigen Schritt, von der richtigen Person und innerhalb des erforderlichen Zeitrahmens ausgeführt wurde? Für Unternehmen, die SOX, ISO-Standards oder Finanzdienstleistungsregulierung unterliegen, macht Prozessmonitoring aus Richtliniendokumentation nachweisbare Praxis. Monitoring-Daten werden zum Audit-Trail.

📊 In der Praxis:
Compliance-Teams, die Prozessmonitoring für SOX-Compliance einsetzen, benötigen mehr als ein Dashboard – sie brauchen mit Zeitstempeln versehene Ereignis-Logs, die zeigen, dass bestimmte Kontrollen an bestimmten Prozesspunkten ausgeführt wurden. Das Monitoring-Setup, das für operative Transparenz funktioniert, benötigt für Audit-Zwecke häufig eine parallele Log-Struktur. Das sind unterschiedliche Anforderungen, und von Anfang an für beide zu planen, ist günstiger als eine Nachrüstung nach einer Audit-Feststellung.

Produktionsleiter und Fertigungsaufsichten nutzen Prozessmonitoring im zuvor beschriebenen industriellen Kontext: Sensoren, Steuerungssysteme und die Verfolgung von Echtzeitvariablen, um Produktqualität, Anlagenverfügbarkeit und Betriebssicherheit aufrechtzuerhalten. Ihre KPIs sind direkt mit physischen Ergebnissen verbunden – Temperaturtoleranzen, Druckbereiche, Fehlerquoten im Produktionsoutput. Die Kosten eines übersehenen Signals in diesem Bereich werden in Stunden ungeplanter Ausfallzeit gemessen. Die von Wiss zitierte Forschung beziffert diese branchenübergreifend auf mehr als 125.000 US-Dollar pro Vorfallsstunde. Bei dieser Kostenstruktur ist Monitoring keine Option.

Jede dieser Gruppen könnte technisch dieselbe Monitoring-Plattform nutzen. Ob sie ein Dashboard teilen, hängt davon ab, ob ihre KPIs, Warnschwellenwerte und Reaktions-Workflows tatsächlich abgestimmt sind – was sie in der Regel nicht sind.