Prozessaufnahme, Prozessanalyse, Prozessmodellierung, BPMN – seit mindestens zwei Jahrzehnten kreiseln diese Begriffe durch die Verwaltungsmodernisierungsdiskussionsmaschine und richten dort – nun, was richten sie an?
Auf jeden Fall scheinen sie Geschäftigkeit zu fördern. Ein Vertreter eines Bistums erzählt mir: „In den vergangenen drei Jahren haben wir fast 400 Prozesse aufgenommen.“ Auch ein Landrat meldet Erfolg: „Jeder Fachbereich hat inzwischen mindestens einen seiner Kernprozesse beschrieben und ist nun gefordert, die Prozesslandkarte Schritt für Schritt auszubauen.“
Aber lohnt der Erfolg den Aufwand? Was ist der praktische Nutzen? Dazu möchte ich aus praktischen Projekterfahrungen ein paar Überlegungen vorstellen.
Erfahrungen und Vorüberlegung
Ich stelle zwei Thesen zur Diskussion (und Feedback, inclusive Gegenbeispiele, würde mich freuen):
- Prozessaufnahmen spielen eine große Rolle in öffentlichen Verwaltungen, meinem Eindruck nach vor allem in Kommunal- und Hochschulverwaltungen. Das heißt, es gibt viele Organisationsabteilungen, die den Auftrag haben (oder sich selbst erteilten), Prozesse möglichst umfassend zu dokumentieren. Dafür spricht auch die reichhaltige Literatur und das umfangreiche Seminar- und Beratungsangebot, z. B. bei der KGSt.
- Ein großer Teil der Ergebnisse führt zu keinen praktischen Schlussfolgerungen. Es sei denn, man würde das Erreichen der Zahl 400 oder den „Ausbau der Prozesslandkarte“ (siehe Zitate oben) schon an sich unter „Nutzen“ verbuchen.
Ich habe einige E-Akten-Projekte in Verwaltungen begleitet, bei denen mir der Projektleiter zu Beginn stolz eine Ordnerreihe im Regal zeigte: „Und hier sind unsere Prozessbeschreibungen“ – aber sie waren fünf Jahre oder älter. Und nichts damit passiert. „Prozessbeschreibungen sind Schrankware“, sagte mal ein Seniorberater zu mir.
Diese Thesen mal vorausgesetzt – was könnte sie erklären? Vermutlich gibt es nicht „den einen“ Grund, sondern eine Vielzahl. Ich möchte mich hier auf einen Aspekt fokussieren – die Visualisierungsmethode selbst. Konkret die Frage: „Erlaubt die Prozessdarstellung mittels Flussdiagrammen nach BPMN es den Betrachtern wirklich, ein lebendiges Bild zu gewinnen? Und: Schlägt sie die Brücke zu Verbesserungsansätzen, also erkennt man schnell, wo ‚etwas klemmt‘, oder tut man das eher nicht?“
Prozessaufnahme in einem e-Rechnungsprojekt
Was bewirkt ein Flussdiagramm im Betrachter bzw. in einem Projektteam, das damit arbeiten soll? Das will ich an einem konkreten Beispiel illustrieren.
Eine Verwaltung möchte die Verarbeitung ihrer Eingangsrechnungen digitalisieren. Es handelt es sich um einen kommunalen Dienstleister in einem der norddeutschen Bundesländer, eine Körperschaft öffentlichen Rechts. Nennen wir sie hier einfach KDLZ (Kommunales Dienstleistungszentrum).
Ein externer Berater wird beauftragt, den Ist-Prozess aufzunehmen und einen Soll-Prozess zu modellieren. Dazu moderiert er einen zweitägigen Workshops unter Einbeziehung künftiger Anwender:innen aus dem Einkauf und von Vertreter:innen der Poststelle – bei der schon jetzt alle Papier-Rechnungen eingehen und die auch das Funktionspostfach invoice@kdlz-kueste.de verwaltet.
Der Berater (Wirtschaftsinformatiker mit Ausrichtung Business Analytics) steuert die Prozessaufnahme aktiv: Er führt quasi ein Dauerinterview, notiert Antworten der Teilnehmer:innen auf den Whiteboards an der Wand, zeichnet Verbindungslinien, wischt sie wieder weg und fügt neue Informationen ein.
Der Berater stellt immer wieder Fragen und auch das schon Erarbeitete in Frage. er hat den aktiven Teil. Er strukturiert. Die Teilnehmenden sind eher in der passiven Rolle; sie antworten so gut sie können.
Und sie können es – das muss man leider sagen! – bisweilen nicht sehr gut. Zum Beispiel die einfache Frage: „Wer zeichnet denn die Eingangsrechnung sachlich richtig?“ führt zu einem verschlungenen Netz von Alternativen. Das Wischschwämmchen des Beraters ist fast mehr in Aktion als sein Boardmarker.
Es stellt sich nämlich heraus: es gibt mindestens sechs, vielleicht zehn verschiedene Varianten innerhalb des KDLZ:
- In der Regel ist der Antragsteller der Beschaffung, der sog. „Bedarfsanmelder“, auch der „sachliche Feststeller“.
- Aber ab einer Wertgrenze über 5.000 € geht es erstmal an seinen Vorgesetzten.
- Und wenn es sich beim beschafften Gut um IT-Hardware handelt, ist auf jeden Fall die IT zuständig, die Richtigkeit der Lieferung zu bestätigen – nicht der Bedarfsanamelder (weil dem ja vielleicht das Fachwissen fehlt).
- Und wenn es sich um zu magazinierende Ware handelt, gibt es für jedes konkrete Warenlager einen Prüfbeauftragten, weil in einem Arbeitsgang mit der Rechnungsprüfung die Aktualisierung des Magazinbestandes erfolgen soll.
- usw.
Man hat den Eindruck: Die beteiligten Kolleg:innen aus Einkauf und Poststelle treffen diese Entscheidung „an wen leite ich die Rechnung zur sachlichen Feststellung weiter?“ nicht anhand voll bewusster Überlegungen (also eines Regelkatalogs im Kopf), sondern „aus dem Bauch“. Deshalb müssen sie aus dem Bauchgefühl quasi die Regeln erstmal herausdestillieren. Das ist mühsam, und immer wieder wird eine Regel vergessen. Und ihre Korrektur wird dann später mit einem „ach so, und dann noch was“ eingeleitet – was, nachdem es ein paar Mal vorgekommen ist, zu Gelächter in der Runde führt.
Die Regeln, nach denen der sachliche Feststeller bestimmt wird, haben sich als sehr kompliziert herausgestellt. Sie sehen aus wie ein Garnknäuel oder wie ein Gordischer Knoten. Man hat den Eindruck, es handelt sich um ein Gemisch aus durchaus sinnvollen Festlegungen und aus Sonderstandards, die irgendwann mal von Führungskräften irgendwelcher Silos eingefordert wurden.
Das Ergebnis und seine Wirkung
Nach dem Workshop erstellt der Berater ein professionelles Flussdiagramm in BPMN. Es ist einen guten Quadratmeter groß und wird von ihm in mehrere pdf’s in Kleinschrift aufgeteilt. Den Gordischen Knoten, den ich geschildert habe, hat er in ein einziges Kästchen „sachlichen Feststeller herausfinden“ gepackt, das jetzt wie eine Blackbox wirkt. Bei der Modellierung des Sollprozesses soll dann entschieden werden, was damit passiert.
Bei der Vorstellung im Abschlussworkshop ist keine wirklich motivierte Stimmung spürbar. Die Teilnehmer:innen sitzen im Kreis und wirken eher ratlos. Klar, wenn die Rechnungen statt per Papierumlauf künftig per digitalem Workflow durch KDLZ wandern, wird das etwas weniger Arbeit machen und man wird – Verkürzung der Durchlaufzweit – vielleicht Chancen haben, Skonto abziehen zu können. Aber sonst?
Die wichtigste Verbesserungsidee, die im Raum steht und die (auch wieder ein „Bauchgefühl“) eine höhere Effizienz verspricht, wäre die sachliche Rechnungsprüfung. Die Zahl der Varianten reduzieren, vor allem aber die Anzahl der Beteiligten in bestimmten Fällen (also Vorgesetzter und Bedarfsanmelder oder IT und Bedarfsanmelder usw.). Aber zur Klärung der Fragen „Ist das wirklich notwendig? Können wir da nicht etwas straffen?“ bräuchte man die entsprechenden Fachbereiche mit am Tisch. Und das wäre wahnsinnig aufwendig. Und die Arbeitsgruppe hat auch gar kein Mandat dafür.
Die Stimmung wird zunehmend gedämpfter. Die Workshops haben verwaltungsseitig (bei sechs Beteiligten) zwölf Arbeitstage erfordert, plus 3,5 Beratertage. Und herausgekommen ist wenig wirklich Begeisterndes.
Erfahrungen und Fragen
Im späteren Projektverlauf zeigte sich noch eine weitere Lücke im so erzeugten Flussdiagramm.
Und zwar bezog sie sich auf die sachliche Prüfung selbst, hier dargestellt als Verzweigung „Lieferung = Bestellung? ja/nein“. Dieser Schritt wurde im Workshop überhaupt nicht problematisiert, stellt aber in der Praxis oft einen vermeidbaren Aufwand dar. Das läuft so: der sachliche Feststeller kriegt die Rechnung auf den Tisch. Seine Bedarfsanmeldung ist drei Monate her. Jetzt soll er testieren, dass die Rechnung seiner Anmeldung entspricht. Ja, Himmelherrgott – wo ist denn diese v… Bedarfsanmeldung? Habe ich sie in der Wiedervorlage? Oder habe ich eine Kopie auf dem Laufwerk abgelegt?
Langer Rede kurzer Sinn: eine vermeidbare Suche geht los. Vermeidbar weil:
Würde
- bei der Bedarfsanmeldung eine eindeutige Bestellnummer erzeugt,
- und das Bedarfs-Dokument mit dieser Nummer getaggt,
- und dem Lieferanten diese Bestellnummer mitgeteilt, damit der sie
- auf der Rechnung vermerkt
könne der „sachliche Feststeller“ mit einer Sucheingabe dieser Nummer sofort seine Bestellung finden.
Warum ist in den langen Workshops dieser Umstand überhaupt nicht zur Sprache gekommen? Weil der externe Berater in seinen Interviews immer nur die Frage gestellt hat „Und was machen Sie dann?“ und niemals bei einem Punkt verweilt ist und gefragt hat „Und wie machen Sie das?“ Die einzelnen Aktivitäten – die „Kästchen“ des Flussdiagramms – erscheinen immer als unproblematisch.
Die BPM ist narrativ strukturiert. Sie schildert Abläufe von einer Aktivität zur nächsten und einem Zuständigen zum nächsten. Die Arbeit selbst wird nicht in ihrer konkreten Ausprägung (aufstehen, suchen …), sondern als Input-Output-Schema (eingehende und ausgehende Dokumente) beschrieben.
Die Flussdiagramme, die man so erzeugt, bleiben deshalb merkwürdig unwirklich. Sie bewegen sich auf großer Flughöhe- auch wenn sie sehr unübersichtlich und kompliziert wirken. Das kommt aber nur von den vielen Verzweigungen aufgrund von Ja-Nein-Entscheidungen. Jede Verzweigung hat das Zeug, einen eigenen Teilfluss zu erzeugen und die Größe des Diagramms zu verdoppeln. So führen relativ wenige Entscheidungen zu einer Verkomplizierung der Darstellung, die aber keinem Gewinn an Konkretion entspricht.
Und nur ganz selten wird von einem messbaren Nutzen gesprochen. In einem einzigen Beispiel habe ich eine Zielstellung gefunden, die Durchlaufzeit von derzeit zwei Wochen auf drei Tage zu verkürzen und damit in den Genuss von Skonto zu kommen. Aber auch hier war kein Mengengerüst angegeben (Anzahl der Rechnungen, Durchschnittsbetrag) und dem Aufwand (Arbeitstage des Projektteams, Beraterhonorar, Softwarekosten) gegenübergestellt. Ich habe mal für mich eine solche Rechnung exemplarisch vorgenommen – und die ergab ein niederschmetterndes Ergebnis.
Iterativ-inkrementelle Umsetzung – verbaut!
Das ganze Flussdiagramm steuert natürlich auf die Abbildung in einer Software hin. Die ganze Übersetzung der situativen Handlungsweisen der Anwender:innen in regelbasierte Ja-Nein-Entscheidungen dient ja keinem anderen Zweck.
Damit ist das Ergebnis aber auch festgelegt. In manchen Publikationen vor allem von kommunaler Seite kann man lesen, den Sollablauf werde man nun „agil“ implementieren. Ja wie denn das? Agilität geht davon aus, dass die Ergebnisse noch nicht bis ins Detail festgelegt sind, sondern im Verlauf der Umsetzung erst richtig entwickelt werden. Aber bei den Flussdiagrammen steht schon der Software-Lieferant Gewehr bei Fuß und wartet nur auf den Auftrag einer Implementierung des Flussdiagramms – ohne Einmischung von Anwenderseite, versteht sich.
Warum sind Flussdiagramme trotzdem so beliebt? Und was wären Alternativen?
Fangen wir mit der ersten Frage an. Warum will die Führung eines Bistums die vollständige Beschreibung von 600 Prozessen, die das Organisationsreferat identifiziert hat, und ist stolz auf die Erreichung der Landmarke „400“? Was verbindet der Landrat mit einer „ausgebauten Prozesslandkarte“? Also im Unterschied zu meinem Beispiel auch außerhalb aller konkreten Optimierungsprojekte?
Ich habe die Vermutung (natürlich reine Spekulation), dass es etwas zu tun hat mit dem Wunsch, „es soll Ordnung herrschen“. Und das hat etwas mit Verwaltungskultur zu tun. Es geht, glaube ich, nicht um Kontrolle – also der Landrat will nicht wissen, wer in welchem Prozess was macht. Er will auch nicht die Einhaltung der beschriebenen Prozesse überwachen und Abweichungen sanktionieren. Er möchte das gute Gefühl haben, dass Chaos in seiner Verwaltung keinen Platz hat. So wie man privat den Vorsatz fasst, jetzt mal endlich den Dachboden aufzuräumen – ohne dass dahinter eine konkrete Nutzenvorstellung stecken würde.
Was wären alternative Methoden einer Prozessanalyse? Das wären aus dem agilen Methodenkoffer das User Story Mapping, auch Customer oder User Journey. Und dann die situative Störungsanalyse. Die wollen wir demnächst mal vorstellen.
Agile Verwaltung 
Ich sehe praktische Probleme mit Flussdiagrammen. Das erste liegt in der Perspektive: Es ist die eines Werkstücks, das auf vorbestimmten Wegen eine Fabrik durchläuft (oder in der Ausschusskiste landet, wenn etwas schiefgeht, aber das bleibt im Modell meist unerwähnt). Keine Rolle spielt die Perspektive der daran Arbeitenden. Ist es sinnvoll, dass das Werkzeug bei mir vorbeikommt? Kann ich meine Aufgabe effizient erledigen? Welche Arbeitslast entsteht bei mir und wie verträgt sie sich mit anderen Aufgaben? Welchem Ziel dient meine Tätigkeit an dieser Stelle überhaupt? Ist es sinnvoll, dass ich dafür einzelne Vorgänge bearbeite oder könnte ich meine Ziele besser auf einer Aggregation erreichen? Welche Anordnungen in einer Reihenfolge repräsentieren Abhängigkeiten und welche wurden willkürlich festgelegt, weil es die Notation erfordert? Solche Fragen gehen unter – oder werden gar zum Sakrileg, wenn eine Organisation den Ablaufplan zum Prozess™ geheiligt hat, welcher der Einheitlichkeit wegen bitte als Vorgabe einzuhalten sei.
Das zweite Problem sind Regelungsartefakte. Mit der Festlegung auf Flussdiagramme zwingt man sich die Illusion auf, die Ablaufplanung sei das wichtigste und eine enge Kopplung (vgl. https://en.wikipedia.org/wiki/Normal_Accidents) sei erstrebenswert. Dies nährt den Irrtum, es sei sehr wichtig, dass Vorgänge dann wie beschrieben abliefen. Auch verbaut es den Weg zu Prozessdesigns, die wie in der agilen Softwareentwicklung auf lose gekoppelte, teilautonom agierende Rollen mit definierten Zielen und Aufgaben setzen. Statt belanglose Einzelheiten der Selbstorganisation zu überlassen und Optimierungen zuzulassen, legt man sie fest, und sei es willkürlich – während wichtige Fragen (z.B.: Warum gibt es diesen Prozess überhaupt?) unbeantwortet hinter dem detailreichen Diagramm verschwinden.
Das dritte Problem ist die Notation selbst, die dazu neigt, Banalitäten umständlich auszudrücken, wo Text, Aufzählungen und Tabellen das geeignetere Medium wären. Aus Visual Thinking for Design von Colin Ware habe ich mir das Zitat notiert:
“Flowcharts were a very expensive mistake. Hundreds of thousands of dollars were spent documenting computer programs in this way, only for the results to languish on shelves never to be consulted. It turned out that it was easier to read a pseudo-code description, or even the program logic itself, than the flowchart. Flowcharts now stand as a reminder of the limitations of visual representation. There are some things that words do much better.”
So manches Element ist dann auch noch komplett unnötig, weil nur der Notation geschuldet (z.B.„Fax empfangen“ als Pseudotätigkeit, weil der Vorgang halt irgendwie weitergehen muss, nachdem es gesendet wurde).
LikeLike
Ein paar weitere Gedanken und Erfahrungen zum Beitrag von Wolf „Prozessbeschreibungen: Die Grenzen des traditionellen Verfahrens“
These 2 zu den wenig verwertbaren Ergebnissen entspricht zumindest rückblickend auch meinen Erfahrungen. Doch es gibt mittlerweile auch ein Umdenken in vielen Institutionen – nämlich weg von diesem klassischen methodischen Ansatz hin zu einer prozessorientierten Steuerung bzw. zur Prozessorientierung als Führungs- und Steuerungsinstrument.
Mit diesem Fokus bietet Prozessmanagement viel mehr als hier im Artikel beschrieben.
So geht es in innovativen Workshops zur Prozessoptimierung neben den Prozessschritten auch sehr stark um eine Rollenklärung bzw. ein Rollenverständnis. Denn in nur seltenen Fällen agiert jemand in einem Prozess als „Abteilung“ – wie es aber leider noch oft in Prozessbeschreibungen abgebildet wird – sondern in einer bestimmten Rolle. Und in dieser Rolle mit den dazu definierten Aufgaben, aber auch Anforderungen und Verantwortungen interagiert er*sie mit den anderen am Prozess beteiligten Rollen. Ganz wichtig hier neben dem Verständnis der jeweils eigenen Rolle, auch die anderen zu verstehen.
Ein modelliertes BPMN-Diagramm steht letztlich ganz am Schluss und hat dann seinen Mehrwert z.B. als Basis für jede Digitalisierung – aber auch das nur, wenn Schritte mit In- und Output-Daten sowie dem WIE eine Aufgabe erledigt (und dann auch digital abgebildet) werden soll, genau beschrieben sind. Hilfreich sind solche Prozessbeschreibungen natürlich auch für neue Mitarbeiter*innen zur Einarbeitung – als Wissenstool.
Dabei ist die obige Aussage, dass BPMN nie die Arbeit selbst beschreibt, nicht ganz richtig. Moderne Prozessmanagementtools haben selbstverständlich für jede Task im Prozess Beschreibungsfelder, in denen je nach Bedarf das WIE mehr oder weniger ausführlich beschrieben werden und z.B. auch wichtige Dokumente angefügt werden können. Insofern wird in den Workshops zur Prozesserhebung und im besten Fall zur Prozessoptimierung mit den Beteiligten genau das WIE erhoben und selbstverständlich werden Optimierungen diskutiert. Im Falle einer gewünschten Prozessdigitalisierung bedarf es dabei eines besonders hohen Detailgrades der Beschreibung. Das ist mitunter mühsam, aber ohne einen optimierten SOLL-Prozess gibt es keine effektive digitale Variante. Und wenn ich hier „Beteiligte“ schreibe, meine ich Vertreter*innen derer, die letztlich den Prozess umsetzen. Bei einer guten Prozessmanagementorganisation gibt es dafür die sog. Prozessverantwortlichen, die immer auch aus den Fachbereichen mit entsprechender Expertise kommen. Diese Fachexpert*innen gehören von Beginn an mit an den Tisch. Wer sonst wüsste besser, an welchen Stellen optimiert werden muss, kann oder sollte? Und je nach Entscheidungsausmaß ist mind. punktuell immer auch der*die Prozesseigner*in einzubeziehen.
Doch neben dieser methodischen Arbeit ist oft eben viel spannender sind die Diskussionen in den Workshops rund um das Outputverständnis (=Was ist ein für den Kunden gelungenes Prozessergebnis) und um die Rollenklarheit bei den Prozessbeteiligten. Das an sich ist schon ein immenser Mehrwert!
Die hier gestellte Frage nach alternativen Methoden zur Prozessanalyse stellt sich m.E. nach so nicht. Denn es handelt sich hier nicht um Alternativen, sondern wir können und sollten a) beides tun und b) agile Methoden zur Prozessanalyse nutzen.
In diesem Sinne – mit einem organisationsgestaltenden Verständnis von Prozessmanagement kann man durchaus begeistern!
LikeLike
Salut Wolf, danke für Deinen Blog. Du sprichst da etwas Wahres an, das Aufnehmen von Prozessen ist eine Disziplin, die man nicht beherrscht, weil man die BPMN mit all Ihren Elementen anzuwenden weiß, sondern es kommt sehr stark auf den Kontext an, also für welchen Zweck bzw. für welchen Personenkreis werden die Diagramme erstellt. Ich habe inzwischen Modelle gesehen, die syntaktisch und semantisch absolut korrekt sind und trotzdem verfehlen sie ihre Wirkung, nämlich den schnellen Wissenstransfer. Dennoch glaube ich, dass die Prozessaufnahme als Flussdiagramm (und ich meine insbesondere die Aufnahme mit BPMN) zu Unrecht in Verruf geraten ist.
In den letzten 2 – 3 Jahrzehnten wurden ohne Ende Prozesse dokumentiert, ein wenig nutzbringendes Unterfangen. Aber wenn wir uns ansehen, wie wir bestimmte Services, also Dienste, die der Bürger oder der Kunde konsumiert, erstellen, dann kann einen erst recht das nackte Grausen ereilen. Meistens gibt es in der IT eine monolithische Anwendung, die sämtliche Prozesse – und eben auch die, die sich an den Verbraucher wenden – beherrscht. Entwickelt und gepflegt werden sie durch ausgewiesene IT-Experten, die eigentlichen Fachexperten sind stets außen vor und haben kaum Mitspracherecht in der Gestaltung des Dienstes. Was wäre denn, wenn wir die monolithischen Systeme (und das soll durchaus bedrohlich klingen) sukzessive durch agilere Software-Module ersetzen? Ich denke besonders an Process Engines, die BPMN verstehen. D.h. ich entwickle den Service als BPMN-Modell und zwar kollaborativ zwischen IT- und Fachexperten. Die Process Engine steuert dann den Ablauf. Ein wenig kennt man das von sog. Workflow Engines, die voll automatisch ohne menschliche Interaktion den Prozess abwickeln. Genau darum geht es aber nicht. Wir werden immer mehr Prozesse haben, deren Verlauf nicht von vornherein festgelegt ist, sondern durch den Input von Experten definiert werden. Natürlich soll oder kann man bei der Entwicklung eines neuen Dienstes auf kreativitätsfördernde Methoden zurückgreifen – User Story Cards, etc. -, aber wenn es dann um die Umsetzung geht, brauche ich eine gemeinsame Sprache zwischen IT und Prozessexperten – und ganz nebenbei muss der Service schnell und einfach anpassbar sein!
Mein Fazit: BPMN (eine andere Notation mit ähnlichen Qualitäten ist mir nicht bekannt) zu beherrschen, scheint mir eine Grundqualifikation zu sein – und ganz nebenbei hätte die produzierte Schrankware doch noch einen Nutzen generiert.
LikeLike