Prozessmonitoring: woran man merkt, dass eine Automatisierung noch arbeitet

Prozessmonitoring ist die laufende Überwachung, ob ein automatisierter Ablauf tatsächlich arbeitet: ob er zur erwarteten Zeit gelaufen ist, ob er Daten verarbeitet hat und ob das Ergebnis im Zielsystem angekommen ist. Es meldet sich, wenn ein Lauf ausbleibt oder auffällig wenig liefert, nicht erst, wenn ein Kunde nach seiner Bestellung fragt.

Prozessmonitoring: Begriff und Abgrenzung

Im Prozessmanagement bezeichnet das Wort auch die Messung von Geschäftsprozessen über Kennzahlen wie Durchlaufzeit oder Fehlerquote, meist in periodischen Berichten. Hier geht es um die betriebliche Bedeutung: die Beobachtung automatisierter Abläufe wie Datenabrufe, Abgleiche, Belegverarbeitung oder nächtliche Exporte, die ohne Aufsicht laufen und deshalb auch ohne Aufsicht stehen bleiben.

Drei Nachbarn werden oft damit verwechselt. Server-Überwachung prüft, ob eine Maschine läuft, nicht ob der Ablauf darauf etwas Brauchbares tut. Ein Fehlerprotokoll hält fest, was schiefging, weiß aber nichts von Läufen, die nie gestartet sind. Und die Ausnahmebehandlung kümmert sich um einzelne Datensätze, die Überwachung um den Ablauf als Ganzes.

Lebenszeichen: der Heartbeat eines Ablaufs

Die Grundform ist ein Lebenszeichen, englisch Heartbeat: Nach jedem Lauf meldet der Ablauf an eine zentrale Stelle, dass er fertig ist. Bleibt diese Meldung länger aus als erwartet, stimmt etwas nicht. Entscheidend ist, woran das Lebenszeichen hängt – drei Varianten sind verbreitet, mit sehr unterschiedlicher Aussagekraft:

• Der Dienst läuft. Das Programm ist gestartet. Die schwächste Aussage: Ein Dienst kann laufen und seit Tagen an einer abgelaufenen Anmeldung hängen.
• Der Lauf ist beendet. Der Durchgang endete ohne Abbruch. Schon besser, doch ein Lauf, der keinen einzigen Datensatz verarbeitet hat, endet ebenso sauber.
• Das Ergebnis ist bestätigt. Der Abruf hat geliefert, und die Daten sind im Zielsystem angekommen. Nur diese Variante beantwortet die Frage, die das Unternehmen wirklich hat.

Die Aktualität der Daten allein taugt nicht als Lebenszeichen. An einem ruhigen Sonntag entsteht in manchen Quellen schlicht nichts Neues, und der Ablauf ist trotzdem gesund. Umgekehrt kann eine Quelle frische Daten zeigen, während der eigene Abruf seit Stunden scheitert.

Signal bei Stille statt Meldung bei Fehler

Die meisten Automatisierungen melden Fehler. Das deckt nur Fälle ab, in denen der Ablauf noch fähig ist, etwas zu melden. Fällt der Zeitplan aus, startet ein Server nach einer Wartung nicht neu oder läuft ein Zugang ab, bevor der Ablauf überhaupt beginnt, entsteht keine Fehlermeldung, sondern Stille. Jedes Prozessmonitoring braucht deshalb die Gegenrichtung: Nicht der Ablauf meldet das Problem, sondern die Überwachung bemerkt, dass eine erwartete Meldung fehlt.

Dafür bekommt jeder Ablauf ein erwartetes Intervall mit Toleranz – stündlich mit Puffer, nachts bis zu einer festen Uhrzeit, am Wochenende anders als unter der Woche. Wichtig ist, dass „nichts zu tun“ und „kaputt“ unterscheidbar bleiben: Ein Lauf, der keine neuen Nachrichten findet, sendet trotzdem sein Lebenszeichen. Ein leerer, aber erfolgreicher Lauf ist eine andere Aussage als gar kein Lauf.

Die Stelle, die Stille bemerkt, läuft nicht auf demselben System wie der Ablauf. Fallen beide gemeinsam aus, schweigen Ablauf und Wächter gleichzeitig, und die Übersicht bleibt grün.

Welche Laufkennzahlen ins Prozessmonitoring gehören

Über das Lebenszeichen hinaus zeigen wenige Kennzahlen je Lauf, ob ein Ablauf gesund ist oder schleichend schlechter wird:

• Verarbeitete Datensätze. Weicht die Menge deutlich vom üblichen Niveau desselben Wochentags ab, ist das ein Hinweis, auch ohne Fehler.
• Zurückgestellte Fälle. Wie viele Datensätze in der Klärung liegen und wie alt der älteste offene Fall ist.
• Fehler in Folge. Ein einzelner gescheiterter Abruf ist Alltag, eine ununterbrochene Serie ist ein Ausfall.
• Dauer. Braucht ein Lauf plötzlich ein Vielfaches der gewohnten Zeit, kündigt sich oft ein Problem an, bevor es eintritt.
• Zeit seit dem letzten Erfolg. Seit wann hat der Ablauf nichts mehr erfolgreich geliefert – die Zahl, die eine Übersicht zuerst zeigen sollte.

Schwellenwerte richten sich nach dem bisherigen Verhalten des einzelnen Ablaufs, nicht nach einer Zahl für alle. Eine Quelle, die nachts nie etwas liefert, braucht eine andere Grenze als ein Postfach, das stündlich Post bekommt. Jede Meldung braucht außerdem eine Entwarnung, sobald der Ablauf wieder liefert.

Typische Fehler

• Grün, weil etwas anderes grün ist. Die Anzeige prüft Verbindung oder Dienst, nicht das Ergebnis. Die Übersicht zeigt Betrieb, während Daten verloren gehen.
• Alarm für jede Abweichung. Wer alles meldet, erzieht die Empfänger zum Wegsehen, und eine echte Störung geht im Rauschen unter.
• Überwacht wird nur das Offizielle. Skripte und Tabellenabläufe, die Citizen Developer in Fachabteilungen gebaut haben, laufen ohne jede Beobachtung – obwohl gerade sie am leichtesten brechen und beim Neustart ohne Idempotenz Einträge doppelt anlegen.
• Kein Adressat. Die Meldung landet in einem Sammelpostfach, und keine Person ist für die Reaktion benannt.

Wie wir Abläufe beobachtbar machen

Wir schlagen vor, dass eine Automatisierung ihr Lebenszeichen erhält, bevor sie abgenommen wird, und nehmen die zugehörigen Kennzahlen als Abnahmekriterium ins Angebot auf. Das Lebenszeichen hängt am Ergebnis und nicht an der Verbindung: Es zählt, was im Zielsystem angekommen ist, nicht, ob ein Dienst erreichbar war. Für jeden Datenfluss legt das Angebot fest, wie lange ein Ablauf schweigen darf, bevor eine Meldung kommt, wer sie erhält und woran sich ein ruhiger Tag von einem stehenden Ablauf unterscheidet. Warum ein Statusfeld diese Frage nicht beantwortet, zeigt der Beitrag Überwachung von Prozessen. Wie ein beobachtbarer Ablauf entsteht, beschreibt die Seite Geschäftsprozesse automatisieren.