A Model for Process Transformation

30,240 views

Published on

This session introduces some of the principles behind a proposed Business Process Management (BPM) reference model, equivalent to the Workflow Management Coalition (WfMC) Workflow Reference Model.
There is signifi cant holistic advantage in deriving the BPM reference model not from workflow or BPM technology, but from logical and architectural analysis of what it is to be a business process. The same model
can then support technology, operational process management and business transformation. The principles address fundamental questions like:
• What is a business process? Where does it start and stop? What are its logical components?
• How can one process control structure cover both manual and automated functionality?
• Where do rules fit in?
• How to ensure process models align with data models?
Does process thinking mean rethinking requirements analysis, solution design and IT engagement and delivery models?

Published in: Business, Technology
1 Comment
12 Likes
Statistics
Notes
No Downloads
Views
Total views
30,240
On SlideShare
0
From Embeds
0
Number of Embeds
162
Actions
Shares
0
Downloads
1,415
Comments
1
Likes
12
Embeds 0
No embeds

No notes for slide

A Model for Process Transformation

  1. 1. <ul><li>Chris Lawrence </li></ul><ul><li>Business Architecture Consultant </li></ul><ul><li>Old Mutual South Africa </li></ul><ul><li>Session Title: </li></ul><ul><li>A Model for Process and Transformation </li></ul>Welcome to Transformation and Innovation 2007 The Business Transformation Conference Welcome
  2. 2. A Model for Process and Transformation <ul><li>WfMC BPM and Workflow Handbook 2007 </li></ul><ul><ul><li>Paper: </li></ul></ul><ul><ul><ul><li>Business Process Architecture and the Workflow Reference Model </li></ul></ul></ul><ul><ul><li>Argument: </li></ul></ul><ul><ul><ul><li>Derive BPM reference model not from workflow or BPM technology , but from logical analysis of the business process </li></ul></ul></ul>
  3. 3. A Model for Process and Transformation <ul><li>Draft BPM reference model </li></ul><ul><ul><li>Logical analysis of the business process </li></ul></ul><ul><ul><li>Advantages: </li></ul></ul><ul><ul><ul><li>Same model can support: </li></ul></ul></ul><ul><ul><ul><ul><li>Technology </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Process management </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Transformation </li></ul></ul></ul></ul><ul><ul><li>Analogy: </li></ul></ul><ul><ul><ul><li>Relational data model </li></ul></ul></ul>
  4. 4. WHAT versus HOW <ul><li>Analogy: </li></ul><ul><ul><li>Logical data model v physical data design </li></ul></ul>Process rules even if no systems were used Process features relating to a specific implementation
  5. 5. Process analysis, process modelling, process mapping, process design, process improvement... Operational procedure design around given system components ‘ Process’ = linking components together (procedurally or automatically or both) This is HOW not WHAT
  6. 6. Draft BPM reference model <ul><li>Objectives: </li></ul><ul><ul><li>Understand process as WHAT </li></ul></ul><ul><ul><li>To get best available HOW </li></ul></ul><ul><li>Initial scope: </li></ul><ul><ul><li>‘ Administration’: </li></ul></ul><ul><ul><ul><li>Processing orders & applications, granting approval, carrying out instructions …etc etc </li></ul></ul></ul><ul><ul><ul><li>Sales, financial services, central & local government, education, travel, tourism …etc etc etc </li></ul></ul></ul>
  7. 7. Administration <ul><li>Service to ‘end-customer’ </li></ul><ul><ul><li>Implicit or explicit ‘request’ </li></ul></ul><ul><li>Rule-governed </li></ul><ul><ul><li>Right and wrong ways </li></ul></ul><ul><ul><li>Standard v exceptions </li></ul></ul><ul><ul><li>Sequence; completeness </li></ul></ul><ul><li>Increasingly supported by computer systems </li></ul><ul><ul><li>People deal with exceptions and special cases </li></ul></ul><ul><ul><li>People make rules rather than follow them </li></ul></ul>
  8. 8. Administration <ul><ul><li>Content & rules can be treated abstractly </li></ul></ul><ul><ul><li>Essence survives translation into different formats (brain, paper, digital…) </li></ul></ul><ul><ul><li>Eg life insurance policy: </li></ul></ul>legal contract between a financial organization and another person or organization, in relation to one or more human lives Almost everything about it and its creation can be treated abstractly - in a translatable (eg digitizable) way Cannot say the same about the process of making an armchair
  9. 9. Administration <ul><li>Concrete object </li></ul><ul><ul><li>Cannot be translated into another form and stay an armchair </li></ul></ul>Life insurance policy <ul><li>Abstract entity </li></ul><ul><ul><li>Can be translated into another form </li></ul></ul><ul><ul><li>Only has to exist as hard copy if rules say so </li></ul></ul>
  10. 10. Process Process Input(s) Input(s) Output(s) Familiar model
  11. 11. Process Order process Input(s) Received goods Business process Customer order
  12. 12. Process Addition process 2 3 5 Calculation process
  13. 13. Process Photosynthesis Water Carbon dioxide Sunlight Glucose Oxygen Natural process
  14. 14. Process <ul><li>This model is generic </li></ul><ul><ul><li>Nothing special about business process </li></ul></ul>Process Input(s) Input(s) Output(s)
  15. 15. Process Process 1 Input 1 Output 1
  16. 16. Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 =
  17. 17. Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 Input 4 Process 3 Output 4 =
  18. 18. Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 Input 4 Process 3 Output 4
  19. 19. Process Input 1 Input 3 Process 4 (1+2+3) Output 4 Output 3
  20. 20. Process <ul><li>This model is also indefinite </li></ul><ul><ul><li>Where does the process start and stop? </li></ul></ul><ul><ul><li>For a business process we need something more precise </li></ul></ul>Process Input(s) Input(s) Output(s)
  21. 21. Business process <ul><li>For a business process we need to identify: </li></ul><ul><ul><li>A particular kind of input </li></ul></ul><ul><ul><li>A particular kind of output </li></ul></ul>Request is for the outcome Outcome = thing requested Request = entity changing business status through the process Outcome = last business status change BPMN symbol for ‘data object’ BPMN symbol for ‘process’ or ‘process component’
  22. 22. Business process Unambiguous start point Unambiguous end point At individual instance level Paradigm case: request is from a customer (external or internal) Paradigm case: outcome is for that customer Achieving the requested outcome will involve following rules ‘ Process’ is not arbitrary : starts with the request & = everything which must be done to achieve the requested outcome
  23. 23. Business process <ul><li>The business process will involve following rules </li></ul><ul><ul><li>Rules may or may not be satisfied </li></ul></ul><ul><ul><li>Requested outcome may not be achieved: </li></ul></ul><ul><ul><ul><li>Eg ordered goods unavailable; loan application unsuccessful; … </li></ul></ul></ul><ul><ul><li>But just like the requested outcome, any alternative outcome will also be correct in terms of the rules of the process </li></ul></ul>
  24. 24. Business process Business process Order process Input(s) Received goods Customer order
  25. 25. Subprocess <ul><ul><li>A business process can normally be broken down into a finite series of subprocesses … </li></ul></ul>
  26. 26. Subprocess Fixed pattern: sequential; parallel… Subprocess 1, subprocess 2 etc can be described in purely business terms, eg ‘authorise order’, ‘match against stock’. Subprocesses would need to happen whatever system was used, or whether a system was used at all. Boundaries often = hand-offs/breakpoints needing internal/external interaction, eg input or authorisation. Boundaries set by business not system constraints. Boundaries often correspond to bottlenecks, eg x cases awaiting authorisation . Subprocesses not arbitrary collections of actions, nor events in terms of a particular computer system: Eg not Run job C123 but Check customer’s credit rating .
  27. 27. Subprocess <ul><li>A subprocess is not : </li></ul><ul><ul><li>An arbitrary set of actions </li></ul></ul><ul><ul><li>A piece of functionality </li></ul></ul><ul><li>A subprocess is : </li></ul><ul><ul><li>A transition from one business status to the next </li></ul></ul><ul><li>In this example order process: </li></ul><ul><ul><li>‘ Check credit rating’ = transition from ‘awaiting Check credit rating’ to ‘awaiting Match against stock’ </li></ul></ul>
  28. 28. Where are we? <ul><li>So far: </li></ul><ul><ul><li>Business process </li></ul></ul><ul><ul><ul><li>Request </li></ul></ul></ul><ul><ul><ul><li>Outcome </li></ul></ul></ul><ul><ul><li>Subprocess </li></ul></ul><ul><li>Next: </li></ul><ul><ul><li>Business rule </li></ul></ul><ul><ul><li>Task </li></ul></ul>
  29. 29. Business rule Rules about what subprocesses Rules about sequence of subprocesses Rules about what happens inside a subprocess <ul><li>Subprocess ‘Check order’: </li></ul><ul><ul><li>All orders must be for a known customer </li></ul></ul><ul><ul><li>Items must be identifiable as goods the business trades in </li></ul></ul><ul><ul><li>Quantities must be specified </li></ul></ul><ul><ul><li>… etc. </li></ul></ul>
  30. 30. Business rule <ul><li>NOT: </li></ul><ul><ul><li>Process and subprocesses come first </li></ul></ul><ul><ul><li>Then decide what the rules are </li></ul></ul><ul><li>BUT: </li></ul><ul><ul><li>Rules come first </li></ul></ul><ul><ul><li>Definition of process = rule </li></ul></ul><ul><ul><ul><li>Where process starts and stops </li></ul></ul></ul><ul><ul><li>Analysis into subprocesses = rules </li></ul></ul><ul><ul><li>Some rules fit inside other rules, eg </li></ul></ul><ul><ul><ul><li>Rule that you have to achieve something </li></ul></ul></ul><ul><ul><ul><li>Rules about what to do to achieve it </li></ul></ul></ul>x ...which takes us to the concept of task
  31. 31. Task Rules about what happens inside a subprocess <ul><li>Subprocess ‘Check order’: </li></ul><ul><ul><li>All orders must be for a known customer </li></ul></ul><ul><ul><li>Items must be identifiable as goods the business trades in </li></ul></ul><ul><ul><li>Quantities must be specified </li></ul></ul><ul><ul><li>… etc. </li></ul></ul>
  32. 32. Task Check each order against business rules But what about invalid orders?  x OK Not OK Valid orders can pass to the next subprocess
  33. 33. Task All the work of the subprocess is contained within the tasks. ‘ Subprocess’ = container for the tasks. All orders go through the automatic check task, which runs business rules Some orders (perfect ones) only need to go through the automatic task Others (imperfect ones) are routed by the automatic task to the manual task Manual task to correct the errors The manual task then routes them back to the automatic task for rechecking
  34. 34. Task Example of a more complex task structure for subprocess: Check credit rating But the principle is the same: tasks & routing derived from applying rules to possible orders
  35. 35. Task <ul><li>Apply the concept of a </li></ul><ul><ul><li>Business rule </li></ul></ul><ul><li>to the </li></ul><ul><ul><li>Routing </li></ul></ul><ul><li>needed to achieve the work of a </li></ul><ul><ul><li>Subprocess </li></ul></ul><ul><li>and you get the concept of a </li></ul><ul><ul><li>Task </li></ul></ul><ul><li>Flow at subprocess level: </li></ul><ul><ul><li>From logical sequencing of process rules </li></ul></ul><ul><ul><li>Ignores variety of individual cases </li></ul></ul><ul><li>Flow at task level: </li></ul><ul><ul><li>From logic & logistics of applying process rules to variety of individual cases </li></ul></ul>
  36. 36. Draft BPM reference model <ul><li>Process architecture approach: </li></ul><ul><ul><li>Three levels </li></ul></ul><ul><ul><ul><li>A business consists of a finite set of processes </li></ul></ul></ul><ul><ul><ul><li>A process consists of a finite set of subprocesses </li></ul></ul></ul><ul><ul><ul><li>A subprocess consists of a finite set of tasks </li></ul></ul></ul><ul><ul><li>Result = process model </li></ul></ul><ul><ul><ul><li>Derived from </li></ul></ul></ul><ul><ul><ul><ul><li>Business rules </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>applied to </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Business data entities </li></ul></ul></ul></ul>
  37. 37. Process model Business (area) Process 1 Process 2 Process 3 <ul><li>Model can also show how processes interact with each other: </li></ul><ul><ul><li>One may initiate another </li></ul></ul><ul><ul><li>One may terminate another </li></ul></ul><ul><ul><li>One may determine outcome of another </li></ul></ul><ul><ul><li>… etc </li></ul></ul>… etc +
  38. 38. Transformation AS IS TO BE
  39. 39. Transformation <ul><li>Both are HOW not WHAT : </li></ul>TO BE AS IS AS IS TO BE At physical level: HOW Current solution, using current systems, people, partners etc At physical level: HOW Proposed solution, using proposed systems, people, partners etc
  40. 40. Transformation <ul><li>Need a stepping stone : </li></ul>AS IS TO BE Logical model
  41. 41. Transformation <ul><li>Logical model </li></ul><ul><ul><li>= step between TO BE and AS IS </li></ul></ul><ul><ul><ul><li>Implicit or explicit </li></ul></ul></ul><ul><ul><ul><li>= AS IS with all contingent constraints removed </li></ul></ul></ul><ul><ul><ul><ul><li>(Abstract away everything that could be otherwise) </li></ul></ul></ul></ul><ul><ul><ul><li>Logical model can only be realised in physical terms </li></ul></ul></ul><ul><li>TO BE : </li></ul><ul><ul><li>= best available/achievable implementation of logical model </li></ul></ul>
  42. 42. Logical model BPM reference model = principles for developing a logical process model aligned with the logical data model = Process model + Data model To support: business analysis; system selection & design; transformation; change management; process management; ...etc
  43. 43. A Model for Process and Transformation <ul><li>Draft BPM reference model </li></ul><ul><ul><li>Logical analysis of the business process </li></ul></ul><ul><ul><li>Advantages: </li></ul></ul><ul><ul><ul><li>Same model can support: </li></ul></ul></ul><ul><ul><ul><ul><li>Technology </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Process management </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Transformation </li></ul></ul></ul></ul><ul><ul><li>Analogy: </li></ul></ul><ul><ul><ul><li>Relational data model </li></ul></ul></ul>More than an analogy
  44. 44. Thank Y <ul><li>Chris Lawrence </li></ul><ul><li>Business Architecture Consultant </li></ul><ul><li>Old Mutual South Africa </li></ul><ul><li>Contact Information: </li></ul><ul><li>+27 76 610 0436 </li></ul><ul><li>[email_address] </li></ul>ou Thank Y ou

×