In meinen Beratungsmandaten zum Thema Business Process Management finde ich oft sehr unterschiedliche Ansätze, wie mit der toolgestützten Modelllierung von Business-Prozessen oder IT-Prozessen umgegangen wird. Es gibt nicht wenige Hardliner, die auf proprietäre Microsoft-Applikationen setzen, da diese ja ohnehin im Lieferumfang des Gesamtpaketes enthalten sind. So werden mir unter anderem meist Prozess-Grafiken auf Basis von Powerpoint oder Visio vorgelegt, die zwar schnell zu machen sind, aber dadurch auch gravierende Nachteile aufweisen. Zumindest gibt es für Visio bereits eine BPM-Palette im Standard-Paket und ein breit gefächertes Angebot an Stencils, die gegen Entgelt oder sogar lizenzfrei für etwas entspannteres Modellieren sorgen – und sogar BPMN 2.0 konforme Notation erlauben.
oft ausreichend: BPMN mit MS VISIO
Aber mal Hand aufs Herz: Welcher Modellierprofi kommt heute bei der bereits recht breiten methodischen Durchdringung noch ohne eigenes Repository, Plausibilitätsprüfungen und Prozess-Simulation aus? Vielleicht ist das ja auch der Olymp der BPMN-Nerds….am Gipfel der unterstützten Modellierung wieder zurück zur guten alten Handzeichnung zu wechseln und zu wissen, dass es so passt. Doch davon bin ich aber irgendwie noch meilenweit entfernt.
Also die Frage stellt sich: WAS möchte ich mit meinen Prozessen anschliessend anstellen und WIE stelle ich sicher, dass sie “richtig” modelliert sind? Bei dem Wort “richtig” modellieren wird’s dann schon kompliziert…etwa so, wie wenn man in einer Amerikanischen Kaffeehaus-Kette einen Filterkaffee bestellt und mit 10 Gegenfragen als Antwort bombardiert wird. Viele Tools implementieren bereits eigene Auslegungen bzw. Varianten der BPMN 2.0 Notation der OMG. So gibt es Anbieter, bei denen auf Level 2 (aufgeklappte Teilprozesse) schon keine separaten Pools mehr möglich sind. Andere schränken die Symbolpalette von vorne herein “pragmatisch” ein, was aber in der Modellierung schnell an Grenzen führen kann. Solche Begleiterscheinungen des Tooleinsatzes treten meist erst nach einer erfolgten Evaluation und strategischen Festlegung auf – die Folgen sind oft Ärger oder unnötige Kompromisse in der Modellierung.
In vielen Anforderungen geht es tatsächlich immer noch um die abstrakte, von jeglichem Workflow oder Folgeaktivitäten abgekoppelte Dokumentation von Prozessen – sei es zur Vervollständigung von Arbeitspapieren oder zur Vorbeitung auf eine Zertifizierung mit dem Anspruch auf dokumentierte Prozesse. Spätestens an dieser Stelle sollte die Entscheidung fallen: WAS ist das Ziel der Prozessmodellierung? Hier kann es sogar pragmatisch sinnvoll sein, zur besseren Lesbarkeit im Rahmen einer Weisung auf komplexe Tools mit diversen Muss-Kriterien zu verzichten. Was aber, wenn dann plötzlich doch eine Workflow-Engine eingeführt werden soll, die einige Arbeitsabläufe wie Genehmigungsinstanzen automatisch abbildet? Auch hierzu hat der Markt längst reagiert und bietet selbst für einfache Freeware-Notationsprogramme die benötigten Schnittstellen-Funktionalitäten wie UML an. Soweit gut – aber ich habe in meiner Praxis noch KEIN Tool und keine Suite erlebt, wo der Export von UML-Code aus der Modellierung als Input für eine Workflow-Steuerung getaugt hätte. Spricht also UML auch Dialekte…oder liegt es einfach an den fehlenden Verifizierungsmöglichkeiten einfacher Tools, so dass Modellierungsfehler 1:1 in die UML-Sprache einfliessen und die Worklfow-Engine dann nur Bahnhof versteht? Ich habe die Erfahrung sowohl mit einfachen Tools wie Bizagi gemacht als auch mit aufwändigen Suiten, die die Modellierung mittels Token-Simulation verifizieren.
manche BPM-Suiten erlauben Token-Simulationen
Aus meiner bisherigen Praxis habe ich einige Bewertungskriterien als unbedingtes Muss definiert, die ich persönlich bei Kunden-Evaluationen einfliessen lasse und hoch priorisiere. Hier ein Ausschnitt der wichtigsten Kriterien aus meiner Sicht:
- ist reine Prozess-Dokumentation gewünscht oder ist eine Automatisierung geplant?
- wird streng gemäss BPMN 2.0 Notation modelliert oder sind aus Pragmatismus Abweichungen erlaubt/vorgesehen?
- Dokumentieren mehrere User parallel an Prozessmodellen oder gibt es nur einen Autor?
- Sollen neben der Prozessmodellierung auch Kontext- und Datenflussdiagramme erstellt werden?
- Gibt es eine Versionierung bzw. Release-Management für die erstellten Daten?
- Werden ältere Versionen archiviert und können diese bei Bedarf wieder aktiviert werden?
- Gibt es Vorgaben, in welche Umsysteme die UML-Exporte eingelesen werden sollen?
- Soll eine Prozesslandkarte mit interaktivem HTML-Code für die Publikation auf dem Intranet erstellt werden?
- Können Prozess-Informationen und Dokumentationsinhalte direkt im Tool erfasst werden?
- Werden Prozesse in mehreren Sprachen ausgerollt?
- Lassen sich einmal definierte Prozessteile als Objekte in anderen Prozessen verwenden?
- Gibt es einen guten technischen Support, Newsgroups, Foren und sonstige Interessengruppen für dieses Werkzeug?
Diese Liste ist natürlich nicht abschliessend – aber ohne diese Kriterien abzufragen würde ich inzwischen keine Tool-Evaluation für Kunden mehr durchführen.
Im Internet finden sich dazu immer wieder Vergleichstests und Empfehlungen, die allerdings mit grosser Vorsicht zu geniessen sind. Nicht immer sind die Autoren objektiv, nicht immer sind die Kriterien wirklich ausschlaggebend, da die Gewichtungen bei der Bewertung sehr unterschiedlich ausfallen. Auf der anderen Seite schiessen die Tools wie Piilze aus dem Boden, was die Entscheidungsfindung auch nicht gerade einfacher macht. Mit der Zeit kristallisieren sich aber doch einige “preferred supplier” heraus, mit denen man einfach über die Bandbreite der Kriterien gute Erfahrungen macht. Die eigene Erfahrung ist denke ich auch der Schlüssel – und je tiefer man in die Möglichkeiten dieser Werkzeuge eintaucht, desto schärfer wird das Bild. Blindes Vertrauen in die Meinung anderer kann erheblichen Verdruss für das eigene Einsatzgebiet bedeuten.
Denn letztendlich zählt der Mehrwert für den Kunden bzw. Auftraggeber – nicht der für den BPMN-Modellierer.