Foto: Inga F - Fotolia.com
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.
Tatsache ist: 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 sind leicht änderbar. Gleichzeitig bilden 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.
Routinearbeit versus Wissensarbeit
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 leicht 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 teuer. Zudem ist die Hoffnung auf ein vollständiges Ergebnis wirklichkeitsfremd.
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 der individuelle Entscheidungsspielraum gegen null.
Aber Aufgaben wie etwa Kundenbeschwerde-Management, Bearbeitung von Schadensfällen, Unterstützung von Arbeitssuchenden, Beurteilung rechtlicher Sachverhalte oder Forschung und Entwicklung verlangen dynamische Reaktionen, denn hier geht es um komplexe Sachverhalte und sich ständig verändernde Rahmenbedingungen. Management-Größen wie Peter Drucker und Thomas Davenport beschreiben den Aufstieg des "Knowledge Worker", der im Vergleich zum Production Worker viel schlechter zu steuern sei.
Die Evolution von BPM
Foto: Opitz
Welche Auswirkungen haben die unterschiedlichen Arbeitsweisen von Production und Knowledge Workers auf die BPM-Initiativen? 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 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 Prozesse als Teildisziplin
Es müssten also "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 Wissensarbeiters im Zusammenhang mit dem Fall nachgehen kann.
BPM ist als eine ü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.
Modellierung von adaptiven Prozessen
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 a priori festgelegt. Automatisch ausführbare Geschäftsregeln bestimmen 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.
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, deklariert als Vorbedingungen, unterstützt. Diese Regeln 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 haben keine eingebauten Möglichkeiten für eine Optimierung über Prozesserfahrung zu bieten. 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.
Design by doing
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. 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. Eine Ontologie beschreibt die Beziehungen, die Aktivitäten zueinander haben. Sie tut das semantisch im Rahmen einer Aktivitätenontologie. Derartige Beziehungstypen drücken aus, ob jeweils eine Aktivität zuvor durchlaufen sein muss oder kann. Durch die Ontologie kann festgelegt sein, dass nach einer bestimmten Aktivität immer eine Folgeaktivität ausgeführt werden muss.
Trotzdem werden diese Aktivitäten nicht aufgrund eines Prozessmodells 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 wird es möglich, die regulatorischen Richtlinien einer Unternehmung abzubilden und gleichzeitig dem Benutzer ein größtmögliches Maß an Freiheit zu 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.
Hingegen 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 kleinen Mikroschrittes in einem großen Prozessablauf, sondern die komplette Tätigkeit.
Deshalb haben wir es hier eher 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.
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, adaptiv neue Aktivitäten an den Fall anzuhängen, die bisher 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. (hv)