Kostensenkung, Optimierung der Bearbeitungszeit, Steigerung der Qualität – alles erstrebenswerte Ziele. Zu erreichen mit Prozessautomatisierung. Der BWLer ist erfreut und auch der ITler findet’s cool. Macht ja auch Spaß, sowas zu bauen. Noch dazu ist es in vielen Fällen wirklich sinnvoll und ein echter Mehrwert. Aber die Verlagerung von Ablauf- und Fachlogik in den Automaten darf nicht zum Selbstzweck werden. Passiert dies dennoch, werden wertvolle Mitarbeiter zu unzufriedenen Arbeiterhumanoiden, Änderungen an bestehenden Prozessen langwierig und teuer und somit die Ziele und Versprechen von BPM konterkariert.
Prozessautomatisierung und -optimierung. Gerne, aber richtig.
Um das Bild zu konkretisieren: mit einem allmächtigen Prozess ist ein Prozess gemeint, der in seiner jetzigen Form absolut vollständig ist und so auf jede noch so unerwartete Situation und Variante reagieren und diese vollautomatisch verarbeiten kann. Heute, morgen und immer. Aber wozu führt dieses Bild? Ist es realistisch und überhaupt erstrebenswert?
Nahezu jeder Geschäftsvorfall ist eine Kombination aus wiederkehrenden (häufig wenig spannenden) Routinetätigkeiten und komplexen, teils hochindividuellen Tätigkeiten. Erstere erfordern Wissen, letztere Können und Erfahrung. Nun ist es so, dass sich wiederholbar anwendbares Wissen recht gut in Prozessen festschreiben und in Algorithmen abbilden lässt. Bei Können und Erfahrung verhält es sich anders. Von Können und Erfahrung profitieren wir, wenn wir mit neuen, unbekannten Situationen umgehen müssen, dabei ist Talent gefragt. Reines Wissen versagt hier, da das neue Problem nicht durch das Abspulen eines Routineplans gelöst werden kann. Der interessierte Leser findet dazu exzellente Vertiefung hier.
Aber was heißt das nun für unsere Geschäftsprozesse? Diese können wir recht leicht mit Wissen versehen und sie mit verhältnismäßig kleinem Aufwand in die Lage versetzen, wiederkehrende Routinetätigkeiten zu automatisieren. Gehen wir dabei aber blindlings weiter und erliegen der Versuchung, jedwede Eventualität für die Zukunft in den Prozess einzubauen, stellen wir uns mit geschärfter Axt in den Schiffsrumpf.
Zum einen ist dieses Unterfangen unverhältnismäßig teuer. Kein Betriebswirt klatscht Beifall, wenn wir eine Prozessvariante mit großem Aufwand automatisieren, die einmal im Jahr vorkommt. Oder vielleicht nie. Abgesehen davon wird es uns auch bei größter Anstrengung nicht gelingen, jede Möglichkeit vorherzusehen. Dafür ist die Dynamik in der heutigen Geschäftswelt und den Kundenwünschen zu groß. Machen wir uns nichts vor: sich änderndes Kundenverhalten, geänderte Richtlinien und Gesetze auch in noch so regulierten Umfeldern und neue Produkte machen jedem starren Prozess im Nu den Garaus.
BPM adé?
Und nun? Geschäftsprozesse adé? Nö. Aber eben robust für Dynamik. Häh? Nun, wie oben beschrieben, sind wir heute schon sehr gut darin, Routinetätigkeiten in Prozessen abzubilden. Man muss nur im Prozess den richtigen Absprung finden und erkennen, dass der konkrete Geschäftsvorfall die Norm verlässt. Anstelle dann (am besten noch technisch) auf die Bretter zu gehen, muss der Geschäftsprozess so gestaltet sein, dass er aus dem stark strukturierten Teil ausbricht und die Arbeit in die Hände eines geeigneten Bearbeiters gelangt. Dieser ist dann in der Lage, auch für unvorhergesehene Situationen die richtige Lösung zu finden und das Geschäftsziel zu erreichen.
Was haben wir in diesem Moment getan? Zwei Dinge: Zum einen haben wir den Geschäftsprozess robust gemacht, weil er nicht mehr fehlerhaft abbricht, sondern einen geeigneten Mitarbeiter identifiziert und diesen in die Bearbeitung – wichtiger noch, in die Entscheidung (!) – einbezieht. Und wir haben an dieser Stelle den Fokus verschoben. In den hoch automatisierten, stark strukturierten Passagen ist uns neben dem Prozessziel vor allem das WIE wichtig. Also: WIE erreichen wir das Ziel mit minimalem Aufwand und minimalen Kosten? Dies verliert in selten vorkommenden Fällen und insbesondere in einer unvorhergesehenen Ausnahmesituation an Bedeutung. Hier ist allein das Erreichen des Ziels … äh … das Ziel. Also das WAS. Bei freier Wahl der Mittel. Daran hängen so Dinge wie Servicequalität und Kundenzufriedenheit. Bei allem Effizienzdrang dürfen wir das ja auch nicht vergessen.
Rückkopplung und Optimierung
Das alles heißt nun nicht, dass wir die Tugenden von BPM über Bord schmeißen. Auch diese Fälle lassen sich analysieren und, wenn sie zukünftig häufiger vorkommen, auch zumindest teilweise automatisieren. Monitoring und Reporting sind hier die Schlagworte. Und mit einigen modernen Process Engines lassen sich beide Welten auch auf Basis von BPMN und CMMN kombinieren. Dennoch bleibe ich bei meinem Plädoyer, nicht dem Automatisierungswahn zu erliegen und der Versuchung zu erliegen, den einen, für immer funktionierenden, vollautomatisierten Prozess zu ersinnen. Und bitte vergesst nicht das Wertvollste, das ihr habt: eure Mitarbeiter. Bezieht sie in die Prozessgestaltung mit ein und vermeidet langweilige Fließbandarbeitsplätze.
Interessanter Posting wo ich den meisten Punkten zustimmen möchte. Mir fehlt ein wenig aber der alternative Plan, nämlich der anstatt Orchestrierung überhaupt über Choreografie nachzudenken. Oft sind Architekten die klassischerweise immer das Saga Pattern anwenden zuerst skeptisch, meiner Erfahrung nach hapert es aber komplexen Prozessen mit ihren Substeps aber üblicherweise an der Kapselung. Meist kann man viel der Logik in die Endpoints verschieben
Nächstes Gegenargument ist dann oft, dass ich dann an zentraler Stelle keinen Infostatus über den choreografierten Ablauf habe. Auch das stimmt dann nicht, da man ja jederzeit Events die im Zusammenhang damit emmitiert werden an einer Zentralen stelle konsumieren, sammeln und anzeigen kann. Dort kann man auch alerten falls etwas nicht fertig wird
Im Endeffekt ist die Choreografie flexibler, zB von ihrer Erfüllung des Open-Closed Principles her ist es leichter neue Funktionalitäten auf Basis der gekapselten Funktionalität und der emittierten Events anzubieten. Ein unschätzbarer Wert für ein Unternehmen