Der Entwicklungsprozess für BPM-Lösungen bringt oft Herausforderungen bei Governance, Organisation und der praktischen Durchführung mit sich. Die Komplexität erhöht sich mit der Involvierung von verschiedenen Rollen, die vom Fachbereich über die IT-Entwicklung bis hin zum Betrieb reichen. Die Koordination und Durchgängigkeit des Gesamtprozesses ist keine einfache Aufgabe. Trotzdem lohnt sich diese Konsolidierung und Bündelung der Aktivitäten verschiedener Bereiche mit dem Ziel eines flexiblen, adaptiven und schnell reagierenden Unternehmens. Ergebnisse dieser Anstrengungen sind u. a. in die Lösung eng eingebundene Fachbereiche und eine vitale IT, die schnell auf fachliche Anforderungen reagiert.
Eine pragmatische und mit Tools unterstützte „Business-driven Development“-Methodologie leistet hier eine große Hilfe. Das Vorhandensein einer starken Process-Engineering-Rolle ist die Grundvoraussetzung für die erfolgreiche Umsetzung der BPM-Disziplin.
Der Grad der toolgestützten Umsetzung des BPM-Zyklus wird oft als „Round-Tripping" bezeichnet. Man unterscheidet generell zwischen zwei Round-Tripping-Implementierungen:
Sichten auf ein Modell: Basierend auf unterschiedlichen Sichten auf dasselbe Prozess-Repository, wobei sich Änderungen auf dieselben Artefakte beziehen und je nach Sicht – fachlich oder technisch – gefiltert werden können. Häufig handelt es sich hier um BPM-Suites mit proprietärem Objektmodell und wenig Integrationsmöglichkeiten mit anderen Tools im Rahmen des BPM-Zyklus. Ein Vorteil ist die Pflege aller Modelländerungen aus allen Perspektiven. Nachteile bestehen in großen Objektmodellen sowie in der Einstellung zur absichtlichen Trennung der fachlichen und IT-relevanten Prozessmodelle in den Unternehmen.
Modell-Transformationen: Dabei handelt es sich entweder um ein oder unterschiedliche Repositorys, wobei das Prozessmodell als Computational Independent Model (CIM) über das Platform-Independent-Model (PIM) nach in ein Platform-Specific-Model (PSM) überführt und durch die Anwendungen ausführbar wird. Das ist der typische Fall bei der Integration von Tools unterschiedlicher Hersteller, wobei die Offenheit oft durch die „schmale“ Standard-Schnittstelle beeinträchtigt wird. Daher werden hier Tool-Integrationen eingesetzt, die über die Standard-Austauschformate (z. B. BPEL) hinausgehen und Hersteller-Erweiterungen berücksichtigen. Eine Herausforderung ist auch die Asynchronität der Integration, die typischerweise besser in Richtung Ausführung (Business zu IT) als umgekehrt (IT zu Business) ausgestattet ist. Dies hat auch Gründe im Verständnis der Anwendung des End-to-End-Change-Management-Prozesses, der immer im Fachmodell anfangen muss. Trotzdem ist es notwendig, Änderungen aus der IT zurück ins Fachmodell zu übernehmen (s. o.), damit wiederholte Anpassungen an derselben Stelle in künftigen Prozessversionen vermieden werden. Selbst wenn die Überführung der IT-Änderungen zurück ins Fachmodell manuell bzw. halb manuell erfolgt, wird das durch die daraus resultierte Einsparung der Aufwände in den folgenden Versionen überkompensiert.
Auch wenn die erste Alternative als die bessere Lösung erscheint, wird in der Praxis häufiger die zweite Alternative verwendet. Gründe dafür sind:
-
historische Nutzung von Fachmodellierungstools und große Anzahl vorhandener Prozesse,
-
unterschiedliche Stärken der BPM-Tools und „Best-of-Bread“ BPM-Toolauswahl,
-
unterschiedliche Prioritäten und Vorlieben der unterschiedlichen Rollen, die am BPM-Prozess beteiligt sind.
Daher ist „Round-Tripping“ ein Muss im BPM-Entwicklungsprozess, die konkrete Ausprägung des „Round-Trippings" allerdings muss gemäß den Gegebenheiten und verwendeten BPM-Tools optimiert und möglichst automatisiert werden.
Durchgängigkeit zwischen CIM, PIM und PSM
Ein weiterer Erfolgsfaktor bei der Implementierung liegt in den unterschiedlichen Ansichten bzgl. Durchgängigkeit und Überführung des fachlichen Prozessmodells bis zur Prozesslaufzeit. Ein ursprünglich aus ausschließlich fachlicher Sicht modellierter Prozess ist nicht ausführbar. Oft enthält das Modell implizite Informationen, die nur der Prozessmodellierer erläutern kann, und Mehrdeutigkeiten, d. h. mangelnden Determinismus. So ist es meist nicht algorithmisch vollständig. Daher existieren zwei Ansichten bei der Überführung dieses CIM-Modells nach PIM und PSM:
Klonen des CIM in ein PIM, das synchron mit dem PSM gehalten werden kann („Round-Tripping"): Hintergrund dieser Methodik ist die unterschiedliche Denkweise in den Fachbereichen und in den IT-Abteilungen. Erstere denken nicht in ausreichendem Maße algorithmisch. Dabei wird das fachliche Prozessmodell beibehalten, wie es ist. Das PIM-Modell wird parallel erstellt und in Anlehnung an das CIM auf die Ausführung vorbereitet. Danach wird eine enge Integration von PIM und PSM gewährleistet, sodass ab dem PIM-Stand das Round-Tripping gegeben ist. Ergebnis ist das Prinzip der „Separation of Concern" zwischen Fach- und IT-Abteilung. Die Synchronisation zwischen CIM und PIM stellt allerdings eine Herausforderung dar, da diese manuell erfolgt.
Änderungen am Prozessmodell: Hier erfolgt die Anpassung zum PIM im CIM selbst, was zur Folge hat, dass bei den nächsten Versionen eine gemeinsame Basis für Fachbereich und IT geschaffen wird. Gestützt durch Modellierungskonventionen, wird das Round-Tripping auf die CIM-Ebene erweitert. Der Vorteil einer gemeinsamen Sicht wird durch die höheren Anforderungen an die Fachabteilung und durch die Vermischung von IT- und fachlichen Artefakten häufig relativiert. Unterschiedliche Sichten und Filter können jedoch bei der der Trennung von Fach- und IT-Artefakten helfen.
Mit der Anpassung des PIM im CIM selbst erhält man einen weiteren Vorteil: Die Prozesse können im Laufe ihrer Entstehung direkt getestet und dabei häufige Deployment-Zyklen ohne IT-Abhängigkeit durchlaufen werden. Voraussetzungen hierfür ist die Bildung einer „Sandbox"-Umgebung sowie die Versorgung mit den notwendigen („Mocked") Services seitens der IT. Dieses sogenannte direkte Deployment ist ein mächtiges Mittel zur Steigerung der Prozessqualität und Plausibilität.
Auch hier hängt das Kosten-Nutzen-Verhältnis von den unternehmensspezifischen Gegebenheiten und der Tool-Integrationsfähigkeiten ab. Allerdings ist im Rahmen der Festlegung der BPM-Methodik zu überlegen, wo die Grenze zwischen CIM und PIM liegen soll und in welchem Format bzw. Tool diese Variante optimal eingesetzt werden kann.
Die Entwicklungsphasen entlang des Regelkreises
Ein typischer, einmaliger Durchlauf des BPM-Regelkreises im Rahmen eines BPM-Projekts wird in Abbildung 8 schematisch dargestellt.
Abbildung 8: Phasen im BPM-Entwicklungsprozess
Es folgt eine kurze Beschreibung sowie eine Erläuterung der ausführenden Rollen, verwendeter Tools und zu beachtender Details der einzelnen Entwicklungsphasen:
Phasen im BPM-Entwicklungsprozess – Teil 1
Abbildung 9: Phasen im BPM-Entwicklungsprozess – Teil 1
