Erfolgreiche Prozessanalyse: So geht’s!

Montag, 14.10.2024

Prozessanalyse

Wenn man die Automatisierung von Prozessen in einem Unternehmen vorantreiben möchte, ist die Analyse bestehender Prozesse (IST-Prozesse) und ihrer Schwachstellen der erste wichtige Schritt. Dabei erleben wir in unserer Praxis immer wieder, dass die Prozesse nicht immer allen verantwortlichen oder beteiligten Stakeholdern in Gänze bekannt sind und eine gute Prozessdokumentation fehlt. In diesem Fall macht es Sinn, dass du einmal alle Wissensträger an einen Tisch bringst und den Prozess mit ihnen zunächst sauber erhebst und dokumentierst! Sobald die Prozessdokumentation vorhanden ist, kannst du den Prozess mit den Teilnehmenden auf Schwachstellen hin analysieren. Das IST-Prozessmodell und die Liste der Schwachstellen können dann als Ausgangspunkt für die Konzeption eines mittels Process-Engine automatisierten Prozesses dienen.

Typischerweise startest du mit einem Workshop in die Prozessanalyse. Mit diesem Artikel möchten wir dir einen praktischen Leitfaden an die Hand geben, wie du diesen Workshop (und die darauf folgenden) zur Prozesserhebung und -analyse durchführst, welche Methoden du sinnvoll einsetzen kannst und welche Informationen relevant sind.

Vorbereitung

Als erstes steht die Frage nach dem Format im Raum! Du solltest dir Gedanken machen, ob du den Workshop in einem Konferenzraum vor Ort oder online als Videokonferenz stattfinden lassen möchtest. Wir empfehlen klar ein Treffen vor Ort für den ersten Termin - das schweißt euch als Gruppe besser zusammen! In ersterem Fall solltest du sicherstellen, dass der Raum entsprechend ausgestattet ist. Hilfreich für die Prozessmodellierung sind Beamer, Metaplanwände, eine große leere Wand oder ein Whiteboard sowie (selbstklebende) Moderationskarten und Stifte. Im Internet findest du auch magnetische, beschriftbare BPMN 2.0 Symbole - diese können dann entsprechend an einem magnetischen Whiteboard verwendet werden. Falls die Teilnehmenden nur wenig oder keine Erfahrung mit der BPMN 2.0 haben, kannst du Ihnen als Hilfestellung auch eine (ausgedruckte) Übersicht der BPMN 2.0 Symbolpalette mitbringen (z.B. die der Berliner BPM-Offensive).

Die Dauer des Workshops richtet sich nach der Komplexität und Anzahl der Prozesse sowie der Anzahl an Teilnehmenden. Die Erhebung und Analyse von komplexen Prozessen ist in der Regel nicht nach einem Termin abgeschlossen; daher sollte der Workshop nur als Startpunkt betrachtet werden. Dafür reichen in der Regel vier Stunden bis zwei Tage. Wenn du die Komplexität schon im Vorfeld abschätzen kannst, macht es ggf. Sinn, gleich eine ganze Workshop-Reihe bzw. einen Regeltermin anzusetzen. So kann das Prozessmodell in einem iterativen Vorgehen nach und nach verfeinert werden und die Teilnehmenden haben dadurch die Möglichkeit, die Zeit zwischen den Terminen zur Klärung offener Fragen zu nutzen.

Ankommen

Zu Beginn solltest du die Teilnehmenden willkommen heißen und die Agenda vorstellen. Falls sich noch nicht alle untereinander kennen, kann euch eine kurze Vorstellungsrunde und Abfrage der Erwartungen helfen, das Eis zu brechen! Du kannst z.B. die Teilnehmenden reihum bitten, folgende drei Fragen zu beantworten:

  • Wer bist du?
  • In welcher Rolle hast du mit dem zu analysierenden Prozess zu tun?
  • Was sind deine Erwartungshaltungen an den heutigen Tag?

Als Sprache zur Prozessmodellierung hat sich die Business Process Modeling Language and Notation (BPMN 2.0) etabliert. Obwohl die BPMN in ihrer Grundstruktur recht intuitiv ist, weist sie eine Vielzahl von Elementen auf, die nicht selbsterklärend sind. Falls den Teilnehmenden die BPMN 2.0 noch nicht geläufig ist, kannst du sie ihnen kurz vorstellen. Wir empfehlen, dass du dich hier auf die wichtigsten Elemente beschränkst:

  • Pools und Swimlanes
  • Sequenzflüsse
  • Tasks (User, Manual, Service, Business Rule und Send Message Task)
  • Events (Start, Intermediate, End und Receive Message Event)
  • Exclusive und Parallel Gateways

Basic Elements BPMNDie wichtigsten BPMN 2.0 Elemente im Überblick

Alle weiteren Elemente kannst du immer noch im weiteren Verlauf des Workshops erklären, wenn du sie benötigst.

Den Prozess auf hoher Flughöhe erfassen

Zum Einstieg solltest du mit den Teilnehmenden die wichtigsten Rahmeninformationen zu dem Prozess klären und dokumentieren. Dazu kannst du einen Prozesssteckbrief in tabellarischer Form erstellen. Der Steckbrief muss nicht unbedingt fertig werden bevor du zur Modellierung übergehst, viele Dinge fallen einem oft erst später auf oder sind noch unklar. Mit folgenden Informationen kannst du den Steckbrief befüllen:

  • Prozessname - Wie heißt der Prozess? Wir empfehlen die Nutzung von Substantivierungen wie z.B. "Eingangsverarbeitung".
  • Prozessverantwortlicher bzw. Process Owner - Wer sorgt dafür, dass der Prozess in der Organisation gelebt wird und ist Ansprechpartner für strategische Fragen?
  • Prozessmanager - Wer kümmert sich um den reibungslosen (operativen) Ablauf des Prozesses?
  • Prozessbeteiligte - Welche Personen oder Organisationen steuern etwas zum Prozess bei?
  • Beschreibung - Wie läuft der Prozess ab (ganz grob in Stichpunkten)?
  • Prozessziele - Welche Ziele sollen mit dem Prozess erreicht werden?
  • Auslöser - Was ist das auslösende Startereignis für den Prozess?
  • Vorgelagerte Prozesse - Welche Prozesse gehen dem zu analysierenden Prozess voraus? Idealerweise mit Verknüpfung zu bestehenden Prozesssteckbriefen um eine einfache Navigation in der Prozesslandkarte zu ermöglichen.
  • Lieferanten/Schnittstellen - Wer oder was liefert etwas für den Prozess?
  • Input - Was wird im Prozess als Eingabe benötigt?
  • Ende - Wann ist das Ende des Prozesses erreicht? Welches Ereignis muss eintreten oder welches Ergebnis erreicht sein, damit der Prozess beendet ist?
  • Nachgelagerte Prozesse - Welche Prozesse folgen auf den zu analysierenden Prozess? Idealerweise mit Verknüpfung zu bestehenden Prozesssteckbriefen
  • Kunden - Wer erhält ein Ergebnis aus dem Prozess?
  • Ergebnis/Output - Was ist die Ausgabe aus dem Prozess?
  • Übersichtsprozessmodell - Eine Kompakte Darstellung des Prozesses mit der BPMN, manchmal auch "Strategisches Prozessmodell" genannt. Ziel dieses Prozessmodells ist es, dass auch jemand aus dem Management ohne tiefergehende BPMN-Kenntnisse eine grobe Idee hat, wie der Ablauf des Prozesses grob aussieht. Es sollte daher nur eine sehr kleine Teilmenge der in der BPMN verfügbaren Elemente verwendet werden. Ausnahmen und Sonderfälle sollten hier außen vor gelassen werden. Im "Praxishandbuch BPMN" gibt Bernd Rücker konkrete Hinweise zur Erstellung eines solchen Prozessmodells. Wenn den Teilnehmenden diese Abstraktion nicht sofort gelingt kann es durchaus Sinn ergeben, dieses Modell erst zu ergänzen, sobald das operative Prozessmodell mehr Details enthält. Manchen Menschen fällt es leichter, eine abstrakte Darstellung aus den Details zu erarbeiten als anders herum. Man kann auch immer mal wieder raus und rein "zoomen", also zwischen den Abstraktionsniveaus hin und her springen.

Unserer Erfahrung nach empfiehlt es sich, Prozesssteckbriefe in einem Wiki (z.B. Confluence) an einer zentralen Stelle zu hinterlegen, damit alle Beteiligten den aktuellen Stand zu jeder Zeit abrufen können.

Prozesssteckbrief

Sollte unser BPMN Modeler Enterprise für Confluence als Plugin in deiner Confluence-Instanz installiert sein, verfügst du nicht nur über ein leistungsstarkes Tool zur Prozessmodellierung sondern auch über eine Confluence-Seitenvorlage für Prozesssteckbriefe. So kannst du die Prozessmodelle in den Prozesssteckbrief einbetten. Als Übersicht über alle wichtigen Prozesse kannst du eine Prozesslandkarte erstellen, in der du wiederum den Prozesssteckbrief verlinkst.

Analyse des operativen Ist-Prozesses

Im nächsten Schritt geht es darum, den Ablauf des Prozesses gemeinsam so detailliert wie möglich mittels der BPMN zu modellieren. Dabei kannst du den Prozess entweder gemeinsam mit den Teilnehmenden an einer (Metaplan-)Wand mit selbstklebenden Moderationskarten oder an einem Whiteboard modellieren. Möchtet ihr lieber ein BPMN-Tool nutzen, kannst du einfach ein Modellierungstool wie den BPMN Modeler Enterprise für Confluence öffnen und per Beamer and die Wand projizieren. Das hat den Vorteil, dass du gleich eine fertige BPMN-Datei hast und diese nicht im Nachgang noch erstellen musst. In einem Remote-Setting kann jemand von euch einfach den Bildschirm für das Modellieren freigegeben. Dabei sollte jemand mit Modellierungserfahrung die Führung übernehmen. Wichtig ist vor allem, dass ihr alle das Prozessmodell gut sehen könnt, damit ein gemeinsames Verständnis geschaffen wird und ihr für alle weiteren Diskussionen eine solide Grundlage habt.

Nun fangt ihr ganz am Anfang beim Start Event an und arbeitet euch dann Schritt für Schritt zum End-Event vor (manchmal hilft es auch das Ende des Prozesses in Anknüpfung an den Prozesssteckbrief schon zu Beginn zu modellieren). Damit ihr euch nicht sofort in Ausnahmen und Sonderfällen verstrickt, solltet ihr den Fokus erstmal auf den sogenannten Happy Path legen. Damit ist der typische Pfad durch das Modell gemeint, den der Prozess in der überwiegenden Zahl der Prozessausführungen nimmt. Für jeden Prozessschritt solltest du klären, welche Informationen bzw. Daten grob benötigt werden und wer oder was den jeweiligen Prozessschritt ausführt. Die Akteure könnt ihr mittels Swimlanes oder im Falle von Systemen mittels zugeklappten Pools und Nachrichtenflüssen visualisieren. Bei einer sehr großen Anzahl an Akteuren oder Systemen reicht es, diese per Annotation an das jeweilige BPMN-Elemente zu schreiben.

Es ist wichtig, dass du dich immer wieder rückversicherst, ob alle Teilnehmenden mit dem aktuellen Modellierungsstand einverstanden sind. Wir haben es bei Kunden immer wieder erlebt, dass Teilnehmende unterschiedliche Ansichten hatten, wie ein Prozess abläuft oder abzulaufen hat; verschiedene Menschen haben unterschiedliche Perspektiven darauf - ein:e Expert:in für Sonderfälle hat z.B. einen anderen Blick auf den Prozess als Sachbearbeiter:innen die den Standardfall bearbeiten. Hier solltest du auf eine Harmonisierung hinwirken - versuche, zunächst den kleinsten gemeinsamen Nenner zu finden, auf den sich alle Beteiligten festlegen können. Sollte das nicht möglich sein, liegen vielleicht auch ganz unterschiedliche Prozesse bzw. Prozessvarianten vor. Sobald der harmonisierte Happy Path fertig modelliert ist, kannst du für jeden Prozessschritt nach Sonderfällen und Ausnahmen fragen. Diese können dann z.B. mittels Gateways, Boundary Events oder Business Rule Tasks modelliert werden. Eventuell könnte hier auch die Verwendung der Decision Model and Notation (DMN) sinnvoll sein, um Geschäftsregeln für Entscheidungen im Prozess formal eindeutig (und ggf. automatisierbar) zu modellieren. Das hat den Vorteil, dass man Diskussionen über Entscheidungslogik von denen zum Prozessfluss trennen kann - das schafft Klarheit und Fokus.

Eine weitere Möglichkeit um an Einsichten zu gelangen ist es, die Teilnehmenden einen Prozessdurchlauf mal live vorführen und erklären zu lassen, was sie genau tun (z.B. in dem sie ihren Bildschirm teilen). Es ist allerdings wichtig, bei der Modellierung immer eine gewisse Abstraktionsebene zu wahren, damit das Prozessmodell verständlich bleibt und nicht zu groß wird. Einzelne Klickpfade oder Eingaben in Bildschirmmasken zu modellieren ist nicht zielführend. Hinterfrage immer die Zweckmäßigkeit der Modellierung und überlege, für welche Aspekte eine Modellierung sinnvoll ist und welche nicht. Es gilt der Leitsatz "So viel wie nötig, so wenig wie möglich".

Schwachstellen und Potenziale ermitteln

Im nächsten Schritt können die Schwachstellen des Prozesses identifiziert werden. Falls es belastbare Zahlen gibt, ist das von Vorteil - interessante Kennzahlen sind z.B.

  • Durchschnittliche Durchlaufzeiten
  • Durchschnittliche Ausführungsdauer von einzelnen Prozessschritten
  • Anzahl von Prozessausführungen (z.B. pro Monat)

Meist können die Teilnehmenden auf Nachfrage bereits eine Vielzahl an Symptomen benennen, daher solltest du diese einfach erfragen. Die Symptome können mit Kärtchen auf einem Whiteboard, einer Metaplanwand oder in einer digitalen Whiteboard Software festgehalten werden. Im nächsten Schritt solltet ihr dann gemeinsam eine Root-Cause-Analyse durchführen, sprich ihr solltet die zugrundeliegenden Ursachen dieser Symptome ermitteln. Die Teilnehmenden kannst du mit wiederholtem Nachfragen nach dem "warum" dorthin führen. Eine mögliche Ursache für zu lange Durchlaufzeiten könnten z.B. händisch durchgeführte Datenübertragungen von einer Bildschirmmaske in eine andere sein. Die Ursachen könnt ihr gemeinsam am Whiteboard/der Metaplanwand erfassen, hier bietet sich eine baumartige Visualisierung an. Habt ihr die die Ursachen vollumfänglich ermittelt, ist auch die nötige Grundlage geschaffen, um in die Konzeption eines optimierten bzw. (teil-)automatisierten SOLL-Prozesses einzusteigen.

Wie geht es weiter?

Je nach Komplexität des Prozesses kann die Zeit knapp werden und ihr müsst weitere Termine abstimmen. Ansonsten kannst du noch offene Details auch in Einzelgesprächen mit Teilnehmenden im Nachgang klären und ggf. das IST-Prozessmodell iterativ verfeinern. Halte offene Aufgaben und Klärungspunkte an zentraler Stelle nach und fordere auch ein zeitliches Commitment seitens der Teilnehmer ein (die drei W's: wer macht was bis wann?). Die erarbeiteten Ergebnisse des Workshop solltest du allen Teilnehmenden zur Verfügung stellen (Links zu Confluence-Seiten teilen oder Steckbrief und BPMN-Datei per E-Mail an alle versenden). Darüber hinaus ist es hilfreich, einen schnellen Kommunikationskanal etablieren (z.B. über einen Gruppenchat), um mit den Teilnehmenden weiterhin im Austausch zu bleiben und den aktuellen Status der Bearbeitung offener To-Dos zu kommunizieren. Wie eingangs beschrieben ist es oft sinnvoll, einen Regeltermin zu etablieren. Sollten die Teilnehmenden noch offene Fragen haben, können diese beantwortet werden. Zum Abschluss kannst du dir auch Feedback einholen, insbesondere in Bezug auf die zu Beginn des Workshops geäußerte Erwartungshaltung. Habt ihr den IST-Prozess und seine Schwachstellen dann vollumfänglich erfasst, steht der Konzeption eines automatisierten SOLL-Prozesses nichts mehr im Wege - das kann auch Teil dieses Workshops sein bzw. in Folgeterminen angegangen werden. Dabei gehst du prinzipiell genauso vor wie bei der Modellierung des operativen IST-Prozesses.

Ihr benötigt Unterstützung bei der Prozessanalyse? Wir helfen euch gerne - nicht nur bei der Prozessanalyse, sondern in allen Phasen des BPM-Zyklus! Schaut gerne in unser BPM Leistungsspektrum.

 


Haben wir Ihr Interesse geweckt? Melden Sie sich gerne bei uns.

Jetzt kontaktieren


zurück zur Blogübersicht

Diese Beiträge könnten Sie ebenfalls interessieren

Keinen Beitrag verpassen – viadee Blog abonnieren

Jetzt Blog abonnieren!

Kommentare

Gero Zimmer

Gero Zimmer

Gero Zimmer ist Berater für Agile Methoden und Prozessautomatisierung. Während er als Team Coach Teams bei agilen Veränderungsprozessen begleitet, unterstützt er als Integrationsarchitekt Kunden bei der Integration von Prozesssteuerungsplattformen in heterogenen Anwendungslandschaften sowie der Entwicklung von Prozessanwendungen.

Gero Zimmer bei LinkedIn