BPM: Annäherung statt normativer Prozesse

12.01.2012
"Knowledge Workers" über streng vorgezeichnete Prozessmodelle steuern zu wollen ist falsch. Mehr Erfolg verspricht "adaptives" Business-Prozess-Management.

Automatisierte Prozesse führen zu mehr Effizienz. Diese Denkweise zieht sich durch die Geschichte. Henry Ford hat sie geprägt und dabei den "Production Worker" in der industriellen Fertigung im Auge gehabt. Doch heute heulen Angestellte vor ihren Bildschirmen auf, wenn sie durch zu starre Prozesskorsette in immer gleiche Aufgabenlisten und Maskenflüsse gezwängt werden. Innovatives, der Situation angemessenes Handeln wird so erschwert, wenn nicht gar verhindert.

Der Mensch im Vordergrund

Die Wahrheit ist also: Das simple Automatisieren von Routinetätigkeiten, wie sie in heutiger Standard-ERP-Software abgebildet ist, führt nicht automatisch zu mehr Effizienz. Vielmehr geht es darum, den Wissensarbeitern einen optimalen Arbeitsplatz zur Verfügung zu stellen, damit sie bestmögliche Entscheidungen für das Unternehmen treffen können. Theoretisch sind dabei Business-Process-Management-(BPM-)Initiativen hilfreich, die den Menschen wieder in den Vordergrund rücken: als Person, die nicht vollständig über Prozessmodelle gesteuert wird, sondern aktiv und unmittelbar zur Verbesserung beiträgt.

Nehmen wir zum Beispiel den Prozess zum Anheuern externer Mitarbeiter. Er ließe sich bestens in einem sequenziellen Ablaufmodell bestimmen, denn im Detail besteht dieser Vorgang aus einer Vielzahl von Beurteilungen und Genehmigungen auf verschiedenen Management-Ebenen. Die genauen Abläufe lassen sich in den Modellierungssprachen BPMN 2.0 (Business Process Model and Notation) oder in ereignisgesteuerten Prozessketten (EPK) gut ausdrücken. Solche Modelle werden von der Fachseite verstanden und lassen sich leicht ändern. Gleichzeitig sind sie die Grundlage für einen informationstechnisch exakt ausführbaren Prozess.

Trotzdem ist ein Business-IT-Alignment durch BPM offenbar nicht so leicht machbar. Automatisierte Prozesse sind wohl eher auf der Mikroebene, also in den Abteilungen, realistisch, weniger jedoch auf der Enterprise-Ebene. Das Business-Prozess-Management setzt sich nicht so kraftvoll durch wie von vielen Spezialisten erwartet.

Die tayloristische Sicht

Henry Ford und Frederick Taylor, die Urväter der Arbeitsteilung, verfolgten das Ziel, Arbeit auf einfache Tätigkeiten herunterzubrechen, um die Komplexität einer Gesamtaufgabe bewältigen zu können. Der Bau eines Autos zerfiel in viele kleine Einheiten, die nur noch wenige Handgriffe erforderten. Jeder Production Worker hatte exakt definierte Arbeitsschritte umzusetzen. Raum für eigenverantwortliches Handeln blieb nicht - und war auch nicht nötig.

Aus der Taylorschen Sicht heraus propagieren einige Autoren im Umfeld der Management-Disziplin BPM seit den 1980er Jahren das Optimieren von Geschäftsprozessen durch Flow Charting. In solchen "normativen" BPM-Projekten werden die Fachbereiche im Idealfall in die Lage versetzt, Geschäftsprozesse zu analysieren, zu dokumentieren und nach Bedarf unkompliziert zu ändern. Das funktioniert aber nur für normative Prozesse, also solche, deren Ablauf sich im Vorfeld der Ausführung genau beschreiben lässt.

In wissensintensiven Kontexten ist diese Art von Prozessen zu starr und damit außerstande, die komplexe Wirklichkeit abzubilden. Alle denkbaren Varianten von Prozessläufen inklusive aller Fehler- und Ereigniszustände im Vorfeld zu modellieren kommt das Unternehmen einfach zu teuer. Zudem ist die Hoffnung auf ein vollständiges Ergebnis wirklichkeitsfremd.

Routinearbeit versus Wissensarbeit

Ein normativer Prozess lässt sich auch nur dann erfolgreich implementieren, wenn die beteiligten Personen sehr eng geführt werden. Gemäß dem Modell müssten die Führungskräfte sie quasi an die Hand nehmen und durch einen vorgegebenen Prozess navigieren. Wie beim Fließbandarbeiter geht dabei der individuelle Entscheidungsspielraum gegen null.

Aber Aufgaben wie etwa Kundenbeschwerde-Management, Bearbeitung von Schadensfällen, Unterstützung von Arbeitsuchenden, Beurteilung rechtlicher Sachverhalte oder Forschung und Entwicklung verlangen dynamische Reaktionen, denn hier geht es um komplexe Sachverhalte und sich ständig verändernde Rahmenbedingungen. Wie die Management-Größen Peter Drucker und Thomas Davenport beschreiben, iniitiert das den Aufstieg des "Knowledge Worker", der im Vergleich zum Production Worker schlechter zu steuern sei.

Prozess eingehalten - alles gut?

Welche Auswirkungen haben die unterschiedlichen Arbeitsweisen von Production und Knowledge Workers auf die BPM-Initia-tiven? Normative Prozesse, in denen der Ablauf vorab definiert ist, ergeben dann einen Sinn, wenn das Ziel tatsächlich ein einheitlicher Arbeitsablauf ist. Beispielsweise ist es oft so, dass Angebotsprozesse, Urlaubsanträge, rechtlich bedingte Freigabeprozesse, geführte Arbeit in IT-Systemen oder Integrationsprozesse immer gleich ablaufen und von einheitlicher Qualität sein sollen. Hier bietet sich die klassische Prozessautomatisierung an.

In vielen anderen Fällen ist jedoch nicht immer klar, wie viele Schritte nötig sind und welche Wege man genau gehen muss, um ans Ziel zu gelangen. Dies gilt für die wissensintensiveren Prozesse, aber auch für solche Kernprozesse, für die Spezialisten eingestellt werden. Beispiele für Letztere sind Beratungs- oder Verkaufsgespräche, Unfallaufnahmen, Gutachten oder Untersuchungen. Um einen Geschäftsvorfall in diesem Kontext optimal abschließen zu können, stehen das Wissen und die individuelle Auswahl der Teilaufgaben durch den Benutzer im Vordergrund.

Der Versuch, diese Art von Wissensarbeit dennoch mit normativen Prozessen zu unterstützen, führt zu Prozessbürokratie nach dem Motto: Alles ist gut, solange der Prozess eingehalten ist, selbst wenn das Unternehmen dabei Schaden nimmt. Zudem werden die Prozessinstanzen nach und nach unproduktiver, da kein Nachsteuern über Erfahrung möglich ist. Statt Taylorismus wäre hier ein zielunterstützendes, adaptives BPM sinnvoll.

Adaptive Case-Management

Es müssten also auch "adaptive Prozesse" her. In BPM-Kreisen ist in diesem Zusammenhang vom "Adaptive Case-Management" (ACM) die Rede. Im Mittelpunkt stehen dabei nicht die Prozesse an sich, sondern der Fall ("Case"), für den ein Ziel erreicht werden soll. Das lässt sich, je nach Situation, mit einer Vielzahl möglicher Prozesse oder Prozessschritte umsetzen.

Ein Fall kann vieles sein: ein Versicherungsfall, ein Patient, ein Projekt, ein Wirtschaftsgut (etwa ein Gebäude), eine Kundenanfrage oder auch gleich der ganze Kunde. Die "adaptive" Sichtweise erfasst dabei jegliche Art von Tätigkeit, der ein flexibler Wissensarbeiter im Zusammenhang mit dem Fall nachgehen kann.

BPM ist als übergreifende Management-Disziplin zu verstehen. "Normatives BPM" (nBPM) und "adaptives BPM" (aBPM) stellen zwei gleichwertige Teildisziplinen dar. Sie können, je nach Umfeld, beide nützliche Werkzeuge in der Toolbox der Business- und IT-Architekten sein.

In der heutigen IT-Welt sind die normativen Prozesse im Sinne einer Prozessautomatisierung mit BPEL (Business Process Execution Language) oder BPMN gut verstanden. Es obliegt jedem im BPM-Umfeld tätigen Architekten, sich auch mit den Konzepten der adaptiven Prozesse auseinanderzusetzen, um optimale Lösungen für die Anforderungen in wissensintensiven Kontexten gestalten zu können.

Die Grundideen beider Disziplinen

Das Wichtigste in Kürze: Die Grundidee des normativen BPM besteht darin, dass ein Prozess eine vorab definierte sequenzielle Folge von Aktivitäten bildet. Alle Übergänge ("Transitionen") zwischen den Aktivitäten sind ebenfalls apriori festgelegt.

In einem normativen Prozess bestimmen automatisch ausführbare Geschäftsregeln die Abläufe. Menschliche Interaktion wird umgesetzt, indem die Prozessbeteiligten durch Einträge in Arbeitslisten Aufgaben erhalten. Alle denkbaren Varianten des Prozesses sind durch Weichen ("BPMN-Gateways") vorgegeben. Es ist unmöglich, einen anderen Weg zu gehen, als er im Gesamtprozessmodell vorgegeben ist.

Modellierung adaptiver Prozesse

In adaptiven Prozessen haben die Teilnehmer mehr Freiheiten - wenngleich in einem mehr oder weniger eng gesteckten Rahmen. Auch hier werden Aktivitäten vorgegeben, jedoch mit der Option, adaptiv weitere Arbeitsschritte einbauen zu können. Auch die Transitionen zwischen den Aktivitäten werden nicht fest ausmodelliert. Sie geschehen zur Laufzeit durch die Entscheidung, die der am Prozess teilnehmende Mensch trifft. Gegebenenfalls wird er dabei durch Regeln unterstützt. Sie schlagen dem Benutzer eine Liste der im gegenwärtigen Kontext denkbaren Aktivitäten und Werkzeuge vor.

Adaptive Prozesse befinden sich in einem permanenten Zustand des Lernens und Weiterentwickelns. Das unterscheidet sie von Ad-hoc- oder dynamischen Prozessen. Letztere lassen dem Benutzer große Freiheiten - durch die willkürliche Ausführung ohne eine vorgegebene Reihenfolge. Ihr Nachteil: Sie bieten keine eingebauten Möglichkeiten für eine Optimierung über Prozesserfahrung. Adaptive Prozesse hingegen räumen dem Wissensarbeiter die Möglichkeit ein, situationsgetrieben weitere Prozessschritte zu definieren. Dies hilft ihm, die Wissensbasis zu erweitern und damit nachhaltig Mehrwert zu generieren. So wird eine permanente Annäherung (Adaption) an die Realität erreicht.

Trotz aller Freiheiten wird der Weg, den die Prozessbeteiligten gegangen sind, protokolliert - als Basis für die permanente Ablaufoptimierung durch Fachseite und IT. Festzuhalten und regelmäßig auszuwerten sind insbesondere Verbesserungsvorschläge der Beteiligten. Diese Vorgehensweise wird als "Model afterwards" oder "Design by Doing" bezeichnet. Der eigentliche Prozesslauf ergibt sich nachträglich aus der Vielzahl konkret abgelaufener Instanzen.

Eine Möglichkeit für das Modellieren adaptiver Prozesse ist der Einsatz von Ontologien. Sie beschreiben die Beziehungen, die Aktivitäten zueinander haben - semantisch im Rahmen einer Aktivitätenontologie. Beziehungstypen dienen dazu, auszudrücken, ob vor einer Aktivität eine andere durchlaufen sein muss oder kann.

Trotzdem werden diese Aktivitäten nicht automatisch zu vorher definierten Zeitpunkten und Orten im Prozessbild abgearbeitet. Vielmehr stehen alle Aktivitäten dem Benutzer als Angebote zur Verfügung. Er entscheidet, ob und wann er davon Gebrauch macht. So lassen sich die regulatorischen Richtlinien einer Unternehmung abbilden und gleichzeitig dem Benutzer ein hohes Maß an Freiheit gewähren.

Benutzerführung und Oberflächen

Typische Benutzeroberflächen im BPM-Umfeld bestehen aus Arbeitslisten, in denen die Benutzer ihre von Prozessen zugeordneten Aufgaben finden. Hier sind oft auch kleine Masken zur Dateneingabe in den einzelnen Aufgaben hinterlegt, die dann in einem generischen User-Interface-Bereich angezeigt werden.

Demgegenüber stellen Benutzeroberflächen für adaptive Prozesse dem Wissensarbeiter eine flexiblere IT-Unterstützung zur Seite. Hier kommen zwar auch Arbeitslisten vor, im Fokus steht aber nicht die Abarbeitung eines Mikroschritts in einem großen Prozessablauf, sondern die komplette Tätigkeit. Deshalb haben wir es hier mit einer portalartigen Oberfläche zu tun, die eine aggregierte Gesamtsicht auf den Fall darstellt. Beispielweise sind dort alle zugeordneten Stammdaten, Historien und bisherigen Geschäftsvorfälle zu finden.

Noch keine Standardsoftware

Geht es um ein Patientensystem, so betrifft das die gesamte Krankenhistorie, alle hinterlegten Untersuchungen, Röntgenbilder etc. Der Zugriff auf unstrukturierte Daten, etwa auf ein Dokumenten-Management-System, ist also ein wichtiges Feature der Oberfläche. Aber auch soziale und kollaborative Eigenschaften und allgemein alle Aktivitäten, die im Kontext sinnvoll sein können, sollten jederzeit zur Verfügung stehen. Oft wird eine Unterteilung in laufende, abgeschlossene und in Zukunft mögliche Aktivitäten dargestellt - erweitert um die Möglichkeit, neue Aktivitäten an den Fall anzuhängen, die nicht vorgedacht waren.

Unsere heutigen Wissensarbeiter benötigen optimale Unterstützung durch Softwaresysteme. Sie brauchen Flexibilität und Entscheidungsfreiheit, um ihr Wissen im Sinne des Unternehmens bestmöglich und ohne unnötige Schranken einsetzen zu können. Die IT hat die Aufgabe, ihnen das zu ermöglichen. Allerdings gibt es noch kaum Standardsoftware, die das komplett leistet.

Gleichwertig nebeneinander

Eine Unterstützung der adaptiven Prozesse als Teildisziplin von BPM - neben den normativen Prozessen - sollte in der Toolbox von Business- und IT-Architekten ihren festen Platz haben. Effizienz lässt sich heute nicht mehr durch das simple Automatisieren von Routinetätigkeiten erreichen. Die Innovation liegt im bestmöglichen Ausschöpfen der menschlichen Potenziale. (hv)

Masons of SOA ist eine unternehmensübergreifende Arbeitsgruppe (siehe Kasten "Die Autoren")

Die Autoren

2007 gründeten die sieben Verfasser des vorliegenden Beitrags die "Masons of SOA", eine Arbeitsgruppe mit der Vision, SOA über internationale Unternehmensgrenzen hinweg zu propagieren. Zudem wollten sie sich hinsichtlich kritischer Projekte gemeinsam unterstützen.

Im Einzelnen handelt es sich um die folgenden Fachleute:

  • Berthold Maier (T-Systems International),

  • Hajo Normann (Accenture),

  • Gregor Scheithauer (Opitz Consulting),

  • Danilo Schmiedel (Opitz Consulting),

  • Jürgen Kress (Oracle),

  • Clemens Utschig-Utschig (Boehringer Ingelheim Pharma GmbH & Co. KG),

  • Torsten Winterberg (Opitz Consulting).

Ein Beispiel für die Arbeit der Autoren stellt die Publikation einiger Entwurfsmuster in dem Buch "SOA Design Patterns" von Thomas Erl dar. Derzeit arbeiten sie an einem Buchprojekt mit dem Titel "Next Generation SOA - A Real-World Guide to Modern Service-Oriented Computing".

Darüber hinaus beschäftigt sich die Arbeitsgruppe auch intensiv mit Themen rund um BPM und adaptive Prozesse.