Wir prozessieren uns zu Tode. Und das Schlimmste daran: Wir machen es freiwillig.

Ich kann dieses „Da brauchen wir einen Prozess!“ langsam nicht mehr hören.

Es ist faszinierend, mit welcher Begeisterung Unternehmen ihre eigene Bürokratie erschaffen. Da sitzt irgendjemand in einem Meeting und sagt „Man müsste mal …“, ein anderer antwortet „Das ist doch eigentlich ganz einfach!“ und spätestens wenn jemand BPMN ins Spiel bringt, gibt es kein Halten mehr. Ein bisschen „Bürokratie ist geil“ schwingt auch immer mit.

Also werden Workshops organisiert, Zuständigkeiten definiert, Kästchen gemalt und Pfeile gezogen. Irgendwann hängt da ein wunderschönes Flussdiagramm mit fünf Swimlanes, zwölf Entscheidungen und drei Eskalationspfaden. Alle sind zufrieden. Endlich ist dieser Ablauf sauber geregelt!

Bis die Realität vorbeikommt und sich nicht daran hält.

Und das tut sie erstaunlich zuverlässig.

Die Ausnahme ist keine Ausnahme. Sie ist der Normalfall.

Das größte Problem mit starren Prozessen ist aus meiner Sicht eine ziemlich grundlegende Fehleinschätzung: Wir glauben, dass sich die Wirklichkeit vollständig modellieren lässt.

Nehmen wir einen ganz gewöhnlichen Beschaffungsprozess. Ein Mitarbeiter benötigt ein Gerät, stellt einen Antrag, der Vorgesetzte genehmigt, der Einkauf bestellt und irgendwann kommt die Ware. Klingt logisch. Ist es auch.

Jetzt wird aber kurzfristig ein anderes Gerät benötigt, weil das ursprünglich ausgewählte Modell nicht mehr lieferbar ist. Oder das günstigere Angebot läuft in zwei Stunden ab. Oder der Mitarbeiter stellt fest, dass ein vorhandenes Gerät völlig ausreichen würde. Vielleicht hat der Hersteller auch einfach ein neues Modell veröffentlicht, das besser und günstiger ist.

Natürlich kann man für solche Fälle weitere Verzweigungen modellieren. Das ist ja das Schöne an BPMN. Es gibt immer noch ein Gateway, das irgendwo hinpasst.

Aber mit jedem Sonderfall wird das Diagramm größer, die Zahl möglicher Abläufe steigt und die nächste unvorhergesehene Situation wartet bereits hinter der nächsten Ecke.

Was passiert dann? Richtig. Wir brauchen eine Prozessanpassung!

Noch ein Workshop, noch ein Gateway, noch eine Freigabe. Das ist dann übrigens kein Fehler des Prozesses, sondern ein „Optimierungspotenzial“.

Ich finde diese Denkweise bemerkenswert. Wir verbringen immer mehr Zeit damit, die Realität in unsere Modelle zu zwingen, statt unsere Arbeitsweise an die Realität anzupassen.

Und nein, das ist kein Argument gegen BPMN als Modellierungssprache. BPMN kann eine ganze Menge und ist für viele Aufgaben ausgesprochen nützlich. Aber nur weil sich etwas modellieren lässt, heißt das noch lange nicht, dass es sinnvoll ist, daraus eine verbindliche Arbeitsvorschrift zu machen.

Wenn plötzlich der Prozess wichtiger ist als das Ergebnis

Besonders spannend wird es, wenn Mitarbeiter anfangen, sich an Prozessen statt an Ergebnissen zu orientieren.

Ein Kunde hat ein Problem. Der zuständige Mitarbeiter könnte es lösen, muss aber zunächst ein Ticket an eine andere Abteilung übergeben. Dort wird es kategorisiert, priorisiert und irgendwann zurückgegeben, weil eine Information fehlt. Zwei Tage später landet das Ticket wieder bei der ursprünglichen Person.

Problem gelöst? Nein. Prozess eingehalten? Selbstverständlich!

Und niemand hat etwas falsch gemacht. Zumindest nicht aus Sicht der Organisation.

Das ist für mich einer der absurdesten Effekte übertriebener Prozesssteuerung: Wir schaffen Systeme, in denen Menschen formal alles richtig machen können, während das eigentliche Ergebnis immer schlechter wird.

Irgendwann lautet die wichtigste Frage nicht mehr „Haben wir das Problem gelöst?“, sondern „Wurde der vorgesehene Ablauf eingehalten?“.

Herzlichen Glückwunsch. Wir haben die Verantwortung für Ergebnisse erfolgreich durch die Verantwortung für einzelne Arbeitsschritte ersetzt.

Das Ganze wird gerne mit Qualitätssicherung begründet. Und ja, standardisierte Abläufe können Qualität sichern. Aber ein zusätzlicher Freigabeschritt ist nicht automatisch Qualitätssicherung. Manchmal ist er einfach nur ein zusätzlicher Freigabeschritt.

Wir optimieren nicht mehr die Wertschöpfung. Wir optimieren die Verwaltung der Wertschöpfung.

Und wundern uns anschließend, warum alles so lange dauert.

Die Bürokratie, die wir uns selbst bauen

Was mich daran besonders stört, ist der Mechanismus dahinter.

Ein Fehler passiert. Irgendjemand fordert Maßnahmen, damit dieser Fehler nie wieder vorkommt. Also wird ein neuer Prozess eingeführt, eine Checkliste ergänzt oder eine zusätzliche Freigabe verlangt.

Das ist auf den ersten Blick absolut nachvollziehbar.

Aber wer fragt eigentlich nach den Kosten dieser Maßnahme?

Wenn ein Fehler einmal im Jahr auftritt und einen Schaden von 500 Euro verursacht, ist es dann wirklich sinnvoll, 50 Mitarbeiter jede Woche zehn Minuten mit einer zusätzlichen Kontrolle zu beschäftigen?

Natürlich nicht. Trotzdem passiert genau diese Art der Überregulierung ständig. Der einzelne Fehler ist sichtbar, seine Vermeidung lässt sich wunderbar präsentieren. Die vielen kleinen Zeitverluste verteilen sich dagegen über die gesamte Organisation und tauchen in keiner Präsentation auf.

Und wenn der neue Prozess selbst Probleme verursacht, wird selten über seine Abschaffung diskutiert. Stattdessen wird er angepasst, erweitert oder mit einem weiteren Prozess abgesichert.

Das ist schon fast eine Art organisatorischer Selbsterhaltungstrieb.

Dabei haben wir diese Bürokratie selbst erfunden. Kein Gesetzgeber hat sie verlangt, kein Kunde hat sie bestellt und vermutlich hat auch niemand ausgerechnet, ob sie wirtschaftlich überhaupt sinnvoll ist.

Wir wollten einfach mal etwas „sauber regeln“.

Warum eigentlich nicht Freiheit + Controlling?

Ich frage mich zunehmend, warum Unternehmen so viel Energie darauf verwenden, den Weg zu einem Ergebnis vorzuschreiben, statt das Ergebnis selbst zu kontrollieren.

Was wäre denn, wenn wir deutlich häufiger einfach Ziele und Leitplanken definieren würden?

Ein Mitarbeiter darf beispielsweise bis zu einem bestimmten Betrag eigenständig Beschaffungen durchführen. Er muss begründen können, warum die Ausgabe sinnvoll war, sie muss nachvollziehbar dokumentiert sein und innerhalb des Budgets liegen. Ob er dafür drei Angebote eingeholt, einen bestehenden Rahmenvertrag genutzt oder ein besonders gutes Angebot gefunden hat, ist erst einmal zweitrangig.

Das Ergebnis zählt. Und die Verantwortung dafür liegt bei ihm.

Natürlich braucht es Grenzen. Gesetze, Sicherheitsvorgaben, finanzielle Risiken und Qualitätsanforderungen verschwinden nicht dadurch, dass man Prozesse abschafft. Auch Controlling darf nicht einfach nur auf eine einzelne Kennzahl schauen, sonst schafft man sich direkt das nächste Problem.

Aber genau dafür gibt es Führung und Controlling.

Ich will doch wissen, ob eine Abteilung wirtschaftlich arbeitet, ob Kunden zufrieden sind, ob Fehler passieren und wo Geld oder Zeit verloren geht. Ich muss dafür nicht jede einzelne Entscheidung auf dem Weg dorthin vorgeben.

Menschen einzustellen, weil sie etwas können, und ihnen anschließend detailliert vorzuschreiben, wie sie dieses Können einzusetzen haben, ist doch irgendwie widersprüchlich.

Gerade in der Softwareentwicklung ist das besonders offensichtlich. Ein großer Teil unserer Arbeit besteht darin, Probleme zu lösen, die vorher noch gar nicht vollständig bekannt waren. Wenn wir alle Schritte im Voraus definieren könnten, hätten wir einen erheblichen Teil der eigentlichen Arbeit bereits erledigt.

Trotzdem versuchen wir immer wieder, komplexe Wissensarbeit wie eine industrielle Fertigungsstraße zu organisieren.

Und dann wundern wir uns, wenn das nicht funktioniert.

Ja, natürlich brauchen wir Prozesse. Aber doch nicht für alles!

Bevor das falsch verstanden wird: Es gibt ausgezeichnete Gründe für Prozesse.

Eine industrielle Fertigung, standardisierte technische Prüfungen, regulatorische Kontrollen oder automatisierte Rechnungsverarbeitung profitieren enorm von klar definierten Abläufen. Wo Dinge unter vergleichbaren Bedingungen tatsächlich immer wieder gleich passieren, sind Prozesse ein großartiges Werkzeug.

Dort schaffen sie Verlässlichkeit, reduzieren Fehler und ermöglichen Automatisierung.

Aber das ist doch der Punkt!

Je weniger vorhersehbar eine Tätigkeit ist, desto fragwürdiger wird der Versuch, ihren Ablauf vollständig vorzuschreiben.

Und gerade dort, wo Erfahrung, Kreativität, Kommunikation und situative Entscheidungen benötigt werden, versuchen wir häufig besonders aufwendig zu modellieren.

Vielleicht auch, weil ein fertiges BPMN-Diagramm ein wunderbar greifbares Ergebnis ist. Man kann es präsentieren, versionieren, freigeben und anschließend stolz verkünden, dass der Prozess jetzt definiert ist.

Ob dadurch irgendetwas besser geworden ist, steht auf einem anderen Blatt.

Vielleicht sollten wir einfach mal weniger machen

Ich bin inzwischen ziemlich überzeugt davon, dass viele Unternehmen nicht zu wenige Prozesse haben, sondern zu viele.

Und ich glaube auch, dass wir die Fähigkeiten unserer Mitarbeiter systematisch unterschätzen, wenn wir versuchen, jede mögliche Entscheidung im Voraus zu regeln.

Das heißt nicht, dass jeder machen soll, was er will. Es bedeutet, Verantwortung dort zu lassen, wo die Arbeit tatsächlich passiert, und die Ergebnisse vernünftig zu kontrollieren.

Vielleicht sollten wir beim nächsten „Man müsste mal einen Prozess definieren“ einfach ein paar andere Fragen stellen.

Welches konkrete Problem lösen wir damit eigentlich? Wie häufig tritt es auf? Was kostet es uns? Was kostet uns der Prozess selbst, und was wäre das Risiko, wenn wir einfach darauf verzichten?

Und die für mich wichtigste Frage: Könnten wir das Problem nicht lösen, indem wir Menschen die nötigen Informationen, Kompetenzen und Verantwortung geben?

Manchmal ist eine klare Zuständigkeit besser als ein zwanzigseitiges Prozesshandbuch. Manchmal reicht eine einfache Regel. Und manchmal muss man akzeptieren, dass nicht alles vorhersehbar ist.

Ein Unternehmen ist keine BPMN-Engine. Menschen sind keine Prozessinstanzen. Und die Realität hat leider keinen Exklusiv-Gateway, der garantiert alle Eventualitäten abdeckt.

Vielleicht ist es an der Zeit, weniger Arbeitsabläufe zu verwalten und wieder mehr Arbeit zu erledigen.

Aber vermutlich müsste man dafür erst einmal einen Prozess definieren. 😉