Gastbeitrag von Dr. Martin Bartonitz, Product Manager Workflow
SAPERION AG
1 Einleitung
In der Vergangenheit gab es zwei Bereiche innerhalb einer (größeren) Firma, in denen Aufgabenketten getrennt voneinander grafisch modelliert wurden. Die Motivation der Einen war und ist es, die Qualität der Geschäftsprozesse allgemein zu sichern, indem sie diese detailliert beschrieben. Und damit man in der Außendarstellung auch noch besser da steht, lässt man sich diese Arbeit nach EN ISO 9001 zertifizieren. Die Motivation der Anderen war und ist es, Aufgabenketten automatisiert mit Hilfe von entsprechender Software ablaufen zu lassen. Ziele sind hier die operativen Geschäftsprozesse effizienter zugestalten, indem Medienbrüche vermieden und damit Fehlerquellen reduziert werden, als auch mehr Transparenz zu schaffen. Die Aufgabe der ersten Gruppe ist es also, eine reine Dokumentation der internen Verfahren aus organisatorischer Sicht zu schaffen, die jederzeit von den Mitarbeitern eingesehen werden kann. Die Aufgabe der zweiten Gruppe ist es, die Prozesse aus technischer Sicht durch Verbindung unterschiedlicher Systeme in die Ausführung zu bringen, so dass die Mitarbeiter ihre Aufgabenliste auf ihrer Workstation leichter abarbeiten können.
Abb. 1: Business Process Improvement Cycle nach Gartner
Die Vision des BPM Round-Trip Engineering ist ein reibungsloser Durchlauf durch den in Abbildung 1 dargestellten Business Process Improvement Cycles. Nach einer initialen Phase der Ist-Aufnahme (Discovery noch vor dem Define, nicht in der Abbildung dargestellt) und der Fest-legung der Strategie sowie der resul-tierenden Prozesse durch die Organi-sation, werden die Modelle zur Aus-führung übergeben werden. Während der Laufzeit werden die Prozessdaten gesammelt, um diese später wieder durch die Organisatoren zu analysieren. Resul-tie-rende Rück-schlüsse zur Optimierungen in den Stra-tegien und Prozessen schlagen sich wieder in Änderungen an den Modellen nieder.Die Realität ist, dass die Organisatoren ihre anfänglichen (grafischen) Modelle kaum mehr wieder erkennen, nach dem die IT-Engineers diese übernommen, mit den notwendigen Parametern zur Integration der zu nutzenden Systeme angereichert und ggf. auch noch an die Restriktionen des Workflow/ Business Process Management Systems angepasst haben. Besonders in den Fällen, in denen zwei unterschiedliche Anwendungen für die Beschreibung der Prozesse und für die Ausführung genutzt werden, gibt es bisher nur erste Gehversuche, die jedoch schnell bei komplexeren Prozessen an ihre Grenzen stoßen.
Aufgrund der bisherigen Erfahrungen werden daher derzeit häufig die folgenden Handlungsweisen ausgesprochen:
| | | |
| | · | Benutzt beim Modellieren nur die für das organisatorische Verständnis der Prozesse notwendigsten Symbole, d.h. überfrachtet die Modelle nicht. |
| | · | Übertragt das Modell in das technische Zielmodell manuell. |
Der Artikel legt im Folgenden die aktuell vorhandenen, noch nicht gelösten Fallstricke dar und wagt abschließend einen Blick in die Kristallkugel.
2 Doppeltes Dilemma - Sichtweisen und Software-Modelle
Abb. 2: Entwicklung der BPM und IT Modellierungssprachen.
Quelle: Sphenon
So wurde die Unified Modeling Language (UML) 1993 aus der Taufe gehoben, um genau dieser „Sprachverwirrung“, Organisator versteht IT-Engineer nicht und umgekehrt, entgegenzutreten. Mittels Visualisierungen für die Aspekte der Anwendungsentwicklung sollte es leichter werden, die beiden Parteien zusammenzubringen. Leider sind die über 10 Diagramm-Typen weiterhin sehr technisch, so dass sich die Organisatoren noch immer nicht recht abgeholt fühlen.
Deutlich besser scheint es da mit der Business Process Modeling Notation zu werden (siehe Abbildung 3). Mit der Version 2.0, die noch in 2009 das Licht der Welt erblicken soll, sind weitere Lücken aus dem eher technischen Bereich geschlossen, so dass sich diese Art der grafischen Prozessdarstellung als tragfähig für beide Gruppen erweisen könnte.
Abb. 3: Beispiel eines BPMN-Diagramms, erstellt mit dem kostenlosen BizAgi Process Modeler
Das zweite Dilemma liegt in der Unterschiedlichkeit der Tools, die zur Unterstützung für die jeweilige Aufgabe der Organisatoren und IT-Engineere entwickelt wurden. Impliziert ist dies allerdings auch wieder durch die unterschiedlichen Anforderungen. Ein Werkzeug, das sich mehr mit der Hinterlegung von detaillierten, textuellen Beschreibung und deren Veröffentlichung für die Mitarbeiter sowie Versionierung der Überarbeitung beschäftigt, bewegt ganz andere Parameter als ein Werkzeug, das die Geschäftsprozesse in der Produktion steuert. So gibt es für die Organisatoren Anwendungen wie ARIS Toolset von IDS Scheer, Prometheus von IBO, Adonis oder Bonapart von Emprise, etc. Und für die IT-Engineers ein Fülle von Workflow oder Business Process Management Systeme, wie IBM MQ Series Workflow, ORACLE BPEL Engine, TIBCO iProcessTM Suite oder SAPERION Workflow.
Letztere sind optimal für die Nutzung in der Ausführung von Prozessen bis hin zur Steuerung von Arbeitskrafteinsätzen aufgrund von Auftragsmengen. Jedoch eignen sie sich weniger für die Aufgaben der Organisatoren. In den meisten Fällen reichen den Unternehmen auch die grafischen Modellierungseigenschaften der Steuerungsanwendungen. Schaut man speziell in den deutschen Mittelstand, so wird häufig noch viel einfacher gearbeitet. Der Autor hat im letzten Jahr einen Vortrag zu diesem Thema vor den Qualitätsmanagern des Verbands der Maschinen- und Anlagenbauer gehalten. Auf die Frage, welche Werkzeuge sie für die Dokumentation nutzen, waren hauptsächlich Textverarbeitungen zusammen mit Powerpoint oder Visio genannt. Workflow-Systeme waren kaum im Einsatz, eher Dokumentenmangementsysteme mit Routing-Funktionen.
Für Firmen, die viel Aufwand in die ISO 9001 Zertifizierung gesteckt haben und mit einem der Tools der erste Gruppe gearbeitet haben und nun die Aufgabenketten in eine Workflow-Steuerung bringen wollen, kommt schnell die Enttäuschung. Viele der Tools habe zwar inzwischen eine Export-Schnittstelle entweder auf Basis der Standardsprache XPDL (XML Process Definition Language der WfMC – siehe Abbildung 6, meist noch in Version 1.1 und nicht in der aktuellen 2.0) oder von BPEL (Business Process Execution Language der OASIS). Workflow Management Systeme (WMS) werden eher XDPL importieren können während Business Process Management Systeme (BPMS) eher BPEL verarbeiten können. Die Unterscheidung der beiden liegt in der Art der Aufgaben. Während WMS primär Aufgaben an Rollen, also Personenkreise vergeben, werden von BPMS so genannte Web-Services, also Computer-Programme orchestriert.
Wurden die Prozessmodelle von einem Tool der ersten Gruppe (Tool a) in eines der zweiten Gruppe (Tool B des WMS/BPMS) übergeben, folgt noch die Arbeit der IT-Engineers. Die Modelle müssen im Tool B mit weiteren Parametern angereichert werden, u.a. für die Integration von Anwendungen wie CRM, ERP oder anderen Legacy-Systemen. Und spätestens hier kommt der Bruch. Diese Parameter finden nicht mehr den Weg zurück in das Tool A. Ändern aber die Organisatoren nochmals ihre Modelle in ihrem Tool und exportieren wieder nach Tool B, so fehlen anschließend die Parameter der IT-Engineers, die ihre Arbeit dann wiederholen müssen.
Zudem ist ein weiteres Manko festzustellen. Die SAPERION AG, bei der der Autor beschäftigt ist, musste bei der Implementierung der eigenen XPDL-Schnittstelle erfahren, dass 70% der eigenen Workflow-Funktionen in die so genannten Extensions der XPDL geschrieben wurden. Extensions werden nur von der erstellenden Anwendung verstanden, nicht jedoch von einer anderen. D.h. auf Ebene der rein grafischen Modellierung durch Organisatoren ist mit BPMN ein einheitlicher Standard gegeben, der durch Speicherung im XPDL zwischen grafischen Tools einen Austausch zu 100% ermöglicht. Ein Austausch von Prozessen zwischen WMS/BPMS macht kaum Sinn, es sei denn man verzichtet auf den Großteil der Funktionen, die den Reiz des individuellen Systems ausmacht. Auch ist eine Zusammenarbeit eines beliebigen Tools aus der ersten Gruppe mit einem der zweiten Gruppe aufgrund der Extension-Problematik derzeit nur sehr bedingt möglich.
3 Die Detaillierungsproblematik
Aber es geht noch weiter. Organisatoren beschreiben häufig in ihren Modellen jede Tätigkeiten grafisch, auch jene manuellen, die nicht durch das WMS unterstützt werden. Wenn Aufgabenketten bis ins kleinste Detail beschrieben werden, ist dies auf Seiten der Ausführungsebene eher kontraproduktiv. Die Anwender wollen nicht jede kleinste Aufgabe quittieren wollen. Hier ist jeder Mausklick zu viel. D.h. das organisatorische Prozessmodell wird durch die IT-Engineers zur Akzeptanz der Anwender „eingedampft“. Und schon wieder gibt es das Problem beim Round-Trip: Die Organisatoren erkennen ihr Modell nicht wieder.
Aber auch hier ist noch nicht zu Ende. Organisatoren visualisieren zum besseren Verständnis gerne Entscheidungsbäume. Umfangreiche Regelwerke werden mittlerweile in Rule Engines ausgelagert, d.h. für das grafische Modell ein weiteres Eindampfen, was die folgende Abbildung zeigt.
Abb. 4: Vereinfachung eines EPK-Prozessmodells durch „Eindampfen“ des Entscheidungs¬baums auf eine einzige Check-Funktion, die eine Rule Engine die Auswertung durchführen lässt
4 Die Mapping-Problematik
Und es geht noch weiter. Sollte sich der Standard BPMN tatsächlich durchsetzen (in Deutschland sind noch sehr stark die EPKs des ARIS Toolsets, wie in Abbildung 4 dargestellt, verbreitet), so haben zumindest alle Personen ein gleiches Verständnis des grafischen Modells. Bleibt noch die Frage des persistenten Speicherformats. XPDL und BPEL waren schon als Exportformat erwähnt. Jedoch lassen sich BPEL Modelle nicht wieder einlesen, da ihnen die grafischen Strukturen fehlen und sie auch Rollen nicht kennen. Bisher hat sich hier daher als Austauschformat XPDL etabliert. Ende letzten Jahres hat die OMG, unter deren Obhut auch die BPMN spezifiziert wird, ein eigenes Speicherformat, die Business Process Definition MetaModel (BDPM) in Version 1.0 freigegeben. D.h. es kommt nochmals Bewegung in das Umfeld BPM. Vermutlich wird damit XPDL überflüssig. Aber auch dem inzwischen stärker verbreiteten BPEL könnte es an den Kragen gehen. Der Grund liegt speziell in der Struktur der Modelle. BPMN und damit auch BPDM sind Graphen orientiert, d.h. sie arbeiten nach dem alten GoTo - Verfahren, indem von Aktivität A nach B nach C ggf. zuück nach B verfahren wird. BPEL dagegen ist streng Block-orientiert (und damit eher eine Programmier-sprache). So kann zwar ein Mapping von BPMN nach BPEL unter bestimmten Umständen ohne Probleme durchgeführt werden, weniger gut klappt es dagegen von BPEL nach BPMN, was wieder das BPM Round-Trip Engineering behindert. Die folgende Abbildung zeigt an einem einfachen Beispiel ein Mapping-Problem von BPMN nach BPEL.
Abb. 5: einfaches Beispiel eines Mapping Problems von BPMN nach BPEL
Die orange-farbenen Pfeile zeigen eine korrekte Repräsentation einer BPMN-Aktivität (linkes Modell) in eine entsprechende BPEL-Entität (rechtes Modell). Das hier enthaltene Problem ist die BPMN-Aktivität mit den zwei ausgehenden Pfeilen. Diese Aktivität wir im BPEL-Modell verdoppelt.Die neu freigegebene Spezifikation BPDM lässt neue Hoffnung keimen, dass das Ziel eines durchgängigen BPM Round-Trip Engineerings noch erreicht werden kann. BPDM soll die jeweiligen Vorteile der XPDL und BPEL zusammengeführt haben und optimal auf das in 2009 kommende BPMN Version 2.0 abgestimmt sein.
Zusammenfassend bleibt festzustellen, dass es bis zu einem durchgängigen BPM Round-Trip Engineering noch einige Jahre brauchen wird. Kurzfristig ist zu empfehlen, entweder nur mit dem Modellierungswerkzeug des ausgewählten WMS/BPMS zu arbeiten oder im Falle zweier unterschiedlicher Anwendungen die Überführung manuell durchzuführen. Mittelfristig könnten vorhandene Schnittstellen genutzt werden, wenn sich alle Beteiligten auf die mit ihnen verbundenen Restriktionen einlassen können. Langfristig werden wir Tools benötigen, die es ermöglichen, zwischen den Sichten der beiden Ebenen Organisation und IT-Engineering verlustfrei hin- und herzuschalten.
5 Entwicklung der relevanten
Standards im BPM
Wie bisher diskutiert, hängt die Zukunft eines reibungslosen BPM Round-Trip Engineering zwischen der Modellierungssicht der Organisatoren und der IT- Engineers von ausgereiften Standards ab. Nur mit diesen ist es möglich, Modelle aus beliebigen grafischen Prozesseditoren mit anderen auszutauschen und damit ein Zusammenspiel mit Workflow Management bzw. Business Process Management Systemen zu gewährleisten. Daher lassen Sie uns einen Blick auf die bisherige Entwicklung der relevanten Standards im Geschäftsprozessmanagement. Ich habe das erste Mal Mitte 2005 einen Überblick über die Standards gegeben, diesen Ende 2006 nochmals erneuert, und es ist wieder Zeit zu schauen, was es Neues gibt.
Abb. 6: Der lange Weg der Standards im Umfeld der Geschäftsprozesse
Die Grafik gibt einen Überblick über die Entwicklung der wichtigsten Standards im BPM-Umfeld. Der Zeitstrahl ist nicht exakt, wichtig sind hier die Zusammenhänge. Die verantwortlichen Organisationen sind mit ihrem Gründungsjahr am linken Rand angegeben. Die Kästchen der 3 wichtigen Standards XPDL, WS-BPEL und BPMN sind zur besseren Lesbarkeit heller dargestellt. Ähnlichkeiten der Grafik mit den Swim Lanes der BPMN sind rein zufällig.
Die wichtigsten Änderungen sind schnell dargestellt. Neben den Upgrades auf jeweils höhere Versionen ist wesentlich festzustellen, dass die OMG (Object Management Group) an einer eigenen Spezifikation zum Austausch von Prozessdefinitionen gearbeitet hat, der BPDM (Business Process Definition MetaModel). Die bisherigen beiden auf dem Markt genutzten Standards zur Prozessausführung sind die XPDL (XML Process Definition Language) – der WfMC (Workflow Management Coalition) und die BPEL (Business Process Execution Language) der OASIS (Organization for the Advancement of Structured Information Standards). Es gab zwei wesentliche Motivatoren für die OMG, an einer eigenen Spezifikation für die Prozessausführung zu arbeiten:
1. XPDL und BPEL haben jeweils unterschiedliche Schwächen. Während der XPDL Komponenten fehlen, die für eine vollständige Ausführbarkeit sorgen (z.B. Exception Handling, Asynchronität), fehlen der BPEL Komponenten der grafischen Positionen, Werte für die Simulation, aber viel wichtiger ein Rollenkonzept (Wer soll einen Prozessschritt ausführen?).
2. Die OMG ist auf einem guten Weg, zusammen mit der UML (Unified Modeling Language), der BPMN (Business Process Modeling Notation) und den erstmals in der Grafik dargestellten Spezifikationen BMM (Business Motivation Model), SBVR (Semantic of Business Vocabulary and Rules) und der OSM (Organizational Structure Model) das vollständigste Paket anzubieten. Zur Komplettierung fehlte noch die Komponente zur Speicherung der grafischen BPMN und damit auch der möglichen Prozessausführung. Um sich hier nicht von anderen Organisationen wie der WfMC und der OASIS abhängig zu machen, wurde daher seit etwa 2 Jahren an der eigenen BPDM (Business Process Definition MetaModel) gearbeitet.
Die BPDM-Spezifikation ist im November 2008 in der Version 1.0 freigegeben worden. Diese Version umfasst wesentlich mehr Elemente, als die BPMN in der aktuellen Version 1.1. Diese Lücke soll mit ihrer Version 2.0 noch in 2009 gestopft werden.
Wenn ich einen Blick in die Galskugel werfe, so sehe ich mit der neuen BPDM, das sowohl als Speicherformat für BPMN als auch als Basis für die Prozussausführung dienen kann, ein großes Potential, dem BPM Round-Trip Engineering näher zu kommen. Vorstellbar wäre, dass sowohl BPEL als auch XPDL überflüssig werden könnten. Allerdings stehen gerade alle großen Firmen wie IBM, ORACLE und SAP hinter BPEL, was sich insbesondere in der Anzahl entsprechend konformer Anwendungen wiederspiegelt, so dass sich diese Programmiersprache für die Orchestrierung von Web-Services noch eine zeitlang halten sollte.
Damit sich die BPMN und BPDM endgültig durchsetzen kann, ist es aber wichtig, dass sich die beiden OMG-Lager (BPM und OOP) zusammen setzen, um die UML-Diagramme mit den Spezifikationen der BPMN, BPDM, BMM, SVBR und OSM zu verheiraten. Mein Eindruck ist, dass die Programmierer eher Fans der UML sind, da in dieser Welt das Round-Trip Engineering schon etwas reifer ist, und sich mit der BPMN noch nicht richtig anfreunden können.
6 Glossar
| | |
Akronym
| Erklärung
|
BPDM
| Business Process Definition Metamodell, Definition durch OMG, 2004
Brücke zwischen BPMN und potentiellen Prozessausführungssprachen wie BPEL und XPDL
|
BPEL / BPEL4WS
WS-BPEL
| Business Process Execution Language for Web Services, IBM, Microsoft, SAP, BEA,…
XML-based Sprache zur Standardisierung von Business Processes in einer verteilten (grid computing) Umgebung, um unterschiedliche Anwendungen miteinander zu verbinden und Daten auszutauschen. Das Design ist eine Kombination von IBM’s alter WebServices Flow Language und Microsoft’s XLANG
|
BPDM
| Business Process Defintion MetaModel, Spezifikation der OMG, Version 1.0 freigegeben Ende 2008
|
BPM
| Business Process Management, Spezifikation durch BPMI
Methode als auch Verfahren zur kontinuierlichen Verbesserung von Geschäftsprozessen unterstützt durch u.a. WMS.
|
BPMI
| Business Process Management Initiation, gegründet 1999, Mai 2005 in OMG aufgegangen. Organisation von Herstellern, Beratern und Anwendern zwecks Standardisierung der Architektur und Schnittstellen von BPMS.
|
BPML
| Business Process Management Language, Definition durch BPMI, 2001
XML-basierte Geschäftsprozessbeschreibung. Zugunsten WS-BPEL aufgegeben
|
BPMN
| Business Process Management Notation, Definition durch BPMI, 2004
Grafische Notation zur Beschreibung von Geschäftsprozessen, ist auf dem besten Wege, sich neben den EPKs und Petri-Netzen zum Standard zu werden.
|
BPMS
| Business Process Management System, Definition durch BPMI
System zur Unterstützung von BPM mit dem Kreislauf: Model, Execute, Monitor, Analyze & Improve. Ein WMS ist eine Teilkomponente.
|
OASIS
| Organization for the Advancement of Structured Information Standards, seit 1993.
Sie ist ein not-for-profit, internationales Konsortium, das die Entwicklung und die Verbindung mit anderen e-Business Standards vorantreibt (u.a. UDDI, WSS, ect.)
|
OMG
| Object Management Group, seit 1997. Ein not-for-profit Konsortium, das die wichtigsten Interoperabilitätsstandards der Computer-Industrie specifications vorantreibt (u.a. MDA, UML, OMA, CORBA, …)
|
OOP
| Object Oriented Programming, Programmier Methode unterstützt durch die UML-Diagramme der OMG
|
SOA
| Service Oriented Architecture, eine Methode, die vorhandenen EDV-Komponenten wie Datenbanken, Server und Websites so in Dienste zu kapseln und dann zu koordinieren („Orchestrierung“), dass ihre Leistungen zu höheren Diensten zusammengefasst und anderen Organisationsabteilungen oder Kunden zur Verfügung gestellt werden können.
|
SOAP
| Simple Object Access Protocol SOAP, spezifiziert von der W3C.
XML-basiertes “lightweight protocol” zum Austausch von Informationen in einer dezentralisierten, verteilten Umgebung.
|
UDDI
| Universal Description Discovery and Integration, Spezifikation der OASIS
|
UML
| Unified Modeling Language, Definition durch OMG, Version 2.0 in 2005
Grafische Notationen zur Beschreibung IT-spezifischer Aspekten zur Erstellung von Software, u.a. von Geschäftsprozessen, hat das Zeug zum Standard zu werden.
|
W3C
| World Wide Web Consortium, gegründet 1994 durch Tim Berners-Lee, dem erfinder des Web.
|
WfMC
| Workflow Management Coalition, gegründet 1993
Organisation von Herstellern, Beratern und Anwendern zwecks Standardisierung der Architektur und Schnittstellen von WMS.
|
WMS
| Workflow Management System, Definition durch WfMC
System zur Automatisierung von Geschäftsprozessen.
|
WPDL
| Vorgänger von XPDL, 1999
|
WSFL
| Web Services Flow Language, spezifiziert von IBM. Eine XML-basierte Sprache zur Beschreibung von Web-Services Kompositionen als Teil einer Business Process Definition. Sie wurde von IBM als Teil eines Web-Service-Technologie-Framework definiert und berücksichtigt existierende Spezifikationen wie SOAP, WSDL, XMLP and UDDI.
|
XLANG
| Siehe BPEL
|
XPDL
| XML Process Definition Language, Definition durch WfMC, 2001 & 2005
XML-basierte Geschäftsprozeßbeschreibung, dient u.a. dem Austausch zwischen unterschiedlichen WMS.
|
Metadata
