Das Dokument behandelt die Implementierung und Herausforderungen von agilem Geschäftsprozessmanagement (BPM) in IT-Projekten, einschließlich der Notwendigkeit, technische und organisatorische Aspekte zu berücksichtigen. Es zeigt auf, wie agile Methoden wie Scrum in BPM-Projekten angewendet werden können, während es gleichzeitig auf die Schwierigkeiten hinweist, die durch verteilte Teams und Integration entstehen. Der Autor betont die Wichtigkeit, den Fokus auf Wertrealisierung zu legen und flexibel zu bleiben, anstatt strikt an vorgegebenen Prozessen festzuhalten.

1. Agiles BPM in der Praxis
Robert Gimbel
camunda services GmbH

2. Prozessorientierung ist eine Philosophie,…
Geschäftsprozessmanagement (GPM) beschäftigt
sich mit der Identifikation, Gestaltung, Dokumentation,
Implementierung, Steuerung und Verbesserung von
Geschäftsprozessen. Ganzheitliche Ansätze zum
p
Geschäftsprozessmanagements adressieren nicht nur
technische Fragestellungen, sondern insbesondere auch
organisatorische Aspekte… Wikipedia.org
g
Business process management (BPM) is a holistic
management approach focused on aligning all aspects
of an organization with the wants and needs of clients.
Wikipedia.org
…sagt aber nichts zum Thema Projektmanagement

3. camunda BPM-Kreislauf

4. Agilität ist ein Wertegerüst…
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
agilemanifesto.org
…für IT Projekte
Scrum is an iterative, incremental framework for
project management often seen in agile software
j t t ft i il ft
development, a type of software engineering.
Wikipedia.org

5. It‘s all about Value
Wertrealisierung agil
Wert
Wertrealisierung klassisch
Teamkosten
T k
Zeit

6. Wer setzt auf agile Softwareentwicklung?

7. Agiles BPM
Agiles
g
BPM Agile
BPM
Aber was heißt
das konkret?

8. Agiles BPM - ein neuer Hype?

9. Hurra, ein BPM Projekt
Start-UP
Neues GM

10. Projektumfang – ein Ebene 1 Modell

11. Die Teilprojekte… Web Frontend
Web-Frontend
Backend, ,
Umsysteme,
Sachbearbeiter,
Activiti

12. Die Details – ein Ebene 2+3 Modell - Entwurf

13. LL#1: Ein Prozessmodell beantwortet nicht alle Fragen
Womit fangen
wir an?

14. Priorisieren nach Wert und Risiko
Feature 3
Sprint 1 Burndown
Feature 23
Feature 1
Feature 7
Sprint 2 Feature 11
Feature 16
Feature 17
Sprint 3 Feature 22
Feature 13
Review 1 Review 2 Release Zeit

15. Und wie sah das konkret aus?
Kritisch
- Anbindung des Frontends (inkl. Datenmodell)
- Anbindung des CRM Systems
- Anbindung des Dokumentdienstleisters
Unverzichtbar
- Erweiterung Datenmodell
- Komplette Fallexport in das CRM
- Korrekte Dokumentgenerierung
- Bereitstellung Airline Stammdaten
Wichtig
- Emailversand der Zahlungsaufforderung
- Faxversand der Zahlungsaufforderung
- Postversand der Zahlungsaufforderung

16. LL#2: Im Prozessmodell fehlen Details
Wie genau soll das
implementiert
werden?

17. User Stories liefern die Details

18. User Stories liefern die Details
Frage: Wer erkennt ein Problem?
g

19. LL#3: Nicht alles lässt sich als User Story beschreiben
Und wohin mit
dem Rest?

20. Auch nicht User Stories im Backlog

21. LL#4: Man kann nicht immer 100% Scrum machen
Also doch
Wasserfall?

22. Soviel Scrum und Kanban wie nötig..

23. LL#5: Man kann auch wichtige Dinge weglassen
Sollen wir nicht
lieber das Release
verschieben?

24. Beispiel: Brauchen wir von Anfang an einen Faxdienstleister?
• Nur wenige Airlines nutzen das Fax
• Anfangs sind nur 5-10 Faxe am Tag zu
versenden
• Evaluation und technische Anbindung eines
Faxdienstleisters sind teuer
• Wer macht das denn heute?  Frau Schmidt
• Hat Frau Schmidt Zeit für 5-10 Faxe pro Tag? 
p g
ja
 Workaround: Frau Schmidt bekommt eine Email
mit Faxnummer und PDF

25. LL#6: Verteilte Teams/Kompetenzen verzögern Projekte
Aber der Preis für
das Teilprojekt war
unschlagbar!

26. Kein vorzeitiges End-to-End Testen möglich

27. LL#7: Die Dokumente machen wir selbst
Die Integration mit dem
Dienstleister wurde
einfach zu teuer!

28. Beispiel: ZA-Dokument

29. Licht ins Dunkel: der Maskenfluss als Prozess

30. Erste Schritte in Richtung Testautomatisierung

31. LL#8: Am Ende sieht die Welt dann doch anders aus
Wir haben unterwegs
wiedermal einiges
gelernt!

32. Und hier der BPM-Roundtrip

33. Ist das die Projektrealität?

34. Unsere Projekte sind eher so…

35. Danke für die Aufmerksamkeit

36. Softwareentwicklung nach dem Wasserfall Modell
Spezifikation
Entwicklung
Test
Rollout

37. Agile Softwareentwicklung
Feature 1
Feature 2
Feature 3
Feature 4

38. Testautomatisierung der fachlichen Tests
?
Expected
= Result

39. Testszenarien als jbehave Stories
Definierter
Input
Szenario: 1. Ein Produkt mit pic, Austauschtabellen-Service
wird aufgerufen, gibt eine Menge von potentiellen Substituten
zurück
Gegeben clientId 1
Und ein Produkt mit pic 0000649
Und it d Beschraenkung St d d
U d mit der B h k Standardpackungsgroesse
k
Und mit dem Substitution-Level hart
Und mit der Substitution-Form NULL
Wenn der Austauschtabellen Service aufgerufen wird
Austauschtabellen-Service
Dann sollte die Menge der pics potentieller Substitute
folgende Werte haben
{3411979,4876226,6883696,6987444,2245734,3753042,00
{3411979 4876226 6883696 6987444 2245734 3753042 00
00655,1782766,6154796,0658797}
Expected
Result

41. Agiles BPM - Workshop
Robert Gimbel
camunda services GmbH

42. 1. Rollen festlegen (5 Min)
2. Thesen/Themen sammeln (10 Min)
3. Thesen/Themen auswählen (5 Min)
4. Thesen/Themen diskutieren (2 x 20 Min)

43. Das größte Potential für schnellere IT
Projekte liegt in den Backlogs

44. Outsourcing und verteilte Teams
verzögern IT Projekte

45. Integrationsintensive BPM Projekte
I t ti i t i P j kt
passen nicht 100%ig zu agilen
Methoden

46. Auch mit BPMN lassen sich keine
perfekten Anforderungen definieren