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.Grundsatz der Richtigkeit

Entscheidet man sich für eine standardisierte Modellierungsnotation kann die Syntax der Modelle einfach überprüft werden indem man diese gegen die Spezifikation der Notation validiert (z.B. mit BPMN 2.0). Bei der Semantik wird es schon schwieriger. Hierfür müssen die Fachexperten die Prozessmodelle überprüfen und absegnen. Das Problem hierbei ist leider häufig, das die Fachexperten sich nicht konkret mit der Semantik der der Modellierungsnotation auskennen oder beschäftigen wollen. Daher sollte die Komplexität der gewählten Modellierungsnotation den Fachexperten nicht überfordern, so dass bei einer Abnahme der Modelle sichergestellt werden kann, dass die Modelle wirklich semantisch richtig sind. (siehe auch Grundsatz der Klarheit). Bei der BPMN empfiehlt es sich mit nur einem Bruchteil der zur Verfügung stehenden Elemente zu Arbeiten. Zusätzlich kann es hilfreich sein, die Modelle zu animieren. Damit kann man die verschiedenen Prozessvarianten als Film ablaufen lassen und der Fachexperte wird dabei unterstützt die verschiedenen alternativen Prozessabläufe richtig zu erkennen und bewerten zu können.

Hier ein Beispiel das mit Visual Paradigm Agilian erstellt worden ist:

Zusätzlich ist es hilfreich, wenn die Kunden direkt in den Prozessmodellen Anmerkungen hinterlassen können, z.B. für Reviews oder zur Anreicherung mit Informationen.

Grundsatz der Klarheit

Es ist eigentlich selbstverständlich, dass die Modelle nur einen Nutzen erbringen können wenn diese vom Kunden verstanden werden. Daher ist es u.a. wichtig zu versuchen möglichst einheitlich zu Modellieren. Dies macht die Modelle einfacher lesbar. Hierfür können interne Modellierungsrichtlinien aufgestellt werden. Modellierungsrichtlinien können iterativ entstehen. Denn durch die Erstellung erster Modelle erkennt man worauf es dem Kunden ankommt. Es ist auch wichtig darauf zu achten, dass mit den internen Richtlinien keine Überregulierung stattfindet. Denn diese würde die Modellierer behindern und die Modelle würden nicht schnell genug fertig gestellt. Hierbei hilft es häufig sich auf einen Modellierungsstil zu einigen. Ein pragmatischer Ansatz wäre es, z.B. ein Buch wie „BPMN Method & Style, Bruce Silver“ oder „BPMN 2.0, Thomas Allweyer“ oder „Praxishandbuch BPMN, Jakob Freund et al.“) als Grundlage zu wählen und immer dann, wenn in dem Buch verschiedene Modellierungsvarianten beschrieben werden sich auch eine als Standard zu einigen. Hierbei ist zu beachten, dass der allgemeine Grundsatz zur Klarheit vorrangig behandelt werden sollte, d.h. man soll schon mal von der internen Richtlinie abweichen dürfen um ein klareres Modell zu verwirklichen.

Grundsatz der Relevanz

Und damit ist man schon bei einem wesentlichen Punkt: Der Kunde muss mit dem Modellen arbeiten können. Damit wäre zu klären:

  • Welche Ziele verfolgt der Kunde? (z.B. Kostenanalyse, IT-Realisierung, Organisationsveränderung)
  • Wie arbeitet der Kunde mit den erstellten Modellen? (Online, Client-Tool, Print, Präsentation, Selbststudium)
  • Wie viel Zeit steht für die Modellierung zur Verfügung?
  • Was ist der Hauptfokus der Modellierung? (z.B. Kommunikation, Warenfluss, Informationsfluss, Geldfluss, IT-Systeme, Abteilungen, Business Objekte)

Problematisch wird es hier, wenn es mehrere Kunden mit verschiedenen Ansprüchen an das Modell gibt. Ein wenig Abhilfe kann hier der Grundsatz des systemischen Aufbaus schaffen.

Grundsatz des systemischen Aufbaus

Neben der grundsätzlichen Entscheidung verschiedene Sichten (Funktionssicht, Datensicht, Organisationssicht) in verschiedene Modelle mit ggf. verschiedenen Notationen zu beschreiben kann auch jede Sicht für sich durch einen weiteren systemischen Aufbau strukturiert werden.

Hierbei hilft es verschiedenen Ebenen mit verschiedenen Abstraktionsgraden/Detailtiefen zu definieren. Dies hilft dabei sowohl eine Übersicht der Modelle für das Management zu erstellen als auch die Details für die Fachexperten zur Verfügung zu stellen. Darüber hinaus unterstützt ein Ebenenmodell dabei die einzelnen modellierten Bereiche sauber gegeneinander abzugrenzen. Durch eine sinnvolle Verknüpfung der verschiedenen Modelle kann ein sichtübergreifendes und konsistentes Gesamtmodell entwickelt werden.

Folgende Funktionen von Modellierungstools erweisen sich in der Praxis als nützlich:

  • Repository (am besten ein zentrales für alle Projekte)
  • Glossar (ein zentrales Glossar kann ggf. ein Repository ersetzen)
  • Gemeinsames Modellieren an Modellen
    • Direkt online
    • Über ein CVS (Achtung: Konfliktlösung beim „Commiten“ kann sehr komplex werden)
  • Versionierung
  • Reporting (z.B. Auswertung welche Prozesse werden durch Abteilung A unterstützt)
  • Möglichkeit verschieden Sichten zu einem Diagramm zu erstellen (z.B. einen Pool mal als Whitebox-Pool anzeigen und diesen bei Bedarf als Blackbox-Pool zeigen um Details auszublenden)
  • automatische Aggregation von Details auf höhere Ebenen
  • verschiedenen Export Möglichkeiten
    • MS Word (Inkl. komplett anpassbarem Layout)
    • PDF (Inkl. komplett anpassbarem Layout)
    • Web (Inkl. komplett anpassbarem Layout, komfortable Navigation, Druckmöglichkeit, Suchfunktion)

Grundsatz der Vergleichbarkeit

Grade der Vergleich von Ist- und Soll-Modellen ist interessant für den Vergleich. Hierfür sollte ein Modellierungstool die Möglichkeit bieten die Modelle am besten Visuell zu vergleichen und Unterschiede aufzuzeigen. Hierbei ist es für die Tools nicht einfach die Unterschiede festzustellen. Dass Mapping zwischen dem Ist- und Soll-Modell ist nicht immer einfach oder überhaupt machbar. Denn es können sich sämtliche Informationen im Diagramm ändern (z.B. Beschriftung der Elemente, Position und Format der Elemente, Neue Elemente kommen hinzu, Elemente werden gelöscht). Hier hilft es sich ggf. manuell in den Ist- und Soll-Modellen die Änderungen zu markieren, z.B. neue und geänderte Elemente farblich oder mit Stereotypen im Soll-Modell kennzeichnen. Oder Elemente im Ist-Modell kennzeichnen die im Soll-Modell geändert oder gelöscht werden sollen. Daher ist es auch Sinnvoll die visuelle Darstellung im Diagramm möglichst nicht komplett um zu gestalteten, so dass man neue und gelöschte Elemente im Soll-Modell schnell identifizieren kann. Übertrieben gesagt hilft es, wenn Sie das Ist- und Soll-Modell auf Folie ausdrucken, übereinander legen und die Änderungen einfach erkennen können.

Grundsatz der Wirtschaftlichkeit

Natürlich ist das Kosten-Nutzen Verhältnis auch bei der Modellierung zu beachten. Doch der Nutzen von Modellen ist nicht immer einfach messbar. Wenn man zu wenig Zeit in die Modelle investiert kann es sein, dass diese nicht vollständig genug sind um einen spürbaren Nutzen zu stiften. Anders herum kann man unendlich viel Zeit in die Modelle investieren ohne den Nutzen spürbar zu steigern. Hierbei ist ganz Elementar der Grundsatz der Relevanz zu beachten. Wenn das Ziel erreicht ist kann man beruhigt mit der Modellierung aufhören.

nutzen

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