The document presents a draft BPM (Business Process Management) reference model, emphasizing the importance of deriving the model from logical analysis of business processes rather than from existing technologies. It details how processes, subprocesses, and tasks can be structured around business rules to achieve requested outcomes, highlighting the need for systematic modeling in transformation and management. Overall, it argues for a generic and abstract approach to understanding business processes that can adapt across various sectors.

1. Chris Lawrence Business Architecture Consultant Old Mutual South Africa Session Title: A Model for Process and Transformation Welcome to Transformation and Innovation 2007 The Business Transformation Conference Welcome

2. A Model for Process and Transformation WfMC BPM and Workflow Handbook 2007 Paper: Business Process Architecture and the Workflow Reference Model Argument: Derive BPM reference model not from workflow or BPM technology , but from logical analysis of the business process

3. A Model for Process and Transformation Draft BPM reference model Logical analysis of the business process Advantages: Same model can support: Technology Process management Transformation Analogy: Relational data model

4. WHAT versus HOW Analogy: Logical data model v physical data design Process rules even if no systems were used Process features relating to a specific implementation

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. Draft BPM reference model Objectives: Understand process as WHAT To get best available HOW Initial scope: ‘ Administration’: Processing orders & applications, granting approval, carrying out instructions …etc etc Sales, financial services, central & local government, education, travel, tourism …etc etc etc

7. Administration Service to ‘end-customer’ Implicit or explicit ‘request’ Rule-governed Right and wrong ways Standard v exceptions Sequence; completeness Increasingly supported by computer systems People deal with exceptions and special cases People make rules rather than follow them

8. Administration Content & rules can be treated abstractly Essence survives translation into different formats (brain, paper, digital…) Eg life insurance policy: 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. Administration Concrete object Cannot be translated into another form and stay an armchair Life insurance policy Abstract entity Can be translated into another form Only has to exist as hard copy if rules say so

10. Process Process Input(s) Input(s) Output(s) Familiar model

11. Process Order process Input(s) Received goods Business process Customer order

12. Process Addition process 2 3 5 Calculation process

13. Process Photosynthesis Water Carbon dioxide Sunlight Glucose Oxygen Natural process

14. Process This model is generic Nothing special about business process Process Input(s) Input(s) Output(s)

15. Process Process 1 Input 1 Output 1

16. Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 =

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. Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 Input 4 Process 3 Output 4

19. Process Input 1 Input 3 Process 4 (1+2+3) Output 4 Output 3

20. Process This model is also indefinite Where does the process start and stop? For a business process we need something more precise Process Input(s) Input(s) Output(s)

21. Business process For a business process we need to identify: A particular kind of input A particular kind of output 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. 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. Business process The business process will involve following rules Rules may or may not be satisfied Requested outcome may not be achieved: Eg ordered goods unavailable; loan application unsuccessful; … But just like the requested outcome, any alternative outcome will also be correct in terms of the rules of the process

24. Business process Business process Order process Input(s) Received goods Customer order

25. Subprocess A business process can normally be broken down into a finite series of subprocesses …

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. Subprocess A subprocess is not : An arbitrary set of actions A piece of functionality A subprocess is : A transition from one business status to the next In this example order process: ‘ Check credit rating’ = transition from ‘awaiting Check credit rating’ to ‘awaiting Match against stock’

28. Where are we? So far: Business process Request Outcome Subprocess Next: Business rule Task

29. Business rule Rules about what subprocesses Rules about sequence of subprocesses Rules about what happens inside a subprocess Subprocess ‘Check order’: All orders must be for a known customer Items must be identifiable as goods the business trades in Quantities must be specified … etc.

30. Business rule NOT: Process and subprocesses come first Then decide what the rules are BUT: Rules come first Definition of process = rule Where process starts and stops Analysis into subprocesses = rules Some rules fit inside other rules, eg Rule that you have to achieve something Rules about what to do to achieve it x ...which takes us to the concept of task

31. Task Rules about what happens inside a subprocess Subprocess ‘Check order’: All orders must be for a known customer Items must be identifiable as goods the business trades in Quantities must be specified … etc.

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. 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. 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. Task Apply the concept of a Business rule to the Routing needed to achieve the work of a Subprocess and you get the concept of a Task Flow at subprocess level: From logical sequencing of process rules Ignores variety of individual cases Flow at task level: From logic & logistics of applying process rules to variety of individual cases

36. Draft BPM reference model Process architecture approach: Three levels A business consists of a finite set of processes A process consists of a finite set of subprocesses A subprocess consists of a finite set of tasks Result = process model Derived from Business rules applied to Business data entities

37. Process model Business (area) Process 1 Process 2 Process 3 Model can also show how processes interact with each other: One may initiate another One may terminate another One may determine outcome of another … etc … etc +

38. Transformation AS IS TO BE

39. Transformation Both are HOW not WHAT : 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. Transformation Need a stepping stone : AS IS TO BE Logical model

41. Transformation Logical model = step between TO BE and AS IS Implicit or explicit = AS IS with all contingent constraints removed (Abstract away everything that could be otherwise) Logical model can only be realised in physical terms TO BE : = best available/achievable implementation of logical model

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. A Model for Process and Transformation Draft BPM reference model Logical analysis of the business process Advantages: Same model can support: Technology Process management Transformation Analogy: Relational data model More than an analogy

44. Thank Y Chris Lawrence Business Architecture Consultant Old Mutual South Africa Contact Information: +27 76 610 0436 [email_address] ou Thank Y ou