BPM meets APM: Systemübergreifendes Prozessmonitoring auf Basis von Open Source

Ich weiß nicht, wie es Ihnen geht, aber ich habe mich schon oft darüber geärgert: Wenn ich einen BPMN 2.0-Prozess automatisiere, dann bekomme ich die KPIs zum modellierten Prozess quasi geschenkt. Aber im Sinne einer Verbesserung, insbesondere mit Blick auf die Geschwindigkeit und die Kosten, schmerzen einen oft die manuellen Tätigkeiten in einem Prozess – und diese bleiben leider hinter der Fassade eines Human Tasks verborgen. Welche Arbeitsschritte der Mitarbeiter durchführt und in welchen Systemen er diese erledigt, kann nicht gemessen werden. Und dieses Wissen wird somit für die Prozessverbesserung auch nicht genutzt.

An dieser Stelle greift man gerne auf Process Mining-Tools, bzw. noch präziser Task Mining-Tools, zurück. Diese können die Aktionen sichtbar machen und verknüpfen und somit genau die fehlenden Informationen liefern. Leider sind die mir geläufigen Tools alle kommerziell und stammen auch technologisch aus einer ganz eigenen Welt. So habe ich zuletzt einen interessanten Artikel in der Computerwoche gelesen, der aus einem anderen Blickwinkel dasselbe Thema betrachtet.

Wenn wir (die Novatec Consulting) Prozesse automatisieren, dann gerne auf einer BPM-Engine wie zum Beispiel Camunda BPM und auch sehr gerne mit Open Source-Technologie. Das wollen wir gerne auch im Bereich des Prozessmonitorings fortsetzen. Leider gibt es hier nicht viele (bis gar keine?) bereits verfügbaren Lösungen.

Da trifft es sich gut, dass vor nicht allzu langer Zeit meine Kollegen aus dem APM-Beratungsteam die extrem coole OpenAPM-Initiative gestartet haben, die jedem hilft, die sehr vielfältigen Kombinationsmöglichkeiten von Open Source APM-Tools zu durchdringen. Und nicht nur das: Die Kollegen beschäftigen sich auch mehr und mehr mit der Frage, wie sie mit dem APM-Tooling neben technischen auch fachliche Kennzahlen ermitteln können – beschrieben im Blog: Collecting Business Metrics using Open Source Monitoring Tools. Während wir aus BPM-Sicht gerne mehr ins Detail gehen wollen, versucht man aus APM heraus höherwertige Informationen zu ermitteln. Hier wächst also was zusammen, was vielleicht schon immer zusammen gehörte. Höchste Zeit also, dass wir uns das einmal genauer anschauen. Luc Weinbrecht und ich haben das im Rahmen eines Prototyps einmal gemacht.

Im Kern geht es zunächst um die Frage, warum überhaupt weitere Tools im Unternehmen eingeführt werden sollen, wenn die relevanten Tools doch schon etabliert sind? Auch beim Prozessmonitoring geht es „nur“ um die Sammlung, Korrelation, Aggregation und Visualisierung von Events und KPIs – darin unterscheiden sich APM und BPM nur in speziellen Aspekten. Und viele Unternehmen haben die dafür notwendige Infrastruktur schon etabliert. Exemplarisch seien hier Elastic oder Kafka erwähnt. Warum also nicht diese Infrastruktur auch für das Prozessmonitoring nutzen?

In unserem Prototyp sind wir dazu vierstufig vorgegangen:

1. Anbindung der Process Engine an die Event-Infrastruktur (Elastic Search) und Visualisierung der KPIs im zugehörigen Dashboard (Kibana)
2. Verknüpfung der einzelnen Events über Complex Event Processing (CEP) zu höherwertigen, komplexen KPIs über die Siddhi-Engine
3. Verknüpfung der Process-Events mit den User-Events aus der APM-Welt, um übergreifende KPIs zu erlauben
4. Visualisierung der Abläufe in verschiedenen Detailierungsstufen – zunächst mit Hilfe eines einfachen, selbstgeschriebenen Tools

Diese 4 Schritte hat Luc Weinbrecht sehr schön in seinem Blog über die technischen Details des Prototyps beschrieben.

Der Prototyp hat aus unserer Sicht sehr vielversprechende Ergebnisse geliefert. Wir wissen nun, dass wir die Events relativ einfach miteinander in Verbindung bringen können und auch, wie das geht. Wir haben auch gesehen, wie schon der erste Schritt in diese Richtung, konkrete und nutzbare Ergebnisse liefert. Und wir haben vielfältige neue Ideen generiert, wie wir das Erreichte nun noch erweitern und verbessern können. Letzteres macht uns natürlich immer besonders viel Spaß.

Und, da das Konzept vollständig auf offenen Technologien basiert, ist es flexibel erweiterbar. Natürlich könnten auch wir die Event-Logs großer Standardsoftwaresysteme anbinden und mit in die Auswertung einbeziehen. Oder alternativ könnten wir auch Altsysteme (auf Java-Basis) instrumentieren und somit die dort ablaufenden Prozesse überwachen und auswerten. Da hilft uns natürlich, dass wir mit inspectIT Ocelot eine dafür notwendige Technologie selbst bereitstellen und weiterentwickeln. Natürlich als Open Source.

Erste Unternehmen, die diesen Weg mit uns gemeinsam gehen wollen, haben wir auch schon gefunden. Aber wir freuen uns natürlich über weiteres Feedback. Insbesondere auch deshalb, da wir neugierig sind, welche dieser Aspekte in der Praxis sich als besonders wertvoll erweisen werden. Und gerne unterstützen wir beim „Ausprobieren“ mit unseren BPM– und APM-Beratern.