Erfahrungen aus BPMS Projekten

Hohe funktionale Spezialisierung erfordert viel Koordinationsarbeit

Selbst die Automatisierung "einfacher" Prozesse in den großen arbeitsteiligen Unternehmen erfordert bereits die Einbindung einer Vielzahl von Abteilungen und Personen. Aufgrund von verteilten Zuständigkeiten ist es oftmals recht herausfordernd, die entsprechenden Know-how Träger zu identifizieren.

In der Praxis ist manchmal auch schwer festzustellen, "was geht" und "was nicht geht", die Gründe dafür sind unterschiedlich. Befindlichkeiten (wie "Festhalten an bestehender Lösung") spielen genauso eine Rolle wie das verteilte Know-how. (Wo findet man jemanden, der jemanden kennt, der weiß, wie es funktioniert ... ?)

In diesem Zusammenhang bewährt sich auch eine deutliche Modifikation des herkömmlichen Software-Entwicklungsprozesses. Dabei wird der Anwender durch einen Analytiker / Designer vom eigentlichen Programmierer abgeschirmt. Der Analytiker nimmt (abstrakt) die Anforderungen des Anwenders entgegen, formalisiert sie, der Designer entwickelt die grobe Architektur der Applikation und der Programmierer codiert dann.

Diese Trennung sollte man über weite Strecken beim "Programmieren" eines BPMS-Systems aufheben; der Anwender (ein Schlüsseluser) sollte direkt mit dem BPMS-Designer vor dem Tool sitzen und seinen Prozess "zeichnen". Dabei kann man auch gleich (Web 2.0 Technologien machen das bei großen BPMS-Suiten möglich) ein grobes graphisches Benutzerinterface gemeinsam erarbeiten. Durch das probeweise Ausführen (Simulation, Debugging Modus) dieser Prozessmodelle stellen dann beide Seiten laufend sicher, dass sie sich gegenseitig richtig verstanden haben: Sichergestellt, durch die Verwendung ein und desselben Prozessmodells.

Sicherlich muss dann später ein IT-Integrationsspezialist technische Details zu einigen "Kästchen" hinzufügen; alleine, die Struktur der Prozesses ändert sich dann nicht mehr. So wird tatsächlich "Rapid Prototyping" möglich.

Rein fachliche Modellierung in aller Regel ungeeignet für die Ausführung im BPMS

Für die fachliche Modellierung wird in vielen Betriebsorganisationen ein Standardwerkzeug eingesetzt (Visio, Adonis, Aris, etc.); praktisch alle (guten) BPMS Systeme haben aber ebenfalls einen entsprechenden Designer für den Business Architekten, noch ganz ohne Technikdetails also. Mit einem gravierenden Unterschied: In einem zweiten Schritt wird im BPMS-System das rein fachliche Modell mit den notwendigen Ausführungsdetails ergänzt. (Wo laufen welche Services? Wie werden Rollen und User aufgelöst? Wie schaut die Eingabemaske tatsächlich aus?)

In den allermeisten Fällen stellt sich heraus, dass ein wirklich ausführbares Prozessmodell circa 2-3 Mal so groß ist, wie das ursprüngliche "hübsche" Prozessdiagramm aus dem Lieblingsmodellierwerkzeug Ihrer Org-Abteilung. Vergessene Ausnahmebedingungen, Verzweigungen, Rollen, Eskalationen, Geschäftsregeln und Bedingungen: Eine deterministische Maschine verlangt eben nach allen Details - sonst kann man den Prozess eben nicht ausführen (und muss dauernd rückfragen).

Die gute Nachricht dabei ist, dass beide Seiten, der Business Architekt der Fachabteilung und der IT Designer für den IT Prozess, immer am selben Prozessmodell arbeiten. So werden Missverständnisse von Vorneherein vermieden und die Fachabteilung sieht ständig "ihren" Prozess graphisch und in der notwendigen Tiefe.

Ein weiteres "Caveat" in diesem Zusammenhang: Hersteller überbieten sich darin, den "Import" aus Visio, Aris, Adonis in ihre Prozessmaschine zu demonstrieren. Die Diskussion läuft heute meist auf den möglichen BPEL-(Business Process Execution Language)- oder XPDL-(XML Process Definition Language)-Import/Export hinaus. Viele Beratungsprojekte haben aber ergeben, dass diese Schnittstellen in der Realität kaum zu gebrauchen ist, da die meisten Werkzeuge viele Eigenmächtigkeiten zum Standard hinzufügen. Darüber hinaus - siehe oben - sind die rein fachlich modellierten Prozesse ohnehin nie ausführbar. In der Praxis spart man sich überhaupt keine Arbeit durch den Import über derartige Schnittstellen.

Steuerung ("BPM Governance") ist anzupassen

Früher gab es nur Code, Libraries, Daten(bank)modelle und Applikationen. Da hat man 20 Jahre Zeit gehabt, sich zu überlegen, wie man die von der Entwicklungsumgebung in die Testumgebung und dann in die Produktivumgebung schiebt ("Deployment" im Jargon). Und das funktioniert ja mittlerweile für diese Objekte ("Artefakte" neudeutsch) auch einigermaßen.

Mit einem BPMS fallen aber plötzlich neue zusätzliche Artefakte (Prozessdefinitionen, graphische Layout Definition für ihr Portal, Service-Definitionen, die sie aus dem Prozess aufrufen) und Metadaten an (beispielsweise unterschiedliche Versionen desselben Prozesses oder von Services), die noch dazu auch kompliziert zusammen hängen. Das kann man nicht mehr mit Excel oder Access managen, sondern benötigt ein dafür geeignetes Tool. Nicht, dass es diese nicht bereits gäbe, man muss natürlich investieren - vor allem Zeit, es zu befüllen. Zeit, die später mit einem Faktor 10 zurück kommt: Fehlersuche, Auskünfte an User, Veränderungen und Change Management (Stichwort: "Impact Analyse"). Es gibt lückenlose "Return on Investment" (ROI) Rechnungen für solche Steuerungstools: Doch gerade die Bereitschaft, ein bisschen über das nächste Quartal oder Halbjahr zu planen kann man nicht kaufen.

Fazit

Zusammenfassend lässt sich aber aus allen BPMS-Projekten eines klar ablesen und erkennen: Wenn man zu den oben angeschnittenen kleinen Modifikationen seines eigenen Verhaltens bereit ist, dann lukrieren die Unternehmen einen ROI, der den Return des reinen "Kästchen Zeichnens" um einen Faktor 50-250 übersteigt. Nun darf man sich natürlich genau solche drastischen Antworten und Konsequenzen von einer "Gretchen-Frage" erwarten: wenn man sich ihr nur stellen würde ...

www.softwareag.com/at