17th International Conference of the

TOC Practitioners Alliance - TOCPAwww.tocpractice.com 15 May 2015, Vilnius, Lithuania

Applying TOC to Services

A reality check

Hans Steenpoorte, TOC Resultants/Critical Task Manager, The Netherlands15 May 2015

Agenda

1. About us

2. About services

3. About the solution

4. About implementing & results

About Hans Steenpoorte

Co-owner of TOC Resultants and Critical TaskManager (CTM)TOC implementer in service organizations; government,professional services, IT and healthcare. All implementationsare aimed at delivering more services faster, with the samepeople and resources.

Hans worked 10 years in the steel and aluminum industry.Since 2000, he moved to professional services and in 2005founded TOC Resultants with Michel Stijlen. Since then,they have been implementing TOC solutions in services, andadapting them if and where necessary.

In 2009, Hans & Michel co-founded Critical Task Manager(CTM), TOC-based software for service organizations thatwant to deliver more services faster and more reliably.

Hans lives in Amersfoort, The Netherlands with his wife and 2daughters. When hes not implementing TOC, he riding hisbicycles

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

TOC-based Operations Management

software for services and projects

The Methodology

The Service Factory

Agenda

1. About us

2. About services

3. About the solution

4. 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

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

Intake Production of the service Delivery

(

(

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 desirableSo , 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. About us

2. About services

3. About the solution

4. About implementing & results

How hard can it be ;-) ?

3 steps to success:

1. Assume service

delivery needs S-

DBR & 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 25-

50% 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

Prime focus:

WIP vs. target

Result:

Extrapolated LT

(Littles Law)

Secondary

focus (only

later): DDP

Key

1. Performance Period and YTD

2. Only Performance vs Standard (=norm) (green and red)

3. 3 levels: 1. Organization, 2. teams, 3. individuals

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:D: Put significant

time into process

(re) design

D: Not put

design

D: Not put

significant time

into process (re)

design

B: Efficient

supplier of quality

services

C: Fast and

reliable supplier of

services

A. Succesful

service provider

NAITF

IO: Draw up a

PSC quickly

2: Quick PSC!

Product/

service

End state Necessary input Plan (#/

week)

Stan-

dard LT

DDP

(%)

Service X Widget sent to

customer

Customer name & cell

phone nmbr

Customer request

20 2 wks 90%

Service Y Widget

explained to

customer

Customer name & cell

phone nmbr

Customer address

Customer request

Etc Etc Etc

Maybe even 25% of

current LT!Critical: Often

not clear

Critical: Comparable to

full kit

Critical: Comparable to

full kit

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 S-

DBR (Kanban) than with CCPM

Source: Kanban, David Anderson

3: Cut WIP by 50-75%

2 Problems:

1. WIP is often so high that current average LTs are unacceptable, and

2. You cant close shop for X weeks/months because youre chocking the

release => Intake and service delivery often involve interaction with

customers

Dilemma:D: Focus only on

oldest tasks/

requests

D: Not only focus

on oldest

tasks/resquests

B: Service all

customers

equitably

C: Service present

customers

correctly

A. Be a good

service provider

IO:

Intermediate

Sprint

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

Standard

LT

Average

(Little) LT

Example: Current WIP = 300 Current output = 100/week Standard LT = 3 weeks DDP target = 90% Whats your WIP target?

150!

-/- 50%

3. A little more

complex product mix

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

Product

Annual

Plan

Standard

LT

Target average LT

(% of Standard LT)

Target average LT

(in days)

Target average

WIP

Apple 1000 30 50% 15 41

Orange 500 60 50% 30 41

Tomato 1500 40 50% 20 82

Grand total 3000 164

4. Buffermanagement &

Stand Ups

Smart TV on wall with CTM or BM-work lists

Stand-up headed by Foreman. Foreman

checks for

1. Blacks and reds; Whats blocking completion

now?

2. Cherry picking

3. 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

They are accountable

Poor continuity, continuous improvement and high

peaks & troughs in load vs capacity

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

(Un)expected benefit: Many of

our clients find this solution

element to be the most

powerful, and the strongest

driver of employee satisfaction

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!

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

WIP (#units) = Average LT (in days)

Output/day

John Little (MIT)

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?

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

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

Agenda

1. About us

2. About services

3. About the solution

4. 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 WIP-

target)

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)