17th International Conference of the

TOC Practitioners Alliance - TOCPA

www.tocpractice.com

15 May 2015, Vilnius, Lithuania

Applying TOC to Services

A reality check

Hans Steenpoorte, TOC Resultants/Critical Task

Manager, The Netherlands
15 May 2015

Agenda
1.
2.
3.
4.

About us
About services
About the solution
About implementing & results

About Hans Steenpoorte

Co-owner of TOC Resultants and Critical Task
Manager (CTM)
TOC implementer in service organizations; government,
professional services, IT and healthcare. All implementations
are aimed at delivering more services faster, with the same
people and resources.
Hans worked 10 years in the steel and aluminum industry.
Since 2000, he moved to professional services and in 2005
founded TOC Resultants with Michel Stijlen. Since then,
they have been implementing TOC solutions in services, and
adapting them if and where necessary.
In 2009, Hans & Michel co-founded Critical Task Manager
(CTM), TOC-based software for service organizations that
want to deliver more services faster and more reliably.
Hans lives in Amersfoort, The Netherlands with his wife and 2
daughters. When hes not implementing TOC, he riding his
bicycles

www.toc-resultants.com
info@toc-resultants.com
See also:
www.criticaltaskmanager.nl
info@criticaltaskmanager.com

Our expertise
Our expertise: Operations Management of Services
How to plan, execute and improve service delivery so that
more services are delivered faster and more reliably with
the same people/resources and without compromising
quality and/or working conditions
Implementations

The Methodology

TOC-based Operations Management

software for services and projects
The Service Factory

Agenda
1.
2.
3.
4.

About us
About services
About the solution
About implementing & results

About services
Focus: Repetitive services, (often) produced by people away from the
customer
Public services (e.g. municipalities)
Professional services (e.g. lawyers)
IT services (in- and external)
Healthcare services (patient care)
Banking/insurance (customer service/back office)
Tel cos (customer service/back office)
Other service industries, not covered today, are ..
Hotels
Rental services
Events
Travel business
etc.

Services vs. production

Intake

Production of the service

Delivery

Characteristic

Manufacturing Services

Routing & semi

products and BOM

Well defined

Often poorly/not defined

WIP

Physical

Intangible (or the customer/client!)

Resources

Machines

People (and IT systems)

Touch time as % of
lead time

Low

Low, but frequently hard to control

LT outside the primary system

Intake => Production Decoupled

Often performed by same function, or

even person

What are common

problems?

Some services are delivered late

Resources (people) are not always available when needed
Semis are not delivered in time or in desired state
Sometimes critical information is lacking
Planning is often changing
Unclarity/discussion about priorities
There is quite some expediting
Workload is sometimes considered to be (too) high
Productivity (of end products) is lower that desirable

So , the (implicit) need of companies in the service environment is:

Deliver more services faster and more reliably, with the same
people/resources, without compromising quality or working
conditions

Agenda
1.
2.
3.
4.

About us
About services
About the solution
About implementing & results

How hard can it be ;-) ?

3 steps to success:
1. Assume service
delivery needs SDBR & BM for MTO
2. Take the best book
on TOC for
Production
3. Lets go!

What does Ever Improve

say?
Mindset: Customer orders are prime driver for managing Operations
(Drum)
1. Achieving high DDP is prime measurement
Immediate improvement in Due Date Performance (DDP)
2. Ambitious Production Buffer with Raw Materials released
accordingly
3. Work Orders are sequenced according to buffer status
4. Buffer Management for recovery action is in place
5. Availability of selected Raw Materials is monitored/managed
Continuous Improvement POOGI
6. Buffer penetration reasons reviewed periodically for POOGI
7. Capacity is monitored for Capacity Constraint Resource(s) CCR
8. Transfer batches are challenged/sized to support flow

What did we end up doing?

1. Low LT is a prime measurement and (high)
WIP a crucial symptom to watch (UDE)
2. Products & Services are registered and
delivered according to Products & Services
Catalogue (PSC)
3. WIP is radically reduced and controlled at 2550% of starting level
4. Tasks/files are prioritized/expedited
uniformly, using buffer management
5. Tasks/files are allocated to teams (not
individuals)
6. Sources & causes of delay are identified and
eliminated 1-by-1

1. Focus on LT and WIP

TOC assumption: Most manufacturers promise/deliver (at)
industry average SLTs, and primarily have a DDP problem
Most service companies have unacceptably long SLTs and no
clue as to their DDP (as do their customers)
High WIP is prime cause of SLT (and DDP) problems:
Littles Law: WIP (#units) = Average LT (in days)
Output/day
Gives immediate insight in extrapolated LTs
Buy-in that WIP and (thus) LTs need to come down fast

On top, Littles Law is easy to understand & basis for

management reports:
Input, Output, WIP, LT and (later) DDP

John Little (MIT)

1: Reports to influence
mindset & behaviour
Key
1. Performance Period and YTD
2. Only Performance vs Standard (=norm) (green and red)
3. 3 levels: 1. Organization, 2. teams, 3. individuals

Prime focus:
WIP vs. target

Result:
Extrapolated LT
(Littles Law)

Secondary
focus (only
later): DDP

2: Products & Services

Catalogue (PSC)
S-DBR is based on the (implicit) assumptions that semis,
routing and BOMs are well defined
In Services they are (often) not!
Dilemma:
B: Efficient
supplier of quality
services

D: Put
significant
IO: Draw
up a
timePSC
intoquickly
process
(re) design

C: Fast and
reliable supplier of
services

D: Not put
significant time
into process (re)
design

A. Succesful
service provider
NAITF

2: Quick PSC!
Product/
service
Service X

End state

Necessary input

Widget sent to
customer

Service Y

Widget
explained to
customer

Customer name & cell

phone nmbr
Customer request
Customer name & cell
phone nmbr
Customer address
Customer request

Critical: Often
not clear

Critical: Comparable to
full kit

Plan (#/ Stanweek) dard LT

20
2 wks

DDP
(%)
90%

Etc

Etc

Etc

Maybe even 25% of

current LT!

Based on this, work is registered uniformly and planned 1 buffer

from now, and/or released 1 buffer before the agreed due date
Our version of the rope

2. Bonus: Phasing!
In manufacturing semis and process steps are well defined
Most service companies dont have any of this, and some
have way too much (workflow systems)
Solution: Identify and attach uniform (sequential!) phasing
across (most of) the entire organisation, for instance .
1. Intake, 2 Analysis, 3. Report, 4. Closure
1. Plan, 2. Improve, 3. Sustain

Using this phasing, WIP can be segmented and prioritized

much more meaningfully

2. This is where we got it

from

David Anderson (ex TOC/CCPM guy) realized that software

development is a multi-project environment, that can be
managed more effectively with a bastardized version on SDBR (Kanban) than with CCPM
Source: Kanban, David Anderson

3: Cut WIP by 50-75%

2 Problems:
1.
2.

WIP is often so high that current average LTs are unacceptable, and
You cant close shop for X weeks/months because youre chocking the
release => Intake and service delivery often involve interaction with
customers

Dilemma:

B: Service all
customers
equitably

D: Focus only on
oldest tasks/
requests

IO:
Intermediate
Sprint

A. Be a good
service provider
C: Service present
customers
correctly

D: Not only focus

on oldest
tasks/resquests

3: Intermediate Sprint!
Intermediate Objective (IO), instead of injection
1. Based on the new standard LT, we split the WIP in ..
A. Services that are still within the (new) Standard LTs ( 50%)
B. Services that are already over the Standard LTs ( 50%)

2. Split the organization in 2 parts

Going concern ( 80% of capacity); takes care of A
Intermediate sprint ( 20% of capacity); takes care of B

3: Intermediate sprint?
(Relatively) senior multi-disciplinary group of people
physically (!) put together
Objective:
1. Rapidly reduce WIP by finishing overdue services (starting
from the oldest)
No fancy BM tools necessary at this point; just lists on the wall

2. Collect ideas during daily stand-ups about how to simplify

and uniform the process(es)
Question: Can the other 80% of the capacity keep up with 100%
of the (new) inflow?
Yes: Delayed services are often complex and cause extra load

3. Target setting for

Intermediate Sprint
Low LTs are an effect of low WIP
What should be the WIP target of your Intermediate Sprint?
Depends on your DDP ambition/target!

Insight: When aiming for 90% DDP, target for average (Little) LT
of 50% of the standard LTs as laid down in your PSC
Example:
Current WIP = 300
Current output = 100/week

-/- 50%

Standard LT = 3 weeks
DDP target = 90%
Whats your WIP target?
Average
(Little) LT

Standard
LT

150!

3. A little more
complex product mix
Product
Apple
Orange
Tomato
Grand total

Annual Standard Target average LT Target average LT Target average

Plan
LT
(% of Standard LT)
(in days)
WIP
1000
30
50%
15
41
500
60
50%
30
41
1500
40
50%
20
82
3000
164

Caution!
For an Intermediate Sprint (= temporary effort), the
calculation/communication of such a WIP-target is crucial
For structural Operations Management (low) WIP is just an
means to the objective of low LTs => Set/monitor LT targets
See solution element 6

4. Buffermanagement &
Stand Ups
Smart TV on wall with CTM or BM-work lists
Stand-up headed by Foreman. Foreman
checks for
1.
2.
3.

Blacks and reds; Whats blocking completion

now?
Cherry picking
Too many tasks on 1 worker

On a weekly basis, the foreman joins the

MT on behalf of his/her team

Discuss Mngmt Report (see Inj. 1) and Top 20

delayed services (across teams)

Non-compromisable
point!

Simple buffer
management 2.0
Assume you have WIP in different phases and apply only 1
time buffer for the full duration of the service delivery
How to prioritize if people can work on different/all phases?
They will continually be pulled to the end of the process!

Buffers per phase?

Rather not! => Complexity & risk of local optima

OK, what then?

Agree on a standard (= norm) buffer status per phase
Discuss at stand ups those services that have a buffer status
higher than the above mentioned standard:
What will you do today to move to the next phase?

5: Allocate work to teams

Due to lack of standardization and process control,
tasks/services are often assigned to individuals
They know the file
(Un)expected benefit: Many of
They are accountable

our clients find this solution

Poor continuity, continuous
improvement
and high
element to be
the most
powerful,
the strongest
peaks & troughs in
load vsandcapacity
driver of employee satisfaction

Solution: Allocate work to semi-homogeneous skill groups

(teams)=> aggregation
1. Team is responsible for output, LT and DDP (if
applicable) and quality/conformity
2. Team is headed by (informal) foreman
3. Foreman heads the daily stand-up and weekly MT
meeting

6. POOGI: Sources &

causes of delay
Insight: Delays are important objectieve indicator of some
underlying problem in the muddy waters of service delivery
Lack of capacity, quality issues, policies, 3rd party interactions etc

Our standard Managent Report makes quite clear where

(source) delays are high and/or growing
Next, classic TOC tells you to identify the why (cause) of
delay by asking for Causes of delay per delayed task (67
100% buffer status) and generate statistical data, right?
Issues with that:
No reliable info about preceding causes of delay upstream
Quality of the registrered data depends on the ability of the people not
to speculate/finger point, or to fill them out in the 1st place
Data is sometimes converted to statistical information too infrequently,
potentially causing a solution to come too late

6. Whats the
alternative?
Assumptions:
1. Delays are important objective indicator of underlying problems
2. We know in which phase all active tasks are
D.O.S: Monitor weekly how WIP per phase develops and you know
where (source, not cause!) to direct your management attention
WIP is fever (Taiichi Ohno)
Really?
Not quite!
Indeed .
Increasing WIP can point at lower output, but also higher input!
In other words, increasing WIP is not a 100% reliable indicator of a
source of delay

Hmmmm, who was it that combined WIP and output in 1 neat

formula?

6. John Little!
WIP (#units) = Average LT (in days)
Output/day
John Little (MIT)

Solution:
Show development of the (Little) LT per phase/team through time
(stack chart)
Discuss in weekly Ops meeting (MT)
Through time, agree on standard (= norms) LTs per phase/team
Agree on corrective actions when norms are exceeded

6. What to do if Little-LT
remains stubbornly high?
High LTs are a symptom of underlying causes
What are the causes and solutions of high LTs?
Cause

Solution

1. Too high WIP

Reduce WIP, and keep it down at

necessary level (Intermediate sprint)

2. Too low productivity

(output semis/unit of time)

Increase productivity (TOC: Exploit,

Lean: Reduce touch/wait time)

3. External LT ( touch time)

Frequent/organised chasing or
insourcing

4. Batching (mainly meetings)

Increase meeting frequency or take

meeting out of primary process

Caution: Processes or process steps suffering from 2, 3 or 4 will also

have high WIP, but this will be the effect, and not the cause

Agenda
1.
2.
3.
4.

About us
About services
About the solution
About implementing & results

Conclusions & results

TOC is (very) effective in (repetitive) services
WIP/LT reduction by factor 2-4
DDP > 90%, if required
Productivity will increase up to 50% (until you reach WIPtarget)

Main Sales/implementation obstacle: Hourly

thinking
Because they dont control the primary process, quite
some service providers resort to extensive writing of hours
=> Ceiling thinking
Because employees fill the hours in the way they need, they and
management see the data as proof that they cant do more/faster
(assumption: Output = capacity)