Unwillkürlich kamen mir zwei Geschehnisse aus meiner beruflichen Vergangenheit in den Sinn. Vor vielen Jahren war ich in einem Projekt beteiligt, bei dem wir bei einem grossen deutschen Unternehmen ein Dokumentenmanagement-System eingeführten. Eines der ersten Projekte wurde in der Personalabteilung gestartet, wo die sogenannte P-Akte, die elektronische Personalakte, realisiert wurde.
Die Dokumentenseite liess sich sehr schön implementieren, jedoch sollten auch Personalprozesse automatisiert werden. Dieser Teil des Projektes war aus meiner Sicht vor allem aus zwei Gründen nicht erfolgreich: Wir bildeten Prozesse in Absprache mit dem Fachbereich beispielhaft ab und versuchten, sie zu optimieren (und nicht nur Bestehendes zu elektrifizieren, wie es noch immer oft getan wird). Das Ergebnis der Demonstration des ersten Prototypen war ernüchternd: Scheinbar kannte man seine eigenen Prozesse nicht oder war sich über deren Ablauf uneinig. Daraus ziehe ich zwei Schlüsse: Man braucht schnelles Prototyping und immer wiederkehrendes SignOff der und Verifizierung Prozessbeteiligten.
Die zweite, fast noch grössere Herausforderung war, dass man im Projekt versuchte, jede Prozessausnahme zu bedenken und in einem Workflow abzubilden. Ich habe das später einmal als typisch deutsche Eigenheit bezeichnet, einen Prozess „perfekt“ machen zu wollen. Dieser Hang nach Perfektionismus führte zu endlosen Prozessdefinitionstapeten, die ganze Wände füllten, und zu einer endlosen Projektzeit. Hier ist mein Schluss, dass man den Kernprozess abbilden und in ihm „Exception Handling“, Ausnahmefälle, vorsehen solle, Absprungpunkte, in denen eim Fall gesondert behandelt wird, um dann wieder geordnet in den Ablauf zurückgeführt zu werden.
Viele der damaligen Workflow-Tools konnten das nicht leisten. Während meiner Zeit bei FileNet haben wir versucht, dies in Kombination von FileNet eProcess Services/Business Process Manager und einem Team Collaboration-Produkt zu lösen (Letzteres gibt es wohl heute nicht mehr).
Der Drang und Anspruch, alle Prozesse perfekt abzubilden und zu harmonisieren ist auch heute noch da. Patel nennt das „Process Work“ nach einem strikten „Playbook“. ERP Anbieter und Prozessbürokraten glauben wohl weiterhin, dass alle möglichen Abläufe kosteneffizient und standardisiert in zahllosen Softwaremodulen automatisierbar sind. Ich habe da bei allem Verständnis für Prozessoptimierung und Kosteneinsparung so meine Zweifel. Gerade an der Schnittstelle zum Kunden – und darunter verstehe ich auch den internen Kunden, den Mitarbeiter – sollte es mögliche Interaktionspunkte, Möglichkeiten zur Ausnahmebehandlung geben.
Der von Patel zitierte Fall von Delta Airlines ist sicher einer, der dramatisch einen Schaden zeigt, der durch zu strikte Prozesstreue und die fehlende Möglichkeit einer Ausnahmebehandung entstanden ist. Im Zeitalter sozialer Medien haben die Kunden enorm an Macht gewonnen und sind auch bereit, diese auszuüben. Ich kann das zitierte Beispiel aufgrund persönlicher Erfahrungen – zum Beispiel im Umgang mit meinem Telekommunikationsanbieter – sehr gut nachvollziehen. Vielen Mitarbeiter fehlt einfach auch die Möglichkeit einer Ausnahmebehandlung. Patel beschreibt das sehr schön mit dem Bild, dass ihm in den Lösungen und Prozessdefinitionen zwischen dem „Übertragen“- und „Abbrechen“-Knopf oft der Schalter „Nachfragen“ fehlt.
Heute sind wir jedoch technologisch und auch mental in der Lage, solches Exception Handling durch einen sozialen Layer im Unternehmen besser abzubilden als je zuvor. Expertensuche, einfache Nachfragemöglichkeit über Real Time Communication (z.B. Chat), kollaboratives Aktivitätenmanagement wie beispielsweise in IBM Connections erlauben es einfacher denn je, Ausnahmen kollaborativ zu behandeln.
Damit es nicht missverstanden wird: Ich spreche nicht davon, dass es nur noch Ausnahmen geben kann und soll. Ich spreche davon, dass an definierten Stellen Absprungpunkte aus dem Standardprozess vorhanden sein sollten. Diese definierten Stellen sind für mich insbesondere Punkte, an denen man mit meinem Kunden – ob externer oder interner Kunde – kommuniziert und wo Kundenzufriedenheit besonders wichtig ist. Hier könnte und sollte der soziale Layer gepaart mit einer Bevollmächtigung des Mitarbeiters, der mit dem Kunden kommuniziert, greifen.
Natürlich müssen dafür die technischen Voraussetzungen – der Social Layer mit Möglichkeit zur abteilungsübergreifenden Expertensuche, mit Dokumentation von Best Practises, mit leistunsgfähigen Real Time-Kommunikationsfunktionen usw. – geschaffen werden. Vor allem muss aber wohl in den Köpfen ein Umdenken weg von starrem, einbetonierten Prozess- und Silodenken hin zu kundenorientierten, flexibilisierten Abläufen stattfinden. Nicht der Prozess, der Kunde sollte im Mittelpunkt stehen, und das nicht nur, weil er im sozialen Zeitalter ungeheuere Macht hat.
Links: Klint Finley: The Rules of Exception – http://www.readwriteweb.com/enterprise/2011/07/the-rules-of-exception.php
Sameer Patel: Why Exception Handling Should be the Rule – http://www.pretzellogic.org/blog/2011/07/21/why-exception-handling-should-be-…
StefanPfeiffer.Blog 
Kommentar verfassen