The document discusses Toyota's approach to one piece flow and problem solving. It describes how Toyota implements one piece flow throughout the entire business process improvement cycle and values delivering benefits in small, testable pieces. Toyota also takes a three-level approach to problem solving to thoroughly investigate issues, set challenging targets, and implement countermeasures to continuously improve.

1. The Quest of One Piece Flow Lean IT Summit 2014
Pierre Masai CIO, Toyota Motor Europe

2. Introduction
Toyota, TME and Information Systems

3. 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

Market share: 47% in Japan, 14% in US, 4.7% in Europe

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 Headquarters
Toyota City, Japan

4. Toyota Motor Europe
TME Head Office
TME Head Office Evere, Belgium

Began selling cars in 1963

9 manufacturing plants in 7 countries

Over €8 billion invested since 1990

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)

5. TME IS
TME R&D Centre Zaventem, Belgium

263 employees

Responsible for: Development, infrastructure, networking, (mobile) communication & user support

Functional areas: 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)

6. 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 – as conceived by Taiichi Ohno
What does it mean in a pure manufacturing Environment

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

8. Benefit Example – Wiremold Manufacturing
Before and after Introducing Lean

9. 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
10
Minutes
10 Minutes
10
Minutes
1 Minute
1
Minute
1
Minute
First Piece = 21 Minutes
Entire Batch of 10 Pieces = 30 minutes
First Piece = 3 Minutes
Entire Batch of 10 Pieces = 12 minutes
Batch and Queue Process
One Piece Flow Process
A
B
C
A
B
C

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

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

12. One Piece Flow
How do we apply in IS ?

13. •
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.
One Piece Flow – in Business Process Improvement
….. not just Software Development

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

15. •
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.
Measure and prove that every € we spend gives maximum return

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

17. •
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)
We need to avoid any unnecessary “batching” of activities.

18. •
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.
Deliver functions in small and even pieces ...

19. Tracing Requirements through to Deliverables – an Example Deliverable Index 1Deliberable Index 2Deliverable Index 2Deliberable Index 3Deliverable Index 3Deliberable Index 4Deliverable Index 4Deliberable Index 5Deliverable Index 5Deliberable Index 6Deliverable Index 6Deliberable Index 7Deliverable Index 7Deliberable Index 8Deliverable Index 8Deliberable Index 9Deliverable Index 9Deliberable Index 10Deliverable Index 10Deliberable Index 11Deliverable Index 11Deliberable Index 12Deliverable Index 12Deliberable Index 13Deliverable Index 13Deliberable Index 14Deliverable Index 14Deliberable Index 15Deliverable Index 15Deliberable Index 16Deliverable Index 16 1.1  1.2  1.3  1.4  1.5  1.6  1.7  1.8  2.1  2.2  2.3  2.4  2.5  2.6  2.7  2.8  2.9  2.10  2.11  2.12  2.13  2.14  3.1  3.2  3.3  4.1  4.2  4.3  5.1  5.2  5.3  5.4  5.5  5.6  5.7  Week 14Week 15W Week 8Week 9Week 10Week 11Week 12Week 13Week2Week 3Week 4Week 5Week 6Week 7Week 1Benefit Grouping 1Benefit Grouping 2Benefit Grouping 3Benefit Grouping 4Benefit Grouping 5
15.5 Week Code Delivery; Two functionally testable deliveries per week.
Benefits promised split into use cases; tracked against deliverables.
Each delivery checked against meaningful unit tests to measure delivered benefit and for regression testing (Jidoka).
Other Quality tests built into CI process (performance, code quality, Unit test coverage etc)

20. •
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.
Tools and approaches

21. Maximum Value for customer, checked throughout the process
Project Linked to Hoshin
Benefits broken down and linked back to Hoshin deliverables
Project split into phases with biggest benefit first, deliverables linked to benefits
Benefits measured in Audit to support next project and improve process.
Heijunka – No Batching
Clear Hoshin Kanri Targets per Division
Clear tangible benefits linked to Hoshin targets
Iterative Design, build and Test using continuous Integration tools. Infrastructure as code.
Business case written in measureable way – Audit prefilled at project start.
Kaizen Project
Agile Approach, Iterative Design, build and Test using continuous Integration tools. Infrastructure as code
Enabling one-piece flow in Business Process Improvement
Project Selection & Feasibility Study
Audit
Requirements gathering
Design Construction & Testing
Project
phases
One piece
flow themes

22. Back to the Toyota House (and Art Byrne’s 3 Principles)
Our Guidelines
1
Work to Takt Time
•
Two Deliverables a week
•
Testable and linked to firm Requirement and Benefit.
2
Implementing One Piece flow
•
Each project Linked to Hoshin.
•
Value delivered in ideal sized pieces through careful balancing of workload
3
Use a Pull system
•
Track deliverables to Requirements and Hoshin
•
Biggest value delivered first.

23. Problem Solving
Q: How can we eliminate all Problems? A: We can’t – but it is still our aim!

24. Problem Solving - How
Toyota Business Practices
Customer First
Always Confirm the Purpose of Your Work
Take Ownership and Responsibility
Visualization (MIERUKA)
Judgment Based on Facts
Think and Act Persistently
Speedy Action in a Timely Manner
Follow Each Process with Sincerity and Commitment
Thorough Communication
Involve all Stakeholders
Plan
Do
Check
Act
Clarify the Problem
Break Down the Problem
Target Setting
Root Cause Analysis
Develop Countermeasures
See Countermeasures Through
Monitor both Results and Processes
Standardize Successful Processes and Start next iteration

25. •
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 - When
What is our target

26. •
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.
Problem Solving – Beyond failures
The next stages
反省

27. Hansei 27

28. Problem Solving Levels
3
Problem Solving – Environmental and Organisational
•
Bring data from inside and outside the company.
•
Identify trends, underlying issues and new opportunities.
•
Take steps to implement processes and organisation to elevate performance.
2
Problem Solving – Setting Type
•
Set a new target based upon deep understanding.
•
Breakdown the challenge into manageable pieces.
•
Understand the barriers and overcome them.
1
Problem Solving – Gap Type
•
Break down the problem and set a challenging target.
•
Thoroughly investigate the Root causes.
•
Implement countermeasures and Track; Yokoten.
0
Understand the current situation and the standard.

29. Part 1 – One Piece Flow
Summary

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.

30. Part 2 – Problem Solving
Summary

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.

31. @PierreMasai
Have we got time for Questions?
Thank you for your attention today at #LeanIT2014