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

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

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)

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)

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

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

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

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 ?

• 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

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.

• 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

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

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

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

Tracing Requirements through to Deliverables – an Example

Deliv

erable

Inde

x 1

Delib

erable

Inde

x 2

Deliv

erable

Inde

x 2

Delib

erable

Inde

x 3

Deliv

erable

Inde

x 3

Delib

erable

Inde

x 4

Deliv

erable

Inde

x 4

Delib

erable

Inde

x 5

Deliv

erable

Inde

x 5

Delib

erable

Inde

x 6

Deliv

erable

Inde

x 6

Delib

erable

Inde

x 7

Deliv

erable

Inde

x 7

Delib

erable

Inde

x 8

Deliv

erable

Inde

x 8

Delib

erable

Inde

x 9

Deliv

erable

Inde

x 9

Delib

erable

Inde

x 10

Deliv

erable

Inde

x 10

Delib

erable

Inde

x 11

Deliv

erable

Inde

x 11

Delib

erable

Inde

x 12

Deliv

erable

Inde

x 12

Delib

erable

Inde

x 13

Deliv

erable

Inde

x 13

Delib

erable

Inde

x 14

Deliv

erable

Inde

x 14

Delib

erable

Inde

x 15

Deliv

erable

Inde

x 15

Delib

erable

Inde

x 16

Deliv

erable

Inde

x 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 14 Week 15 W Week 8 Week 9 Week 10 Week 11 Week 12 Week 13Week2 Week 3 Week 4 Week 5 Week 6 Week 7Week 1

Benefit Grouping 1

Benefit Grouping 2

Benefit Grouping 3

Benefit Grouping 4

Benefit 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)

• 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

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

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.

Problem Solving

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

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 D

o C

heck 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

• 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

• 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

反省

Hansei

27

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.

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.

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.

@PierreMasai

Have we got time for Questions?

Thank you for your attention today at #LeanIT2014