The Power of Process
Download as PPT, PDF1 like335 views
The document discusses process improvement opportunities for a request for service process used by an organization to obtain additional computing resources. Currently the process involves many roles, handoffs, and manual activities, taking an average of 47 days to complete. A case study is presented of analyzing the current "as-is" process and identifying issues like long lead times, lack of end-to-end ownership, and functional silos. The presentation recommends taking a systematic approach to developing new process requirements and redesigning the end-to-end "to-be" process to streamline activities and approvals.
The Power of Process
- 1. The Power of Process For Driving Business Improvement Fred Hess, Paramount Strategies LLC Brainstorm Conference - September 28-30, 2008 1
- 2. Process is the Clark Kent of business ideas: seemingly mild and unassuming but actually amazingly powerful. Michael Hammer, Agenda, 2001 2
- 3. The House-Building Contest How long does it take to build a house? My baseline => 4 months The rules are simple: normal tools must be used building codes must be followed no prefabricated components only the concrete curing can be accelerated must be finished and landscaped The record? 2 hours, 47 minutes! Do you think process had something to do with it? 3
- 4. Insights Schedule improvement = 99.6%! May not be the most cost effective approach Percentage of non-value added tasks? Response to proposed project? Teamwork - single focus Flawless execution Lessons learned? 4
- 5. Definition of Process A process is a set of activities that produce products and services for customers. GAO’s BPR Glossary of Terms A process is an organized group of related activities that together create a result of value to customers. Michael Hammer, Agenda, 2001 The term process is a proxy for a business operation which is comprised of process steps, people and tools. Fred Hess, 2004 5
- 6. Common Issues in Companies CEO VP VP VP VP VP Procure Ship Sales Order Mfg ment ping Functional departments are usually measured and controlled vertically 6
- 7. Common Issues in Companies CUSTOMER CEO Item Order VP VP Dept Mterics VP VP VP Procure Ship Sales Order Mfg ment ping Work Work usually proceeds through the company horizontally 7
- 8. An Aerospace View CUSTOMER PM Contract Deliverable FM FM Functional Focus FM FM FM Design Stress Electrical Procur Mfg Work Work usually proceeds through the company horizontally 8
- 9. Insights Department measurements and the flow of work are typically at right angles to each other These vertical measurements typically do not measure flow of work and can sometimes cause behaviors that interfere with the flow Aerospace and other large enterprises have many more functions than ordinary businesses so the silo effect is greater If there are no metrics or ownership related to the flow of work, it will probably not improve 9
- 10. A Real Life Example – Telecom Manufacturer Client defined processes Proposal The client team, with IBM help, had Sales modeled the 8 As-Is processes and were now designing the To-Be Finance processes, starting with Collections. Order Mfg Do these really look like processes? Deployment Billing Collections 10
- 11. A Real Life Example – Telecom Manufacturer I convinced them that their 8 “processes” were phases of the same process. Finance Process Submit Propose Sell Mfg Deploy Collect Product Order Invoice What was the common business object that made it the same process? What might this process be called? 11
- 12. The Proposal to Cash Process The common business object is the “Order” CUSTOMER Order Finance Process Submit Propose Sell Make Deploy Collect Product Order Invoice Collections were running at 50% Customer satisfaction was poor. How would you find the root causes? 12
- 13. Analyzing the Proposal to Cash Process CUSTOMER Collect Proposal Sales Order Mfg Deploy Billing ions What were the root causes? What group suffered the most pain? At what point did the salesman get his commission? Who did the customer call for status or problems? Who was responsible for customer satisfaction? 13
- 14. Root Cause Analysis Customer Installation Caused By facility not Schedule not on ready Caused By slip schedule Caused By Caused By Customer schedule No one is Customers won’t not tracked Caused By responsible pay until system installed Caused By Caused By Installation not correct Order must Collections rate not match acceptable proposed Configurator Caused By Customer pays configuration out of date slowly Caused By Caused By (SAP) Caused By Caused By Order not correct Caused By Configurator Customers Caused By Proposed not available can’t pay configuration not correct Caused By Prices in 3 different databases 14
- 15. Findings The root cause of the collections problem was primarily in sales No single role owned the customer for the duration of the transaction No one realized the number of potential customer touchpoints There was no mechanism for collecting and utilizing all customer information 15
- 16. A Touchpoint Analysis Was Performed # TOUCH POINT DOCUMENT CUST EFFECT. EFFIC. ACCESS OVERALL TREND BUSINESS CURRENT IMPACT/ DESIRED IMPACT/ GAP SAT CHANNELS PERF IMPACT CHARACTERISTICS EXPERIENCE 1 Marketing/Sales 2 Advertising Branding Communications Product Launch Public Relations Trade Shows 6 Future Product Development Develop Customer Plan Develop Service Plan Approve Service Plan Develop Partnership Plan Develop Account Plan Clarification of Customer's Business Reqmt's 16
- 17. How did we proceed? Customer Salesman Order/Finance Buyer Mfg Engr Deployment Billing Collections Got all roles together in workshop Developed to-be requirements Worked out the handoffs and interactions Designed the end-end to-be process 17
- 18. Recommendations Adjust the SAP business rules Maintain current configurators and price databases Form customers teams Appoint a Chief Customer Officer Acquire/develop a customer information database and application 18
- 19. Insights The focus on departmental, instead of end-to- end, processes precluded their ability to determine the root cause of the issues There was no ownership of the end-to-end process measurements Business growth of 30%/year contributed to lack of focus on the customer 19
- 20. The Request for Service Process An outsource process for obtaining additional computing resources Projects take from 8 to 16 weeks to implementation Average transaction time = 47 days Could take as long as 14 days to obtain a license key to run an installed application Quick-hit teams trying to improve process performance 20
- 21. The Approach – Step 1 Issues 1. Analyze the Current State Root Cause Desired R2 Dev. Concept Desgn 1 Use Existing DE1 Cgng R3 Reqts DE2 Approve DE3 Chnge Capabilities R2 DE1 Desgn Choose 1 R3 DE2 Cgng Model OK Multithread DE3Results 1 Choose Chnge Concept Choose ChooseConcept Chnge 1 Dev. Concept Multithread Design Eng Dsgn Disapprove scope Reqts OK 2 Approve Design 2 Model not Results R4 Design Eng Dsgn Disapprove scope R4 Model OK Design Use Existing Model not Chnge OK Number Assign R1 EA1 R1 EA1 Eng. Administrator Assign Eng. Administrator Number R2 R4 R2 R4 R1 R1 TL1 Check Concept TL3 TL3 Team Scope TL2 Choose 1 TL1 Check TL2 Choose 1 Work Team Scope Leader Concept Reject Leader Work Reject Approve Approve Analysis Submit 1 A1 A1 Analyst Submit Analyst Doc. Detail 1 Analysis Dwg Dwg Doc. Detail Drafter D1 D1 Drafter Solution Ideas R3 Develop Spec. R3 TW1 Technical Writer TW1 Technical Writer Develop Spec. Model RN0-1 Design Create/Modify RN0-1 Eng Designer Design Eng Designer Create/Modify Model Check Drwgs DrwgsC1 Checker C1 Check Checker DesignFlow As-is DesignFlow To-be Organization Application Process Enablers Reqmts Enablers As- Is To -Be Org Design, Application Teaming, Skills, Function, Data, Knowledge Infrastructure 21
- 22. Current State Process E2E Current RFS Process (As-Is) Ends With: Implementation plan and Starts With: Request for Service solution components ready for implementation Process Roles Obtain Requester Approval End Initiate Request Delivery Package Request Project Evaluate Approve Mgr Request Approve Solution Develop QA2/3 Check (state 33) Rework Loop Team Solution Develop Obtain & Deliver Approval Prop Mgr Proposal Outsource Obtain 40 State Mgr Approval Perform Procure Acquisition Services = Silo 22
- 23. The Approach – Step 2 Issues Project Goal: Root Systematic and Repeatable Cause Approach Desired R2 Dev. Concept Desgn 1 Use Existing DE1 Cgng R3 Reqts DE2 Approve DE3 Chnge Capabilities R2 DE1 Desgn Choose 1 R3 DE2 Cgng Model OK Multithread DE3Results 1 Choose Chnge Concept Choose ChooseConcept Chnge 1 Dev. Concept Multithread Design Eng Dsgn Disapprove scope Reqts OK 2 Approve Design 2 Model not Results R4 Design Eng Dsgn Disapprove scope R4 Model OK Design Use Existing Model not Chnge OK Number Assign R1 EA1 R1 EA1 Eng. Administrator Assign Eng. Administrator Number R2 R4 R2 R4 R1 R1 TL1 Check Concept TL3 TL3 Team Scope TL2 Choose 1 TL1 Check TL2 Choose 1 Work Team Scope Leader Concept Reject Leader Work Reject Approve Approve Analysis Submit 1 A1 A1 Analyst Submit Analyst Doc. Detail 1 Analysis Dwg Dwg Doc. Detail Drafter D1 D1 Drafter Solution Ideas R3 Develop Spec. R3 TW1 Technical Writer TW1 Technical Writer Develop Spec. Model RN0-1 Design Create/Modify RN0-1 Eng Designer Design Eng Designer Create/Modify Model Check Drwgs DrwgsC1 Checker C1 Check Checker DesignFlow As-is DesignFlow To-be Organization Application Process Enablers Reqmts Enablers As- Is To -Be 2. Develop the Requirements Org Design, Application Teaming, Skills, Function, Data, Knowledge Infrastructure 23
- 24. As-Is Baseline - Analysis The current Request for Service (RFS) is burdened by a process that contains a high number of roles, tools, hand-offs, manual activities and rework. 2. Evaluate 3. Develop 4. Develop 5. Obtain 6. Perform 1. Initiate and Route Solution and Deliver Approvals Acquisition Request Request State 20, 23 Proposal to State 40, 50, Services State 0, 5, 10 State 15 Customer 60, 100 State 162, 1 63 State 30, 33 Receive Request Finalize Project Validate Request Scope Summary Route to Customer Type Identify Required Finalize Proposal for Approval and Assign the RFS Acquire Hardware and Work Products Outputs Signoff Category + Queue Software Contact Customer Obtain Pricing Perform Customer Reroute as Needed Schedule and Begin Within 5 Days Agreement Review/Response Submit RFS Validate Form Assign Resources Receive Signature / Implementation Perform QA2/3 Content and Notify Gather/Validate Submit to Rework as Needed Requester Requirements Governance for Route to Governance Validate Funding Perform Quality Review and for Final Approval Information Review w/in Team Concurrence Obtain Governance Log Project/New Finalize Solution Rework as needed Approval Business Request Outputs Deliver FAL and Assign to Perform QA1 Project Scope Resource Summary to Review Customer Activities per step: 37 + 14 + 56 + 26 + 20 + 56 = 209 Choices per step: 19 + 6 + 36 + 13 + 4 + 36 = 114 Handoffs per step: 9 + 4 + 13 + 9 + 7 + 24 = 66 IT Tools per step: 15 9 15 11 10 14 = 32 24
- 25. Major Contributor to Schedule Delay – Capital Requisition Approval 13 roles required for approval 25
- 26. Findings Excessive number of non-integrated applications Many manual handoffs Quick-fix teams were changing rules weekly Lengthy approval cycles Manual tracking Multiple procurement systems 26
- 27. The Approach – Step 3 Issues Project Goal: Root Systematic and Repeatable Cause 3. Develop the To-Be Approach Process Desired R2 Dev. Concept Desgn 1 Use Existing DE1 Cgng R3 Reqts DE2 Approve DE3 Chnge Capabilities R2 DE1 Desgn Choose 1 R3 DE2 Cgng Model OK Multithread DE3Results 1 Choose Chnge Concept Choose ChooseConcept Chnge 1 Dev. Concept Multithread Design Eng Dsgn Disapprove scope Reqts OK 2 Approve Design 2 Model not Results R4 Design Eng Dsgn Disapprove scope R4 Model OK Design Use Existing Model not Chnge OK Number Assign R1 EA1 R1 EA1 Eng. Administrator Assign Eng. Administrator Number R2 R4 R2 R4 R1 R1 TL1 Check Concept TL3 TL3 Team Scope TL2 Choose 1 TL1 Check TL2 Choose 1 Work Team Scope Leader Concept Reject Leader Work Reject Approve Approve Analysis Submit 1 A1 A1 Analyst Submit Analyst Doc. Detail 1 Analysis Dwg Dwg Doc. Detail Drafter D1 D1 Drafter Solution Ideas R3 Develop Spec. R3 TW1 Technical Writer TW1 Technical Writer Develop Spec. Model RN0-1 Design Create/Modify RN0-1 Eng Designer Design Eng Designer Create/Modify Model Check Drwgs DrwgsC1 Checker C1 Check Checker DesignFlow As-is DesignFlow To-be Organization Application Process Enablers Reqmts Enablers As- Is To -Be Org Design, Application Teaming, Skills, Function, Data, Knowledge Infrastructure 27
- 28. To-Be Process - 1st Release 2. Evaluate 3. Develop 4. Develop 5. Obtain 6. Perform 1. Initiate and Route Solution and Deliver Approvals Acquisition Request Request State 20, 23 Proposal to State 40, 50, Services State 0, 5, 10 State 15 Customer 60, 100 State 162, 163 State 30, 33 Receive Request Finalize Project Validate Request Scope Summary Route to Customer Type Identify Required Finalize Proposal for Approval and Assign the RFS Acquire Hardware and Work Products Outputs Signoff Category + Queue Software Contact Customer Obtain Pricing Perform Customer Reroute as Needed Schedule and Begin Within 5 Days Agreement Review/Response Submit RFS Validate Form Assign Resources Receive Signature / Implementation Perform QA2/3 Content and Notify Gather/Validate Submit to Rework as Needed Requester Requirements Governance for Route to Governance Validate Funding Perform Quality Review and for Final Approval Information Review w/in Team Concurrence Obtain Governance Log Project/New Finalize Solution Rework as needed Approval Business Request Outputs Deliver FAL and Assign to Perform QA1 Project Scope Resource Summary to Review Customer As-Is Activities 37 + 14 + 56 + 26 + 20 + 56 = 209 per step To-Be Activities 11 + 7 + 28 + 7 + 7 + 49 = 109 per step 28
- 29. Results - Phase 1 Removed non-value add activities 209 => 109 Reduced roles from 37 to 30 Reduced applications form 32 to 24 Reduced handoffs from 66 to 30 Removed many sources of rework Implement with WBI workflow Focus on 21 most critical process steps Set objectives for Phases 2 and 3 29
- 30. Insights There was a lack of both a tool and data architecture Lack of clear process governance The process was assembled, not designed The quick-fix attempts actually degraded process performance 30
- 31. The Dell Process Advantage Maintain Identify Config Get Order Install Inven Upgrade Need Solution OK tory Extranet Buy Order Ass’y Ship Parts Look upstream and downstream for additional improvement opportunities 31
- 32. Insights Dell’s integration with their customer’s processes added value Control of standard configurations Workflow for approval and ordering Easy inventory management Provided clear competitive advantage Harder for customers to buy from competitors 32
- 33. Process Can Drive Schedule Improvement Proxy for elapsed time Time • What percentage of the time (schedule) would you estimate is in the tasks? • How much in the white space? 33
- 34. Process Can Drive Cost Improvement • The Cost of process execution equals the sum of the cost of all activities times the number those activities are executed. • How much cost is in rework? 34
- 35. Process Can Provide Tool Requirements Roles 1 hr • Tool requirements are obtained by compiling the functional requirements from all the tasks that use the tool. • Integration requirements can be derived by identifying tasks that require more than one tool. 35
- 36. Process Can Provide Skill Requirements • Skill requirements are obtained by compiling the requirements from all the tasks on the role swimlane 36
- 37. Process Has Power An end-end cross-functional process can: define how all groups/departments/roles must work together to achieve the business objectives show where the time is spent and where to reduce it identify the cost of the activities in the process and show which ones can be reduced identify the skill requirements required by each role establish the functional requirements the applications must have to support the process provide the context for root cause analysis Process is the most powerful and effective driver of business alignment and improvement 37
- 38. Thank You! Questions? References: • Google: 4 Hour House • www.2hourhouse.com 38
Editor's Notes
- #2: In my 13 years process consulting, I’ve learned that process can be a powerful force in driving business improvement if used in the proper context.
- #3: In his book, Agenda, process guru Michael Hammer calls process the Clark Kent of business ideas.
- #6: Process is one of those terms that can have many meanings and contexts. So it is important to define it’s definition when discussing process. You can be talking about a credit checking process while I am thinking about a product development process.
- #7: This is clearly not an Aerospace company but the principles apply to all medium and large companies. These functions are typical. Sales is focused on quota, order on order rate, procurement on costs and EOQ, manufacturing on costs and rate and shipping on overall costs and order consolidation.
- #8: These measurements usually don’t work in favor of the customer order which flows through the functions horizontally. Do you think that the functional processes were designed to support/improve the functional metrics or the flow of orders?
- #9: These measurements usually don’t work in favor of the customer order which flows through the functions horizontally. Do you think that the functional processes were designed to support/improve the functional metrics or the flow of orders?
- #11: Here is an actual engagement that I was brought into.
- #12: When they reviewed the processes with me, I convinced them that their processes are really just phases of the same end-end process. So, what would you think would be the common business object that made it the same process. And what would you think this process should be called?
- #13: I called this the proposal to cash with process. Because proposal was one of the processes. Though the problem that they were trying to correct here is that collections were running at 50%, and customer satisfaction was very low. In fact, while we were doing this process, a customer came in, and described to the client that they represented there are satisfaction to be 3.4 out of four. In this case for war was the lowest, and one was the highest score. After some discussion, they agreed that it was all part of the same process. The major point of contention was the proposal that they didn’t think was in order. And I explained that it was a customer order to add and yet been accepted. In other words, it was an order that had a state of proposed. Now that that’s established, how would you determine the root causes of the problems that they were having?
- #14: The technique that I used to find the root causes was to start at the end of the process, where the most obvious problems were. I asked the collections department. Why the customers were not paying. They described that fact that there were problems with the installation, and they would not pay their bills until the problems were fixed. I then went to the deployment group, who described the situation in that there were problems with the configuration of the orders. There were problems with parts being incorrectly ordered the were problems with the schedule.
- #23: I’m sure this is hard to read so let me step you thru it. This is a high level view of the RFS process in DesignFlow format. It begins with a requestor in one of the business units, card services, travel, etc, that wants to develop a new service or offering that requires capacity over and above normal business. Like all customers they want it now, so the RFS team begins by checking for validity/completeness/funding. Once it passes, the RFS is planned, roles are selected, a solution developed, then a proposal created and priced. A governance board approves the request and it goes to the requestor for approval. It then comes back thru governance for a final OK, a notification goes out to all interested parties and the request goes to procurement for capital approp and acquisition. Our scope ended when the equipment was available for installation in the datacenter. The blue boxes show the various org groups that tended to have common set of activities and toolsets. The blue lines represent rework loops. This process is a very manual, email-driven, with information contained in Word and Excel with teamrooms for storage. Because of the high visibility and pressure to perform, each group needed information in their own format and had developed their own spreadsheets to protect themselves
- #24: After this step the team knows more about how the business runs and its problems than anyone else in the company.
- #25: We’ve covered the need to understand the complexity of the existing process. Here is DesignFlow EKG chart. We modeled and analyzed the As-Is process and found that it was comprised of 209 activities performed by 37 roles using 32 tools. They had 114 choices to make and had up to 66 handoffs. And the choices didn’t include the business rules for executing the process differently based on RFS type, $ clip levels, etc., that were implemented to “speed up” the process. The abundance of tools was worsened by the requirement that AMEX insisted that their toolset be used along with what IBM required and that no tool changes be made for one year.
- #32: This is clearly not an Aerospace company but the principles apply to all medium and large companies. These functions are typical. Sales is focused on quota, order on order rate, procurement on costs and EOQ, manufacturing on costs and rate and shipping on overall costs and order consolidation.