ACM, ECM, STP, MfG, ojemine … Es kommt auf den Prozesstyp an

Agiles Prozessmanagement, Adaptives Case Management (ACM), Dynamic Case Management (DCM), Enterprise Content Management (ECM)  für Ad-hoc-Prozesse oder doch Business Process Management (BPM) für Straight Through Processing (STP)? Keine Angst, ich will mich neuerdings nicht am Buzzword-Bingo beteiligen und nur noch mit Anglizismen um mich schmeißen. Aber was soll man machen, wenn solche Begriffe in der eigenen Fachwelt auftauchen und Gartner und Forrester Research diesen Konzepten die große Zukunft vorhersagen? Da kann ich ja nicht wegschauen.

Im Kern geht es hier um das Thema, das ein Prozess nicht immer so schön vorstrukturiert und statisch abläuft, wie es die klassische Prozessdefinition suggeriert. Aber was heißt schon klassische Prozessdefinition? Je nach Betrachtungsweise kann ein Prozess höchst unterschiedlich definiert werden.

Unser Denken wurde in den letzten Jahren stark geprägt durch die Modellierung von Prozessen als kontrollflussorientierte  Prozessdiagramme. Und hat man bei Notationen wie EPK, Folgeplan oder UML noch gewisse Freiheiten bei der Dokumentation der zeitlich-logischen Folge von Aufgaben, so ist spätestens mit BPMN 2.0 Schluss damit. Hier erfordert die unmittelbare  technische Umsetzung  des Prozessdiagramms eine exakt strukturierte und determinierte  Prozessmodellierung.

Mit dieser Prozessdenke im Gepäck, kommt man schon mal ins Grübeln, ob man nicht selber der „Schuster mit dem Leisten“, Sie wissen schon … Hier mal ein Beispiel eines aktuellen Prozesses aus der eigenen Firma:

Zurzeit suche ich für ibo einen neuen Produktmanager Projektmanagement.  Zunächst habe ich in den eigenen Reihen geschaut. Dann passte gerade zufällig eine Initiativbewerbung, die aber nach dem persönlichen Gespräch nicht zum Tragen kam. Parallel habe ich im Netzwerk meine Fühler ausgestreckt.  Dieser Blogbeitrag ist mal ein neuer Ansatz, auf unkonventionelle Art indirekt Bewerber anzusprechen. Ja, und wenn ich  dann die nächsten Tage nicht fündig werde, werde ich wohl mit klassischen Anzeigen loslegen, Bewerber auswählen, Vorstellungsgespräche führen und am Ende hoffentlich einen Vertrag mit unserem neuen Produktmanager Projektmanagement machen.

Kennen Sie solches Vorgehen? Klar, in großen Unternehmen würden jetzt die Personaler über mein unstrukturiertes Vorgehen die Hände über den Kopf zusammen schlagen. Dort findet der Prozess hunderte bis tausende Male im Jahr statt. Dann lohnt sich auch der Einsatz von Online-Portalen und E-Recruitment-Lösungen.   Aber bei aller technischen Unterstützung von administrativen Rekrutierungsaufgaben wird der Personalbesetzungsprozess am Ende nie voll-automatisiert werden. Bei der Personalgewinnung bleiben von Menschen getroffene Entscheidungen die wesentlichen Leistungen des Prozesses. Und wenn dann auch noch wie bei uns der Prozess eher selten ist (im Schnitt stellen wir bei ibo 10 neue Mitarbeiter im Jahr ein), auf mehrere Führungskräfte verteilt ist, dann ist eine Standardisierung oder gar Automatisierung weder sinnvoll noch wirtschaftlich vertretbar.

Und jetzt wieder zur Frage der Prozessdefinition. Ist das Beispiel ein Prozess? Na klar, es hat einen Input „Stelle frei“, eine Reihe von Aufgaben, und am Ende als Ergebnis eine hoffentlich gut besetzten Job. Aber kann und sollte man ihn vorher so planen, dokumentieren und verbindlich vorgeben? Wohl kaum.  Aber genau das ist der Irrglaube: nur weil die Aufgaben nicht immer gleich strukturiert ablaufen und eine Modellierung des Kontrollflusses schwierig ist, ist es trotzdem ein Prozess.

Das führt  mich zu den eingangs erwähnten neuen Schlagwörtern. Die bei Prozessmanagement oder Case Management  zugefügten Adjektive adaptiv, agil oder dynamic  drücken alle aus, dass sie Lösungsstrategien für unstrukturierte Prozesse anbieten. Und laut Gartner machen diese Prozesse  80 % der Prozesse in den Unternehmen aus. Da wundert es nicht, dass immer mehr Softwarehersteller Produkte mit dreistelligen Acronymen wie ACM, DCM oder ECM auf den Markt bringen.  Vergleicht man daneben das bereits große Angebot an BPM-Lösungen für strukturierte Prozesse, kann man sich vorstellen, was da in den nächsten Jahren noch auf uns zukommen wird.

1997 habe ich mich in der 5. Auflage des „Praxishandbuch Prozessmanagement“ (damals noch unter dem Namen Grundlagen der Prozessorganisation) zum ersten Mal mit der Klassifizierung  von Prozessen beschäftigt. Grundsätzlich unterscheiden sich Prozesse nach ihrer Wiederholungshäufigkeit, Determiniertheit, Kommunikationsintensität und Komplexität. Auch gibt es qualitative und quantitative Unterschiede bei den Prozessanforderungen an Mitarbeiter oder IT-Systeme. Schließlich kann man auch die vorrangig relevanten Kundenbedürfnisse (Qualität, Kosten, Zeit, Risiko) zur Charakterisierung von Prozessen heranziehen.  Seinerzeit habe ich folgende drei Prozesstypen unterschieden:

• Routineprozesse
• Regelprozesse
• seltene Prozesse (Projekt).

Letztere nenne ich mittlerweile ad-hoc-Prozesse oder situative Prozesse, da weniger die Häufigkeit als vielmehr die Determiniertheit der Prozesse eine Rolle spielt. Ein Prozess ist determiniert, wenn die Abfolge und Art der Aufgabenerledigung im vor hinein festgelegt ist. Das Gegenteil von determiniert ist agil. Hier entscheiden sogenannte Knowledge worker flexibel und situativ, welche Aufgaben sie wie und in welcher Reihenfolge bearbeiten. Ähnlich wie bei Projekten, die ja per Definition einmalige Prozesse sind, sind ad-hoc-Prozesse Unikate, die sich nicht vorher exakt planen lassen und in der abgelaufenen Form auch nicht  1:1 wiederholt werden. Beispiele für ad-hoc Prozesse finden sich bei Anwälten, die ihre Fälle dynamisch angehen oder bei Tüftlern, die ihre Produkte situativ entwickeln. Über Case Management hat Dr. Martin Bartonitz eine Reihe interessanter Blogbeiträge verfaßt, unter anderem über die Entstehungsgeschichte des Case Managers (siehe “Case Management ein alter Hut? Neben Kostensenkung hat es auch viel mit Humanismus zu tun” ).

Selbstverständlich gibt es Grauzonen und Mischformen zwischen den Prozesstypen. Nehmen wir nochmals mein Rekrutierungsprozess als Beispiel. Grundsätzlich würde ich die Personalgewinnung als Regelprozess einordnen. Die Aufgabenfolge (z.B. erst intern, dann extern ausschreiben) und Entscheidungen (z.B. passende Initiativbewerbung vorhanden?) können im Vorfeld generell festgelegt werden. Dennoch sollte der Prozess flexibel genug geregelt werden, dass  er zum Beispiel innovative Wege (zum Beispiel Ausschreibung per Blog) ad-hoc zu lässt, ohne dass man hierfür eine Arbeitsanweisung anpasst oder gar einen Workflow umprogrammieren muss.

Und selbstverständlich zeigt mein Beispiel auch, dass der Kontext entscheidend für den Prozesstyp ist. Abhängig von Unternehmenszweck, Größe, Branche,  Wettbewerbssituation und Marktanforderungen kann im Extremfall der gleiche Prozess in dem einen Unternehmen ein ad-hoc, in einem anderen ein Regel- und in einer weiteren Firma ein Routineprozess sein.  Das wird besonders deutlich, wenn Unterstützungsprozesse wie beispielsweise  Personalprozesse outgesourct werden. Während sie beim Outsourcingnehmer vorher mangels Masse und Bedeutung unstrukturiert abliefen,  sind sie beim Outsourcinggeber strukturierte und automatisierte Kernprozesse.

Die  Dreiteilung hat mir seitdem in vielen Projektsituationen geholfen, die Charakteristik unterschiedlicher Prozesstypen zu verstehen und entsprechend differenziert vorzugehen. Ein Einsatzgebiet ist beispielsweise die Frage, welche Verfahren zur kontinuierlichen Prozessleistungsmessung bei verschiedenen Prozesstypen geeignet sind (siehe dazu mehr im Praxishandbuch Prozessmanagement).  Auch nutzen die Prozesstypen bei der Bildung der Prozessarchitektur .

Die Unterscheidung in die drei Prozesstypen ist zunehmend auch bei anderen BPM-Autoren zu finden. So beispielsweise in dem frisch erschienenen Buch von Dirk Slama und Ralph Nelius  zum Thema Enterprise BPM. In diesem Werk unterscheiden die Autoren Voll-Automatisierte Prozesse/Straight Through Processing, Entscheidungsintensive Prozesse und Case Management. Für ersteren Prozesstyp sehen sie die technische Umsetzungsoption eines integrationszentrierten BPMS (Business Process Management Suite). Dahinter verbirgt sich das Konzept der Prozessautomatisierung im Sinne einer prozessorientierten Anwendungsintegration, bei der eine process-engine  die Steuerung der Prozesslogik übernimmt und interne und externe IT-Systeme über Maschine-Maschine-Schnittstellen aufruft (siehe hierzu Jakob Freund und Bernd Rücker in ihrem Buch  Praxishandbuch BPMN 2.0). Da hier im Extremfall keine Menschen mehr in den Prozessablauf eingreifen, hat sich das Wort „Dunkelverarbeitung“ etabliert.  Bei den Regelprozessen wird es „heller“, weil bei diesen viele Entscheidungen von Menschen getroffen werden. Da dieser Prozesstyp relativ strukturiert und  häufig stattfindet, kann hier eine Prozessautomatisierung im Sinne eines Human-Workflow-Managements sinnvoll sein. Dabei initiiert und überwacht  die process-engine mit Mensch-Maschine-Schnittstellen  die Aufgabenerledigungen der Prozessbeteiligten. Slama/Nelius sehen für diese entscheidungsintensiven Prozesse anwenderzentrische BPM Systeme vor. Und für die ad-hoc-Prozesse favorisieren sie dokumentenzentrierte BPM Systeme die wie eingangs erwähnt zur Zeit mit Abkürzungen wie ACM, DCM oder ECM in den Markt drängen. Auch wenn bei all diesen Systemen noch viel im Fluss ist, so ist die Grundidee der Case- oder Contentmanagementsysteme der Wissensmanagement-Ansatz.  Der Fallbearbeiter wird bestmöglich durch vom System priorisierte Aktivitäten, Informationen, Templates, Checklisten, Vorlagen etc. bei seiner  Aufgabenerledigung unterstützt.

Die skizzierten Lösungen für unstrukturierte Prozesse werden derzeit technisch getrieben diskutiert.   Meiner Ansicht  nach kommen dabei organisatorische Fragen zu kurz. Zum Thema, ob und wie ad-hoc-Prozesse dokumentiert, analysiert und gestaltet werden sollen, gibt es noch viel zu sagen und zu schreiben … aber das bei meinen folgenden Blogbeiträgen oder Vorträgen.