BPM-Freigabeworkflows: Paradebeispiel für starre Strukturen

Nach (oft wochenlanger) harter Arbeit und unendlichen Diskussionen und Anpassungen ist es endlich soweit: der neue Prozess ist unter allen Gesichtspunkten fertig definiert. Doch das schlimmste steht erst noch bevor: die Freigabe des Prozesses durch alle Verantwortlichen. Ein Prozedere, welches oft unverhältnismäßig länger dauert als die eigentliche Prozessgestaltung. Katastrophal vor allem in Projekten, wenn es schnell gehen muss.

Qualität und Qualitätssicherung ist ein wichtiger Faktor

Wie ich unter anderem in dem Beitrag „Prozesse müssen gepflegt werden“ geschildert habe, halte ich die Qualität und Qualitätssicherung von Prozessen für einen äußerst wichtigen Faktor. Denn nur aktuelle und gute Prozesse bilden eine stabile Basis, aus der man schnell und flexibel handeln kann. In diesem Sinne sind auch Freigabeworkflows besonders wichtig. Denn sie sind dafür da, dass nur Prozessmodelle und –dokumente veröffentlicht werden, die formal und inhaltlich eine entsprechende Qualität aufweisen. Das Problem sehe ich viel mehr in folgenden beiden Punkten:

• die Workflows dauern zu lange. Oft länger als die eigentliche Prozessgestaltung. Langes Warten sorgt vor allem für Verdruss bei den Beteiligten. Und deren Motivation ist mit entscheidend für den Erfolg von BPM und seinen Methoden.
• es gibt i.d.R. einen definierten Workflow, der für alle Szenarien gilt. Also z.B. muss ein und derselbe Workflow eingehalten werden, ob es sich um „unwichtigere“ Prozessanpassungen im Tagesgeschäft handelt oder „dringende“ Prozessgestaltungen in Projekten

Der typische Freigabeworkflow

BPM Methoden sind meist starr wie Stahl

Natürlich gibt es „den“ typischen Workflow nicht, aber so oder so ähnlich haben bis jetzt die meisten ausgesehen, die ich bisher kennengelernt habe. Nehmen wir als Beispiel ein Workflow für die Freigabe eines Prozesses, der mit Prozessmodellierung in einem Tool dokumentiert wird.

1. Prozessgestaltung, z.B. in Rahmen von Workshops
2. Modellierung des Prozesses
3. Syntaxprüfung des Prozessmodell durch Prozessmodellierer (meist in den Tools standardmäßig integrierte Funktion)
4. Abstimmung des Prozessmodells mit allen, die an der Gestaltung beteiligt waren
   1. Anpassung Prozess und Prozessmodell
   2. Wiederholung bis alles OK (dieser Schritt raubt oft viel Zeit. Das hängt nicht unbedingt immer mit einem „schlechten“ Prozess zusammen, sondern weil Notation und Syntax der Prozessmodellierung für die Beteiligten zu kompliziert und nicht verständlich ist)
5. Fachliche Prüfung und Freigabe durch Fachverantwortliche (Fachbereiche, IT, Compliance etc.), Prozessverantwortliche usw.
   1. zurück zu Schritt 2 (ist eigentlich die Regel, weil in der Prozessgestaltung nicht alles bzw. jeder berücksichtigt worden ist)
6. Formale Prüfung des Prozessmodells, z.B. durch Konventionen-Verantwortliche, Tool-Administratoren, Prozessarchitekten
   1. zurück zu Schritt 2 (und auch hier kommt es noch sehr oft zu Nacharbeiten, manchmal wegen der banalsten Dinge)
7. Veröffentlichung des Prozesses, z.B. Dokumentenverteilung, Prozessportal o.ä.

Wenn man dies sieht, ist es nicht schwer vorstellbar, dass eine solche Freigabe viel Zeit (und Nerven) kosten kann. Argumente wie „gleich richtig machen und Nacharbeiten sparen“ oder „von Anfang an alle Mann an Bord holen“ sind mit Sicherheit richtig, lösen aber das eigentliche Problem nicht: wenn es schnell gehen muss, ist ein solcher Workflow nicht akzeptabel! Die Realität ist aber, dass solche Vorgehen auf Biegen und Brechen eingehalten werden müssen, auf Kosten z.B. von Projekterfolgen.

Freigabeworkflows müssen flexibel sein

Agile Methoden wie SCRUM halten schon länger Einzug in die Unternehmen und Projektarbeit. Und auch agiles Prozessmanagement ist mittlerweile kein Fremdwort mehr. Wo Prozesse schnell und flexibel angepasst oder geschaffen werden müssen, darf der Erfolg nicht an starren Strukturen scheitern. Deswegen ist es meiner Meinung nach besonders wichtig, dass auch die Freigabe der Prozesse sehr flexibel ist. Am besten gibt es sogar spezifische Workflows. Diese können über die verschiedensten Kriterien definiert werden, die auch miteinander kombiniert werden können, wie z.B.

• Priorität / Dringlichkeit: wird die Änderung dringend benötigt oder hat man Zeit?
• Projekt / Tagesgeschäft: arbeitet man in agilen Projekten, in denen Prozess schnell und in kurzen Zeitabständen eingeführt werden?
• Freigabe-Befugnisse: wer muss wirklich alles unterschreiben? Kann es Ausnahmen geben? Kann man Rollen zusammenfassen?
• Reduzierter Workflow: Kann man Workflow Schritte aus- oder nachlagern? Muss ein Prozessmodell zur Freigabe wirklich syntaktisch richtig sein, oder reicht es, dass zunächst der Inhalt stimmt und es verständlich ist, und die korrekte Modellierung im Nachgang erledigt wird?

Fazit

Freigabeworkflows sind für mich ein schönes Beispiel, wie starr, formal und bürokratisch Business Process Management oft noch in der Praxis ist. Dies kann nicht nur quantitative Folgen haben (z.B. Projektmehrkosten, Verzögerungen), sondern sich auch auf die Begeisterung und Motivation der Beteiligten auswirken. Wenn Methode und Form vor Mensch steht, rückt ein nachhaltiger Erfolg in weite Ferne. Dabei lassen sich einige Dinge auch sehr einfach verbessern und flexibler gestalten. Es muss nicht immer gleich die Einführung einer ganzheitlichen „agilen Mentalität“ sein. Im Beispiel der Freigabeworkflows reicht es vielleicht schon, einen vereinfachten Workflow für Projekte zu definieren.