Die Branche beschwört das Alignment, doch die Praxis in den Unternehmen sieht meist anders aus. Nachdem in den 90er Jahren die Modellierung der Fachabteilungen mit klassischen Notationen wie ereignisgesteuerten Prozessketten (EPK) von IDS Scheer oder Adonis ihren Höhepunkt erlebte und die so in Form von Modellen dokumentierten Prozesse reihenweise Büroschränke füllten, änderte sich die Situation spätestens mit der SOA-Welle. Mit ihr verstärkte sich der Trend zur IT-getriebenen Prozessautomatisierung etwa mit der Business Process Executive Language (BPEL) oder der XML Process Definition Language (XPDL).
Diese Schwerpunktverlagerung weg von der fachlichen hin zur technischen Modellierung hat allerdings auch zu bedenklichen Entwicklungen geführt. So haben die letzten Jahre gezeigt, dass gerade die wenig technikaffinen Fachbereiche nicht mehr so strikt auf Standardmodellierer wie etwa Aris setzen, sondern auch aus Kostengründen weniger syntaktisch definierte Formate verwenden, indem sie zum Beispiel mit Visio-Flow-Charts, Excel-Tabellen oder Powerpoint-Zeichnungen arbeiten. Damit läuft man Gefahr, sich im Vergleich zu den 90er Jahren zurückzuentwickeln, da solche "Mal"-Werkzeuge keinen Rahmen mehr für eine einheitliche Modellierung bieten, geschweige denn für den Austausch von Modellen.
Letzterer war allerdings schon vor dem SOA-Hype kaum möglich. Wer glaubte, die im Fachbereich entstandenen Modelle könnten ohne größeren Aufwand für die maschinelle Automatisierung herangezogen werden, wurde oft enttäuscht. In der Regel dienen auch heute noch die fachlichen Modelle nur als Vorlage, um auf ihrer Basis im technischen BPM-System meist manuell ein neues Modell zu erstellen. Der Grund: Die Ursprungsmodelle beschreiben organisatorisch-betriebswirtschaftliche Abläufe und beinhalten damit zwangsläufig viele Aspekte, die für die technischen Modelle zur Prozessautomatisierung völlig irrelevant sind. Gleiches gilt umgekehrt, wenn die IT mit ihren Werkzeugen Prozesse automatisiert und meint, die dabei entstehenden Modelle mit ihren systemseitigen Ausführungsinformationen seien auch im Fachbereich zu gebrauchen.
Verständnis entwickeln
Letztendlich ist der Weg vom fachlichen zum technischen Prozessmodell der sinnvollere. Bereits die manuelle Übertragung von fachlichen Prozessen auf ein technisch ausgerichtetes Prozessmodell verbessert den Entwicklungsprozess deutlich. Dieses Vorgehen stellt zumindest sicher, dass sich beide Seiten Gedanken darüber machen müssen, worauf die jeweils andere abzielt. Das gegenseitige Verständnis der Beteiligten steigt enorm - die größte Strecke im Business-IT-Alignment dürfte hiermit bereits zurückgelegt sein.
Klar verteilte Rollen
Trotz dieser Annäherung waren und sind die Aufgaben klar verteilt: Dem organisatorischen Prozess-Management obliegt die Modellierung betrieblicher Abläufe, die technische Umsetzung von Prozessen in Softwaresystemen übernimmt die IT. Entgegen dieser Praxis propagiert die Branche in jüngster Zeit eine durchgängige Werkzeugkette und führt nicht selten die bevorstehende Version 2.0 des OMG-Standards BPMN als Brückenschlag an. Die Notation soll beiden Welten dienen und erntet damit Lob und Kritik.
Befürworter begrüßen, nun beides mit einer Sprache bewerkstelligen zu können, so dass Fachbereich und IT näher zusammenrücken könnten. Kritiker halten dagegen, BPMN sei ein Kompromiss, der nichts richtig könne. So behaupten EPK-Anhänger, dass BPMN für die Fachbereiche zu technisch sei. Ein BPMN-2.0-Diagramm, wenn es mit dem Einsatzziel Prozessautomatisierung erstellt wurde, sei nicht weniger komplex als bislang ein BPEL-Diagramm. Das ist sicher nicht falsch, müssen doch die Aussagen zur technischen Realisierung in beiden Notationen getroffen werden. Etwa 30 bis 40 Prozent der Inhalte sind technischer Natur und behandeln zum Beispiel die für Workflows erforderlichen Datentransformationen und Zuweisungen. Für den Fachbereich ist dies nicht nur uninteressant, sondern in BPMN nur unwesentlich besser zu lesen als in einem BPEL-Diagramm.
Tatsächlich stützen die Neuerungen im Update in erster Linie die technische Seite. Die Erweiterungen von Version 1.1 zu Release 2.0 zielen im Wesentlichen darauf ab, die Sprache für Aufgaben der Automatisierung zu verbessern. So haben die Entwickler erstmals definiert, wie man die grafischen Darstellungen standardisiert mit XML ausdrücken kann. Das heißt, die Regeln der im BPMN-Metamodell beschriebenen Sprachsyntax wurden dahingehend erweitert, wie eine in XML konkretisierte Instanz des Modells auszusehen hat, um sie in einer Process Engine auszuführen.
Vom Modell zur XML-Instanz
Die Standardisierung der XML-Instanzen soll natürlich auch den Schritt in Richtung Modellaustausch unterstützen. Wichtig war es den Entwicklern darüber hinaus, in dem als Diagram Interchange (DI) benannten Format nicht nur den Austausch von Symbolen mit ihren Attributen zu ermöglichen, sondern auch den der Layout-Informationen, damit ein Diagramm, wenn es von einem anderen Werkzeug eingelesen wird, nicht völlig anders aussieht.
Mit diesen neuen Möglichkeiten zeichnet sich ein Erfolg für BPMN ab, was bereits daran ersichtlich ist, dass bisherige BPEL-Protagonisten wie IBM, Oracle und SAP künftig bevorzugt auf BPMN setzen wollen. Damit wird aber auch deutlich, dass sich die Gemeinsamkeiten für einen Modellaustausch in erster Linie auf technischer Ebene abspielen. Die Modellkonvergenz zwischen Fachbereich und IT bleibt davon weitgehend unberührt.
Aber selbst im technischen Lager bleibt der Modellaustausch ein frommer Wunsch, da die BPMN-Spezifikationen an mehreren Stellen die Details der Implementierung den Herstellern überlassen. Theoretisch wäre der Modellaustausch zwischen den verschiedenen BPM-Werkzeugen der IT möglich, praktisch funktioniert er aber nur rudimentär. Auf der Ebene des Austauschs ausführbarer Informationen bestehen heute keine funktionsfähigen Lösungen. Der Grund: Die erfassten Daten sind sehr proprietär in den jeweiligen Ausführungsmaschinen eingebunden. Eine allgemeingültige Abbildung über BPMN-2.0-Syntax ist technisch noch in keinem Werkzeug ausreichend implementiert.
Noch schwächer sind technische und fachliche Modellierungs-Tools integriert - selbst innerhalb der Produktsuiten eines einzigen Herstellers. Stellvertretend für die Branche mag hier IBM herangezogen werden, deren fachlich ausgerichteter Modellierer "System Architect" in der Rational-Sparte angesiedelt ist, während das auf technische Automatisierung ausgelegte Produkt "Websphere Modeler" im Unternehmensbereich Websphere-Middleware entwickelt wird. Den fachlichen Part im Websphere-Umfeld soll jetzt die Anfang Januar übernommene Technik von Lombardi übernehmen, die seit Juni in einer ersten Version als "bluewashed" gilt und somit den Namen Websphere Lombardi tragen darf.
Kein Königsweg
Damit wird deutlich, dass BPMN 2.0 nicht der Königsweg zur gemeinsamen Prozessmodellierung von Fachabteilung und IT sein kann. In der Praxis liegt das wesentliche Problem aber nicht auf der Seite technischer Machbarkeit, sondern in der unterschiedlichen Semantik, die die an einer Modellierung beteiligten Personen benutzen. Fachbereiche verfolgen in der Regel andere Ausdrucksziele mit einer Modellierung als Automatisierer. Die Modelle passen deshalb semantisch nicht zueinander. Wenn die Inhalte nicht übereinstimmen, hilft auch keine gemeinsame Notation.