Die Nutzung von „Mapping and Modelling Tools“ hat Mark McGregor in einer Umfrage untersucht, deren Ergebnisse sich hier herunterladen lassen (Registrierung erforderlich). Beim „Mapping“ von Prozessen handelt es sich um die rein grafische Darstellung, also das bloße „Malen“ eines Prozessablaufs, wie es häufig mit Microsoft Visio praktiziert wird. Interessanterweise wird hierfür neben Visio auch sehr häufig Powerpoint eingesetzt.
Im Gegensatz dazu versteht McGregor unter „Modelling“ die konsistente Erfassung aller mit einem Prozess verbundenen, relevanten Informationen, typischerweise mit einem Datenbank-gestützten Tool, das auch Auswertungen, verschiedene Sichten usw. zulässt. Führendes Tool in diesem Bereich ist ARIS, gefolgt von System Architect, iGrafx, Provision, Casewise, Nimbus und MEGA. Die Antworten auf einige Fragen legen allerings den Schluss nahe, dass auch diese, sehr leistungsfähigen Tools, häufig nur zum reinen Prozess-Malen verwendet werden. Kein Wunder, dass viele Firmen den tatsächlichen Nutzen dieser Tools als sehr gering erachten. So gaben bei den teureren Tools 60% der Nutzer an, dass der Return on Invest (ROI) niedriger als erwartet ausgefallen sei.
Als wichtigste Anforderung an die Tools wurde eine einfache Bedienung genannt. Andererseits vermeldeten die Anwender, die bereits seit längerer Zeit ein richtiges Modellierungstool verwenden, keinerlei Probleme mit der Bedienung. Hier herrschen zu Beginn wohl oftmals falsche Erwartungen bei den Anwendern. Um tatsächlichen Nutzen zu erzielen ist ein leistungsfähiges Tool erforderlich. Ein solches weist zwangsläufig eine gewisse Komplexität auf. Viele Funktionen sind daher nicht intuitiv bedienbar und müssen erlernt werden. Eine wichtige Grundlage für den Erfolg ist daher eine gute Schulung der Modellierer.
40% nutzen sowohl Mapping- als auch Modellierungstools. Dies bedeutet zwangsläufig, dass es keine unternehmensweite durchgängige Modellierung gibt, sondern verschiedene Bereiche ihre eigenen Modellierungswelten aufgebaut haben.
Bei 20% der Endanwender werden überhaupt keine Mapping- oder Modelling-Tools verwendet. Dies ist erstaunlich, handelt es sich bei den Befragten doch im Wesentlichen um Empfänger des BPM-Newsletters von Mark McGregor, die zwangsläufig eine gewisse Nähe zum Thema Prozessmanagement haben. McGregor wundert sich über diesen Prozentsatz und stellt die Frage, wie solche Organisationen ISO 9000- oder SOX-Compliance erreichen wollen.
Es wurde auch danach gefragt, für wie wichtig die Unterstützung der BPMN gehalten wird. 40% aller Befragten hält dies für sehr wichtig oder wichtig, nur 25% antwortetet, dass die BPMN nicht benötigt würde. Verglichen mit der öffentlichen Diskussion um BPMN findet McGregor diese Zahlen niedrig. Hierbei unterscheidet sich die Einschätzung zwischen den befragten Tool-Herstellern und End-Anwendern wenig. Größeres Interesse haben die Berater, die davon profitieren würden, wenn sie in allen Projekten dieselbe Notation anwenden könnten. Trotzdem sind 75%, die die BPMN zumindest nützlich finden, eigentlich nicht gering zu schätzen. Das Interesse an BPMN ist vor allem dann gegeben, wenn es darum geht, eine neue Notation oder ein neues Tool auszuwählen, oder wenn man die verschiedenen im Unternehmen vorhandenen Notationen vereinheitlichen möchte.
Der Unterschied zwischen Malen und Modellieren ist vielen Menschen immer noch nicht geläufig. Interessant finde ich auch die Aussage mancher BPMS-Anbieter, die behaupten, mit Tools wie ARIS könne man ja nur malen. Da vermischen sich die Begriffe: Diese Anbieter unterscheiden nur modellieren und automatisieren, und setzen ersteres mit „malen“ gleich. Was mich aber auch etwas nervt, ist die Gleichsetzung von „modellieren“ und „Datenbank“, ich höre immer: „Wir brauchen ein datenbank-basiertes Tool“, damit wir ordentlich modellieren können. Das ist natürlich Quatsch, denn 1) arbeiten auch Mal-Werkzeuge häufig mit Datenbanken (nur dass sie die DB nicht für Modelle verwenden), und 2) braucht man keine Datenbank, um Modelle strukturiert zu speichern (geht ja auch mit XML etc.). Hier kehrt sich die Sache um: Die Anwender setzen gewünschte Funktionen zu früh mit vermuteten Technologien gleich. Jetzt denkt manch einer „Ist doch egal, Hauptsache man versteht’s!“. Aber genau das ist eben nicht gegeben, ich habe die entsprechenden Ausschreibungen gesehen, die viel kosten und nichts nutzen wg. solcher Missverständnisse. Besser wäre es m.E., von einem strukturierten Objekt-Repository zu sprechen. Aber das ist vielen wieder zu abstrakt, zu technisch oder zu englisch. Naja, die liebe Sprache.
Ich habe so gelacht, als ich Ihren Bericht gelesen habe. Auch in meinem ehemaligen Unternehmen wurden die in ARIS modellierten Prozessen als ‚bunte Bildchen‘ bezeichnet. Lieber wurden an den in Word beschriebene Arbeitsbeschreibungen festgehalten, um eine gewisse ‚Flexibilität‘ zu gewährleisten. Meines Erachtens war Transparenz und die wahrscheinlich daraus resultierenden Maßnahmen nicht wirklich erwünscht. Auch ich konnte die Erfahrung machen, was alles in den großen wohlklingenden Topf ‚BPM‘ zusammen gefasst wurde. Ich frage mich auch nicht, warum einige Unternehmen ihre Prozesse nicht im Griff haben. Wenn man doch so viele Systeme für ‚Prozessmanagement‘ im Hause hat. Workflowsysteme, ARIS, SAP, IT-Bebauungsplan (hierfür auch ein separates System), Visio, Word, auch Excel und wer weiß was noch – und jedes System ist nur für einen Bruchteil zuständig. Aber immerhin – jeder Prozess ist für sich ein end-to-end-Prozess. Wäre es nicht möglich den Überblick in einem System zu integrieren? Mit Schnittstellen versehen?
Oder ist dies wieder eine Kostenfrage?
Ich denke, es ist nicht alleine eine Kostenfrage. Oft setzen Unternehmen gleichzeitig mehrere Tools ein. Für die Qualität der Modellierung ist es aus der Toolsicht die Frage, welche Unterstützung das Tool zur Modellierung bietet. Und hier kann auch ein Visio mit ein paar Verfeinerungen (Add-ons) schon einiges bieten. Die Datenbank ist im Hinblick auf ein Objekt-Repository schon wichtig. Aber so etwas kann man auch mit einer geschickten Anwendung von Modellen für statische Inhalte eines Prozessmodells umsetzen. Letztendlich liegt es aber am Modellierer, und der wird nicht von selbst besser, ob er nun ein Tool für 8000 € oder 800 € verwendet.
Keiner der Hersteller hat eigentlich ein richtiges Interesse, vorhandene Prozess-Beschreibungen aus seinem Tool an andere Tools weiterzureichen. Man spricht zwar von offenem Datenaustausch über XML, aber versuchen sie mal mit solchen Formaten wie XMI oder XPDL Daten zwischen zwei Tools auszutauschen. Es ist weniger eine Kostenfrage als die Strategie der Marktführer, einen Datenaustausch nur halbherzig zu unterstützen. Z.B. keine oder nur unvollständig Metadaten für einen Austausch von Prozessmodellen in der Schnittstelle vorzusehen. Damit haben sie nur die halbe Miete an benötigter Information.
Dem Thema haben wir uns mit der Plattform BPM-Xchange gewidmet. Diese Plattform fungiert als Prozess-Austausch Hub zwischen den unterschiedlichen Tools wie zB. Metastorm/ProVision, Aris, Casewise oder einem Visio. Damit können wir sicherstellen, dass mit dem notwendigen Metadatensupport die Tools sich verstehen, sprich in Visio Flowchart und in ARIS (zumeist) eEPK zur Modellierung von Prozessabläufen verwendet (äh. gemalt) wird und trotzdem die Prozessbeschreibungen ausgetauscht werden können. Somit kann ein Geschäftsanwender in einem Tools wie Visio Prozesse aufnehmen und dokumentieren und in einem anderen Tool „höherwertigen“ Tool die Prozesse konsolidiert und qualitätsgesichert werden.
In diesem Zusammenhang wird BPMN 2.0 wieder ganz interessant ;-). Der Blog Post hier ist ebenfalls interessant: http://www.brsilver.com/wordpress/2009/03/04/model-portability-in-bpmn-20-2/
A Fool with a Tool is still a Fool.
Natürlich ist ein gutes Handwerkszeug wichtig. Aber es gehört auch eine Mindestqualifikation dazu. Diese kostet jedoch viel „Schweiß und Mühe“. Wir wollen den Erfolg aber ohne Anstrengung. Die Abkürzung ist gefragt. Die Qualifikation ist mit Aufwand verbunden. Aufwand wird generell negativ betrachtet, da der zugehörige Nutzen ja erst nachträglich eintritt, wenn überhaupt.
Die Toolfrage ist nicht die priore, sondern zuerst kommt, wie immer, die Zielorientierung. Wenn jeder anderswo hin will, herrscht Ziellosigkeit und damit Stillstand und allenfalls operative Hektik verpackt in optische Betriebsamkeit.
Dem kan ich nur beipflichten. Oft wird lange und ausführlich über das zu verwendende Tool diskutiert, ohne dass man sich vorher überlegt hat, was man genau will. Und wenn der Erfolg ausbleibt, wird das Tool verantwortlich gemacht. Das ist so ähnlich wie wenn man davon ausgehen würde, dass es nur auf die richtige Textverarbeitung ankommt, um ein gutes Buch zu schreiben.