BPMN vs. EPK & Co. oder auf was es wirklich ankommt

Transkript

1 BPMN vs. EPK & Co. oder auf was es wirklich ankommt Sebastian Adam, Norman Riegel 15. Mai 2012, St. Augustin

2 Die Fraunhofer-Gesellschaft e.v. Benannt nach: Rolle der FraunhoferGesellschaft: Größe: Forschungsvolumen: 2 Joseph von Fraunhofer ( ) ein erfolgreicher Forscher, Erfinder und Unternehmer Deutschlands führende Organisation für angewandte Forschung und Technologietransfer 60 Institute mit über Mitarbeitern 1,8 Milliarden, aufgeteilt in 1/3 Grundfinanzierung (Bund) 1/3 Industrieprojekte 1/3 öffentliche Projekte

3 Das Fraunhofer IESE Kaiserslautern Führendes Institut für Software Engineering Gegründet Mitarbeiter Mission Vorbereitung neuer Methoden und Technologien für den Einsatz in der Industrie Technologietransfer (Auswahl, Anpassung, Pilotierung, Coaching) Unabhängige Bewertung und Verbesserung von Software-intensiven Systemen 3

4 Wir Norman Riegel Sebastian Adam Studium der Wirtschaftsinformatik (Uni Mannheim) Studium der Angewandten Informatik (TU Kaiserslautern) Seit 2007 am Fraunhofer IESE Seit 2005 am Fraunhofer IESE Tätig als wissenschaftlicher Mitarbeiter, Projektmanager und Berater für Requirements Engineering und Geschäftsprozessmanagement Tätig als wissenschaftlicher Mitarbeiter, Projektmanager, Teamleiter und Berater für Requirements Engineering und Geschäftsprozessmanagement Dissertation zum Thema Modellbasierte Leitung zahlreicher Beratungsprojekte Priorisierung in geschäftsprozessgetriebenem Dissertation zum Thema Requirements Engineering Wiederverwendungsorientierte Anforderungserhebung 4

5 Geschäftsprozessnotationen Use Case ADEPT BPMN eepk UML Activity Diagram Petri-Netz Programmablaufplan 5

6 Die gepriesenen Vorteile von BPMN Hohe Ausdrucksmächtigkeit viele spezielle Elemente Ausführbare Modelle (Durchgängigkeit) Standardisierte Notation Unabhängigkeit von Anbietern / Tools Kostenlose Verfügbarkeit Internationalität Interoperabilität Weiterentwicklung Lehrgegenstand an Hochschulen 6

7 Notationsvergleiche Beweise Praxiserfahrungen Simulationen Experimente Analytisch Überprüfungen Berechnungen 7 Empirisch Fallstudien Umfragen

8 Bewertungskriterien und -kontexte Qualität nach IEEE Kontexte korrekt Erhebung eindeutig Analyse vollständig Dokumentation konsistent Implementierung bewertet Controlling verifizierbar modifizierbar verfolgbar verständlich effizient 8 Qualität == f (Kontext, Technik)

9 Kontrolliertes Experiment BPMN EPK 9 UC

10 Kontrolliertes Experiment: Zielsetzung Untersuchung der Korrektheit, Vollständigkeit, Eindeutigkeit, Effizienz und Komplexität aus Sicht einer Person, die einen Prozess dokumentieren muss Wie lange benötigt man um einen Prozess mit einer der Notationen zu beschreiben? Zeit / # modellierter Prozessanforderungen Wie viele Elemente benötigt man, um einen Prozess zu beschreiben? # Elemente / # modellierter Prozessanforderungen Wie eindeutig, vollständig und korrekt sind die resultierenden Prozessbeschreibungen? # Syntaxregelfehler (als Maß für Eindeutigkeit) 10 # fehlende Prozessanforderungen # inhaltlich inkorrekter Anforderungen

11 Kontrolliertes Experiment: Ergebnisse Korrektheit Keine Unterschiede bei inhaltlicher Korrektheit Vollständigkeit BPMN ist inhaltlich am unvollständigsten nach 90 min modelliert (signifikant) Effizienz EPK sind am komplexesten (signifikant), aber am schnellsten zu erstellen (nicht signifikant) Eindeutigkeit Use Cases sind am wenigsten eindeutig modelliert / meiste Syntaxfehler (signifikant) 11

12 Geschäftsprozessmodellierung Darstellung betrieblicher Abläufe meist grafisch ( Modelle ) Ziele: Erhebung (d.h. Verstehen des Ist-Standes) Analyse des Optimierungspotentials Dokumentation zwecks Arbeitsanweisung Schulung, Einarbeitung Vorbereitung einer IT-Unterstützung Geschäftsprozesse als Anforderungen Teil des Geschäftsprozessmanagements (BPM) 12

13 Unser Vorgehen in der Geschäftsprozessmodellierung Pilotprozessanalyse Pilotprozessanalyse Process Design Ist-Analyse Erhebung Analyse Spezifikation Validierung Soll-Definition Erhebung 13 Analyse Spezifikation Validierung

14 Praxiserfahrungen: Erhebung mit BPMN Unsere Erfahrung mit BPMN Erhebung dauert viel zu lange ( Malen am Beamer ) Workshopteilnehmer kommen häufig nicht (mehr) mit Informationstransfer gering Unsere Erfahrung ohne BPMN (oder andere Notationen) Schnelle Erhebung einer großen Informationsmenge Alle Workshopteilnehmer können ihre Sicht auf den Prozess einbringen Leute konsolidieren selbst das große Ganze und diskutieren intensiv Sehr gutes gemeinsames Verständnis am Ende eines Workshops 14

15 Praxiserfahrungen: Dokumentation mit BPMN Unsere Erfahrung mit BPMN Schlanke Modellierung durch zahlreiche Konzepte möglich Ausgereifte Syntaxregeln Modellierung erfordert viel Hirnschmalz und Erfahrung Richtig gute BPMN-Modelle sind (noch) schwerer zu verstehen Unsere Erfahrung ohne BPMN (d.h. mit anderen Notationen) Schnelle und einfache Modellierung durch informelle Beschreibung Tendenziell einfacher zu verstehen, da weniger Konzepte und Regeln Teils ganzheitlichere Modellierung möglich (insb. eepk / ARIS) Generell Häufige Problem in der Praxis sind eher semantischer Natur (z.b. Schnittkriterien, Abstraktionsebenen, Schleifen, etc.) 15

16 Unsere (aktuelle) Einschätzung von BPMN korrekt eindeutig vollständig verständlich effizient Erhebung Dokumentation - Î Ò Î Ô Ô Ô Ô Aus empirischer Sicht ist der Nutzen von BPMN zumindest für Erhebung und Dokumentation von Geschäftsprozessen begrenzt Aus analytischer Sicht sprechen jedoch viele Aspekte für BPMN (insb. Durchgängigkeit und Standardisierung) 16

17 Unsere Empfehlung zu BPMN Erhebe keine Prozesse mit BPMN (oder anderen Notationen) nutze Kartenabfrage, Flipcharts, stattdessen und erstelle Prozessmodelle im Nachgang Dokumentiere Prozesse mit Hilfe von BPMN, wenn hohe Formalität (syntaktische Korrektheit) und Eindeutigkeit wichtig die Verständlichkeit in der Zielgruppe gegeben Faktoren wie Standardkonformität und Durchgängigkeit hohen Stellenwert haben Ansätze, welche sowohl einfache Notationen als Nutze die gute, alte (e)epk, wenn auch BPMN verwenden, Schnelligkeit bei der Modellierung wichtig haben durchaus eine Modelle nicht kompakt sein brauchen Berechtigung. 17

18 Unsere Empfehlung zu BPM (ohne N) BPMN ist nur eine Sprache (wie Java beim Programmieren) Wichtiger für den Erfolg von Geschäftsprozessmanagement sind u.e.: Eine klare Strategie Management-Commitment Eine Vorgehens- und Modellierungs-Methodik Ein motiviertes Team Geeignete BPM-Werkzeuge Die Einbeziehung aller Prozessbeteiligten Das Etablieren von Prozessdenken Eine offene Kommunikation über das Vorhaben Empirische Nachweise des Nutzens verwendeter Methoden 18

19 Fragen? Norman Riegel Fraunhofer IESE Fraunhofer-Platz Kaiserslautern Tel: Sebastian Adam