Enabling Business Process Agility
via
Consolidation
Reculer pour mieux sauter
Dr Marcello La Rosa
Business Process Management Group
Information Systems Discipline
Faculty of Science and Technology
Queensland University of Technology
Brisbane Australia
Before
After
Check
information
Phone call
received
X
Sufficient
sufficient
Not
Register
claim
Claim
registered
Call centre
agent
Call centre
agent
Context-aware process execution
–
Operating in alternative modes
Check
information
Phone call
received
X
Sufficient
sufficient
Not
Register
claim rapidly
Claim
registered
Call centre
agent
Call centre
agent (novice)
Call centre
agent
Call centre
agent (novice)
Call center Brisbane (sunny day)
Call center Brisbane (stormy day)
Each process is varied by product & brand
End to end process has between 250 & 1,000 process steps
Source: Guidewire reference models
Product
Dev
Sales
Service
Claims
•
Estimated total number of process steps: 15,000
•
Total number of models: 3,000+
30
variations
500
steps
Home
Motor
Commercial
Liability
CTP / WC
How many of these are real differences?
Real Differences
vs
Z
N
O
F
H
G
R
P
Q
I
M
J
T
P
Q
Commercial insurance
X
P
Q
R
S
D
A
B
E
F
H
G
I
Home insurance
A closer look at Suncorp’s repository
•
363 models
•
279 clones:
Not just a coincidence…
SAP R/3 reference model:
•
595 models (size from 5 to 119 nodes)
479 clones: 13.8% gain
IBM BIT library:
•
A: 269 models (size from 5 to 47 nodes)
174 clones: 9% gain
•
B3: 247 models(size from 5 to 42 nodes
)
49 clones: 6.6% gain
SAP R/3 reference model: Curran, Keller, Ladd, SAP R/3 Business Blueprint, Prentice Hall, 1997
The problem of cloned fragments
•
Clones may be modified independently,
leading to unwanted inconsistencies
•
Clones hide potential efficiency gains
•
Clones make individual process models
larger than they need be, thus affecting
their comprehensibility
Not only “exact” clones!
There are also “approximate” clones, i.e. similar fragments
“Victoria Beckham and Kate Middleton – Similar Fashion Sense”
Determine if
invoice relates to
claim
Complete
customer
reimbursement
Identify invoice
for claim
Complete
third party
reimbursement
?
?
Process model “chaos”
•
Proliferation
of variants
•
Stagnating
improvement initiatives
•
Inability to turn
agile
•
Need for solid process modeling foundation
•
Continuously clean to achieve agility:
Process model consolidation
1. Feudalism (current situation)
One separate, independent model per variant
2. Weak Federation
One top-level model per variant, but shared sub-processes
3. Strong Federation
One model per variant, models synchronized via change
propagation
4. Unification
Z
N
O
F
H
G
R
P
Q
I
M
J
T
P
Q
Commercial insurance
Z
N
O
R
M
J
T
Commercial insurance
X
X
F
H
G
I
Z
N
O
R
M
J
T
Commercial insurance
X
X
Y
Weak federation
Extract cloned fragments and store them as separate
sub-processes
X:
Y:
L
X
R
S
D
A
B
E
Home insurance
Y
P
Q
F
H
G
I
L
P
Q
R
S
D
A
B
E
F
H
G
I
Home insurance
L
X
R
S
D
A
B
E
Home insurance
F
H
G
I
Strong federation
Store process models as “fragments”…
L
P
Q
R
S
D
A
B
E
F
H
G
I
Home insurance
F1
F2
F3
F4
F5
F6
F7
F8
Home insurance
Version 1.0
Strong federation
…Add pointers for sharing
F1
F2
F3
F4
F5
F6
F7
F8
Home insurance
Version 1.0
F20
F21
F22
Commercial insurance
Version 1.5
F5
F6
F7
F8
=
A
B
A
C
B
Strong federation
F1
F2
F3
F4
F5
F6
F7
F8
F20
F21
F22
Home insurance
Version 1.0
Shared
fragments
Commercial insurance
Version 1.5
Propagation policy:
Instant
Propagation policy:
Instant
Home insurance
Version 1.1
Commercial insurance
Version 1.6
Synchronize via change propagation at the level of
single fragments
3. Strong federation
•
100 updates performed on randomly selected fragments
•
After each update, we measured # automatic changes
Unification
sb.855 sb.865 sb.753 sc.107 cs.106 sc.213 bc.213 bs.180 bc.920 bc.925 cs.926 cb.926 sb.810 sb.857 Return ManagementLoss or Damage Management bs.861 sb.856 cb.delivery bs.860 cb.212 bs.850 sb.870 bs.820 [else] bc.812 [payment correct] cs.210 cb.210 sc.820 bc.820 bc.812 sc.920 bs.report sc.925 sc.108 bc.108 cb.210 / cb.224 bc.820 sb.180 cb.214 bc.213 sc.213 cb.240 cs.240 sb.832 sb.889 bs.846 sb.889 sb.832 sb.852 [-] (re-do request) timeout timeout timeout bc.107 cb.106
(may contact a new carrier) sb.843
bs.confirmation bs.869 bs.840
timeout (no new carrier)
timeout cs.217 cb.217 sc.227 bc.227 bc.250 cs.163 cb.163 bc.204 sc.204 cb.990 sb.163 sb.163 bs.163 bs.163 sb.163 bs.163 bs.163 sb.163 sb.163 sb.163 bs.163 bs.163 sb.163 bs.163 bc.216 bs.163 sb.163 sc.215 cs.990 sc.pickup sc.216 bc.163 sc.163 cb.163 cs.163 bc.163 sc.163 sc.211 cs.163 cs.163 sc.163Pickup AppointmentRequest
Pickup Appointment Confirmation sc.163 Pickup Appointment Request Pickup Appointment Confirmation bc.163 bc.163 cb.163 cb.163 cs.163 cs.163 sc.163 sc.163 bc.216 sc.216 bc.163 bc.163 cb.163 cb.163 reset reset bs.853 bs.754 sb.notification bs.notification c: cs.214 cs.214 [repeat]
Merge in one über model based on “similar” fragments
sb.855 sb.865 sb.753 sc.107 cs.106 sc.213 bc.213 bs.861 sb.856 cb.delivery bs.860 cb.212 bs.850 sc.108 cb.214 bc.213 sc.213 cb.240 cs.240 sb.832 sb.889 bs.846 sb.889 sb.832 sb.852 [-] (re-do request) timeout timeout sb.843 bs.confirmation bs.840 cs.217 sc.227 bc.250 cs.163 cb.163 bc.204 sc.204 cb.990 sb.163 sb.163 bs.163 bs.163 sb.163 bs.163 bs.163 sb.163 bc.216 sc.215 cs.990 sc.pickup sc.216 bc.163 sc.163 cb.163 cs.163 bc.163 sc.163 cs.163 cs.163 sc.163Pickup AppointmentRequest
Pickup Appointment Confirmation sc.163 Pickup Appointment Request Pickup Appointment Confirmation bc.163 bc.163 cb.163 cb.163 reset reset bs.853 bs.754 sb.notification c: cs.214 cs.214 sb.855 sb.865 sb.753 sc.107 cs.106 sc.213 bc.213 bs.180 sb.810 sb.857 Return Management bs.861 sb.856 cb.delivery bs.860 bs.850 sb.870 bs.820 sc.108 bc.108 sb.180 cb.214 sb.832 sb.889 bs.846 sb.889 sb.832 sb.852 [-] (re-do request) timeout timeout timeout bc.107 cb.106
(may contact a new carrier) sb.843
bs.confirmation bs.869 bs.840
timeout (no new carrier)
timeout cs.217 cb.217 sc.227 bc.227 bc.250 cs.163 cb.163 sb.163 sb.163 bs.163 bs.163 sb.163 bs.163 bs.163 sb.163 sc.pickup bc.163 sc.163 cb.163 cs.163 bc.163 sc.163 sc.211 cs.163 cs.163 sc.163 sc.163 bc.216 sc.216 bc.163 bc.163 cb.163 cb.163 reset reset bs.853 bs.754 sb.notification bs.notification cs.214 cs.214 [repeat]
=
+
≈
≈
≈
Über model: characteristics
1. Behavior-preservation
2. Traceability
3. Reversibility
Commerial+Home
insurance
A
D
C
B
Home
insurance
A
D
C
Commercial
insurance
A
B
C
+
=
variation
point
Suncorp: example of merging by product
Motor
v 1.0
Home
v 1.0
Commercial
v 1.0
v 1.0
CTP
Suncorp Base
v 1.0
CTP
v 2.0
merging
configuration
Liability
v 1.0
Suncorp Base
v 2.0
Variants merging @ Suncorp
We run our merging algorithm over a collection of Suncorp models:
1.
Motor claim initiation + Home claim initiation
(25% of which merged manually @ Suncorp in 130 man-hours!)
2.
Motor claim lodgement + Home claim lodgement
Which approach fits best my organization?
Weak federation
Unification
Strong federation
Meet-in-the-middle?
1.Simplify individual process models
(enforce modelling conventions, e.g. labels, layout, degree of abstraction)
2.Remove repository redundancies
(extract cloned fragments and store these as reusable sub-processes)
3.Identify similarities and merge
Results:
•
Smaller and cleaner models
•
Less models
15,
000 p
ro
cess
step
s
3,000
process steps
Minimise process model complexity
Standardise across brands
Merge across products
Meet-in-the-middle @ Suncorp
Vision: AProMoRe
Facilitate the management of large process model
collections via:
•
Advanced Filtering
query for similarities or exact matches
•
Clever Design
control the creation and evolution of process model collections
•
Enhanced Presentation
improve the understanding of process model
collections
•
Evaluation
Key Messages
•
Reculer pour mieux sauter:
•
simplify
•
consolidate
•
Build agility as you consolidate:
•
Product/Brand-aware
•
Context-aware
Dr Marcello La Rosa
Senior Lecturer
BPM Group
Queensland University of Technology
e
w
http://marcellolarosa.com
More information at
•
www.apromore.org
•
www.processconfiguration.com