How to derive better processes understanding and improving design capability

How to derive better processes understanding and improving design capability Process consolidation The case of Suncorp Prof. Michael Rosemann, A/Prof. Marcello La Rosa BPM Discipline Information Systems School Faculty of Science and Engineering James Couzens Solution Architect Suncorp Business Services Queensland University of Technology Brisbane Australia

The fact: Suncorp insurance End to end process has between 250 & 1,000 process steps Product Dev Source: Guidewire reference models Sales Service Claims 500 steps Each process is varied by product & brand Home Motor Commercial Liability CTP / WC 30 variations Estimated total number of process steps: 15,000 Total number of models: 3,000+

Have you ever experienced any problem in managing your process model collection?

How many of these are real differences? Real Differences vs Couleur Locale

A closer look at Suncorp s repository Home insurance X P R Q S 363 models 279 clones: 9% of gain B A D G E F I H Commercial property insurance P Q T R O J P Q N M G Z F H I

Not just a coincidence SAP R/3 reference model for ERP: 595 models (size from 5 to 119 nodes) 479 clones: 13.8% gain IBM BIT library for insurance: 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

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 Determine if invoice relates to claim? Identify invoice for claim Complete customer reimbursement? Complete third party reimbursement Victoria Beckham and Kate Middleton Similar Fashion Sense (International Business Times)

Approximate clones: a closer look L B H A D E I B L H A X E' I

Approximate clones in Suncorp s repository 243-309 clusters of approximate clones (60% similarity) after refactoring exact clones from the repository

Process model jungle Proliferation of variants Stagnating improvement initiatives Inability to turn agile Need for innovative design capabilities: perpetual (and lightweight) consolidation

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 One über-model for all variants

1. Feudalism End to end process has between 250 & 1,000 process steps Product Dev Source: Guidewire reference models Sales Service Claims 500 steps Each process is varied by product & brand Home Motor Commercial Liability CTP / WC 30 variations Estimated total number of process steps: 15,000 Total number of models: 3,000+

Z N O F H G R P Q I M J T P Q Commercial property insurance Z N O R M J T Commercial property insurance X X F H G I Z N O R M J T Commercial property insurance X X Y 2. Weak federation Extract cloned fragments and store them as separate sub-processes. If approximate clones, first standardize. 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

3. Strong federation Store process models as fragments Home insurance P Q A B L D R S Home insurance Version 1.0 E F G H I F1 F2 F3 F4 F5 F6 RPST F7 F8

add pointers for sharing Horizontal sharing Home insurance Version 1.0 F1 F2 Commercial property insurance Version 1.5 F20 F21 F3 F4 F5 F5 F22 F6 = F6 F7 F8 F7 F8

Change propagation Synchronize via change propagation at the level of single fragments Propagation policy: Instant Home insurance Version 1.0 1.1 Commercial prop. insurance Version 1.5 1.6 Propagation policy: Instant F1 F20 F2 F21 F3 F4 F5 F22 F6 C F7 F8 A B B Shared fragments

Vertical sharing Home insurance Version 1.0 P Q X R S B A D G F3 E F H I Home insurance Version 1.1 P Q X R S B A D G? X E F H I

Vertical sharing Monitor the evolution of a process model over time Home insurance Version 1.0 F1 Home insurance Version 1.1 F11 F2 F10 E F3 F4 F5 F9 X E F6 F7 F8

Concurrency control Fragments can be edited concurrently if an edited fragment is not related to another edited fragment Home insurance Version 1.0 A B X D P R Q S E F G H I

sb.857 bs.820 sb.810 cs.163 sc.163 cb.163 bc.163 sc.pickup sb.856 bs.180 Return Management bs.860 sb.865 [repeat] cb.163 bc.163 cs.163 sc.163 sb.180 sc.107 cs.106 sc.108 sc.213 sb.832 sb.889 sb.notification cs.214 bs.853 cs.217 sc.227 bs.846 sb.852 bs.840 sb.843 bs.850 sb.855 bs.confirmation sb.753 timeout (no new carrier) bc.250 bs.163 sb.163 cb.delivery bs.861 timeout reset [-] reset bc.163 cb.163 bs.754 cb.217 bc.227 sb.889 sb.832 (re-do request) timeout bc.107 cb.106 bc.108 bs.notification sb.163 bs.163 sc.211 timeout timeout bc.213 cb.214 cs.214 bs.163 sb.163 bs.869 sb.870 (may contact a new carrier) cb.163 bc.163 sb.163 bs.163 cs.163 sc.163 bc.216 sc.216 sc.163 cs.163 sc.163 cs.163 Pickup Appointment Request Pickup Appointment Confirmation cs.163 sc.163 Pickup Appointment Request Pickup Appointment Confirmation sc.204 cs.990 bs.163 sb.163 sb.163 bs.163 bc.163 cb.163 bs.163 sb.163 sb.163 bs.163 cb.163 bc.163 bc.204 cb.990 cs.163 sc.163 cb.163 bc.163 sc.pickup sb.856 cb.163 bc.163 cs.163 sc.163 bs.860 sb.865 sc.213 cs.214 sb.832 sb.889 bs.853 bs.846 sb.852 bs.840 sb.843 bs.850 sb.855 bs.confirmation sb.753 sc.107 cs.106 sc.108 sb.notification cs.217 sc.227 bc.250 cb.delivery bs.861 reset [-] reset bs.754 sb.889 sb.832 (re-do request) timeout timeout bc.213 cb.214 cs.214 sc.216 c: sc.215 bc.216 sc.213 cs.240 bc.213 cb.240 cb.212 [payment correct] bc.820 bc.812 cb.210 / cb.224 bc.812 sc.163 cs.163 Pickup Appointment Request Pickup Appointment Confirmation [else] cs.210 sc.820 cs.163 sc.163 Pickup Appointment Request Pickup Appointment Confirmation sc.204 cs.990 cb.210 bc.820 bs.163 sb.163 sb.163 bs.163 bc.163 cb.163 bs.163 sb.163 sb.857 sb.163 bs.163 cb.163 bc.163 bs.820 bc.204 cb.990 sb.810 cs.163 sc.163 cb.163 bc.163 sc.pickup sb.856 bs.180 sb.180 Return Management cb.163 bc.163 cs.163 sc.163 bs.860 sb.865 [repeat] sc.107 cs.106 sc.108 sc.213 sb.832 sb.889 sb.notification cs.214 bs.853 cs.217 sc.227 bs.846 sb.852 bs.840 sb.843 bs.850 sb.855 bs.confirmation sb.753 timeout (no new carrier) bc.250 bs.163 sb.163 cb.delivery bs.861 timeout reset [-] reset bc.163 cb.163 bs.754 cb.217 bc.227 sb.889 sb.832 (re-do request) sb.163 bs.163 timeout bc.107 cb.106 bc.108 bs.notification sc.211 timeout timeout bc.213 cb.214 cs.214 bs.163 sb.163 bs.869 sb.870 (may contact a new carrier) cb.163 bc.163 bs.report sc.920 sc.925 cs.926 sb.163 bs.163 Loss or Damage Management cs.163 sc.163 bc.920 bc.925 cb.926 bc.216 sc.213 cs.240 sc.216 sc.163 cs.163 bc.213 cb.240 sc.216 c: sc.215 bc.216 cb.212 4. Unification Merge in one über model based on similar fragments + =

Über model: characteristics 1. Behavior-preservation 2. Traceability 3. Reversibility Commercial prop. insurance A Home insurance A Commerial+Home insurance A variation point B + = D B D C C C

Suncorp: example of merging by product Motor v 1.0 Home v 1.0 Commercial v 1.0 CTP v 1.0 merging Suncorp Base v 2.0 1.0 configuration CTP v 2.0 Liability v 1.0

Variants merging @ Suncorp We run our merging algorithm over a collection of Suncorp models: 1. Motor claim initiation + Personal claim initiation (25% of which merged manually @ Suncorp in 130 man-hours) 2. Motor claim lodgement + Personal claim lodgement 3. Motor invoice received + Personal invoice received

Which approach fits best your organization? Min Feudalism Weak federation Strong federation Max Unification

Where do I start? 1. Simplify individual process models [refactoring] (enforce modelling conventions, e.g. labels, layout, degree of abstraction) 2. Remove repository redundancies [weak federation] (extract cloned fragments and store these as reusable sub-processes) 3. Identify similarities and merge [unification] Results: Smaller and cleaner models Less models Embedded agility via configuration!

15,000 process steps Suncorp Insurance s goal Minimise process model complexity [refactoring] Standardise across brands [weak federation] Merge across products [unification] 3,000 process steps

Apromore Initiative (www.apromore.org) Large initiative among 7 universities Supported by Suncorp and ARC (over 1M$) Aim: develop an open-source, highly scalable, SaaS platform to manage process model collections Service areas: 1. Evaluation Check adherence to benchmarks and reference models 2. Advanced Filtering Identify similarities or cloned process fragments to refactor 3. Clever Design Assemble existing fragments to create new process models 4. Enhanced Presentation improve the understanding of process model collections

Apromore Canonical Process Format Common process representation Life insurance (BPMN) P Q Home insurance (EPCs) A R A B D B X C D D P Q F A B D R C E F A B D

Apromore: Suncorp benefits Build awareness Understand differences and causes for these differences Achieve simplification Identify and consolidate common business functions Achieve centralisation Centralise support for non-core processes across LOB Identify opportunities for partnering Make better decisions about the processes you can partner/run in-house

Does any of this benefit apply to your organization?

Apromore: Engaging the community 1. Donate code, it s open source! Donate plugins as-is Donate patches 2. Join the Apromore Consortium Sponsor a particular feature of Apromore Share your experiences with the community of practice

Apromore: Outlook Monitor the quality of your repository Automatically enforce quality rules Justify improvement initiatives against quality goals Enhance your process models with live data Performance information: waiting time, execution time, bottlenecks Conformance of executed processes with the models

What features would your organization benefit from?

Key Messages Most organizations have significant investments in process modelling Many repeat the development of those processes with every new initiative Apromore helps release the latent value that lies in process models Design by Confidence VS Design by Evidence

Prof. Michael Rosemann, A/Prof. Marcello La Rosa James Couzens m.rosemann@qut.edu.au m.larosa@qut.edu.au james.couzens@suncorp.com.au More information at www.apromore.org This presentation includes slides adapted from J. Cornes, M. Dumas and C. Ekanayake