Reporting ist wichtig! – da würde wohl jeder spontan zustimmen. In der Industrie sind Prozesskennzahlen ein mächtiges Mittel zur Optimierung der Prozesse. Wie viel Zeit beansprucht etwa der Einbau der Windschutzscheibe bei einem PKW? Jeder Automobilhersteller wird diese Frage in kürzester Zeit beantworten können.
Fragen Sie sich jetzt, was Windschutzscheiben mit Ihrer BPM/SOA-Initiative zu tun haben? Das Beispiel ist übertragbar! Wissen Sie, wie lange die Schritte Ihrer Geschäftsprozesse dauern oder wie häufig bestimmte Geschäftsvorfälle eintreten? Wenn ja, dann gratuliere ich Ihnen: Sie sind weiter als die meisten anderen.
Dabei liegt es auf der Hand: Nur wenn Geschäftsprozesse gemessen und bewertet werden, können Optimierungspotentiale erkannt werden. Und wenn es nichts zu optimieren gibt? Machen Sie ihre Stakeholder mit Reports glücklich, die diesen Zustand plastisch widerspiegeln! Und spätestens, wenn aus irgendwelchen Gründen Änderungen an Ihren Prozessen nötig werden, werden Sie von Ihrem Reporting profitieren, denn die gewonnen Kennzahlen erleichtern Ihnen dann die Planung.
Business Activity Monitoring
Im Prinzip ist erst mal unerheblich, ob die Prozesse automatisiert in einer Process Engine ablaufen oder aus einer Folge von manuellen Aktivitäten bestehen. Man spricht im Allgemeinen von Business Activity Monitoring. In der Realität findet man ohnehin meist beides vor. Teilautomatisierte Prozesse, unterbrochen durch Interaktionen mit Benutzern, sind der Normalfall.
Sie können durch geeignetes Reporting einerseits Erkenntnisse über die technische Performance der eingesetzten Process Engine gewinnen: Wie lange braucht eine Prozessinstanz für einen bestimmten automatisierten Prozessschritt? Wie viele Prozessinstanzen laufen pro Zeiteinheit durch die Engine? Solche Einsichten sind bei BPM/SOA-Projekten besonders in der Anfangsphase wertvoll, geben sie doch Aufschluss über die Qualität der Architektur und des Prozessdesigns. Aber auch langfristig liefert Business Activity Monitoring hilfreiche Informationen, wenn es darum geht, Prozesse und Architekturen an veränderte Anforderungen anzupassen.
Andererseits kann Business Activity Monitoring Aufschluss darüber geben, wie die Prozesslaufzeit durch manuelle Tätigkeiten beeinflusst wird. Was passiert, wenn ein Mitarbeiter überlastet ist und Aufgaben liegen bleiben? Wie wirkt sich das auf die Gesamtprozesslaufzeit aus? Auch hier lassen sich durch geeignetes Monitoring und Reporting wichtige Erkenntnisse gewinnen. Auf deren Basis wiederum können dann fundierte Maßnahmen ergriffen und etwa kurzfristig Ressourcen verlagert werden, um Entlastung zu schaffen. Langfristig können solche Kennzahlen schließlich auch Einfluss auf die Personalplanung haben.
Einen weiteren Vorteil bietet Business Activity Monitoring besonders dann, wenn es um weitestgehend automatisierte Prozesse geht, die „im Dunkeln“ ablaufen. Während der Entwicklungsphase sind diese z.B. in Reviews nur schwer zu präsentieren. An der Stelle können Reports helfen, die Funktionsweise solcher Prozesse darzustellen und tragen damit zur Akzeptanz, aber auch indirekt zur Steigerung der Qualität der Anwendung bei. Mehr Informationen zu „Reviews in der Dunkelkammer“ gibt es hier im Blog.
Das richtige Augenmaß
Doch warum wird in vielen Projekten gerade am Anfang das Reporting so stiefmütterlich behandelt? Häufig werden damit komplexe Data-Warehouses und umfangreiche Toollandschaften assoziiert, deren Einführung und Betrieb mit immensem Aufwand und hohen Kosten verbunden sein können. Das ist in vielen Fällen – besonders in frühen Projektstadien – mit Kanonen auf Spatzen geschossen, aber leider dennoch oft genug der Grund dafür, dass ganz auf professionelles Reporting verzichtet wird. Was dabei nicht bedacht wird: Ist das Kind erst mal in den Brunnen gefallen – werden beispielsweise etwaige Schwächen in Architektur oder Prozessdesign zu spät bemerkt – sind die Kosten zur nachträglichen Beseitigung oft ebenfalls immens.
Viele BPM-Produkte bieten von Haus aus schon mindestens rudimentäre Reporting-Möglichkeiten. Steht die Auswahl eines Produkts noch bevor, kann dieser Aspekt angemessen berücksichtigt werden. Doch auch wenn das eingesetzte Produkt keine oder nur unzureichende Möglichkeiten bietet, gibt es durchaus gute und einfach zu bedienende Open-Source-Lösungen. Eine solche Lösung ist BIRT (Business Intelligence and Reporting Tools). BIRT (http://www.eclipse.org/birt/phoenix) fügt sich nahtlos in verbreitete Entwicklungsinfrastrukturen ein und bringt ein Eclipse-Plugin für das Reportdesign sowie eine Reporting-Engine mit, die sich ohne großen Aufwand auf verschiedene Application Server deployen lässt. Es lassen sich beliebige Datenbanken anbinden und mit wenigen Klicks SQL-basierte Reports (die Queries zur Datenbeschaffung muss der Reportersteller allerdings selbst schreiben) grafisch darstellen. BIRT unterstützt viele gängige Diagrammtypen ebenso wie die übersichtliche Darstellung in Tabellen.
Fazit
Dieser Beitrag liefert sicherlich kein Patentrezept, wie Sie Monitoring und Reporting in Ihren BPM/SOA-Projekten gestalten sollen. Er soll viel mehr die Sinne dafür schärfen, dieses Thema nicht aus den Augen zu verlieren. Dass Reporting ein wichtiges Thema ist, behauptet jeder, doch leider bleibt das viel zu oft ein Lippenbekenntnis, das teure Folgen haben kann – und eine anfänglich kleine, erweiterbare Lösung ist definitiv besser als keine Lösung. Technische Mängel zu erkennen ist dabei nur ein Aspekt. Im Laufe der Zeit ändern sich die Anforderungen an Ihr Geschäft und Geschäftsprozesse müssen adaptiert werden. Business Activity Monitoring hilft dann, Änderungen zu bewerten und erleichtert deren Gestaltung. Und nicht zuletzt ermöglichen Prozesskennzahlen erst das kurzfristige Reagieren auf Engpässe, ob nun technischer oder organisatorischer Natur.
