More Related Content

More from Marlon Dumas(20)

Fundamentals of Business Process Management: A Quick Introduction to Value-Driven Process Thinking

  1. Fundamentals of Business Process Management A Quick Introduction to Value-Driven Process Thinking Marlon Dumas University of Tartu Estonian BPM Roundtable – 10 Oct. 2013
  2. 2 Objectives 1. To inspire you to think about your processes as a way of improving your work and that of your colleagues 1. To show you how you can improve your business one process at a time 1. To reflect on which processes you should improve first, why and how?
  3. 3 Structure of the course • Part 1 – A quick tour of the BPM Lifecycle – Why BPM? – Overview of the BPM lifecycle – Introducing BPM in a company: What to do first? • Part 2 – Identifying, Prioritizing and Modeling Processes – Building a process architecture – Prioritization of business processes – Bare-bones introduction to process modeling • Part 3 – Analyzing and re-designing processes – Simple analysis techniques to look at first – Tips for process re-design
  4. 4 Companion Material • Fundamentals of Business Process Management (chapters 1, 2, 6, 8) – Introduction to BPM (freely available) – Identification – Analysis – Design Youtube – Marlon Dumas
  5. 5 Business Process Management (BPM) What is it? Body of principles, methods and tools to design, analyze, execute and monitor and continuously manage business processes
  6. 6 What is a Business Process?
  7. 7 fault-report-to-resolution process “My washing machine won’t work!” VALUE Customer Warranty? Parts StoreService Dispatch Technician Customer Call Centre Customer © Michael Rosemann
  8. 8 Processes and Outcomes • Every process leads to one or several outcomes, positive or negative – Positive outcomes deliver value – Negative outcomes reduce value • Fault-to-resolution process – Fault repaired without technician intervention – Fault repaired with minor technician intervention – Fault repaired and fully covered by warranty – Fault repaired and partly covered by warranty – Fault repaired but not covered by warranty – Fault not repaired (customer withdrew request)
  9. 9 Rule of thumb “If it does not make at least three people mad, it’s not a process.” Hammer and Stanton (1995)
  10. 10 Your turn • Think of a process in your organization: – Is it order-to-cash, procure-to-pay, fault-to-resolution… – Who is/are the customer(s)? – What value does this process deliver to its customer? – Who are the key actors of the process? – List at least 3 outcomes of the process.
  11. 11 Why BPM? The Technology Perspective Information Technology Process Change Yields Yields Business Value Index Group (1982) Enables
  12. 12 Why BPM? The Technology Perspective “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
  13. 13 Why BPM? The Management Perspective Roger Tregear: Practice Processes, BPTrends, July 2012
  14. 14 Why BPM? Roger Tregear: Practice Processes, BPTrends, July 2012
  15. 15 Why BPM?
  16. 16 BPM and Related Disciplines BPM is about managing and improving processes. Whatever tools it takes to do so are most welcome.
  17. 17 How to engage in BPM? After Tregear (2012)
  18. 18 Business Process Lifecycle
  19. 19 Process Identification – Steps • Enumerate major processes • Determine process boundaries (scoping) • Assess strategic relevance of each process • Assess of the “health” of each process • Qualify the culture and politics of each process • Back judgments with performance measures See Davenport (1993) Prioritized Processes & Performance Measures
  20. 20 Process Enumeration “Most businesses have just three core processes: 1. Sell stuff 2. Deliver stuff 3. Making sure you have stuff to sell and deliver” Geary Rummler
  21. 21 Core vs Support Processes (Porter)
  22. 22 Process enumeration • Typical number of processes is unclear • Trade-off: – ensuring process scope is manageable – process scope determines potential impact • Rule of thumb: 10-20 main processes
  23. 23 Exercise • Let us enumerate processes at your company
  24. 24 Process scoping • Processes are interdependent 1. Hierarchical relations: Main processes – subprocesses 2. Upstream–downstream relations • Key scoping questions: 1. When starts a given process instance? 2. When do we consider a process completed/closed? 3. What key objects does the process manipulates? 4. Who participates in the process? 5. Who owns the process?
  25. 25 Process Scoping Rules of Thumb • A well-scoped process: – Has a clear start, clear end (input, output) – Has a clear, coherent set of “main objects” and “participants” – Has a clear owner
  26. 26 Process Architecture Core processes Support processes Management processes Quote handling Product delivery Invoice handling Detailed quote handling process
  27. 27 Exercise • Let us scope 1-2 processes up to level 2
  28. 28 Process selection Three criteria: 1. Assess strategic relevance of each process  Strategic importance 1. Render high-level judgments of the “health” of each process  Potential dysfunction 1. Qualify the culture and politics of each process  Feasibility
  29. 29 Business Process PICK Chart
  30. 30 Back Health Judgments with Performance Measures
  31. 31 Business Process Lifecycle
  32. 32 Purposes of Process Modeling Communication, simulation, activity- based costing… Detailed Models including Data types, conditions, data mappings, fault handling… Integration, testing, deployment…
  33. 33 Business Process Modeling Notation (BPMN) • OMG Standard, supported by many tools: – Bizagi Process Modeller (free) – Signavio ( - subscription – Oracle BPA – “kind of free” – ARIS – very sophisticated but the opposite of free – IBM Websphere Business Modeler – Logizian – reasonable tradeoff – Visio – Your company might already have this – Paper and pen! - No excuse not to start
  34. 34 BPMN from 10 000 miles… • A BPMN process model is a graph consisting of four types of elements (among others):
  35. 35 Revised Order Management Process
  36. 36 When a claim is received, we first check if the claimant has a valid insurance policy. If not, the claimant the claim is rejected and the claimant is informed. Otherwise, the severity of the claim is evaluated. Based on the outcome (simple or complex claims), relevant forms are sent to the claimant. Once the forms are returned, we check them for completeness. If the forms are complete, we register the claim in the Claims Management system and the evaluation of the claim may start. Otherwise, the claimant is asked to update the forms. Upon reception of the updated forms, we check them again and continue. BPMN Exercise: Simplified Insurance Claim Registration
  37. 37 Guideline: Naming Conventions • Give a name to every event and task • For tasks: verb followed by business object name and possibly complement – Issue Driver Licence, Renew Licence via Agency • Avoid generic verbs such as Handle, Record… • Every XOR-split should be labelled with conditions – Policy is invalid, Claim is inadmissible • For events: object + past participle – Invoice received, Claim settled
  38. 38 When? Process Which? Data / Service / Product What? Function Who? Organization Process Modelling Viewpoints
  39. 39 Resource Modelling in BPMN • In BPMN, resource classes are captured using: – Pools – independent organizational entities, e.g. • Customer, Supplier, East-Tallinn Hospital, Tartu Clinic – Lanes – resource classes in the same organizational space and sharing common systems • Sales Department, Marketing Department • Clerk, Manager, Engineer
  40. 40 Example with Pools and Lanes
  41. 41 BPMN Exercise: Lanes, Pools • Claims Handling process at a car insurer A customer submits a claim by sending in relevant documentation. The Customer Service department checks the documents for completeness and registers the claim. The Claims Handling department picks up the claim and first checks the insurance policy. Then, an assessment is performed. If the assessment is positive, a garage is phoned to authorise the repairs and the payment is scheduled (in this order). In any case (whether the outcome is positive or negative), an e-mail is sent to the customer to notify the outcome.
  42. 42 BPMN Information Artifacts • Data Objects are a mechanism to show how data is required or produced by activities. – Are depicted by a rectangle that has its upper-right corner folded over. – Represent input and output of a process activity. • Data stores are containers of data objects that need be persisted beyond the duration of a process instance • Associations are used to link artifacts such as data objects and data stores with flow objects (e.g. activities). Data Store
  43. 43 Example: Data Object
  44. 44 When a claim related to a major car accident is evaluated, a clerk first retrieves the corresponding car accident report in the Police Reports database. If the report is retrieved, it is attached to the claim file. The claim file and the police report serve as input to a claims handler who calculates an initial claim estimate. Then, an “action plan” is created based on a “checklist”. Based on the action plan and the initial claims estimate, a claims manager negotiates a settlement with the customer. After this negotiation, the claims manager makes a final decision, updates the claim file to record this decision, and sends a letter to the claimant to inform him/her of the decision. Depict all relevant documents in the model. BPMN Exercise 3: Data Objects
  45. 45 Anything wrong with this model?
  46. 46 Is this better?
  47. 47 Modeling Guideline Start with a value chain • Good practice is that the top-level process should be simple (no gateways, no lanes) and should show the main phases of the process – Each phase then becomes a sub-process – Top-level process is basically a value chain • Introduce gateways and lanes at the next levels…
  48. 48 Guidelines: Modeling Levels • First level: start with value chain • Next level add: – Main decisions – Handoffs (lanes, see later) • Only at the more detailed level add procedural aspects: – Parallel gateways – Input and output data objects, data stores – Different types of events – And as much detail as you need
  49. 49 Showing the value chain with sub- processes
  50. 50 Question? • What is the biggest pitfall of process modeling? 1. Using the wrong type of gateways, e.g. decision gateway instead of parallel gateways 2. Writing process models from top-to-bottom instead of left-to-right 3. Not following strictly the rules of the BPMN notation 4. Spending lots of time to produce detailed models that nobody uses
  51. 51 Business Process Lifecycle
  52. 52 Process Analysis Techniques
  53. 53 Purposes of Qualitative Analysis
  54. 54 Eliminating Waste "All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value-adding wastes ” Taiichi Ohno
  55. 55 7+1 Sources of Waste 1. Unnecessary Transportation (send, receive) 2. Inventory (large work-in-process) 3. Motion (drop-off, pick-up, go to) 4. Waiting (waiting time between tasks) 5. Over-Processing (performing what is not yet needed or might not be needed) 6. Over-Production (unnecessary cases) 7. Defects (rework to fix defects) 8. Resource underutilization (idle resources) Source: Seven Wastes defined by Taiichi Ohno 8th waste coined by Ben Chavis, Jr.
  56. 56 Value-Added Analysis 1. Decorticate the process into steps 2. Classify each step into: – Value-adding (VA): Produces value or satisfaction to the customer. • Is the customer willing to pay for this step? – Business value-adding (BVA): Necessary or useful for the business to run smoothly, or required due to the regulatory environment, e.g. checks, controls • Would the business potentially suffer in the long-term if this step was removed? – Non-value-adding (NVA) – everything else including handovers, delays and rework
  57. 57 Example (Equipment Rental Process)
  58. 58 Example – Equipment Rental Process
  59. 59 Issue Register • Purpose: to categorise identified issues as part of as-is process modelling • A table with the following columns (possibly others): – issue number – name – Description/explanation – Impact: Qualitative vs. Quantitative – Possible resolution
  60. 60 Issue Register (Equipment Rental) Name Explanation Assumptions Qualitative Impact Quantitative Impact Equipment kept longer than needed Site engineers keep the equipment longer than needed by means of deadline extensions BuildIT rents 3000 pieces of equipment p.a. In 10% of cases, site engineers keep the equipment two days longer than needed. On average, rented equipment costs 100 per day 0.1 × 3000 × 2 × 100 = 60,000 p.a. Rejected equipment Site engineers reject delivered equipment due to non-conformance to their specifications BuildIT rents 3000 pieces of equipment p.a. Each time an equipment is rejected due to an internal mistake, BuildIT is billed the cost of one day of rental, that is 100. 5% of them are rejected due to an internal mistake Disruption to schedules. Employee stress and frustration 3000 × 0.05 × 100 = 15,000 p.a. Late payment fees BuildIT pays late payment fees because invoices are not paid by the due date BuildIT rents 3000 pieces of equipment p.a. Each equipment is rented on average for 4 days at a rate of 100 per day. Each rental leads to one invoice. About 10% of invoices are paid late. Penalty for late payment is 2%. 0.1 × 3000 × 4 × 100 × 0.02 = 2400 p.a.
  61. 61 Techniques for issue analysis • Cause-effect diagrams • Why-why diagrams • Pareto charts
  62. 62 Cause-effect diagram (rejected equipment)
  63. 63 Why-why analysis (equipment rental) Site engineers keep equipment longer, why? • Site engineer fears that equipment will not be available later when needed, why? – time between request and delivery too long, why? • excessive time spent in finding a suitable equipment and approving the request, why? – time spent by clerk contacting possibly multiple suppliers sequentially; – time spent waiting for works engineer to check the requests;
  64. 64 Pareto chart • Useful to prioritize a collection of issues or factors behind an issue • Bar chart where the height of the bar denotes the impact of each issue
  65. 65 Pareto chart (excessive rental expenses)
  66. 66 Business Process Lifecycle
  67. 67 Process Redesign • Purpose: Identify possibilities for improving the design of a process: “as is”  “to be” • No silver-bullet: requires creativity • Redesign heuristics can be used to generate ideas Descriprive modelling of the real world (as-is) Prescriptive modelling of the real world (to-be)
  68. 68 Process Redesign Approaches
  69. 69 The Ford Case Study (Hammer 1990) Ford needed to review its procurement process to: • Do it cheaper (cut costs) • Do it faster (reduce turnaround times) • Do it better (reduce error rates) Accounts payable in North America alone employed > 500 people and turnaround times for processing POs and invoices was in the order of weeks
  70. 70 The Ford Case Study • Automation would bring some improvement (20% improvement) • But Ford decided not to do it… Why? a) Because at the time, the technology needed to automate the process was not yet available. b) Because nobody at Ford knew how to develop the technology needed to automate the process. c) Because there were not enough computers and computer-literate employees at Ford. d) None of the above
  71. 71 The correct answer is … Mazda’s Accounts Payable Department
  72. 72 How the process worked? (“as is”)
  73. 73 How the process worked? (“as is”)
  74. 74 How the process worked? (“as is”)
  75. 75 How the process worked? (“as is”)
  76. 76 How the process worked? (“as is”)
  77. 77 How the process worked? (“as is”)
  78. 78 Reengineering Process (“to be”)
  79. 79 Reengineering Process (“to be”)
  80. 80 Reengineering Process (“to be”)
  81. 81 Reengineering Process (“to be”)
  82. 82 Reengineering Process (“to be”)
  83. 83 Reengineering Process (“to be”)
  84. 84 The result… • 75% reduction in head count • Material control is simpler and financial information is more accurate • Purchase requisition is faster • Less overdue payments  Why automate something we don’t need to do? Automate things that need to be done.
  85. 85 Principles of BPR 1. Capture information once and at the source 2. Subsume information-processing work into the real work that produces the information 3. Have those who use the output of the process drive the process 4. Treat geographically dispersed resources as if they were centralized
  86. 86 Exercise – Claims Handling in a Large Insurance Company • Claims handling for replacement of automobile glass • Under the existing process the client may have to wait 1-2 weeks before being able to replace the damaged auto glass ⇒ Goal – A radical overhaul and of the process to shorten the client waiting time © Laguna & Marklund
  87. 87 Overview of the existing claims process Client Local independent agent Approved glass vendor Claims processing center Request additional information Pay Notify agent File claim Give instructions Forward claim Request quote Provide quote Pay © Laguna & Marklund
  88. 88 Existing claims process 1. Client notifies local agent that she wishes to file a claim. She is given a claims form and told to obtain a cost estimate from a local glass vendor. 2. When the claims form is completed the local agent verifies the information and forwards the claim to a regional processing center. 3. The processing center logs the date and time of the claim’s arrival. The data is entered into a computer-based system (for record keeping only) by a clerk. The claim is then placed in a hard copy file and passed on to a claims representative. 4. a) If the claims representative is satisfied with the claim it is passed along to several others in the processing chain and eventually a check is issued and sent to the client. b) If there are problems with the claim the representative mails it back to the client for necessary corrections. 5. When the client receives the check she can go to the local glass vendor and replace the glass. © Laguna & Marklund
  89. 89 Process Redesign Approaches
  90. 90 Incremental Process Re-design 1. Select issues to address, improvement goals 2. Map goals to process performance measures and set objectives/targets 3. Apply re-design heuristics on the “as is” process model and analyze the tradeoffs 4. Select promising “change options”, justify and prioritize their implementation
  91. 91 Costs Quality Time Flexibility Process Redesign Tradeoffs
  92. 92 Redesign Heuristics 1. Task elimination 2. Task composition 3. Triage 4. Resequencing 5. Parallelism 6. Process specialization and standardization 7. Resource optimization 8. Communication optimization 9. Automation Each heuristics improves one side of the devil’s quadrangle, generally to the detriment of others
  93. 93 Sample Heuristics (8) Communication optimization • Reduce the number of messages to be exchanged with customers and business partners – But avoid front-loading the process too much – Not necessarily suitable if customer contact is desirable • Monitor customer interactions, record exceptions, determine what to front-load/back-load • Try to automate handling, recording and organization of messages (send/receive). (T+,Q+,C+/-,F-)
  94. 94 Specific Guidelines The Complete Kit Concept • Many processes follow the “complete kit” concept: – Work should not begin until all pieces necessary to complete the job are available • In such cases, consider three principles: – Provide complete and easy-to- follow instructions for those who will initiate the process. – If a process cannot start, the client should be notified of all defects that could be reasonably identified at the onset of the process. – Consider the tradeoff between “incomplete-kit” process initiation and roundtrip to revise and resubmit a request. Michael zur Muehlen: “Service Processes: The Customer at the Center?”
  95. 95 Final Words • Any process is better than no process • A good process is better than a bad process • Even a good process can be improved Michael Hammer (1948 – 2008)

Editor's Notes

  1. Business Process Management (BPM) is the art and science of overseeing how work is performed in an organization in view of ensuring consistent outcomes and identifying and taking advantage of improvement opportunities. In this context, the term ``improvement'' may take different meanings depending on the objectives of the organization. Typical examples of improvements include reducing costs, reducing execution times and reducing error rates. Importantly, BPM is not about improving the way individual activities are performed, but rather, it is about managing entire chains of events, activities and decisions that ultimately add value to the organization. Within the broad context of the above definition, BPM regroups a body of methods for managing business operations on the basis of process models. Process models represent the understanding that people in the organization have about how work is done or should be done. They act as the bridge between business operations and IT systems. They allow us to understand how IT systems contribute to adding value to the organization by streamlining its work practices.
  2. Events correspond to things that happen ``atomically'', meaning that they have no duration. For example, the arrival of a plant to the depot is an event. This event may trigger the execution of series of activities. For example, when a plant arrives, the site engineer inspects the plant. This inspection is an activity, in the sense that it takes time. When an activity is rather simple and takes relatively little time, we call it a task. For example, if the inspection that the site engineer performs is quite simple -- e.g. just checking that the plant received corresponds to what was ordered -- we can say that the ``plant inspection'' is a task. If on the other hand the inspection of the plant requires many steps -- such as checking that the plant fulfills the specification included in the purchase order, checking that the plant is in working order, and checking the plant comes with all the required accessories and safety devices -- we will treat it as an ``activity''. The distinction between task and activity is not always clear-cut. This is why, very often people will use the term task and activity interchangeably. Order-to-cash: This is a process that starts when a customer places an order to purchase a product or a service, and ends when the product or service in question has been delivered and the corresponding payment has been received. An order-to-cash process encompasses activities such as purchase order verification, shipment (in the case of physical products), delivery, invoicing, payment receipt and acknowledgment. Quote-to-order: This process typically precedes the order-to-cash process. It starts from the point when a ``request for quote'' is received from a customer, to the point when the customer places a purchase order. The order-to-cash process takes the relay from that point on. The combination of a quote-to-order and the corresponding order-to-cash process is called a quote-to-cash process. Procure-to-pay: This is a process that starts when a stakeholder within an organization -- typically an employee -- determines that a given product or service needs to be purchased. It ends when the product or service has been delivered and paid for. A procure-to-pay process includes activities such as approving the purchase, obtaining quotes, selecting a supplier, issuing a purchase order, receiving the goods (or consuming the service), checking and paying the invoice. Procure-to-pay can be seen as the dual of quote-to-cash in the context of business-to-business interactions. For every procure-to-pay process there is a corresponding quote-to-cash process on the supplier's side. Issue-to-resolution. This is a process that starts when a customer raises a problem, such as a complaint related to a defect in a product or an issue encountered when consuming a service. The process continues until the customer, the supplier, or preferably both of them, agree that the issue has been resolved. A variant of this process can be found in insurance companies that have to deal with ``insurance claims''. This variant is often called claim-to-resolution.
  3. The execution of a process leads to one or several \emph{outcomes}. For example, the above process leads to a plant being used by BuildIT, as well as a payment being made to the plant's supplier. These outcomes deliver \emph{value} to the key actors involved in the process, which in this example are BuildIT and the supplier. In some cases, this value is not achieved or is only partially achieved. For example, when a plant is returned, no value is gained, neither by BuildIT nor by the supplier. This corresponds to a \emph{negative outcome}, as opposed to a \emph{positive outcome} that delivers value to the actors involved.
  4. 10 oktober 2013
  5. BPM provides a natural ground for bridging IT and business, because many (perhaps most) IT projects in enterprises are ultimately aimed at improving a business process
  6. Two points: We should remember all these disciplines have a common goal: to improve business performance and business value. So one should never pitch one discipline against another dogmatically. BPM is about managing and improving processes whatever it takes to do this. In some situations (e.g. continuous improvement initiatives) Six Sigma techniques are handy, so sure, let’s use them.
  7. 10 oktober 2013
  8. 10 oktober 2013
  9. 10 oktober 2013
  10. 10 oktober 2013
  11. There are three dimensions where we typically look for process metrics: cost, time and quality. Do it faster, do it cheaper, do it better.
  12. It is worth emphasizing here that activities located in two parallel paths do not need to be performed simultaneously. For example, “Send invoice” and “Ship goods” need not occur both at the same time, although due to a cosmic coincidence, they could happen at the same time. Instead, it might happen that first the invoice is sent and later the goods are shipped. Or things may happen in the reverse order.
  13. The Functional perspective, indicates What tasks/function are happening in the process? The Control-flow perspective, indicates when should an activity be performed, that is, i n what order should activities and events occur? The resource perspective (also called organisational perspective) indicates Who performs which activity? Finally, the d ata perspective indicate which data are necessary to perform each activity and which data are produced by each activity in the process?
  14. The process now includes two departments within the supplier organization…The purchase order received by the Sales & Distribution department has to be checked against the stock. The order details are sent to the Warehouse department that returns an availability notification. If the purchase order is confirmed, the Warehouse department collects the shipping details from the customer and ships the goods. The Sales & Distribution department sends an invoice to the customer who then makes the payment.
  15. The Purchase Order document serves as an input to the stock availability check. Based on the outcome of this check, the status of document is updated, either to “approved” or “rejected”. We include here the relevant documents in the process model.
  16. Hammer, M., (1990). "Reengineering Work: Don't Automate, Obliterate", Harvard Business Review, July/August, pp. 104–112.
  17. Regarding the first principle, it is worth citing examples of process improvement patterns such as Self-Service and Vendor-Managed Inventory Control. Regarding, the second principle, self-service is again a typical example, particularly the ability for customers or workers to enter data themselves that goes directly into the organization’s databases Regarding the third principle, we can refer back to the idea of performing PO matching at delivery, rather than postponing this till the invoice is received
  18. Boaz Ronen, “The Complete Kit Concept,” International Journal of Production Research, Volume 30, Issue 10 October 1992, pages 2457 – 2466.
  19. 8:52 in video 10 oktober 2013