8. Die zwei Gesichter des BPM
Organisationslehre
Business Process (Orga-) Geschäftsprozess-
Ablauforganisation
Reengineering - BPR Management - GPM
bis 1990
1990 - 2000 ab 2000
Business
Business Process Management - BPM
IT
ab 2004
Prozessautomatisierung
ab 2006
Human Serviceorientierte
Workflow Management Architekturen (SOA)
ab 2000 ab 2005
Dokumenten-Management – Enterprise Application
Systeme – DMS (u.a.) Integration – EAI
10. Peak of inflated Expectations
Challenging –
but powerful!
As-Is
Plateau of Productivity
To-Be
Slope of Enlightenment
Trough of Disillusionment
Technology Trigger Way too
complicated!
11. Business Process Maturity Levels
# Name Description
1 Initial Wherein business processes are performed in inconsistent
sometimes adhoc ways with results that are difficult to
predict.
2 Managed Wherein management stabilizes the work within local work
units to ensure that it can be performed in a repeatable way
that satisfies the workgroup‘s primary commitments.
However, work units performing similar tasks may use
different procedures.
3 Standardized Wherein common, standardizes processes are synthesized
from best practices identified in the work groups and
tailoring guidelines are provided for supporting different
business needs. Standard processes provide an economy of
scale and a foundation for learning from common measures
and experience.
4 Predictable Wherein the capabilities enabled by standard processes are
exploited and provided back into the work units.
5 innovative Wherein both proactive and opportunistic improvement
actions seek innovations.
12. Jeder Geschäftsprozess muss geklärt werden
Reifegrad Reifegrad Möglichkeiten des Häufige Fälle
Ist Soll Prozessmanagements
2/3 2/3 Ist-Dokumentation; Support-Prozesse
Soll-Gestaltung (Kern-Prozesse)
1 2/3 Soll-Gestaltung Kern-Prozesse
(Support-Prozesse)
1 1 - Management-
Prozesse
13. Beispiel: Schadenregulierung ≠ Schadenregulierung
Schadenregulierungsprozess bei KfZ
Parameter:
- Relativ häufig
- Schadensummen relativ niedrig bzw.
- geringe mögliche Bandbreite der Summen
- Regulierung muss effizient sein
Konsequenzen:
- Standardisierter Ablauf
- Dynamik nur bei Ausnahmen (Betrugsverdacht)
- Kaum „Knowledge-Worker“ erforderlich
- Automatisierung möglich und lohnend
- Kann mit BPMN präzise beschrieben werden
Schadenregulierungsprozess bei Unfall
Parameter:
- Relativ selten
- Schadensummen relativ hoch bzw.
- Hohe mögliche Bandbreite (Rente etc.)
- Regulierung muss effektiv sein (=> wenig Auszahlung)
Konsequenzen:
- Wenig standardisierter Ablauf, viel Dynamik
- Basiert auf Know-how und Motivation der Sachbearbeiter
- Automatisierung kann höchstens unterstützen
- Kann mit BPMN nur grob beschrieben werden
14. Was ich klären muss, wenn ich BPMN einführe
Rollen
Methoden
Ziele Werkzeuge
Prozesse
15. Einsatzszenario: Prozessdokumentation
Ziele
• Mehr Transparenz in unseren Prozessen
• Neue Mitarbeiter verstehen, wie wir funktionieren
• Wir schaffen die ISO-Zertifizierung
• Rollen
• Es gibt ein Know-how-Zentrum (Betriebsorga, IT etc.)
• Hier werden die Methodik, das Tool, die Meta-Prozesse definiert
• Dokumentiert werden soll in den Fachbereichen
• Zentrales Know-how-Zentrum unterstützt und übernimmt die QS
• Methodik
• BPMN + Guidelines (Konventionen)
• Textuelle Beschreibungen
• Prozessarchitektur (Prozesslandkarten, Wertketten etc.)
• Tooling
• BPMN-Werkzeug für kollaboratives Arbeiten, Verwaltung umfangreicher
Dokumentationen, Definition von Attributen etc.
• Mitarbeiter-Informationssystem (Wiki, Sharepoint etc.)
• Meta-Prozesse
• Prozesserhebung und –dokumentation
• Pflege und Aktualisierung
• Freigabe von Modellen (methodisch / Inhaltlich)
20. Die Praxis ist leider nicht immer so einfach...
Komplexe Prozesse => Umfangreiche Prozessmodelle
Unterschiedliche Wünsche der Stakeholder, wie genau das Modell sein
soll:
− fachlich grob
− fachlich fein
− technisch
Unterschiedliche Wünsche, welche Abläufe im Modell betrachtet
werden sollen:
− nur fachlich: „Was macht der Mensch?“
− nur technisch: „Was macht die Process Engine?“
− sowohl als auch: „Wie interagieren beide?“
21. camunda-Methodik für BPMN
Prozesslandschaft
Inhalt: Prozess im Überblick
Ebene 1 Ziel: Schnelles Verständnis
Strategisches Semantik: logisch-abstrakt
Prozessmodell
Inhalt: Operative Abläufe
Ebene 2 Ziel: Abstimmung von Details
Fachlich Operatives Prozessmodell Semantik: physisch-konkret
(Business)
Technisch
(IT) Ebene 3a Inhalt: Technische Details
Ebene 3b
Technisches Ziel: Umsetzung
IT-Spezifikation
Prozessmodell Semantik: physisch-konkret
Mit Process Engine
Ebene 4b
Implementierung
Ohne Process Engine
22. Kerngedanke #1: Brüche nach oben verlagern
Prozesslandschaft
Inhalt: Prozess im Überblick
Ebene 1 Ziel: Schnelles Verständnis
Strategisches
Prozessmodell
Inhalt: Operative Abläufe
Ebene 2 Ziel: Arbeits- und
Fachlich Operatives Prozessmodell Umsetzungsgrundlage
(Business)
Technisch
(IT) Ebene 3a
Ebene 3b
Technisches
IT-Spezifikation
Prozessmodell
Inhalt: Technische Details
Ziel: Umsetzung
Mit Process Engine
Ebene 4b
Implementierung
Ohne Process Engine
25. Kerngedanke #2: Verschiedene Sichten auf Ebene 2
Betrachter Process Participant Process Analyst Process Engineer
„Wie muss ich „Wie wird „Was macht die
Zentrale Frage
arbeiten?“ gearbeitet?“ Engine?“
Eigene Gesamte Orchestrierung der
Sicht
Orchestrierung Kollaboration Process Engine
Prozesslandschaft
Ebene 1
Strategisches
Prozessmodell
Inhalt: Prozess im Überblick
Ziel: Schnelles Verständnis
Ebene 2: Operatives
Prozessmodell
Inhalt: Operative Abläufe
Ebene 2 Ziel: Arbeits- und
Fachlich Operatives Prozessmodell Umsetzungsgrundlage
(Business)
Technisch
(IT) Ebene 3a
Ebene 3b
Technisches
IT-Spezifikation
Prozessmodell
Inhalt: Technische Details
Ziel: Umsetzung
Mit Process Engine
Ebene 4b
Implementierung
Ohne Process Engine
26. Vorgabe für den Workflow
(Spezifikation)
Vorgabe für
den Boss
(Arbeitsanweisung)
