BPMN 2.0 – der richtige Umgang mit ersten Widerständen

Gleich vorweg klargestellt: BPMN ist aus meiner Sicht gut, notwendig, und der richtige Schritt zur richtigen Zeit. Und genau deshalb liegt mir der Erfolg dieser Standardnotation am Herzen. Ich sehe aber auch schon, wie sich in den Firmen der Widerstand formiert und wie mit dem Gegenwind umgegangen wird. Und hier befürchte ich, das sich Fehler wiederholen, die bereits in der Vergangenheit dazu geführt haben, dass sinnvolle Standardisierungsmöglichkeiten nicht den dauerhaften Erfolg erzielt haben, den sie verdient hatten. 

Viele der Widerstände gegenüber BPMN äußern sich derzeit auf der Sachebene und werden dann auch prompt von den BPMN-Protagonisten auf der Sachebene bearbeitet. Wird zum Beispiel von den Widersachern moniert, BPMN sei zu komplex für den Fachbereich kommt gleich die Antwort aus der IT, dass das 1. gar nicht so ist und 2. das ja so sein muß, wenn die Prozesse an sich komplex sind. Sachlich mag das ja so stimmen, für eine Akzeptanz der Technik sorgt das nicht. Was sind die wahren Ursachen für die fehlende Begeisterung bei den Betroffenen und wie begegnet man Ihnen sinnvoll?

Erstmal möchte ich zwei Gruppen von Betroffenen differenzieren. 

• Fachbereiche
• BPM-Experten

Das die Fachbereiche nicht auf Anhieb begeistert von BPMN sind ist klar. Was sollte der subjetive Nutzen einer neunen Notation für einen Kreditsachbearbeiter sein? Er will beim Jobeinstieg eine gute Einweisung in seine Arbeitsabläufe und später dann situativ eine lesbare Arbeitsanweisung. 

Jetzt werden Einige wahrscheinlich denken,  BPMN ist ja auch gar nicht als Arbeitsanweisungstechnik gedacht. Aber da sehe ich in der Praxis bereits große Migrationsprojekte starten, die alle in der Vergangenheit in anderen Notationen modellierten Prozesse nun in BPMN überführen. Auslöser für diese Vorhaben ist sicherlich der richtige Business-IT-Alignment-Gedanke. Dann kommen aber auch ganz schnell noch vermeintlich rationale Gründe ins Spiel. Der Aufwand muss sich ja auch lohnen. Und überhaupt muss alles einheitlich sein. Am Ende werden dann die BPMN-Diagramme im Intranet als Arbeitsanweisung für den Fachbereich zur Verfügung gestellt.

Der Köder sollte dem Fisch schmecken und nicht dem Angler!

Ich meine, hier sollte man ehrlich sein und nicht einem Fachbereich einreden, er hätte etwas von dieser Notation. Das wird zum Bumerang. Lieber reinen Wein einschenken und klar kommunizieren, dass es eine wichtige Notation für den Org/IT-Bereich ist. Ehrlichkeit wird immer mit Akzeptanz belohnt.

Und noch eins ist mir im Umgang mit dem Fachbereich wichtig: Nicht alle Prozesse über einen Kamm scheren! 

Wenn ich mein FAU-Prozessmodell mal als Basis nehme, dann unterteilt sich die Prozesslandschaft in Unternehmen grundsätzlich in Führungs-, Ausführungs- und Unterstützungsprozessen. Im Übereifer (oder Unwissen?) wurden in der Vergangenheit Notationsstandards wenn schon, dann natürlich für alle Prozesse verbindlich eingeführt. Klar, ein Standard hat den Namen Standard nur verdient, wenn er für alle gilt. Aber hat das zur Akzeptanz geführt? Wenn ein Betroffener ein ausgefeiltes Business Process Diagramm (BPD) für seinen überschaubaren Zielvereinbarungsprozess vorfindet, stellt er gleich die Sinnhaftigkeit des Ganzen in Frage. Dann hat er leichtes Spiel bei der Argumentation, dass ist ja alles übergeregelt und zu kompliziert. Noch sind wir Gottseidank nicht so weit. Aber deshalb ja auch dieser Post: Wehret den Anfängen! Ich bin der Meinung, dass man beim jetzigen BPMN-Ausrollen eine sorgfältige Differenzierung der Prozesslandkarte vornimmt. BPMN für alle Routineprozesse, der Rest in einer für den Fachbereich verständlichen Darstellung.

Und für diesen gar nicht so kleinen Rest (ich schätze, dass immer noch 60-80% der Mitarbeiter in Nicht-Routineprozessen arbeiten) sollte man sich die Mühe machen, die Betroffenen bei der Wahl der Dokumentation zu beteiligen. Hier lohnt es sich, Prozesse in verschiedenen Darstellungen Mitarbeitern aus Fachbereichen vorzulegen und nach Verständlichkeit und Gefallen zu fragen. Vielleicht kommt am Ende ja sogar eine abgespeckt Swimlane als Favorit heraus 😉

Warum sind denn eigentlich BPM-Experten erstmal reserviert gegenüber BPMN?

Ich denke, dass hat viel mit der grundsätzlichen Neuerungsfeindlichkeit eines Menschen zu tun. Schließlich fangen wir beim Thema Prozessmodellierung ja nicht bei Null an. Das war vor 20 Jahren anders. Die erste Welle an großflächig angelegten Modellierungsbestrebungen mit EPK, Folgeplänen oder sonstigen proprietären Visualisierungsformen fiel auf unbeackertem Boden. Alle Prozessmodellierer waren dankbar für einen Standard, egal welcher. Heute stößt BPMN auf eine bestehende Schaar von Prozessspezialisten, die ihre Notation lieb gewonnen haben und ungern umlernen. 

Und dann ist da ja noch die alte Friktionslinie zwischen Org und IT. Quantitativ hat die IT längst die Vormachtstellung in den Häusern vor der Orga erreicht. Und jetzt geht es an eine der letzten Machtbasen der Orga. Was passiert denn, wenn die IT auch noch die Prozessmodellierung übernimmt? Das da kein Prozessorganisator “Hurra” schreit ist nachvollziehbar. Die Angst von der IT völlig vereinnahmt zu werden, ist überall zu spüren.

Wenn man jetzt aber wiederum die vorhin erläuterten Vorbehalte der Fachbereiche gegenüber einem unreflektierten Ausrollen von BPMN sieht, ergibt sich hier meiner Meinung nach eine große Chance der Betriebsorganisation. Die Organisatoren alter Schule sind gut beraten, die neue Notation aktiv aufzugreifen und differenziert anzuwenden: BPMN für standardisierbare Routineprozesse, leserliche Arbeitsanweisungen für alle anderen unregelmässigen Prozesse. Dann füllen sie eine für jedes Unternehmen wichtige Rolle als Mittler zwischen Fachbereich und IT aus. Und dann verdienen sie auch den Namen eines Business-Analysten, der die Anforderungen der Fachbereiche in eine für den IT-Bereich verständliche Sprache – eben BPMN – übersetzt und umgekehrt.

Warum auch andere Zielgruppen wie Compliance, Controlling oder Revision nicht auf Anhieb von BPMN begeistert sind, hebe ich mir für einen späteren Post auf.