The quest of one-piece-flow in IT by Pierre Masai, Toyota Motor Europe
Post on 15-Dec-2014
672 Views
Preview:
DESCRIPTION
Transcript
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
top related