Business Activity Monitoring: Regeln für den Fachanwender

Für Business Activity Monitoring (BAM) und Business Process Management (BPM) gilt das, was für andere IT-Lösungen – etwa im Umfeld von Customer Relationship Management (CRM) oder Enterprise Ressource Management (ERP) – eher hinderlich scheint: Existierende Strukturen. Die Lösungen profitieren laut Ian Charlesworth von der Butler Group davon, dass Einzelteile schon lange in Betrieb und damit ausgereift sind. Somit zählen auch Anbieter von Applikations-Servern wie IBM mit ‘Websphere Integration Server’, Bea Systems mit ‘Weblogic’ und Microsoft mit ‘Biztalk’ zu den wichtigsten Playern, wenn es um BPM und BAM geht.
Doch warum finden sich dann kaum BAM-Projekte? Mehrere Antworten sind denkbar. BAM ist eine Marketing-Erfindung der Hersteller, und das Thema geht am Interesse der Anwender vorbei. Oder: Das Thema ist heiß, aber in den Anwenderunternehmen noch nicht auf fruchtbaren Boden gestoßen, da die Voraussetzungen fehlen. Oder aber: Die Unternehmen machen BAM-Projekte, bezeichnen sie jedoch anders. Sowohl Charlesworth als auch Joachim Quantz, Chefanalyst bei Berlecon Research, vermuten, dass die Wahrheit Elemente aller Antworten enthalten dürfte.

BPM gliedert sich laut Quantz in Modellierung, Ausführung sowie in Messen und Evaluieren. Modellierungs-Tools wie Aris von IDS Scheer gehörten bisher in die Hände von Fachexperten, Rational von IBM oder auch Visio von Microsoft sind dagegen Werkzeuge von Technikern. Allen gemein ist jedoch, dass erst seit geraumer Zeit an der Umsetzung der Vision ‘Modellieren, Generieren, Ausführen, Messen und Verbessern’ gearbeitet wird. Bisher war der Übergang vom Modell zum ausführbaren Programm gekennzeichnet durch Medienbrüche. So können erst seit kurzem Rational-Entwickler auf eine gemeinsame Datenbasis für Modellierung, Entwicklungsumgebung und Websphere zurückgreifen. Bea Systems und IDS Scheer arbeiten an einer Möglichkeit, über die Modellierungssprache UML 2.0 die Aris-Modelle ausführbar zu machen. Bisher lassen sich die Aris-Modelle nur durch proprietäre Schnittstellen etwa im Vitria-Produkt ausführen.

Anwendungen mit Ladehemmung

Zwar sind die BPM-Bestandteile nur eingeschränkt gleichzusetzen mit Phasen, die aufeinander folgen müssen, dennoch gehört zum Verständnis vom BAM, dass sich hiermit eine Lücke zwischen einfachem Beobachten und Management schließen kann, zwischen operativem Geschehen und einer Analyse im Nachhinein. Das sorgt für Wirrwarr, insbesondere bei der Kundschaft. Norbert Eiglsperger, Leiter IT-Management der Financial Markets Service Bank, steht vor der Frage, ob sich ein BAM-Projekt empfiehlt oder nicht. Dafür spricht, dass bei einer automatischen Überwachung Störfälle früher erkannt werden könnten, für eine Transparenz des Prozessfortschritts gesorgt wäre und damit eine systematische Suche nach “versteckten Kostenfressern” ermöglicht würde.

Ein Pilotprojekt der Transaktionsbank hat es schon gegeben – mit unerwartet hohen Schwierigkeiten. So stellt sich heraus, dass es zwar eine riesige Menge an Dokumentationen gibt, die Prozesse aber letztlich nicht so beschrieben sind, wie es BAM erfordern würde. Eines der Probleme bestehe darin, so Eiglsperger, dass die Prozessschritte, die in Rechnern ablaufen, ausschließlich  technisch beschrieben seien. Dazu komme, dass Banken ihre Geschäftsprozesse pro Segment betrachteten, der bankfachliche Gesamtprozess somit lückenhaft dokumentiert sei. Insbesondere fehlten Schnittstellenbeschreibungen.

Außerdem sei die Installation von “Messfühlern” mit hohem Programmieraufwand verbunden gewesen. Zudem habe sich erwiesen, dass die Folgen der Eingriffe in die komplexe Systemwelt kaum kalkulierbar sind und der Nutzen derzeit nur schwer vermittelbar, da er in einem frühen Stadium nicht quantifizierbar sei, sagt Eiglsperger. Schließlich trügen die Vielzahl der Anbieter, die zudem kaum fachliches Wissen vorwiesen, zur Verwirrung bei.

Dennoch formuliert der IT-Manager ein mögliches BAM-Projekt ehrgeizig: “Geschäftsprozess-Monitoring ist für uns mehr als nur Überwachung.” Dazu gehörten etwa Simulationsmöglichkeiten zur Darstellung von Veränderungen auf die bestehenden Abwicklungsprozesse, Stati-Verfolgung und Reduzierung von Prozessrisiken, sowie die Initialisierung definierter Notfall- und Stützprozesse beim Auftreten von Störungen.

Eiglsperger schätzt, dass ein BAM-Projekt Jahre in Anspruch nehmen könnte. Ein Dashbord, in dem die Messergebnisse in Ampel- oder Thermometerdarstellungen kumulierten, sei in einer solchen Kalkulation nicht einmal eingeschlossen.

Es geht auch ohne Big BAM

Dr. Torsten Greiner, Leiter Architektur-Management der Norisbank AG, geht einen anderen Weg. Sein Team hat eine Lösung gefunden, wie sich zunächst einmal ein Kernprozess mit Hilfe vergleichsweise einfacher Mittel überwachen lässt. Die Bank bietet Konsumenten mit ‘easyCredit’ die Möglichkeit an, online und in wenigen Minuten zu prüfen, ob ihnen ein Kredit gewährt würde. Diesen Service nutzen mittlerweile 700 Partnerbanken als vermitteltes Geschäft. Wesentlich für den Erfolg des Produkts ist die Schnelligkeit, in der ein potenzieller Kunde eine Zusage oder die Ablehnung erhält. Somit sind die Antwortzeiten die wesentlichen Schlüsselindikatoren für eine Prozessüberwachung.

Der Prozess wird durch den Auftrag eines externen oder internen Kunden ausgelöst und endet mit der Lieferung eines vereinbarten Ergebnisses an den Kunden. Um zu messen, wie schnell die Prozesse ablaufen, simulieren kleine, als Perl-Skripte geschriebene Software-Agenten das Verhalten von Antragstellern. Dabei ist jede der 20 Teilaktivitäten ein betriebswirtschaftlich logisch zusammenhängender Abschnitt auf einer HTML-Seite. Gemessen werden somit sowohl aufeinander folgende Webseiten als auch Benutzerverhalten. Den Aufwand für das Aufsetzen des gesamten Kontrollverfahrens schätzt Greiner auf 20 bis 25 Manntage.

Im Sinne von Eigelsperger, Quantz und Charlesworth handelt es sich beim Norisbank-Projekt um kein Business Application Monitoring. Anderen macht der vergleichsweise bescheidene Einstieg Mut. Denn bis sich BAM-Projekte nach seiner Definition etabliert haben, werden noch leicht fünf Jahre ins Land gehen, schätzt der Butler-Group-Analyst Ian Charlesworth. Bis dahin dürfte es zumindest erheblich weniger Anbietervielfalt geben; denn die Marktauguren erwarten eine Marktkonsolidierung erheblichen Ausmaßes.

BAM Check-up

Kürzlich war Professor Rainer von Ammon, Research Director for Bank Innovation an der Universität Regensburg, Gastgeber einer Veranstaltung zum Thema ‘Modellierung und Monitoring von Geschäftsprozessen mit Enterprise Portal Plattformen’. Aus den Problemen, von denen die Anwender der verschiedenen Finanzhäuser berichteten, hat er ad hoc eine Liste zusammengestellt. Sie benennt in Anregungen und Fragen die Punkte, auf die Anwender bei der Tool-Auswahl und beim Aufsetzen eines BAM-Projekts achten sollten.

* Um einen Prozess automatisch überwachen zu können, müssen ‘Fühler’ darin implementiert werden. Die ersten Fragen sollten sich in diesem Zusammenhang damit beschäftigen: Was und wie viel kann automatisch erfasst werden? Ist das, was gemessen werden soll, auch vorhanden? Wie aufwendig ist das Installieren von Fühlern?

* Die Dokumentation sollte die Ausnahmen vom Normalfall aufführen, sowie die Art festlegen, wie mit diesen Ausnahmen verfahren wird.

* Im Normalfall ist BAM nahezu unsichtbar, alles läuft zur Zufriedenheit. Zur Prozessüberwachung gehört jedoch auch ein Notfall- und Störungs-Management.

* Engpässe müssen gesondert dargestellt werden.

* Die Funktion der Fühler und Notfallpläne sind zu testen. Liefern die Kontrollen die Ergebnisse, die zu erwarten sind? Bricht bei einer Störung das Chaos aus? Wie lange dauert es, bis Alternativen funktionieren?

* Welche Standards gibt es und was leisten sie?

* Änderungen im Prozess müssen simuliert werden können.

* Ist die Technik skalierbar und auf proprietäre Systeme anpassbar?

* Für einen Full-Size-Ansatz müssen Anwender mit mindestens eineinhalb Jahre Projektlaufzeit rechnen. Die Implementierung eines Cockpits verursacht zusätzliche Aufwände.