Toolmarktmonitor 2014

Die BPM&O hat eine Marktstudie zu BPM-Tools veröffentlicht. In dieser Marktstudie werden 22 Tools aus D-A-CH vorgestellt und verglichen. Die Schwerpunkte der dargestellten Softwareprodukte liegen in den Bereichen Design und Analyse von Geschäftsprozessen.

Jeder, der sich einen aktuellen Überblick verschaffen möchte oder über die Einführung eines neuen Tools nachdenkt kann hier nützliche Informationen finden.

http://bit.ly/Toolmarktmonitor

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.

Aufwandsschätzung für die Prozessmodellierung

In den letzten Tagen habe ich mich mit dem Thema Aufwandsschätzung für die Prozessmodellierung befasst. Sowohl für den Kunden als auch für die eigene Ressourcenplanung im Team ist es wichtig zu wissen wie hoch der Aufwand für die Prozessmodellierung in einem Projekt ist.

Warum fällt es mir so schwer abzuschätzen wie lange man für die Erstellung einer Prozessdokumentation oder zum Entwickeln von verbesserten Prozessen benötigt? In der Regel erhalte ich Anfragen zur Prozessdokumentation oder -optimierung folgender Natur:

Dokumentieren oder optimieren Sie den Prozess für

- den Einkaufsbereich (Abteilung)

- unser CRM-System (Applikation)

- den Standort Hintertupfingen (Standort)

- die Chefsekretärin (Personen/Rollen)

- die Warenlieferung (Business Objekte & Dokumente)

Ja, die Anfragen zeugen nicht von einer durchgängigen Prozessorientierung im Unternehmen ;-) . Aber auf dem Weg zur stärkeren Prozessorientierung fallen schon mal solche Anfragen ab.

Sämtliche Schätzverfahren basieren darauf, dass man zumindest ein paar Anforderungen kennt. In der IT sind dies häufig Use Cases, Requirements etc. Mit bekannten Anforderungen kann man mit verschiedenen Verfahren eine Aufwandsschätzung erstellen (z.B. CoCoMo, Function Point). Aber auf Basis der oben aufgeführten Anfragen lässt sich wirklich keine zuverlässige Aussage zum Aufwand treffen. Das bedeutet man benötigt für eine Abschätzung weitere Informationen über die Aufwandstreiber.

Was sind also die Aufwandstreiber in der Prozessmodellierung?

Variante 1: Scope bestimmen und Aufwand schätzen

Um abzuschätzen wie hoch der Aufwand ist sind mindestens folgende Informationen zu berücksichtigen

  1. Anzahl und jeweilige Komplexität der zu modellierenden Prozesse
  2. Menge der Prozessvarianten (z.B. der gleiche Prozess ist für Produkt A und B zu 30% unterschiedlich)
  3. Anzahl der beteiligten Rollen in den Prozessen

Zusätzlich gibt es diverse Einflussgrößen die sich positiv oder negativ auf den Gesamtaufwand auswirken. Zum Beispiel:

  • Prozesswissen der Beteiligten
  • Motivation des Teams
  • Methodenwissen
  • Stand der aktuellen Dokumentation

Zu guter letzte ist der Umfang und die Art der Dokumentation ein weiter Faktor

  • Detailtiefe der zu erstellenden Dokumentation
  • Art und Weise der Dokumentation (Print, Web etc. ist abhängig vom eingesetzten Modellierungstool)
  • Umfang der Dokumentation (As-Is Prozesse, To-Be Prozesse, Problemanalyse etc.)

Um diese Faktoren zu bewerten empfehle ich einen Analyseworkshop von 1,5h bis 2h mit den Projektsponsoren. In diesem Workshop werden sämtliche notwendigen Informationen gesammelt und der Scope der Prozessmodellierung festgelegt. Danach kann man eine Bewertung des Aufwands durchführen. Leider ist auch hierfür kein “Standard” verfügbar und man muss sich selbst ein Gerüst zur Bewertung und Gewichtung der Aufwände erstellen, z.B. angelehnt an die Function Point Methode.

Eine pauschale Aussage über den Aufwand zur Prozessmodellierung kann und möchte ich nicht treffen, da der Aufwand für die Dokumentation der Prozesse abhängig von Unternehmensstandards, den eingesetzten Tools und den Kunden stark variiert. Es ist empfehlenswert sich einen Referenzwert für den Aufwand pro Prozess zu erarbeiten. Zum Beispiel: Die Dokumentation eines Standard-Prozesses dauert x Stunden. Ein Standard Prozess ist “mittel-komplex”, umfasst 12 dokumentierten Aktivitäten und hat 3 Prozessbeteiligte. Basierend hierauf kann man per Multiplikator den Aufwand für einfache und komplexe Prozesse ableiten.

Mit diesen Daten kann man nun folgende Berechnung ausführen:

  1. Jeden Prozess mit seinem Komplexitätsfaktor und Standardaufwand multiplizieren
  2. Summe aller Prozesse bilden
  3. Summe der Prozesse mit Faktor für die Einflussgrößen multiplizieren
  4. Multiplikator für Umfang und Art der Dokumentation anwenden

Damit hätte man eine erste Bewertung des Aufwands. Anhand von Daten abgelaufener Projekte kann man die Faktoren justieren und so die Schätzung optimieren.

Variante 2: Budget steht fest

Immer wieder kommt es vor, dass noch vor Beginn des Projektes klar ist wie viel Zeit einzelne Bereiche in die Prozessmodellierung investieren möchten.

Hierbei haben sich grob folgende Schätzregel bewährt: Für die saubere Dokumentation der Prozesse benötigt ein Modellierer nach dem Workshop nochmal ca. die doppelte Dauer des Workshops. Diese Regel passt ungefähr, da ein Modellierer nicht ohne neuen Input weiter modellieren kann. Und eine sauberer Nachbereitung und die Erstellung von Dokumenten zum Review ca. doppelt so lange dauert wie das Meeting. Eine Ausnahme ist natürlich wenn ein Modellierer Informationsquellen nutzen kann, ohne dass der Kunde Zeit investiert (z.B. Dokumentationen, Referenzwerke, Branchenstandards etc.)

Hier die Formel:

[Aufwand für Modellierer] = [Dauer der Workshops] + [Dauer der Workshops]*2

=> [Aufwand für Modellierer] = 3 * [Dauer der Workshops]

Beispiel:

Der Fachbereich steht für Workshops und Interviews über einen Zeitraum von 4 Wochen wöchentlich für 2h zur Verfügung.

Aufwand des Projektes: 4 Wochen * 2h = 8h Aufwand für den Kunden (ggf. multipliziert mit Anzahl der Teilnehmer)

8h * 3 = 24h Aufwand für den Modellierer

Sofern man sich dem Projektaufwand über diese Methode nähert ist es ratsam einen agilen Ansatz für die Prozessdokumentation zu wählen (Top-Down und iterativ). Da man weder die Anzahl der Prozesse, noch die weiteren Einflussgrößen kennt kann man auch nicht genau sagen wie detailliert und umfangreich das Ergebnis der Prozessdokumentation ist. Abhilfe schafft hier ggf. Variante 3.

Variante 3: Mix aus Variante 1 & 2

Wenn ein Auftraggeber genauer wissen möchte welche Ergebnisse erwartet werden dürfen, dann kann man mit dem Ergebnis aus Variante 2 und einer kurzen Analyse der Einflussgrößen und Faktoren die Berechnung aus Variante 1 umkehren und eine Aussage darüber treffen wie viele Prozesse beschrieben werden können oder wie umfangreich die Dokumentation wird.

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 …)

SONOXOplus® Process Modeler testen und 5.000 Euro gewinnen

sonoxoplus_box_1 Speziell in der Prozess- und Organisationsanalyse sollten kooperatives Denken und Handeln als Maxime gelten. Wer sich diesen Grundsatz annimmt steht mit dem Kunden auf einer Ebene.

Eine prozessorientierte Organisationsanalyse ist keine einmalige und kurzfristige Bewältigung des technologischen Wandels. Dahinter steht vielmehr ein stetiger und für den Kunden tiefer greifender Veränderungsprozess. Dieser Veränderungsprozess beeinflusst sich selbst und wird mit neuen Erkenntnissen und neuen Anforderungen immer wieder auf ein neues Niveau gehoben. Um einen solchen Prozess zu begleiten muss man als Prozess- und Organisationsberater mit dem Kunden auf derselben Stufe stehen und die Perspektive des Kunden einnehmen können.

Um die Ergebnisse gemeinsam zu dokumentieren und analysieren zu können ist es sinnvoll zusammen im Team an einem gemeinsamen Modell zu arbeiten. Für Elemente der Aufbau- (Stellenplan) und der Ablauforganisation (Prozesslandkarte) bietet der SONOXOplus® Process Modeler die „Teilen“-Funktion. Durch eine komfortable Web-Plattform lassen sich gemeinsam professionelle Inhalte erarbeiten und teilen. Ob als komplettes Prozessmodell, als öffentliche Prozessbibliothek oder als private Prozessschrittsammlung – die Granularität des zu teilenden Inhalts kann frei definiert werden.

landscape_1

Ziel dieser neuen flexiblen Plattform ist es eine inhaltlich homogenen Community zusammenzuführen um in der Analyse mit dem Kunden interagieren zu können. Damit erweitert man den klassischen Marketingansatzes, der sich oftmals auf Beobachten und Agieren beschränkt.

SONOXO stellt mit dem SONOXOplus® Process Modeler eine webbasierte Plattform bereit, auf der sich Kunden mit Beratern und Prozessexperten treffen und in einem kontinuierlichen Austauschen stehend kollaborativ Wissen erzeugen und visualisieren.

Durch die Erstellung von Prozesslandkarten, hierarchischen Prozessmodellen und Organisationsmodellen lassen sich Prozesse und Verantwortlichkeiten schnell und einfach beschreiben. Durch zusätzliche Features zur Analyse der Prozesse können Optimierungspotentiale identifiziert und gehoben werden.

Wer einmal den neuen SONOXOplus® Process Modeler testen möchte hat ab sofort die Möglichkeit dazu. Die Firma SONOXO veranstaltet vom 1.11.2012 bis zum 31.11.2012 einen Wettbewerb unter dem Motto: „Wer entwirft ein elegantes Prozessmodell?“

Ausgeführt wird der Wettbewerb im Netz durch Einsatz des SONOXOplus® Process Modelers. Ausgelobt werden 5.000 EUR für das beste Prozessmodell. Um an dem Wettbewerb teilzunehmen kann man sich auf der Webseite www.sonoxoplus.com registrieren.