BPM gehört seit einigen Jahren zu den zentralen Themen von Organisation und IT. Von der systematischen und konsistenten Erfassung, Darstellung, Modellierung und Strukturierung der betrieblichen Abläufe erwarten sich Unternehmen mehr Effizienz und Transparenz. Schließlich sollen aber auch durch die konkrete Umsetzung mittels Software die Prozesse unmittelbar automatisiert und damit optimiert werden, das erfolgt beispielsweise indem Prozessmodelle an eine Prozess- oder Workflow-Engine übergeben werden, die die Ausführung selbständig steuert.
Vor dem Hintergrund des aktuellen Trends zu Digitalisierung gewinnen diese Anforderungen besonders an Bedeutung. Möglicherweise entscheidet sich am effizienten Einsatz von BPM die Fähigkeit von Unternehmen, die Digitalisierung zu realisieren.
Foto: Ismagilov - shutterstock.com
Das Grundkonzept des BPM ist aus dem Gedanken des Business Process Reengineerings entstanden. Daraus leiten sich unter anderem folgende Ziele ab:
Kontinuierliche Verbesserung von Prozessen
Schnellere Reaktion auf Prozessänderungen und Varianten
Optimierung der Prozesskosten
Höhere Transparenz der Prozesse
Verbesserte Kommunikation mit Kunden und damit verbunden mehr Kundenzufriedenheit
Die IT soll und kann bei der Realisierung dieser Ziele helfen, und sie hat dafür auch mächtige Werkzeuge entwickelt. Mittlerweile ist ein breiter Markt für BPM-Lösungen entstanden, wobei sich allerdings keine als unbestritten führend erweisen konnte. Neben dem üblichen Für und Wider einzelner Systeme in diversen Marktübersichten und Studien ist aber auch eine ganz grundsätzliche Kritik am Konzept des BPM nie verstummt. So ist beispielsweise immer wieder zu hören, BPM sei zu kompliziert, fände zu wenig Akzeptanz unter den Mitarbeitern, verursache zu hohe Kosten und sei überhaupt nicht flexibel genug.
- Anforderungen an BPM-Werkzeuge
Ein BPM-Projekt sollte mit einer klaren Fokussierung auf den zu er-zielenden Nutzen, geplant werden; die für die Umsetzung notwendi-gen Werkzeuge sollten im Anschluss ausgewählt werden. Für die Auswahl eines geeigneten Werkzeuges ergeben sich dann wiederum folgende Anforderungen:
Definition einer Schichtenarchitektur zur Abbildung von Varianten.
Dynamisches Case-Management zur Abbildung von Vorgängen, Abhängigkeiten oder Ad-Hoc-Prozessmanagement.
Modellgetriebene Entwicklung aller Artefakte – Case, Prozess, UI, oder Regeln – für ein besseres Verständnis der zukünftigen Anwendung durch den Businessanwender.
Unterstützung und Integration aller Kanäle wie Mobile, Web, Social, POS oder CRM.
Collaboration Support für eine enge Zusammenarbeit von Business und IT.
Bleibt diese Kritik noch recht vage und vielleicht auch zu wenig spezifisch - man könnte sie kaum verändert auch gegen viele andere Software-Produkte vorbringen - lassen sich durchaus auch Einwände formulieren, die den speziellen Ansatz von BPM-Anwendungen aufgreifen.
Typische Versäumnisse sind hier:
Der Fokus wird auf (isolierte) Prozesse gelegt, ohne dass die zu erledigende Arbeiten beziehungsweise Vorgänge (Case) und damit deren Kontext berücksichtigt werden.
Die Modellierung und die damit verbundenen Standards sind vielfach zum Selbstzweck geworden. Beispielsweise orientiert sich der BPMN-2.0-Standard zu stark an der Implementierung des Prozesses. Dies hat zur Konsequenz, dass die Anzahl der Modellierungssymbole massiv angestiegen ist - bei mehr als 100 unterschiedlicher Symbole und Items ist die Transparenz und Kommunikationsfähigkeit eines Ansatzes schon in Frage gestellt. Dadurch werden Prozessdesigner dazu verleitet, mehr über die jeweils eleganteste Modellierungsvariante beziehungsweise über die richtige Verwendung der Symbole zu diskutieren, anstatt die Optimierung des Prozesses zu hinterfragen.
Die Umsetzung der neuen Prozesse erfolgt nach dem Verfahren klassischer Softwareprojekte, wobei nur am Anfang die Anforderungen definiert und spezifiziert werden. Eine kontinuierliche Prozessverbesserung findet dabei nicht statt.
Die Prozess-Optimierung wird zu theoretisch behandelt. Tatsächlich ergeben sich viele Verbesserungsmöglichkeiten aus Vorschlägen von Anwendern, die den Prozess täglich "leben".
Eine End-to-End-Prozessbetrachtung wird oft vernachlässigt. So werden neue, innovative Prozesse häufig isoliert in einem Kanal umgesetzt, während die Kunden schon lange nicht mehr exklusiv nur über einen Kanal kommunizieren.
Mögliche Prozess-Varianten werden zu wenig berücksichtigt, beispielsweise nach Produkten, Regionen, Vertriebskanälen oder Kundenwerten. Dies macht die Lösungen unflexibel und führt zu hohen Kosten bei späteren Anpassungen.
Insgesamt müssen sich Softwareanbieter - implizit aber auch Anwender, die diese Lösungen meist nach aufwändigen Evaluierungen kaufen und einsetzen - die Kritik gefallen lassen, dass sie sich allzu oft zu sehr auf "Features" fokussieren und dabei das Wesentliche aus den Augen verlieren. Das Werkzeug rückt in den Mittelpunkt und verdrängt das damit angestrebte Ergebnis, den optimierten Prozess, in die Peripherie.
Aus den aufgeführten kritischen Feststellungen lassen sich natürlich auch konkrete Empfehlungen für BPM-Anwendungen ableiten:
Konzentration auf wertschöpfende Vorgänge. Immer wieder wird versucht, auch periphere Prozesse aufwändig zu modellieren und zu strukturieren. Und das meist nur, um vorhandene BPM-Werkzeuge umfassend anzuwenden.
Berücksichtigung des Kontextes von Prozessen, beispielsweise von Wetterdaten, Lokation oder Kundenwert, wenn diese Aspekte für die Prozessausführung relevant sind.
Einbinden der Fachseite und Anwender über den kompletten Zeitraum der Umsetzung, also nicht nur in der Anfangsphase oder punktuell.
Von Beginn an Berücksichtigung möglicher Varianten der Prozesse.
Erweiterung von relevanten Prozessen auf alle, für Kunden und Anwender relevanten Kanäle.
Prozesse ausgehend von der zu erledigenden Arbeit, den einzelnen Vorgängen, modellieren.
Neue Konzepte
Der letzte Punkt verweist aber auch auf ein grundlegendes Problem des BPM-Konzepts: BPM orientiert sich an den Paradigmen der Fertigungsindustrie die berühmten "Swim lanes", in denen eine Abfolge vordefinierter Arbeitsschritte definiert wird, sind ja nichts anderes als abstrakte Produktionslinien.
Foto: Jakrapong phaophom_shutterstock.com
Das mag zwar für zahlreiche Projekte die passende Herangehensweise sein, jedoch lassen sich auf diese Weise nicht alle Geschäftsvorfälle adäquat abbilden. Für viele Aufgaben ist das Konzept einfach zu starr. In Hinblick auf die Anforderungen der realen Welt zeigen viele Ansätze für die BPM-Modellierung, aber auch die entsprechenden Standards, daher immer wieder Schwächen, weil sie sich zu sehr auf den Prozessfluss konzentrieren, anstatt auf die zu erledigenden Aufgaben und wie die optimale Arbeitsstruktur. Da hier ein konzeptionelles Problem vorliegt, handelt es sich dabei nicht um Schwächen, die sich etwa mit besseren Werkzeugen, durch mehr Standardisierung oder auch durch eine noch elaboriertere Symbolik aus der Welt schaffen ließen.
An diesem Punkt setzt Case-Management an, das die Sichtweise des BPM verändert. Es konzentriert sich auf die zu erledigende Gesamtaufgabe, also auf den eigentlichen Geschäftsvorfall. Zunächst erfolgt die Beschreibung des Vorganges (Case) und der Phasen, die er bis zur abschließenden Bearbeitung durchläuft (Case Lifecycle). Innerhalb der Phasen werden die Arbeitsschritte oder Prozesse zusammengefasst, die notwendig sind, um einen Case in die nächste Phase seines Lifecycle zu bringen. Der Case bildet die logische Einheit, dem die Prozesse untergeordnet sind. In Abgrenzung dazu beschreiben Prozesse die notwendigen Arbeitsschritte, mit denen der Case in den einzelnen Phasen des Case Lifecycle so bearbeitet wird, dass der Fall am Ende auch abgeschlossen ist.
Das Konzept des Case-Management stammt ursprünglich aus dem Dokumentenmanagement. Als Weiterentwicklung dieses, zu sehr auf Dokumente ausgerichteten, Ansatzes deckt Dynamic-Case-Management auch Veränderungen ab, die sich während der Bearbeitungszeit ergeben. Es schließt also Rückkopplungseffekte mit ein. Es gibt Szenarien, die sich mit diesem Konzept besser strukturieren lassen als mit klassischem BPM.
Daraus lässt sich als Empfehlung ableiten, dass zunächst immer geprüft werden muss, ob BPM überhaupt der geeignet Ansatz ist, um die angestrebten Ziel zu erreichen. Diesen Punkt verfehlt man zwangsläufig, wenn man sich vorschnell den Werkzeugen zuwendet. (bw)