thumb

Business Process Management (BPM) gehört heute zum Standard-Repertoire grösserer Unternehmen. Sie versprechen sich von der Modellierung und Strukturierung mehr Effizienz und Transparenz ihrer betrieblichen Abläufe. In den letzten Jahren ist daher ein recht umfangreicher Markt für BPM-Anwendungen entstanden. Trotzdem – so richtig zufrieden sind die Unternehmen mit BPM nicht geworden.

Gastkommentar von Carsten Rust, Senior Manager Solution Consulting bei Pegasystems

Eine Ursache für die Unzufriedenheit ist, dass BPM oft viel zu "technokratisch" angegangen wird. Vielfach erfolgt die Implementierung von Prozessen nach dem Verfahren klassischer Softwareprojekte, wobei nur am Anfang die Anforderungen definiert und spezifiziert werden, eine kontinuierliche Prozessverbesserung findet nicht statt. Dabei finden auch mögliche Prozess-Varianten, etwa Regionen oder Vertriebskanäle, zu wenig Berücksichtigung. Dadurch werden die Lösungen unflexibel und teuer, wenn sie später doch angepasst werden müssen. Häufig werden in der Prozess-Optimierung Verbesserungsmöglichkeiten aus Vorschlägen von Anwendern, die den Prozess täglich "leben", nicht berücksichtigt, weil man sich lieber an ein vorgegebenes Konzept halten will. 


Auch die Technik der Modellierung selbst erweist sich in der Praxis oft als wenig hilfreich, denn in vielen Fällen werden die verwendeten Standards zum Selbstzweck. So orientiert sich zum Beispiel der BPMN-2.0-Standard sehr stark an der Implementierung des Prozesses, sodass die Anzahl der Modellierungssymbole massiv angewachsen ist. Bei mehr als 100 unterschiedlichen Symbolen und Items kann man durchaus die Frage stellen, ob die angestrebte Transparenz und Kommunikationsfähigkeit noch gegeben ist. Prozessdesigner und –Modellierer diskutieren hier gern die jeweils eleganteste Modellierungsvarianten oder die richtige Verwendung der Symbole, anstatt die Optimierung des Prozesses zu hinterfragen.

Schliesslich muss aber auch ein grundlegendes Problem des BPM-Konzepts abgesprochen werden. BPM stammt aus der Welt der Fertigungsindustrie und orientiert sich bis heute an den dort etablierten Paradigmen. Die berühmten "swim lanes", die BPM-Modelle charakterisieren, diese festen Bahnen, in denen eine Abfolge fester Arbeitsschritte definiert wird, demonstrieren das sehr deutlich, denn sie sind ja nichts anderes als abstrakte Produktionslinien. Diese Sicht auf betriebliche Vorgänge mag zwar für viele Vorgänge in Unternehmen passen, es zeigt sich jedoch immer mehr, dass sich keineswegs alle Geschäftsvorfälle auf diese Weise adäquat abbilden lassen. Für viele ist das Konzept einfach zu starr – anders formuliert: das Konzept des industriellen Fertigungsprozesses kann heute nicht mehr als das allgemeinverbindliche Idealbild für betriebliche Prozesse gelten.
Gerade Abläufe in Banken oder Versicherungen, etwa bei der Kontoeröffnung oder bei Schadensmeldungen, lassen sich nicht in starren Lanes abbilden. Diese Prozesse brauchen mehr Flexibilität, sie müssen den Bearbeitern beispielsweise vorstrukturierte Entscheidungsmöglichkeiten eröffnen und sie müssen auch kontextsensitiv sein. Ein solcher Ansatz passt aber nicht zum klassischen BPM- oder auch Workflow-Konzept, das sich auf den Prozessfluss konzentriert, jedoch nicht so sehr auf die zu erledigenden Aufgaben und optimale Strukturierung der Arbeit.

Wie gesagt, es gibt viele Prozesse für die der BPM-Ansatz passt, beispielsweise in der Logistik und der Fertigung sowieso. Für andere Aufgaben eignet sich der Ansatz jedoch nicht und da das eine Frage des Konzepts ist, lässt es sich auch nicht mit besseren BPM-Werkzeugen, durch mehr Standardisierung oder sogar durch noch kompliziertere Symbolik lösen. Hier muss man eben ein anderes Konzept wählen.

Case-Management (CM) hat daher eine ergänzende Sichtweise zum herkömmlichen BPM. CM stellt die zu erledigende Gesamtaufgabe in den Mittelpunkt. Es beschreibt einen Vorgang (Case) und den Case Lifecycle, also die Phasen, die er bis zur abschliessenden Bearbeitung durchläuft. Der Case ist die logische Einheit, der die Prozesse untergeordnet sind. Prozesse beschreiben die 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-Managements stammt ursprünglich aus dem Dokumentenmanagement, also aus einer ganz anderen Welt als die swim lanes. Als Weiterentwicklung des ursprünglichen Ansatzes, der noch sehr auf Dokumente ausgerichtet ist, deckt Dynamic-Case-Management auch Veränderungen ab, die sich während der Bearbeitungszeit ergeben, berücksichtigt also auch Rückkopplungseffekte. Mit diesem Konzept lassen sich viele Szenarien erheblich besser strukturieren als mit klassischem BPM, vor allem überall dort, wo Unternehmen direkt mit Kunden kommunizieren, also etwa in der Telekommunikation, wenn Provider Störungsmeldungen entgegennehmen, aber auch in Call-Centern der Automobilindustrie oder in anderen Service-orientierten Unternehmen.

Ob BPM oder CM der passende Ansatz ist, muss jedes Unternehmen natürlich entsprechend seines jeweiligen Geschäftsmodell und seiner Geschäftsprozesse herausfinden. Sicher ist aber, das BPM alleine nicht für jeden Fall die richtigen Antworten hat.


Empfehlungen für BPM-Anwendungen

- Anwender sollten sich in BPM-Projekten auf wertschöpfende Vorgänge beschränken; oft verzetteln sich Unternehmen beim Modellieren peripherer Prozesse.
- Beim Modellieren von Prozessen sollten auch Kontext-Informationen berücksichtigt werden; beispielsweise von Wetterdaten, Lokation oder Kundenwert, wenn diese Aspekte für die Prozessausführung relevant sind.
- Fachabteilungen und Anwender sollten nicht nur in der Anfangsphase, sondern über den ganzen Zeitraum der Umsetzung eingebunden werden.
- Von Beginn sollten Varianten von Prozessen berücksichtigt werden.
- Relevante Prozessen sollten auf alle Kanäle erweitert werden.
- Alle Prozesse sollten ausgehend von der zu erledigenden Arbeit, den einzelnen Vorgängen modelliert werden.

20142-20142pegasuscarstenrust20130730low.jpg
Gastkommentator Carsten Rust, Senior Manager Solution Consulting bei Pegasystems