Der Prozess-Steckbrief

Nicht nur beim Aufbau einer Prozesslandkarte, sondern immer dann wenn man über Prozesse redet, ist es sehr hilfreich zu beschreiben was eigentlich “der Prozess” ist. Hierfür findet man zum Beispiel das SIPOC-Diagramm aus dem Six Sigma. Im SIPOC-Diagramm werden alle wesentlichen Bestandteile eines Prozesses beschrieben:

S – Supplier (Lieferant
I – Inputs (Einsatzfaktoren)
P – Process (Prozess)
O – Output (Ergebnisse)
C – Customer (Kunde)

Bei Bedarf lässt sich ein solches Diagramm natürlich um den jeweiligen Informationsbedarf erweitern. Einige weitere Informationen könnten sein: Ziele, Applikationen, Rollen, Standorte, KPI, Prüf- & Messverfahren, Stellschrauben für Verbesserungen und vieles mehr. Bei der Erweiterung des SIPOC sollte man darauf achten, dass der komplette Prozess-Steckbrief immer noch lesbar auf eine DIN A4 Seite passt, bzw. sich in eine Präsentation (z.B. mit MS PowerPoint) einbinden lässt.

the_process

Elemente eines Prozesses

Wenn man mehrere Prozesse beschreibt können als Lieferant und Kunde auch die vor- und nach-gelagerten Prozesse erfasst werden. Somit ergibt sich nach und nach über die Steckbriefe ein Netzwerk von Prozessen.

Warum man für Prozesslandkarten kein BPMN verwenden sollte

Die BPMN hat sich als Standard-Notation für die Prozessmodellierung durchgesetzt. Diese erfreuliche Entwicklung führt dazu, dass nun sämtliche BPM Projekte schnell mit BPMN in Verbindung gebracht werden. Doch die BPMN ist kein Allheilmittel und keine Notation für eine Prozesslandkarte oder Process Map oder Process Landscape (wie auch immer Sie eine Übersicht über Unternehmensprozesse nennen möchten). Im Folgenden möchte ich kurz darstellen warum Sie besser keine BPMN für die oberen Ebenen einer Prozesslandkarte verwenden.

Die BPMN wurde entwickelt um die Zusammenhänge einzelner Tätigkeiten in einem Prozess zu beschreiben und nicht für die Zusammenhänge zwischen mehreren Prozessen.

Gut und schön, aber kann man BPMN nicht einfach trotzdem verwenden? Können schon, man muss dann aber akzeptieren, dass es dann schnell zu Missverständnissen und Verwirrung kommt. Warum ist das so?

In einer Prozesslandkarte wechselt zwischen den einzelnen Prozessen schon mal die Multiplizität. Zum Beispiel wird einmal die gesamte Produktion (Summe aller Aufträge) betrachtet und danach nur ein einzelner Auftrag.

Darüber hinaus wechselt auch die Häufigkeit der Ausführung der Prozesse. Die Produktionsplanung wird z.B. einmal im Monat ausgeführt, die Bearbeitung der Kundenaufträge dagegen täglich mehrfach. Die Prozesse stehen aber trotzdem in einer logischen Reihenfolge:

prozesslandkarte1

Eine solche Übersicht mit der BPMN zu modellieren führt zu dem Problem, dass man eigentlich keinen Sequenzfluss benutzt darf. Die Planung führt man einmal im Monat aus, den Einkauf von Rohmaterial stetig, die Kundenaufträge werden für jede Bestellung produziert und der Warenverkauf erfolgt täglich aus der Produktion und aus dem Lager. In der BPMN dürfte man diese Prozesse nicht miteinander verbinden und so darstellen:

prozesslandkarte2 (weiterlesen …)

Sketching at Work – Meetings visuell gestalten

Nicht nur in der Prozessanalyse sondern in fast jedem Meeting welches zur Analyse, Diskussion oder Entscheidungsfindung dient ist es hilfreich den Stand des Gesprächs visuell festzuhalten. Hierdurch erhöht sich nicht nur das Engagement und die Konzentration der Teilnehmer auch die Lösungsfindung wird verbessert und die Zielorientierung der Gruppe wird unterstützt.

Im Buch „Sketching at Work“ stellen Martin J. Eppler und Roland Pfister 35 verschiedene Visualisierungs-Tools vor mit denen man fast jedes Meeting anreichern kann. Der Schwerpunkt der Tools liegt im Bereich Planung und Analyse. Aber auch die Themen Verkauf, Diskussionen und Kommunikation werden angesprochen. Nach einer kurzen Einführung in das Thema der visuellen Unterstützung von Meetings werden dem Leser einige grundsätzliche Tipps und Regeln zur Hand gegeben.

Im Anschluss folgt die Vorstellung der 35 Tools. Jedes von Ihnen wird strukturiert beschrieben und an einem Beispiel erläutert. Hierbei werden zu jedem Tool erklärt wann, warum, wie, was und für wen ein Tool genutzt werden kann. Zusätzlich werden die Tools kategorisiert und auch in Bezug gesetzt um z.B. eine Problemanalyse strukturiert mit mehreren Tools aufzubauen.

Zum Schluss wird vorgestellt wie sich verschiedene Tools kombinieren lassen und wie man eigene Tools entwickeln kann.

Einige der vorgestellten Tools sind eigentlich jedem bekannt (z.B. ein Mind Map) andere wiederum sind vielleicht nur noch versierten Moderatoren geläufig. Schön ist, dass man nicht lange lesen oder sich einarbeiten muss um loszulegen. Theoretisch kann man ad-hoc im Meeting im Buch nachschlagen und sofort beginnen ein dort beschriebenes Diagramm zu zeichnen und mit den Meeting-Teilnehmern zu bearbeiten. Das Buch ist ein gutes Werk für den Werkzeugkoffer eines Moderators, birgt aber keinen Wow-Effekt für geübte Moderatoren. Ich würde als Zielgruppe des Buches Moderatoren von Workshops fürs Management nennen. Aber auch für strategische Workshops in größeren Runden und erste Analysen können die vorgestellten Tools nutzbringend eingesetzt werden.  Für operative Meetings, bei denen es um konkrete Detailarbeit geht müsste man einige der Tools ein wenig abwandeln. Bei dem Preis kann man aber nichts falsch machen, denn selbst wenn nur ein Meeting damit erfolgreicher läuft macht sich das Buch schnell bezahlt.

Warum man für Prozesslandkarten kein BPMN verwenden sollte

Die BPMN hat sich als Standard-Notation für die Prozessmodellierung durchgesetzt. Diese erfreuliche Entwicklung führt dazu, dass nun sämtliche BPM Projekte schnell mit BPMN in Verbindung gebracht werden. Doch die BPMN ist kein Allheilmittel und keine Notation für eine Prozesslandkarte oder Process Map oder Process Landscape (wie auch immer Sie eine Übersicht über Unternehmensprozesse nennen möchten). Im Folgenden möchte ich kurz darstellen warum Sie besser keine BPMN für die oberen Ebenen einer Prozesslandkarte verwenden.

Die BPMN wurde entwickelt um die Zusammenhänge einzelner Tätigkeiten in einem Prozess zu beschreiben und nicht für die Zusammenhänge zwischen mehreren Prozessen.

Gut und schön, aber kann man BPMN nicht einfach trotzdem verwenden? Können schon, man muss dann aber akzeptieren, dass es dann schnell zu Missverständnissen und Verwirrung kommt. Warum ist das so? (weiterlesen …)

Das perfekte Prozessmodell

Immer wieder stößt man in Projekten zur Prozessmodellierung auf einen Punkt an dem man entscheiden muss, ob das erstellte Prozessmodell „richtig“ ist. Die große Frage hierbei ist: Was bedeutet „richtig“?

Erst einmal gilt: Das perfekte Prozessmodell gibt es nicht!

A process is better than no process
A good process is better than a bad process
Even a good process can still be improved

Michael Hammer

Einer der bekanntesten Ansätze sind die „Grundsätze ordnungsmäßiger Modellierung“ (GOM). Diese vermitteln als methodischer Ordnungsrahmen wie Modelle vernünftig aufgebaut werden können. Die Inhalte sind:

  • Richtigkeit
  • Relevanz
  • Wirtschaftlichkeit
  • Klarheit
  • Vergleichbarkeit
  • Systematischer Aufbau

Die einzelnen Grundsätze kann man an diversen Stellen im Internet nachlesen. Ich möchte hier versuchen diese Grundsätze mit konkreten Praxisbeispielen und Anwendungstipps anzureichern. (weiterlesen …)