Ein Prozessmapping-Workshop bringt die Menschen zusammen, die einen Arbeitsablauf ausführen. Gemeinsam beschreiben sie, was zwischen einem festgelegten Anfang und Ende tatsächlich passiert. Das nützliche Ergebnis ist eine gemeinsame Darstellung des Ist-Prozesses, in der Entscheidungen, Übergaben, Verzögerungen und Ausnahmen sichtbar sind. Verbesserungsvorschläge folgen, nachdem die Beteiligten geprüft haben, ob die Darstellung zur tatsächlichen Arbeit passt.
Ein Workshop kann scheitern und trotzdem ein attraktives Diagramm liefern. Zeigt die Karte nur den gewünschten Prozess, erklärt sie nicht, warum Arbeit stecken bleibt. Beginnen Sie mit einem aktuellen Fall, beziehen Sie die daran beteiligten Personen ein und trennen Sie dokumentierte Fakten von Annahmen.
Die ASQ-Anleitung zu Flussdiagrammen empfiehlt, Grenzen festzulegen, Aktivitäten anzuordnen und das Ergebnis mit den beteiligten Personen durchzugehen. Die folgende Agenda überträgt diese Grundsätze auf einen Teamworkshop. Sie ist ein Vorschlag für die Praxis, keine formale Zertifizierungsmethode.
Wählen Sie Grenzen, die zu einem Termin passen
„Unseren Lieferprozess abbilden“ ist für einen ersten Termin zu umfassend. „Von der Meldung eines Abrechnungsfehlers bis zur Bestätigung der Korrektur“ gibt den Beteiligten einen erkennbaren Anfang und ein Ende. Nennen Sie Auslöser und fertiges Ergebnis bereits in der Einladung.
Wählen Sie einen aktuellen normalen Fall und eine relevante Ausnahme. Der normale Fall zeigt den Hauptpfad; die Ausnahme macht eine Entscheidung oder Schleife sichtbar, die ein aufgeräumtes Diagramm sonst auslassen könnte. Entfernen Sie Kundenkennungen und andere unnötige personenbezogene Angaben aus den gemeinsam verwendeten Belegen.
Laden Sie Menschen ein, die die Arbeit ausführen, einschließlich der Person, die das Endergebnis erhält. Eine Abteilungsleitung kennt vielleicht den vorgesehenen Prozess, während eine Supportfachkraft weiß, welche Tabelle ihn tatsächlich am Laufen hält. Kann eine wichtige Rolle nicht teilnehmen, kennzeichnen Sie diesen Abschnitt als ungeprüft, statt ihn mit Annahmen der Führung auszufüllen.
Eine 75-Minuten-Agenda für Prozessmapping
| Minuten | Arbeit | Ergebnis |
|---|---|---|
| 0–10 | Auslöser, Ende und Beispielfall bestätigen | Abgrenzung |
| 10–25 | Den Fall der Reihe nach rekonstruieren | Tatsächliche Aktivitäten |
| 25–40 | Rollen, Entscheidungen und Übergaben ergänzen | Ist-Prozesskarte |
| 40–50 | Den Fall anhand der Karte durchgehen | Korrekturen und fehlende Verzweigungen |
| 50–65 | Wartezeiten, Nacharbeit und Unsicherheit markieren | Durch Belege gestützte Problemliste |
| 65–75 | Eine Verbesserung zum Testen auswählen | Verantwortung, Messgröße und Prüftermin |
Beschriften Sie Aktivitäten konkret: „Support prüft den Rechnungsdatensatz“ statt „Triage“. Eine Beschriftung sollte erklären, was geschieht, statt nur eine Phase zu benennen. Verwenden Sie einen Pfeil für die Reihenfolge und eine Frage für eine Entscheidung. Eine Prozesskarte braucht keine anspruchsvolle Notation, um fehlende Verantwortung sichtbar zu machen.
Wenn Sie ein spaltenbasiertes Kollaborationsboard verwenden, erfassen Sie dort Schritte und Belege. Übertragen Sie Verbindungen bei Bedarf anschließend in ein Diagrammwerkzeug. Gehen Sie nicht davon aus, dass jedes Board Flussdiagramm-Verbindungen unterstützt. Sie können das gemeinsame Nextretro-Board für Beobachtungen und Entscheidungen im Workshop verwenden, ohne es als spezialisierte Anwendung zur Prozessmodellierung zu behandeln.
Praxisbeispiel: Eine Rechnungskorrektur durchläuft zwei Schleifen
Betrachten wir ein hypothetisches Abonnementunternehmen. Ein Kunde meldet eine falsche Abbuchung. Der Support prüft das Konto, sendet eine Anfrage an die Finanzabteilung, wartet auf Rückfragen und bestätigt schließlich eine Korrektur. Diese Schritte wirken einfach, bis die Beteiligten einen bestimmten Fall rekonstruieren.
Die Finanzabteilung hatte die Anfrage zurückgegeben, weil die ursprüngliche Rechnungsnummer fehlte. Der Support fragte daraufhin den Kunden, öffnete die Anfrage erneut und wartete wieder. Für die zweite Übergabe wurde ein anderer Nachrichtenverlauf verwendet, sodass die prüfende Person die erste Erklärung nicht sah. Der Fall ging ein zweites Mal an den Support zurück.
Die Karte enthält jetzt zwei unterschiedliche Schleifen: fehlende Informationen und zersplitterten Kontext. Das Team verzichtet auf eine pauschale Maßnahme wie „Kommunikation verbessern“. Es testet eine Anfragevorlage, die die Rechnungsreferenz enthält und spätere Rückfragen mit derselben Anfrage zusammenhält.
Das Beispiel ist erfunden, um die Methode zu veranschaulichen. Es belegt nicht, dass eine Vorlage jede Verzögerung in der Abrechnung löst. Das Team müsste weiterhin prüfen, ob bei realen Fällen Genehmigungsbefugnisse, Arbeitslast oder eine andere Einschränkung überwiegen.
Ergänzen Sie Belege, ohne den Workshop zum Audit zu machen
Verwenden Sie diese ergänzende Tabelle neben der Karte:
| Schritt | Beleg | Unsicherheit | Zu klärende Frage |
|---|---|---|---|
| Support bereitet die Anfrage vor | In der Beispielanfrage fehlt die Rechnungsreferenz | Wie oft passiert das? | Eine kleine, klar definierte Stichprobe prüfen |
| Finanzabteilung bittet um Klärung | Antwort mit Zeitstempel | War die Anfrage schon vorher sichtbar? | Verhalten der Warteschlange bestätigen |
| Support reicht erneut ein | Separater Nachrichtenverlauf vorhanden | Ist ein neuer Verlauf erforderlich? | Verantwortliche Person für den Ablauf fragen |
| Kunde erhält Bestätigung | Abschlussnachricht | Entsprach die Korrektur der Erwartung? | Abnahmenachweis prüfen |
Ein Zeitstempel zeigt, wann etwas erfasst wurde, nicht unbedingt, wann jemand handeln konnte. Fragen Sie vor der Berechnung von Wartezeiten, wie das System Ereignisse dokumentiert. Liegen keine verlässlichen Daten vor, kennzeichnen Sie die Verzögerung als Beobachtung, die untersucht werden muss.
Verwenden Sie die Karte nicht, um Beschäftigte zu bewerten. Sie soll die Organisation der Arbeit verständlich machen. Öffentlich zu zählen, wie lange eine namentlich genannte Person eine Anfrage „hatte“, kann Prioritäten und Kapazität ausblenden und ehrliche Beschreibungen von Umwegen verhindern.
Wählen Sie eine Änderung und bewahren Sie den Ausgangszustand
Wählen Sie eine Änderung, die die Anwesenden genehmigen oder einer benannten entscheidungsbefugten Person vorlegen können. Dokumentieren Sie den erwarteten Wirkmechanismus: „Die Rechnungsreferenz sollte Rückfragen reduzieren, bevor die Finanzabteilung eine Anfrage bewerten kann.“ Legen Sie dann fest, was Sie wann prüfen werden.
Bewahren Sie die Ist-Prozesskarte auf, bevor Sie den vorgeschlagenen künftigen Ablauf zeichnen. Sonst kann das Team die Belege verlieren, die die Änderung ausgelöst haben. Gehen Sie nach einem Test den tatsächlichen Ablauf erneut durch. Eine neue Eingabevorlage kann eine Schleife beseitigen und gleichzeitig eine neue Belastung für den Support erzeugen.
Eine Retrospektive eignet sich, um diesen Test mit denselben Personen zu prüfen. Nutzen Sie Retrospektiven-Ideen für ein strukturiertes Reflexionsformat und halten Sie die Prozessbelege mit der Entscheidung verbunden.
Häufige Fragen
Wer sollte an einem Prozessmapping-Workshop teilnehmen?
Beziehen Sie Menschen ein, die die wesentlichen Schritte ausführen, die das Ergebnis erhalten und die Prozessentscheidungen klären können. Halten Sie fehlende Perspektiven sichtbar; der Ablauf einer abwesenden Abteilung darf nicht als überprüft gelten.
Sollten wir zuerst den aktuellen oder den künftigen Prozess abbilden?
Wenn Verbesserung das Ziel ist, bilden Sie zuerst den aktuellen Prozess ab. Prüfen Sie ihn anhand realer Fälle, bevor Sie eine künftige Version entwerfen. Kennzeichnen Sie bei einem wirklich neuen Ablauf die Karte als Vorschlag und testen Sie ihre Annahmen.
Was tun, wenn der Ablauf nicht in einen Termin passt?
Begrenzen Sie die Darstellung auf einen sinnvollen Abschnitt und dokumentieren Sie dessen Eingaben und Ausgaben. Planen Sie für den nächsten Abschnitt einen anschließenden Termin, statt die gesamte Organisation in vage Kästen zu pressen.