Tipps zum Business Process Management – Teil 3

Im dritten Teil meine Tipp-Serie zum Business Prozess Management möchte ich auf ein paar wesentliche Punkte zum Thema Prozessmodellierung und Prozessdesign eingehen. Da in jedem BPM-Projekt mindestens ein Prozessmodell den Grundstein des Projektes bildet ist es enorm wichtig, dass die Qualität der Prozessmodelle dem auch gerecht wird.

Tipp 1-3 sind im ersten Teil und Tipp 4 – 7 sind im zweiten Teil dieser Serie zu finden

8. In Ebenen arbeiten

ebenen Leider sieht man viel zu oft Prozessmodelle, die verschiedenste Ebenen miteinander vermischen. Dies führt dann dazu, dass die Modelle komplexer und schwer lesbar werden. Sowohl die IT-Abteilung als auch die Business-Abteilungen können das Modell nicht gebrauchen. Und das Management versteht gar nicht worum es überhaupt grundsätzlich geht.

Um diese Probleme zu lösen ist es sinnvoll die Modelle verschiedenen Modellebenen zuzuordnen. Das klingt einfacher als es ist. Selbst gestandene Process Analysten erwischen sich immer wieder mal selber dabei in eine falsche Ebene abzurutschen. Welches Ebenenmodell man nun verwenden möchte ist einem selbst überlassen, viel wichtiger ist es die Ebenen klar gegeneinander abzugrenzen. Nur dadurch kann gewährleistet werden, dass jeder Process Analyst die Erstellung eines Modells für eine Ebene gewährleisten kann. Grundsätzlich sind in der Regel drei Ebenen interessant:

  1. Übersichtsebene
  2. Businessebene
  3. Technische Ebene

In der Übersichtsebene wird der Prozess an sich im Groben dargestellt, hiermit ist keine Prozesslandkarte gemeint. Diese Darstellung sollte sehr kompakt sein und die wichtigsten Informationen beinhalten. Das Übersichtsmodell dadurch zwar nicht vollständig, man erkennt aber auf einen Blick womit sich der Prozess befasst.

Die Businessebene beinhaltet alle fachlichen Aktivitäten und Abläufe. Hier wird es häufig schon schwer die IT auszublenden. Häufig verbinden auch Mitarbeiter der Fachseite bestimmte Arbeitsschritte mit einem IT-System. Diese Verbindung sollte möglichst aufgelöst werden. Wichtig sind hier alle fachlichen Aktivitäten die einen Mehrwert im Prozess generieren. Hier ist zum einen Erfahrung wichtig, aber auch Disziplin, damit man immer wieder hinterfragt ob man für die richtige Ebene modelliert. Anhand der Prozessbeschreibung aus der fachlichen Ebene soll ein Mitarbeiter die Prozesse abarbeiten können.

Die technische Ebene verbindet dann die Businessebene mit den IT-Systemen. Hierbei müssen ggf. einige Aktivitäten ergänzt werden, die aus Businesssicht nicht unbedingt relevant waren (z.B. Persitierung, Logins, Logfiles, etc). Die verschiedenen fachlichen Aktivitäten werden hier auf IT-Services gemappt und technische Details werden hinterlegt. Wichtig ist es diese Ebene nicht zu stark von der Businessebene abweichen zu lassen, im Idealfall sind die Prozessmodelle sogar identisch und nur die „Hintergrundinformationen“ ändern sich. Dies erleichtert die Abstimmung zwischen IT und Business erheblich und reduziert so den Aufwand für Änderungen am Prozess.

9. KISS

kiss In meinem Artikel „Das Kanninchen Problem“ habe ich dargestellt wie schnell ein doch simpler Prozess schnell anfängt zu wuchern und undurchschaubar wird. Daher sollte man immer versuchen die Darstellung möglichst einfach und kurz zu halten. Die bedeutet nicht dass es einfach ist ein einfaches Modell zu erstellen! Goethe sagte eins: „Entschuldige die Länge des Briefes, ich hatte keine Zeit, mich kurz zu fassen.“ Dies trifft genauso auch auf die Prozessmodellierung zu. Ein Prozess soweit zu vereinfachen, dass alle notwendigen Aktivitäten und Ereignisse vorhanden sind, der Prozess aber dennoch einfach und übersichtlich bleibt benötigt Zeit und Erfahrung. Je weniger Erfahrung man hat, desto mehr Zeit wird man benötigen.

10. Happy Path

happy_path Der Happy Path ist doch meistens das Ziel. FYP heißt hier der Key Performance Indicator: First Yield Pass. Der FYP beschreibt den prozentualen Anteil aller Prozessinstanzen, die im ersten Durchlauf erfolgreich abgearbeitet werden konnten. Also alle Prozessinstanzen, die nur den Happy Path benötigt haben. Ein häufiges Ziel ist es den FYP zu maximieren. Daher ist es auch sinnvoll den Happy Path als erstes zu modellieren und nicht mit den Ausnahmen zu beginnen. Doch leider gibt Ausnahmen die zwingend im Prozessmodell vorhanden sein müssen. Dennoch ist zu prüfen ob man die Ausnahmen nicht ggf. durch vorbeugende Maßnahmen sogar komplett ausschließen kann. Dadurch wird der FYP gesteigert und das Prozessmodell wird übersichtlicher.

11. Wenig Logik im Modell

logik

Wieso soll möglichst wenig Logik ins Prozessmodell? Hintergrund dieser Aussage ist der Zweck eines Prozessmodells. Das Modell soll beschreiben wann welche Aktivitäten auszuführen sind. Es hat also einen starken Fokus auf die Aktivitäten. Entscheidungen werden häufig in komplexen Formeln oder in Entscheidungsbäumen dargestellt. Diese kann man natürlich mit den Boardmitteln des BPMN auch in ein Prozessmodell abbilden, doch dies würde die Prozessmodelle enorm auf blähen und unübersichtlich machen. Die Logik, die sich meistens in den Geschäftsregeln (Business Rules) wiederfinden, sollte daher ausgelagert werden. Hierfür eigenen sich Business Rules Engines. Denn eine Änderung bestehender Geschäftsregeln, z.B. ob ein Kunde ab 50€ oder ab 100€ keine Versandkosten zahlt ändert nicht den Prozessverlauf an sich. Würde diese Logik in die Prozessmodelle aufgenommen werden müsste man bei jeder Regeländerung das Prozessmodell ändern, obwohl die Änderungen keine Auswirkung auf den eigentlichen Ablauf des Prozesses haben. Durch die Auslagerung der Logik spart man also nicht nur Zeit bei der Änderung der Regeln, sonder die Prozessmodelle bleiben auch übersichtlicher.

Happy Path

Der Happy Path ist doch meistens das Ziel. FYP heißt hier der Key Performance Indicator: First Yield Pass. Der FYP beschreibt den prozentualen Anteil aller Prozessinstanzen, die im ersten Durchlauf erfolgreich abgearbeitet werden konnten. Also alle Prozessinstanzen, die nur den Happy Path benötigt haben. Ein häufiges Ziel ist es den FYP zu maximieren. Daher ist es auch sinnvoll den Happy Path als erstes zu modellieren und nicht mit den Ausnahmen zu beginnen. Doch es gibt Ausnahmen die zwingend im Prozessmodell vorhanden sein müssen. Dennoch ist zu prüfen ob man die Ausnahmen nicht ggf. durch vorbeugende Maßnahmen sogar komplett ausschließen kann. Dadurch wird der FYP gesteigert und das Prozessmodell wird übersichtlicher.

Commentary

Leave a response »

Leave a comment, a trackback from your own site or subscribe to an RSS feed for this entry. Trackback URL for this entry Comments feed for this entry

Leave a response

Leave a URL

Preview