Vision und Wirklichkeit

Das vorgestellte und im Grunde sehr einfache Kernprinzip ist die Grundlage zahlreicher Visionen, die mit BPM in Zusammenhang gebracht werden. Eine davon ist die Hoffnung, man könne zukünftig Prozessmodelle durch das Business erstellen und anpassen lassen. Sobald dies erfolgt ist, werde das Modell auf Knopfdruck in die Realität überführt, also an die Process Engine übergeben, und der Prozess genauso ausgeführt, wie das vom Business gewünscht ist. Diese Hoffnung als Illusion zu entlarven ist mittlerweile die Lieblingsbeschäftigung vieler Berater, deren Kernkompetenzen in anderen Themengebieten liegen. Tatsächlich sind wir heute noch weit davon entfernt, reale Prozessabläufe per "Drag and Drop" gestalten zu können, und es stellt sich mitunter auch die Frage, ob das überhaupt zielführend ist. Man sollte jedoch nicht den Fehler machen, die sehr wohl vorhandenen Möglichkeiten einer gesteigerten Agilität auf Basis von Prozessmodellen, die in der Automatisierung ausgewertet werden, einfach als "Buzzword-Bingo" abzutun.

Welche Rolle spielt BPMN?

In diesem Kontext spielt die Business Process Modeling Notation (BPMN) eine zunehmend wichtige Rolle. Dabei handelt es sich um eine durch die Object Management Group (OMG) standardisierte Prozessnotation, die sich mit rasantem Tempo weltweit verbreitet (siehe auch: Standards erleichtern BPM-Projekte). Diese Popularität beruht vor allem auf der Fähigkeit von BPMN, bestimmte für die Prozessautomatisierung relevante Informationen so zu visualisieren, dass Mitarbeiter aus den Fachabteilungen sie verstehen und teilweise sogar selbst modellieren können.

Ein Beispiel: Die Grafik "Prozessdiagramm" zeigt einen sehr kleinen Ausschnitt eines möglichen Business Process Diagram (BPD), so die offizielle Bezeichnung von BPMN-Modellen. Dargestellt ist hier, dass die Aktivität "Anfrage prüfen" maximal zwei Tage in Anspruch nehmen darf (im Sinne der Durchlaufzeit). Ist diese Zeitspanne überschritten, dauert die Abarbeitung dieser Aufgabe also zu lange, soll eine Eskalation eingeleitet werden ("Vorgesetzten informieren"). Eine Process Engine kann genau diesen Sachverhalt zur Steuerung verwenden: Die Aufgabe "Anfrage prüfen" wird dem Sachbearbeiter zugewiesen. Erhält die Engine nach zwei Tagen noch kein Signal, dass die Anfrage geprüft wurde (zum Beispiel durch einen veränderten Datensatz in einer Tabelle des CRM-Systems oder eine Mail, die der Sachbearbeiter an die Engine geschickt hat), informiert sie automatisch per Mail, SMS oder Ähnliches diejenige Person, welche im Organigramm, das in der BPM-Software hinterlegt ist, als Vorgesetzter des Sachbearbeiters gilt. An dieser Stelle ist anzumerken, dass auch dieses Organigramm wiederum aus führenden Systemen importiert werden könnte, etwa aus SAP-HR oder einem Active Directory.

Dank BPMN und der geeigneten BPM-Software ist dieser Sachverhalt fachlich eindeutig und in standardisierter Form dokumentiert, er entspricht der Realität. Selbst eine Prozessanpassung durch das Business ist möglich, denn die an der Uhr eingetragene Zahl von zwei Tagen lässt sich beliebig verändern, genauso wie die Rolle desjenigen, der im Falle der Zeitüberschreitung benachrichtigt werden soll. Der Prozess könnte zum Beispiel etwas "sanfter" gestaltet werden, indem der säumige Sachbearbeiter zunächst an seine Aufgabe erinnert wird, bevor der Vorgesetzte eingeschaltet werden muss.

Dieses Beispiel soll jedoch nicht den Eindruck erwecken, es sei problemlos möglich, komplexe Prozesse mittels BPMN komplett fachlich zu gestalten und direkt zur Ausführung an die Engine zu übergeben. Insbesondere ein komplettes Mapping von BPMN auf die Business Process Execution Language (BPEL), das gern propagiert wird, ist aufgrund syntaktischer Differenzen zwischen der Notation (BPMN) und der Sprache (BPEL) heute noch nicht möglich. Das sehr große öffentliche Interesse an BPEL steht aufgrund dieser Fehleinschätzung in krassem Widerspruch zur verfügbaren Praxiserfahrung, wie eine aktuelle Auswertung von Profilen zeigt, die in der Online-Community BPM-Netzwerk.de hinterlegt sind: Mehr als 400 Personen, die sich für BPEL interessieren, stehen lediglich 43 Personen gegenüber, die diese Sprache tatsächlich schon praktisch genutzt haben.

Die Kernfrage ist jedoch nicht, wie gut oder schlecht BPMN, BPEL oder andere Standards heute funktionieren. Es geht vielmehr darum, zu erkennen, dass mit der Prozessautomatisierung eine neue Form der Unternehmensorganisation ermöglicht wird, die sich gleichermaßen auf Menschen wie auf Software bezieht. Diese kann eine prozessorientierte Denkweise in den Unternehmen Schritt für Schritt etablieren, ohne quälende Motivations-Workshops und endlose Papierschlachten, deren Ergebnisse häufig so nachhaltig wie Strohfeuer sind.

Nichtsdestotrotz haben auch die Softwarehersteller noch einen langen Weg vor sich, um ein IT-gestütztes Prozess-Management wirklich zu ermöglichen. All diese Baustellen hier aufzuzählen würde zu weit führen, nur einige wenige sollen genannt werden: Da wäre zunächst die konsequente Verzahnung der fachlichen und technischen Prozessmodelle. Das vorgestellte Beispiel der Eskalation bei Zeitverzögerung ist längst nicht in allen Werkzeugen verfügbar, und auch bei der Zuordnung gemessener Kennzahlen zu fachlichen Prozessmodellen haben die meisten Produkte noch große Defizite. Dieses Problem besteht insbesondere bei "Patchwork-Lösungen", also Paketen aus ursprünglich isolierten Tools, die bestimmte Teilbereiche (beispielsweise fachliche Modellierung und technische Ausführung) abdecken und über Schnittstellen miteinander integriert wurden. Aber auch die konsequente Abbildung von Notationsregeln oder Funktionen für das Service-Management fehlen häufig oder sind, je nach Herkunft der Lösung, nur halbherzig umgesetzt.