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