Neben den im letzten Beitrag besprochenen bisherigen Entwicklung des Marktes für Business Process Management-Systeme (BPMS) befasst sich das Whitepaper „State of the Business Process Management Market 2008“ von Oracle auch mit den Trends für die künftige Weiterentwicklung von BPM-Suites.
Der erste wichtige Trend ist die Echtzeit-Fähigkeit künftiger Systeme durch die Verarbeitung von Ereignissen („Real-Time Visibility with Event Processing“). Bisherige BPMS unterstützen vor allem gut strukturierte und vorhersagbare Prozesse, die nach einem vorgegebenen Prozessmodell ablaufen. Andererseits gibt es viele Prozesse, bei denen auf plötzliche Ereignisse reagiert werden muss, wie z. B. starke Preisänderungen, Lieferengpässe, auffällige Transaktionen etc. Eine sogenannte „Event-driven Architecture“ (EDA) dient dazu, relevante Ereignisse ohne Zeitverzug zu erkennen und gewisse Aktionen auszulösen.
BPMS & Ereignisse
Künftig soll nach Ansicht von Analysten eine solche EDA Bestandteil von BPMS werden. Dann können beispielsweise Prozesse durch Ereignisse ausgelöst werden, oder es kann in laufenden Prozessen auf plötzlich eintretende Ereignisse reagiert werden. Herkömmliche BPMS arbeiten eher nach dem „Pull“-Prinzip: In einem Prozess werden angefallene Daten verarbeitet, und zwar dann, wenn dies im Prozessablauf vorgesehen ist. Mit einer EDA-Komponente kann aber auch das „Push“-Prinzip realisiert werden: Es tritt ein Ereignis auf, und dies löst sofort einen Prozess oder eine Reaktion innerhalb eines Prozesses aus.
Ebenso kann ein Prozess Ereignisse auslösen, die anderswo eine unverzügliche Reaktion hervorrufen sollten. Auch Prozessmonitoring-Komponenten werden sich nicht mehr darauf beschränken, Daten abgelaufener Prozessinstanzen zu analysieren. Auch sie werden aktiv in Echtzeit auf Ereignisse aufmerksam machen.
Neben der erforderlichen Technologie zum Entdecken relevanter Ereignisse (Complex Event Processing Engines) benötigen die BPM-Systeme hierfür die Fähigkeit, Ereignisse zu empfangen und darauf zu reagieren, und umgekehrt Ereignisse zu erzeugen und zu publizieren. Auch Business Intelligence- und Business Rules-Komponenten müssen künftig die Verarbeitung von Ereignissen und Echt-Zeit-Daten unterstützen. Auch die Prozessmodellierung benötigt eine leistungsfähige Darstellung für die Verarbeitung von Ereignissen. Hier bietet insbesondere die BPMN als Modellierungs-Notation recht umfangreiche Möglichkeiten. Das erfordert auch von den Modellierern ein Umdenken – von einer reinen Reihenfolge-Betrachtung zu einer Ereignis-orientierten Logik.
BPMS & Kollaboration
Ein zweiter wichtiger Trend ist die Unterstützung einer Zusammenarbeit von „Wissensarbeitern“ im Rahmen wenig strukturierter, sich fallweise entwickelnder Prozesse. Hier geht es darum, vorhandene kollaborative Technologien wie Dokumenten-Management und Groupware-Systeme mit BPMS zu verknüpfen.
Häufig ist zwar der grundlegende Ablauf einer Produktentwicklung oder einer Fallbearbeitung strukturiert und kann damit durch ein BPMS unterstützt werden. Die Detailprozesse hingegen lassen sich hingegen nicht im Voraus bestimmen, sie hängen von der jeweiligen Situation und den Entscheidungen der beteiligten Mitarbeiter ab. Anstatt aber die hierfür verwendeten E-Mails und Dokumentenablagen wie bisher isoliert zu lassen, sollen diese Inhalte so mit dem strukturierten Gesamtprozess verknüpft werden, dass alle Informationen, die im Prozess anfallen, auch überall dort im Prozess verfügbar sind, wo sie benötigt werden.
Hierdurch lässt sich auch besser nachvollziehen, wie der Prozess abgelaufen ist, welche Probleme es gab, und wie man den Prozess verbessern könnte. Beispiele, wo dies sinnvoll eingesetzt werden könnte, sind Ausnahmebehandlungen in Standardprozessen, Fallmanagement in der Versicherungsbranche sowie die Forschung und Entwicklung.
BPMS & Web 2.0
Ein dritter Trend sei hier aufgeführt: Nutzer-getriebenes Prozessmanagement. Damit werden die aus dem Web 2.0 bekannten Technologien und ihre Einsatzmöglichkeiten im Unternehmen angesprochen. Insbesondere erwarten die Autoren benutzerfreundlichere, dynamischere Oberflächen und Tools, z. B. zur Prozessgestaltung. Solche Tools ermöglichen die verstärkte Einbindung der Mitarbeiter in die Prozessgestaltung. In manchen Fällen könnten sich von den Mitarbeitern gerade benötigte „Just-in-Time“-Prozesse zusammenstellen und durchführen lassen.
Auf jeden Fall eröffnen sich vielfältige Möglichkeiten zur verbesserten Zusammenarbeit zur „Design-Time“, d. h. bei der Enwicklung der Prozesse. Aber auch die integrierte Nutzung von Funktionalitäten aus sozialen Netzwerken, Wikis, Collaborative Filtering etc. zur „Run-Time“ d. h. bei der Ausführung der Prozesse wird ermöglicht.
Wir dürfen also gespannt sein auf interessante Weiterentwicklungen im Bereich BPMS. Wobei es letzlich immer darauf ankommt, wie diese schönen Technologien konkret dazu eingesetzt werden können, Prozesse zu verbessern und Nutzen für Unternehmen zu stiften.
Zum letztgenannten Thema, BPMS & Web 2.0, sind in diesem Blog bereits einige Beiträge erschienen, z. B. Wiki- und Prozessmanagement – ein Widerspruch?, Geschäftsprozessmodellierung 2.0 und Mashups in Prozessen?.
Ich möchte an dieser Stelle vor der unkritischen Vermischung der zahlreichen „Systeme“ warnen, die in dem oben genannten Artikel mitschwingen (wenn bpsw. ein „BPMS“ auch eine „CEP Engine“ etc. enthalten sollte).
In der Praxis wird es IMMER mehrere (selbständige) Engines (= selbständige Prozesse, die auf einer „Node“ im Sinne von UML2 ablaufen) geben müssen, um die nichtfunktionalen Anforderungen an diese Verarbeitungsform befriedigen zu können: Die BPM Engine für langsamere Humanprozesse wird nur sehr schlecht als „CEP Engine“ taugen – und umgekehrt.
Die Gretchenfrage ist natürlich die nach der Integration dieser mehreren Engines untereinander 😉
Für unsere eigene Software AG webMethods Suite kann ich derzeit schon die folgenden „Engines“ nennen:
– BPM Engine
– ESB Engine
– BAM Engine (Business Activity Monitoring)
– Communications Engine (Event Processing,
Communications
– Task Engine
– Rules Engine
– Policy Decision Point (PDP)
– Policy Enforcement Point (PEP)
Aus unserer Sicht besteht also ein volles „BPM System“ aus diesen 8 „Engines“, die alle untereinander und über CentraSite (= PDP) verbunden sind.
MfG
-cfs
Hallo Herr Strnadl,
das ist interessant. Können Sie evtl. ein Paper empfehlen, das die unterschiedlichen Typen von Engines und ihr Zusammenspiel erläutert?
Viele Grüße
Thomas Allweyer