BPM-Tools hatten es schwer, den hohen Erwartungen, die an sie gestellt wurden, gerecht zu werden. Das Problem ist und war, dass man sich eindringlich mit der Materie beschäftigen sollte, um sie gewinnbringend einsetzen zu können. Um diesen Aufwand zu minimieren, wurden diverse BPM-Varianten entwickelt.

Da gibt es unter anderem die ProcessSuite, ARIS-Lösungen, BPMN-Tools, BPMN 2.0 und Cordys-Pakete, um nur einige zu nennen. Hier sind die Prioritäten hinsichtlich der Ausführbarkeit und der Prozessdokumentation unterschiedlich gesetzt. Daraus ergibt sich folgende zentrale Frage: Welchen Zweck soll BPM-Software eigentlich erfüllen?

Bevor ich mit automatisierten Prozessen in Berührung kam, habe ich im Rahmen eines Hochschulprojektes diverse Prozesse modelliert, welche lediglich dem Zweck der Dokumentation dienten. Nach der Zusammenführung entstand dementsprechend eine Prozesslandkarte. Das Ziel dieser Karte war es, auf lange Sicht alle Prozesse der Hochschule zentral abzubilden. Sicherlich war es eine gute Übung in Bezug auf meine Modellierungsfähigkeiten mit dieser einen Methodik, doch konnte ich keinen größeren Mehrwert erkennen, der den immensen Zeitaufwand für die Erstellung dieser Prozesse aus wirtschaftlicher Sicht rechtfertigen würde, wenn dieses Projekt nicht in einer Hochschule, sondern in einem Unternehmen durchgeführt worden wäre.

Dass die Nachvollziehbarkeit von Arbeitsabläufen in Projekten eine wichtige Rolle spielt, war mir klar, doch wäre es meiner Meinung nach sinnvoller gewesen, statische Prozessmodelle durch ausführbare Prozesse zu ersetzen und somit zwangsläufig auch die Dokumentationsmöglichkeiten von Arbeitsabläufen durch die gewonnene Dynamik zu erweitern. Der indirekte wirtschaftliche Mehrwert der Dokumentation, in Form einer Unternehmenszertifizierung, hätte somit zusätzlich zu einer unmittelbaren Workflow-Optimierung weiterentwickelt werden können. Als ich dann die sicheren Mauern der Hochschule verlassen habe und meine ersten BPM-Erfahrungen in der freien Wildbahn machte, änderte sich mein Denkansatz. Da ich mir sicher bin, dass es in diesem Feld viele Unklarheiten und Grauzonen gibt, möchte ich versuchen durch die Darlegung meines Umdenkens etwas Licht ins Dunkel zu bringen. BPMS ist nicht gleich BPMS. Wie anfangs erwähnt existieren Tools, welche sich auf die Modellierung konzentrieren und andere, die sich die Ausführbarkeit von Prozessen auf die Fahne geschrieben haben. Beide haben in ihrem Segment eine Daseinsberechtigung. Automatisierungstools stellen dem Nutzer meist ein spezialisiertes Set an Modellierungselementen zur Verfügung, welches sich – je nach Umsetzungskonzept des jeweiligen Tools – hervorragend zur Abbildung der auszuführenden Prozesse eignet. Auf der anderen Seite bieten reine Modellierungstools umfangreichste Möglichkeiten, um nach verschiedenen Methoden unterschiedliche Modelltypen erstellen zu können. Dies jedoch ohne Rücksicht auf fehlende Schnittstellen in eine ausführbare Modellebene.

Auf welcher Grundlage sollte man nun Modellierungs-Tools mit Werkzeugen zur Workflow-Automatisierung vergleichen? Auf den ersten Blick erscheinen diese Aussagen trivial. Bei der BPMS-Evaluierung wird dieser offensichtliche Sachverhalt aber zu oft vernachlässigt. Hier sollte die Terminologie und die Selbstdarstellung von BPMS-Anbietern wahrscheinlich auch klarer strukturiert sein, als dies momentan der Fall ist. Am Anfang stellte ich die Frage: „Welchen Zweck soll BPM-Software eigentlich erfüllen?“. Die Antwort lautet, wie so oft: „Es kommt darauf an.“

Wie denken Sie über dieses Thema? Sehen Sie die Übergänge eher fließend oder sollte eine deutlichere Trennung der genannten BPM-Segmente erfolgen? Würden Sie in Ihrer Unterteilung eventuell weiter gehen? Teilen Sie Ihre Meinung in den Kommentaren.

Aljoscha 17:14

Kommentar hinzufügen