The Quest of One Piece Flow

Lean IT Summit 2014

Pierre Masai
CIO, Toyota Motor Europe
 Introduction

Toyota, TME and Information Systems

Toyota – in the World
 Established in 1937

 77 manufacturing companies in 27 countries

 Vehicles sold in > 170 countries worldwide

 9.98 million vehicles sold worldwide in 2013

Toyota Headquarters

 Market share: 47% in Japan, 14% in US, 4.7% in Europe Toyota City, Japan

 Over 7 million cumulative hybrid sales

 25.7 trillion Yen net revenue in FY 2013 (around 180 Billion €)

 2,3 trillion Yen operating income (around 16 Billion €)

 Approx. 338,000 employees worldwide

Toyota Motor Europe

 Began selling cars in 1963

 9 manufacturing plants in 7 countries TME Head Office

TME Head Office

 Over €8 billion invested since 1990 Evere, Belgium

 847,540 Toyota and Lexus vehicles sold by Toyota Motor Europe in 2013

 More than 795,000 hybrids sold in Europe to date

 4.7 % market share in 2013

 Employees (approx.): 93,400 (including distribution network) / 20,000 (direct)

TME IS

 263 employees
 Responsible for:
Development, infrastructure, networking, (mobile) communication & user support
TME R&D Centre
 Functional areas: Zaventem, Belgium

PanE IT Management, Corporate Systems, Manufacturing, Sales, R&D, System & Engineering, CarIT
 7 different locations:
Belgium: Brussels (Head Office) & Zaventem (R&D Centre)
Germany: Cologne (Sales Company)
Poland: Walbrzych (Production)
United Kingdom: Burnaston (Production) & Epsom (Sales Company)
Turkey: Adapazari (Production)
One Piece Flow – as conceived by Taiichi Ohno
What does it mean in a pure manufacturing Environment

Benefits of one piece flow

• Builds in Quality
• Creates real flexibility
• Creates higher productivity
• Frees up floor space
• Improves safety
• Improves morale
• Reduces cost of inventory
One Piece Flow – Does it work ?
Toyota has implemented it for a long time, what happens if you introduce it to an existing company ?

• Art Byrne’s work at Wiremold is the subject of the

well regarded book “Better Thinking Better Results”
• He transformed the business using Three Key
Principles
• Work to Takt Time
• Implement One Piece flow
• Use a Pull system
• How much success did he have?

Search for “youtube art byrne lean 2013”

Benefit Example – Wiremold Manufacturing
Before and after Introducing Lean
What does One Piece flow look like vs other methods?
In a Manufacturing Environment
This illustration shows the impact of batch size reduction when comparing batch-and-queue and one-piece-flow

Batch and Queue Process One Piece Flow Process

A B C A B C

10 10 10 1 1 1
Minutes Minutes Minutes Minute Minute Minute

First Piece = 21 Minutes First Piece = 3 Minutes

Entire Batch of 10 Pieces = 30 minutes Entire Batch of 10 Pieces = 12 minutes
What is a Piece? One part, an assembly or a car ?
….. Good question - it can be all three!

• We need to look at the graph on the

right and consider our economies of
scale vs costs to ‘store’ our work; and
make the best target.
• We can adjust this over time, but
economics of production will affect this.
• The scale of “one Piece” will change as
our product travels towards the
customer.
Flow – Some advice from Ohno San

The slower but consistent tortoise

causes less waste and is much more
desirable than the speedy hare that
races ahead and then stops
occasionally to doze. The Toyota
Production System can be realized
only when all the workers become
tortoises.
Taiichi Ohno (1988)
11
 One Piece Flow

How do we apply in IS ?
One Piece Flow – in Business Process Improvement
….. not just Software Development

• We need to see an unbroken chain of value

travelling towards the customer.
• We need to measure and prove that every
Euro we spend gives the maximum return.
• To maximise the speed of project delivery we
need to avoid any unnecessary “batching” of
activities.
• As the project is delivered we need to deliver
functions in small and even pieces, easily
tested, avoiding big peaks in workload.
An unbroken chain of value travelling towards the customer.
• In Software Development, one piece flow
starts at requirements definition – but
how do we know these are the best ?
• Based upon each Division’s “Hoshin
Kanri” we can clearly see how they want
to improve their performance, and how
this can be measured.
• When this is clear we focus on ensuring
each change we make is a good change.
• Good Change = Kai Zen.
Measure and prove that every € we spend gives maximum return

• Why is this part of one piece flow ? – flow

means benefit delivered; no benefit means no
flow should occur.
• To ensure that each project and part has
value we seek to quantify its benefits in a
tangible manner.
• If one part does not provide benefit we
should lose it.
• If the whole project can not deliver benefit it
needs to make way for a project that does.
Genchi-Genbutsu – Some more advice from Ohno San

People who can't understand numbers

are useless. The gemba where
numbers are not visible is also bad.
However, people who only look at the
numbers are the worst of all.

Taiichi Ohno

16
We need to avoid any unnecessary “batching” of activities.

• Validating each project is a good change takes

time and is a risk of interrupting the flow.
• Toyota emphasises strong links between
process change and measureable value to
make this decision (Kai Zen?) clearer.
• When we are preparing our Plans, we are
thinking of how we will Check the result.
• Project scope is made small enough to
facilitate flow (and deliver most significant
value first)
Deliver functions in small and even pieces ...

• Designing the deliverables using small unit sizes means that

the processing of deliverables is repeated many times during the project.
• This allows visualisation of problems early,
and is an opportunity to improve the process after each iteration.
• It supports the implementation of Jidoka to control quality.
• Careful planning of the deliverables and regular delivery ensures
each part of the process can be done with the correct quality.
• Standardisation, Jidoka and visualisation work closely with Heijunka
to increase quality as part of PDCA.
Tracing Requirements through to Deliverables – an Example
Week 1 Week2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Week 12 Week 13 Week 14 Week 15 W

Deliberable Index 10

Deliverable Index 10

Deliberable Index 11

Deliverable Index 11

Deliberable Index 12

Deliverable Index 12

Deliberable Index 13

Deliverable Index 13

Deliberable Index 14

Deliverable Index 14

Deliberable Index 15

Deliverable Index 15

Deliberable Index 16

Deliverable Index 16
Deliverable Index 1

Deliberable Index 2

Deliverable Index 2

Deliberable Index 3

Deliverable Index 3

Deliberable Index 4

Deliverable Index 4

Deliberable Index 5

Deliverable Index 5

Deliberable Index 6

Deliverable Index 6

Deliberable Index 7

Deliverable Index 7

Deliberable Index 8

Deliverable Index 8

Deliberable Index 9

Deliverable Index 9
Benefit Grouping 1 1.1     
1.2
1.3
1.4









15.5 Week Code 




Each delivery checked
1.5
1.6
1.7









Delivery; Two 





against meaningful
Benefit Grouping 2
1.8
2.1
2.2









functionally testable 





unit tests to measure
Benefits promised
2.3
2.4
2.5









deliveries per week. 





delivered benefit and
split into use cases; for regression testing
2.6      
2.7      
2.8      

tracked against (Jidoka).

2.9      
2.10     
2.11     

deliverables.
2.12     

Other Quality tests

2.13     
2.14     
Benefit Grouping 3 3.1     

built into CI process

3.2     
3.3     
Benefit Grouping 4 4.1     

(performance, code
4.2     
4.3     
Benefit Grouping 5 5.1     

quality, Unit test

5.2     
5.3     
5.4   

coverage etc)
5.5   
5.6   
5.7   
Tools and approaches

• To achieve Heijunka in Software delivery

process; Design, Code and Test – we use
Continuous Delivery tools.
• We use the data this provides to act as a
project virtual Obeya.
• For Kaizen Projects we use an Agile approach
to steadily improve the business.
• In Systems Engineering we are moving to
Cloud operations of some systems using
Infrastructure as Code.
Enabling one-piece flow in Business Process Improvement
Project Project Selection & Requirements Design Construction Audit
phases Feasibility Study gathering & Testing

One piece
flow themes
Maximum Value for Project split into phases Benefits measured in
Benefits broken down
customer, checked Project Linked to with biggest benefit Audit to support next
and linked back to
throughout the Hoshin
Hoshin deliverables
first, deliverables linked project and improve
to benefits process.
process
Iterative Design, build
and Test using
Clear Hoshin Kanri Clear tangible benefits
continuous Integration
Targets per Division linked to Hoshin targets Business case written in
tools. Infrastructure as
Heijunka – code.
measureable way –
No Batching Audit prefilled at
Agile Approach, Iterative Design, build and Test project start.
Kaizen Project using continuous Integration tools. Infrastructure
as code
Back to the Toyota House (and Art Byrne’s 3 Principles)
Our Guidelines

• Two Deliverables a week

Work to Takt
1 • Testable and linked to firm Requirement
Time and Benefit.
Implementing • Each project Linked to Hoshin.
2 One Piece • Value delivered in ideal sized pieces
flow through careful balancing of workload
• Track deliverables to Requirements and
3
Use a Pull Hoshin
system
• Biggest value delivered first.
 Problem Solving

Q: How can we eliminate all Problems?

A: We can’t – but it is still our aim!
Problem Solving - How
Clarify the Problem Customer First

Always Confirm the Purpose of Your

Break Down the Problem Work
Take Ownership and Responsibility
Target Setting
Plan

Visualization (MIERUKA)

Root Cause Analysis Toyota

Judgment Based on Facts
Business
Practices Think and Act Persistently
Develop Countermeasures

Speedy Action in a Timely Manner

See Countermeasures Through
Do

Follow Each Process with Sincerity and

Commitment
Monitor both Results and
Check

Processes Thorough Communication

Standardize Successful Processes

Act

and Start next iteration Involve all Stakeholders

Problem Solving - When
What is our target

• Every Toyota member is expected to follow the

problem solving approach for every problem.
• Problems which impact IS customers are tracked in
great detail by management, root causes pursued
relentlessly and countermeasures and targets
visualised.
• Major issues are discussed with VPs and learning
shared across IS management team.
• Most interesting shared across IS
in Europe/Globally and with the President.
Problem Solving – Beyond failures
The next stages

• Managers and top technicians deliver ‘setting

type’ problem papers to allow us to step up to
the next level.
• Higher management reflect on their issues,
studying deeply to pickup trends and
recommend structural changes in technology
or organisation.
反省
• Every delivered project must reflect on their
successes and learning points to ensure we
can grow as an organisation.
Hansei

27
Problem Solving Levels
Problem Solving – Environmental and Organisational
• Bring data from inside and outside the company.
3 • Identify trends, underlying issues and new opportunities.
• Take steps to implement processes and organisation to
elevate performance.

Problem Solving – Setting Type

• Set a new target based upon deep understanding.
2
• Breakdown the challenge into manageable pieces.
• Understand the barriers and overcome them.

Problem Solving – Gap Type

• Break down the problem and set a challenging target.
1 • Thoroughly investigate the Root causes.
• Implement countermeasures and Track; Yokoten.

0 Understand the current situation and the standard.

Summary
Part 1 – One Piece Flow

For us One-Piece-Flow must address the entire

Business Process Improvement Cycle.
Agile, SCRUM and Devops can help us improve flow
in our software development and release process.
We don’t focus so much on adopting these
techniques wholesale – we focus on the Toyota way
principles and adopt the tools that support them.
We need to take the broadest view to ensure that we
are being the most valuable IS Function we can be.
Summary
Part 2 – Problem Solving

We know what Ohno san said about the man with
‘no problems’.
And although we know we will never get there we
spend a lot of time studying our problems,
setting a target of zero.
To do that we address our problems solving activities
at three levels to relentlessly move closer to the
target.
Have we got time for Questions?

Thank you for your attention today at #LeanIT2014

@PierreMasai