Überwachung von Prozessen: 41 Schemata an echten Daten geprüft

Überwachung von Prozessen beginnt bei der Frage, ob ein Ablauf tatsächlich arbeitet, und nicht bei dem Status, der beim Anlegen gesetzt wurde. Auf der Prozess-Landkarte eines Unternehmens der Lebensmittelproduktion standen 39 von 41 Schemata als Entwurf. Der Inhaber schloss daraus, dass nichts läuft. Ein Lebenszeichen je Schema hätte ihm das Gegenteil gezeigt.

Was „Entwurf“ in der Liste tatsächlich bedeutete

Ein Statusfeld hält fest, was jemand über ein Schema eingetragen hat. Ob der Auslöser feuert, ob Ereignisse ankommen und ob ein Durchlauf zu Ende geht, steht dort nicht. Der Inhaber wollte wissen, welche Abläufe arbeiten. Die Liste beantwortete eine andere Frage, nämlich welche Schemata jemand für fertig erklärt hatte. Beide Fragen teilten sich eine Spalte.

Die Folge ist keine Kleinigkeit. Wer eine Landkarte so liest, baut im schlimmsten Fall einen Ablauf neu, der längst arbeitet, oder verlässt sich auf einen, der nie gestartet ist. Und er sucht an der falschen Stelle, wenn im Betrieb etwas aus dem Ruder läuft: Alles Auffällige ist ja scheinbar abgeschaltet.

Überwachung am Statusfeld: der Schaden blieb unsichtbar

Im Hintergrund lief genug, um echten Schaden anzurichten. Ein Ereignis wurde ohne Dedup-Schlüssel verarbeitet, also ohne ein Merkmal, an dem eine doppelte Lieferung erkannt wird, und vervielfachte sich dadurch 78-fach: 628 000 Ereignisse, 1,87 Millionen leere Durchläufe, 14 GB. Abgebrochene Durchläufe hingen dauerhaft im Zustand „läuft“. Dazu schrieb jeder Durchlauf einen Snapshot von 4,6 KB, den nie jemand las – 9,5 von 10 GB bestanden aus diesem Ballast.

Keine dieser Zahlen tauchte in der Liste auf, weil die Liste nur das Statusfeld kannte. Genau hier trennt sich Anzeige von Beobachtung. Ein Ablauf, der dieselbe Eingabe mehrfach verarbeitet, ist ein klassischer Fall für Idempotenz. Solange niemand die Durchläufe zählt, fällt er erst auf, wenn der Speicher knapp wird.

Ein Urteil und ein Lebenszeichen für jedes Schema

Wir haben alle 41 Schemata gegen Live-Daten geprüft und jedem ein Urteil gegeben: läuft, teilweise oder läuft nicht, jeweils mit Grund. In der Liste zeigt seitdem jedes Schema sein Lebenszeichen, das heißt den Zeitpunkt der letzten Prüfung und die Zahl der Prüfungen in dieser Woche. Status und tatsächlicher Betrieb stehen getrennt nebeneinander.

Für den Inhaber änderte sich damit die Lektüre der Landkarte. Ein Schema kann weiter als Entwurf markiert sein und trotzdem ein frisches Lebenszeichen tragen; dann ist klar, dass es arbeitet, obwohl niemand es für fertig erklärt hat. Umgekehrt fällt ein Schema ohne Prüfungen in dieser Woche sofort auf.

Gezählt wird über eine indexgestützte Abfrage mit Kappe. Das klingt nach Nebensache, entscheidet aber, ob die Ansicht genutzt wird: Die Liste lädt in 44 statt 1585 Millisekunden. Eine Übersicht, auf die man wartet, öffnet im Alltag niemand.

Parallel haben wir die Ursachen abgestellt. Doppelte Ereignisse erkennt der Ablauf jetzt am natürlichen Quell-Identifikator, also an der Kennung, die das liefernde System ohnehin mitgibt. Durchläufe werden immer abgeschlossen, auch wenn sie abbrechen. Den Snapshot schreibt der Ablauf nur noch bei einer Pause. Das Ereignisrauschen fiel von rund 23 000 auf rund 109 pro Tag, der Verursacher des Ballasts ist abgestellt. Welche weiteren Laufkennzahlen ein Prozessmonitoring braucht, steht im Lexikon.

Der Fehler in unserer ersten Korrektur

Die erste Fassung der Korrektur war falsch, und bemerkt haben wir es nicht selbst. Ein unabhängiges Review fand darin einen stillen Verlust von 49 % echter Kundenereignisse. Die Kurve des Rauschens sah zu diesem Zeitpunkt hervorragend aus. Wir haben den Fehler korrigiert und per Live-Messung belegt, dass danach kein Ereignis mehr verloren ging.

Die Lehre daraus nehmen wir in jedes Vorhaben mit. Wer Duplikate entfernt, kann echte Ereignisse gleich mit entfernen, und eine sinkende Zahl beweist dann gar nichts. Den Beweis liefert erst ein Abgleich der echten Ereignisse vor und nach dem Eingriff.

Auch das Lebenszeichen hat eine Grenze. Es zeigt, dass ein Schema geprüft wurde und wann. Ob jedes Ergebnis im Zielsystem fachlich stimmt, sagt es nicht; dafür braucht es eigene Prüfungen am Ergebnis.

Überwachung von Prozessen: so gehen wir vor

Bei gewachsenen Automatisierungen beginnen wir mit einer Bestandsaufnahme gegen Live-Daten, bevor wir etwas umbauen. Jeder Ablauf bekommt ein Urteil mit Grund. Danach legen wir fest, woran sein Lebenszeichen hängt und welche Zählung einen Verlust sichtbar macht. Beides schreiben wir vor dem Start als Abnahmekriterium ins Angebot.

Am Ende der Bestandsaufnahme liegt eine Liste, in der jeder Ablauf mit Urteil, Grund und letzter Prüfung steht. Welche Abläufe umgebaut, welche nur messbar gemacht und welche abgeschaltet werden, entscheidet die Geschäftsführung auf dieser Grundlage und nicht nach dem Eintrag in einer Statusspalte.

Eine Korrektur, die Daten zusammenführt oder aussortiert, gilt bei uns erst mit einer Live-Messung der Verluste als erledigt, nicht mit einer schöneren Kurve. Ob dafür ein Ablauf neu entsteht oder ein bestehender nur messbar gemacht wird, entscheiden wir je Fall – so beginnt jedes Vorhaben, in dem wir Geschäftsprozesse automatisieren.