Elements of Lean Engineering Introduction · 2010 Best Research 2009 2009 Best Product 2011 2010+...

July 2009

Elements of Lean Engineering Introduction

Dr. Hugh McManus Politechnika Wrocławska, June 2013

2013 McManus for Politechnika Wrocławska

Introductions

•  Today’s course is a substantial fraction of the LAI Lean Academy Engineering Shortcourse

•  It is complementary to the other Lean PD events this week at Politechnika Wrocławska

•  Instructors: •  Dr. Hugh McManus •  Dr. Eric Rebentisch

•  Participants •  Facilities


Course Learning Objectives

At the end of this course, you will be able to: •  Demonstrate the application of value

stream mapping to engineering •  Explain how lean principles apply to engineering

processes •  Explain how greater product value can be created •  Describe organizational designs and interventions

appropriate for different engineering products •  Describe methods for implementing lean practices

across complex enterprises


Course Organization

Principles

Methods

Tools

Lean PD Principles

Creating Product Value

Efficient Execution

Enterprise System Design


10-15 Years Ago: Questions

•  Does Lean apply to Product Development, and its primary processes, Engineering?

•  How can we define the “Value” of Product Development?

•  How can processes with variation and iteration be mapped and controlled?

•  How can uncertainties be handled and even exploited?

•  Can “creative” processes be “standardized”? •  Can Engineers practice process discipline? •  Many more….


10-15 Years Ago: Bad Ideas

•  Lean is for factories, not “creative” work •  Every product is different and its development is

special

•  Development should be done “right the first time” and not iterate or follow varying paths

•  Analysis and Testing are “Inspection” and are therefore Pure Waste

•  Engineers should be made to follow work instructions like factory workers

•  Many more….


A great deal of progress

2002

2003

2004 2005 2006

2007

2008

2009 2010 Best Research

2009 Best Product

2011

2010+


Current State of Lean PD Literature

•  Descriptions of Toyota practices and derivatives dominate •  Reports of practices that are observed at

Toyota (e.g., chief engineer, A3s, etc.) •  Extensions/interpretations of the intent of the

Toyota practices (e.g., set-based concurrent engineering, knowledge-based design, etc.)

•  Others (including LAI) have also gone to 1st principles to expand the canon of lean PD principles & practices

•  This course draws on both streams


The Problem: Waste in Product Development

•  Most tasks are idle most of the time

•  When they are in-process, much of the work is NVA

•  The 12% VA time is NOT the problem

Survey of aerospace PD process time (2000)

62% job idle

15% pure waste activities

11% necessary NVA activities

12% value-added activities

77% of time is PURE WASTE

38% job active:


Root Causes of Time Wastes

•  Resources not available •  Not in balance with needs of

task •  Unevenness in availability:

multitasking, firefighting.. •  Institutional/organizational

boundaries •  Unsynchronized operations •  Slow handoffs

•  Legacy processes •  Over-processing •  Unnecessary reviews and

approvals


Wasteful Processes = Targets for Lean

•  Static Muda wastes •  the 7 (or 8 or 10 or 30) wastes applied to the

information used by engineering/product development processes

•  Information “rots” at around 6% per month (!) •  Even more important to PD processes: •  Muri – Overburden of people or equipment •  Mura – Unevenness or instability in operations or

outputs

Answers to some questions: • Lean should be useful for reducing PD wastes • Lean should allow engineers to do more of what they want to do!


What works?

•  LAI / McKinsey study •  300 subjects, 28 companies •  what PD practices correlated with project

success? •  High performing companies consistently did

better on a variety of metrics •  High performing companies tended to employ

a lot of advanced PD practices •  No “silver bullet” practice, but a few

correlated particularly strongly with success


The Main Differentiators between Top and Bottom Performers

1.  High level of upfront project preparation •  Scoping of project •  Staffing of project •  Handling of “Fuzzy Front End”

2.  Focus on project team •  Emphasize on Project Organization over Line Organization •  Strong project leadership

3.  Keep eyes on the ball •  Exploration of customer needs at each step of the project •  Close customer integration, constant feedback loops

These LEAN characteristics correlate with business success


Implementing in an Ordered Improvement Cycle

e.g. Plan-Do-Study-Act (PDSA):

•  Plan based on process definition, mapping, and analysis

•  Do to address issues •  Study the results using

appropriate metrics •  Act to correct, maintain, or

further improve

Act Plan

Do Study

Vital for complex, interdependent PD

processes


References •  Murman, E., Allen, T., Bozdogan, K., Cutcher-Gershenfeld, J., McManus, H.,

Nightingale, D., Rebentisch, E., Shields, T., Stahl, F., Walton, M., Warmkessel, J., Weiss, S., and Widnall, S., Lean Enterprise Value: Insights from MIT’s Lean Aerospace Initiative, Palgrave, New York, 2002

•  Michael N. Kennedy, Product Development for the Lean Enterprise, Oaklea Press 2003. •  Oppenheim, Bohdan W., “Lean Product Development Flow,” Systems Engineering,

Vol. 7 No. 4, Oct. 2004. •  McManus, H.L. “Product Development Value Stream Mapping Manual”, V1.0, LAI, Sep

2005 •  Morgan, James, and Liker, Jeffery, The Toyota Product Development System:

Integrating People, Process And Technology, Productivity Press, 2006 •  McManus, H.L., Haggerty, A. and Murman, E., "Lean engineering: a framework for

doing the right thing right," The Aeronautical Journal, Vol. 111, No. 1116, February 2007, pp. 105-114.

•  Ward, Allen, Lean Product and Process Development, Lean Enterprise Institute, 2007. •  Reinertsen, Donald G., The Principles of Product Development Flow: Second

Generation Lean Product Development, Celeritas Publishing, 2009. •  Oppenheim, B. W., Murman, E. M. & Secor, D. A., “Lean Enablers for Systems

Engineering,” J. Systems Engineering, 2010. http://cse.lmu.edu/Assets/Lean+Enablers.pdf

•  Josef Oehmen and Eric Rebentisch, LAI Paper Series: Lean Product Development for Practitioners, Version 1.1, July 2010.http://lean.mit.edu/products/lean-enterprise-product-development-for-practitioners.html

Efficient Process Execution


Efficient Process Execution v2.3 for Politechnika Wrocławska 2013 Slide 2 Most content © 2011 Massachusetts Institute of Technology

Learning Objectives

At the end of this module, you will be able to: •  Recognize the sources of engineering waste •  Describe how value stream mapping can be

applied to engineering •  Experience a simple exercise in Product

Development Value Stream Mapping (PDVSM) •  Experience iteration and capacity calculations •  Describe methods for designing a better

future state


What is Valued?

•  In manufacturing: the products that customers buy •  Narrowly interpreted as the flow of materials

that result in finished goods •  In product development process: a good

proxy is product risk retired •  Achieving an acceptable likelihood that the

product will be successfully realized •  For enterprises: robust value propositions for

enterprise stakeholders •  The product and its manufacture, sale, use, and

service satisfy various value systems


What is Different about PD?

•  Culture is generally not process-oriented •  Information is flowing instead of material •  Uncertainties are inevitable •  Product is generally incompletely defined •  Process(es) not totally predictable

•  Interdependencies are common •  Process steps depend on each other for

completion •  Complex products with high performance

requirements often can’t avoid coupled functions and forms

These Differences INCREASE the value of PDVSM


The Problem: Waste in Product Development

•  Most tasks are idle most of the time

•  When they are in-process, much of the work is NVA

•  The 12% VA time is NOT the problem

Survey of aerospace PD process time (2000)

62% job idle

15% pure waste activities

11% necessary NVA activities

12% value-added activities

77% of time is PURE WASTE

38% job active:


What is going on?

•  Waiting and interruptions cause work to sit idle •  “Touch time” is when engineers are busy, resources are

being used •  Only some of the touch time is value added

Hand-off Complete Wait Decision

Cycle Do

Work Hand-off Setup Post-processing Wait Interrupt Interrupt

Value-Added Time

Touch Time

Touch Time

Cycle Time

Touch Time


7 Information Wastes

•  Waiting: Idle time due to unavailable information •  Inventory: Information that is unused or is “work in

progress” •  Excessive Processing: Information processing

beyond requirements •  Over Production: Producing, distributing more

information than needed •  Transportation: Unnecessary movement of

information between people, organizations or systems •  Unnecessary Motion: Unnecessary human movement

(physical or user movement between tools or systems)

•  Defects: Erroneous data, information, reports Source: McManus, H.L. “Product Development Value Stream Mapping Manual”, LAI Release 1.0, Sept 2005


Frequency of Info Wastes

Slack, Robert A., “Application of Lean Principles to the Military Aerospace Product Development Process,” Masters thesis in Engineering and Management, Massachusetts Institute of Technology, December 1998.

40 % for Wait Time plus Inventory 28% for Over-processing plus Overproduction


Examples: ECP process

 Engineering release process prior state

New Requirement

Schedule

Review

PR’s

Write EDA

Basic Layout

FAMSCO

Write PS

Assign Task

Detailed Layout

Layout from Config

STRESS

Assy Drawing

Detail Drawing

CHECKBOARD RELEASE CENTER SIGNOFF

NEAR

DCC Investigate

C/A Board

C/A


Request for Engineering Action

Received and Entered Into Data Base!

IPT Lead Validates Package and Takes

to DCC for FAMSCO!

IPT Lead or Designer Carries Job to Preplanner

Tooling !

Designer Writes CR/EDA & Obtains Job No., ECPN No. !

(If Reqʼd)!

Designer Identifies Impacted Drawings!Plus Outstanding !

PS, NCI!

Design Investigates SOC and

Determines Proper Solution!

Eng Completes CR Evaluation and Returns to CCB!

CCB Gives Final Approval of CR!

C/A!

CR!

Designer Coordinates With All Functional IPT

Members !(As Required)!

Designer Searches Data Base for

Outstanding PS and Tags/C/A!

Designer Marks up Drawings of

Outstanding PS, NCI and Idʼs Next

to Change!

Designer Marks up F/D and CSPL to

Identify All Changes!

Designer Identifies ALL

AFFECTED IPT Members and Disciplines to

Review the Marked-up

Drawing!

Reviewers Mark up F/D , CSPL and Sign Above the

Title Block!

Designer (Using Checksheet As a

Guide) Self Inspects the Package for

Completeness and Proper

Coordination!

Preplanner Prepares PPA and Signs DRR CR/EDA!

IPT Lead/designer Carries Package to Material Preplanner!And Writes AMO If

Required!

DCC/FAMSCO Establishes S/S

and Gives IPT Lead Engineering Release Date!

Based on Need Date IPT Leader

Delivers First Package to the

First ʻIn-box!̓

Linearized Process Enables Flow


Package Is!Reviewed and Marked

up by 1st Inbox!

Markups Are Incorporated by Design If Markup From 1st Inbox Is

Significant Discuss With IPT Members!

Package Is Delivered to Release!

Center!IPT Lead Reviews Package and Signs!

Single Piece Flow!

Checker Reviews Package and Signs!

Unique Technology Reviews Package and

Signs!

Manufacturing Reviews Package and

Signs!M&P Reviews

Package and Signs!Product Support

Reviews Package and Signs!

Structures Lead Reviews Package and

Signs!

Release Check Reviews Package and

Signs!Package Released!

Single piece flow achieved! !

Same work, longer chain, but…


Removing Waste and Variation

•  Linearized, more predictable process •  Lower cycle time •  Much lower variation in cycle

times •  Reducing process

variation is a key step in implementing lean practices •  Leaner value streams will

show less overall variation

Pre and post lean engineering drawing release data for major aircraft program

Source: Lockheed Martin Corporation


Outcome

Small Value Stream Map

Product Flow

Iterative “Flow”

“Feeder” Flow

Task

<Outcome C>

<Outcome B>

Decision wait" Task

Control

or inventory WT: TT: VAT:

Data Boxes

Decision

•  Maps the movement of the product or service •  Includes “product” flow which leads to the outcome,

as well as control info., feeder, and iterative flows •  Uses standard mapping symbols for tasks, decisions,

and holds


Basic Mapping Symbols

<noun> verb noun

Answer A <Answer B>

<Answer C>

Question?

I

Issue!?

Inventory or waiting

Decision

Task

Burst

Main process flow

Secondary, feeder flow

Information flow


Some extra artifacts: Swim Lanes Fu

nctio

n

Time


Times and Integrative Events

Func

tion

Time

Event in Time - e.g. Deadline

Cross functional, short tim

e task, e.g. PD

R


Parallel Tasks Fu

nctio

n

Time

Deadline PD

R

Overlap indicates task proceed in parallel for some time

Long task box indicates extent in time

parallel tasks across functions


Interdependence

Func

tion

Time (may or may not be to scale)

Deadline

PDR

Some overlap but are still linear

Some parallel tasks are independent

Some are interdependent - note symbol

This example crosses an organizational boundary - IPT


Massive Interdependence and planned iterations

Func

tion

Time (may or may not be to scale)

Deadline PD

R

Many interdependent tasks require a planned iteration process

This example crosses organizational boundaries - ICE?

Dsgn Anls

Rev Ver


Steps in Typical PD Value Stream Mapping

•  Decide what the unit product is •  Identify Tasks, Decisions, Waits, write on post-its •  Arrange by the main (product) flow •  Identify and mark secondary flows

Today, we will illustrate these steps using the value stream mapping exercise from Tuesday’s simulation-based class


Adding Data

•  Wait time or Inventory Levels

•  Time •  Cycle time (CT) - total end-to-end •  In Process Time (IPT)

- something is happening to job •  Value Added Time (VAT) - core process

•  Quality/Decision outcomes •  Rework rate (incident of defects) •  Probability of different outcomes

I 6 units

Task

CT: 10 IPT: 3 VAT: 2

Review

33% Fail


Value-Added Activities   An activity that transforms or shapes material or information   And the customer wants it   And it’s done right the first time (or as right as possible…)

Non Value-Added – Needed Activities   Activities causing no value to be created but which cannot be eliminated

based on current state of technology or thinking   Required (regulatory, customer mandate, legal)   Necessary (due to non-robustness of process, currently required; current

risk tolerance)

Non Value-Added Activities   Activities that consume resources but create no value in the eyes of the

customer   Pure waste   If you can’t get rid of the activity, it turns to yellow

Value-Added vs. Non-Value Added


PDVSM Steps

•  Decide what the unit product is •  Identify Tasks, Decisions, Waits, write on post-its •  Arrange by the main (product) flow •  Identify and mark secondary flows

•  Add inventory/wait data, time data, rework %’s

•  Add Value “dots”


Capacity: Resources to do job

•  Value Stream shows flow through single station

•  Can it handle it? •  Can it handle iterations

and extra work? •  Key metrics are

availability and number of iterations

Design


Capacity Calculation

x % Time Available

Time per interval (days/yr)

Time available

Time/unit =Capacity

(units/interval)

x number of stations

Touch Time (days)

x number repeats needed to finish one unit

•  Local terminology and practices will vary •  Basic concepts do not


Capacity Caveats

•  Insufficient capacity is common root cause of waiting, inventory

•  Assuming best-case, or even average case, availability is dangerous

•  Being conservative is not lean! •  Mixed model lines will have inefficiencies due

to queuing effects - MUST accommodate this •  Multi-tasking of stations will reduce

availability


Capacity Calculation and Gap Analysis

•  For each of your process steps •  Calculate the capacity in product units/time period

•  Does this meet customer demand? •  Is it balanced?

•  If not, gaps exists

•  Add Capacity and (optional) Repeat Count data to your VSM


Analyzing the Value Stream

•  Muda (Waste) •  Look for the seven wastes •  Assess NVA activities

•  Muri (Imbalance or bottlenecks) •  Processes that are slower than others is one

clue •  Capacity is a better metric - do you have

sufficient, balanced capacity? •  Mura (Instability) •  Are their many paths through the system? •  Is there (excessive or unplanned) rework?

Examine your value stream for these problems


7 Information Wastes

•  Waiting: Idle time due to unavailable information •  Inventory: Information that is unused or is “work in

progress” •  Excessive Processing: Information processing

beyond requirements •  Over Production: Producing, distributing more

information than needed •  Transportation: Unnecessary movement of

information between people, organizations or systems •  Unnecessary Motion: Unnecessary human movement

(physical or user movement between tools or systems)

•  Defects: Erroneous data, information, reports Source: McManus, H.L. “Product Development Value Stream Mapping Manual”, LAI Release 1.0, Sept 2005


Multiple Definitions of Waste


Finding Waste on the VSM

Jin Kato © Massachusetts Institute of Technology 31

1. Overproduction Different people/groups are unintentionally creating the same information.

Creating the same information

Non Value-Adding Work

Wasted Engineer’s Time

Wasted time is this period


Waiting


2. Waiting People are waiting.

Wasted Engineer’s Time (engineer is just waiting doing nothing)

Wasted time is this period


Rework


7. Rework Redoing tasks perceived to be finished for some reason

Rework

Wasted Engineers’ Time

Non Value-Adding Work (discarded) Original work

Discarded Portion

Measured period


Handoffs


9. Hand-Off People have to spend time on non value-adding motions.

Wasted Engineers’ Time

Non Value-Adding Work (documentation)

Wasted time is these periods


Identifying problems

•  For each of your process steps •  Calculate the capacity in product units/time period

•  Does this meet customer demand? •  Is it balanced?

•  If not, gaps exists

•  Add Capacity and (optional) Repeat Count data to your VSM

•  Identify problems with the “current state” using waste walk


Waste Walk Exercise

•  In your handout packet there is a Waste Walk Sheet •  Do a waste walk on your work process

•  Engineering/Design work •  Studies •  Research •  etc…

•  If you have colleagues from the same work area with you, do the waste walk together (teams of 3-4 are best)

•  Spend about 10 minutes brainstorming wastes

•  We will share some of our waste walks with the class


Striving for the Future State

•  Establish a Takt Time •  Average or “Psuedo-Takt” time •  Coordination Mechanisms

•  Assure the Availability of Information •  Practice Information 6S •  Collocation and IPTs •  Make information visual •  Make information flow physically •  Pull, don’t push, information

•  Balance the Line •  Eliminate bottlenecks •  Assure the timely availability of

resources •  Reduce and buffer variation •  Remove external constraints

•  Not different in principle from factory lean

•  Need to reinterpret for engineering


Striving for the Future State

•  Eliminate Unnecessary or Inefficient Reviews and Approvals

•  Break Down Monuments •  Break down silo barriers

•  Eliminate Unnecessary Motion •  Eliminate Unnecessary Documents

and (Re-)Formatting •  Eliminate Unnecessary Analyses •  Exploit Underutilized Capacities and

Capabilities

•  Not always about doing less!


Value Stream Mapping applied to PD

•  Same basic techniques apply •  Flows are knowledge and

information flows rather than physical products

•  Process steps may overlap or involve planned iterations

•  Value added steps add or transform knowledge, or reduce uncertainty (role of analysis steps)

•  Quantifies key parameters for each activity (cycle time, cost, quality defects, inventory, etc.)

•  Provides systematic method to improve a process by eliminating waste


PDVSM: What We’ve Learned •  Process iterations are an intrinsic part of the VSM •  Multi-tasked resources is a fundamental problem •  Estimating system capacity is difficult even with good

data

•  VSMs are different in nature at the higher levels •  Focused VSMs: Can fix local problems but may not have

big impact on overall outcomes •  Local level VSMs still very important to do—builds

capabilities that will be needed in enterprise-level efforts

•  At higher levels of activity, it is helpful to use multiple kinds of maps (data) to characterize the system

•  Challenge: PDVSM is great for local improvements, but is it helpful to design/manage PD systems at Enterprise level?


Take-aways

•  Most Engineering processes are, today, the way factory processes were 20 years ago

•  Some effort is wasted, a great deal of time is wasted

•  VSM techniques can be modified to analyze engineering processes

•  Lean techniques can be adapted to improve engineering processes

•  Early applications have been successful in several different applications


Acknowledgements

•  Hugh McManus - Metis Design

•  Earll Murman - MIT •  Eric Rebentisch - MIT

Creating Product Value


Creating Product Value v2.3 for Politechnika Wrocławska 2013 Slide 2 Most content © 2011 Massachusetts Institute of Technology

Learning Objectives

At the end of this module, you will be able to: •  Describe how value is created from concept selection

through production

•  Explain the challenges of selecting the right product concept

•  Describe how engineering decisions impact the creation of value throughout the product lifecycle


Source: Fabrycky & Blanchard

Conceptual/preliminary

Design

Detaildesign/

development

Productionand/or

construction

Product use/support/

phaseout/disposal

100%

80%

66%

Ease of Change

LCC committed

Cost Incurred

How can we make good decisions?

Value is primarily determined at the beginning of a program


Three keys to good upfront decisions

•  Structured program selection process •  Choosing the programs that are right for the

organization’s stakeholders •  Conceptual design practices •  Finding the right form to maximize stakeholder

value over the product (or product family) lifetime

•  Systems engineering •  Determining stakeholder needs and translating

them into functional requirements


Wirthlin’s Framework for Structured Decision-Making

Process

People and Organizational Culture"

Fundamental Business Environment"Process Enabler"

Process Enabler"

The User Needs/requirements Discovery Process!(Prior to a Business Case Decision)!

Identification!

Screening!

Concept!Development!

Business!Case!

Development!Feedback!Process Flow!

Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI Presentation, 1999


Front End Maturity Matrix Based on Researched Best Practices

Process Step Level 1 Level 2 Level 3 Level 4RequirementsIdentification

ʻValidateʼpreconceivedsolutions

Voice of the customerinfluences solutions

Voice of the customerdefines “trade space”for potential solutions

Analytical definition ofdesired end statecapability

InitialScreening

Risk, resources, ortechnology issues notconsidered

Risk, resource, andtechnology issuesaddressed largely bypromises

Risk, resource, andtechnology issuesaddressed by genericrequirements

Portfolio planning basedon clearly specified risk,resource, andtechnology issues

ConceptDevelopment

Requirements listedwithout priority,tradeoffs, or definitionof “ilities”

Requirementscategorized by roughpriority, sometradeoffs, “ilities”briefly mentioned

Clearly-definedrequirements withtradeoffs and roughprioritization, “ilities”defined without costs

Sets of requirementsprioritized throughmultiple tradeoffs with“ilities” fully defined

Business CaseDevelopment

No fundingcommitment, no linkto strategy, noproduct lifecycle plan

Sponsor organizationmust provide funding,link to strategymentioned, productlifecycle mentioned

Launch as soon asresources are found,tailored to strategy,lifecycle planningdone without specifics

Clear definition ofproduct concept withfunding commitment,tied to strategy, withproduct lifecycle plan

OrganizationEnablers

No clear front endstrategy, functionally-driven structures withad hoc IPTmembership

Guidance given onfront end process,functional matrixstructure withchanging IPTmembers

Explicit front endprocess but withoutperformance metrics,large IPT structures

Product developmentstrategy fully definedwith metrics, cross-functional IPTs remainintact throughout

BusinessEnablers

Management notinvolved in front end,training at discretionof employee

Regular briefings tomanagement, commontraining for allemployees

Formal measures offront endperformance, trainingrequired but limited

Active managementparticipation/coaching,extensive employeetraining

Maturity assessment tool has 37 questions, averaged to score front end maturity in the 4 process steps and 2 enablers!


Assessment of Current Organizations


Military! Commercial Non-Aerospace! Aerospace!


Company A’s Front End Process

Front-End Process Flow

Market &BusinessNeed,New Ideas,TechnologyDevelopments

ScreeningCommittee

ProductProposalList

ProgramInitiationRequest

OperationalList

CommercialResearch

TechnicalResearchFeasibilityPhase

ProductLaunchList

SeniorCommittee

BusinessPlan

InitialScreening

Business CaseDevelopment/ Final ScreenIdentification

ConceptDevelopment

Lists maintained by Program Management for the committees



Past (c. 1999) USAF Front End Process

Front-End Process FlowInitial

Screening

Business CaseDevelopment/ Final ScreenIdentification

ConceptDevelopment

Inputs

Analysis ofAlternatives

Office ofAerospaceStudiesprovidesguidance

MAJCOMruns AoA

AO shepherds PhaseZero

PreparedraftORD

AO preparesfinal ORD

AoAfinalreport

MissionAreaTeam

TPIPT

Mission AreaPlan

To other PPBSactivities

Inputs

AO Activities /Draft MNS

Internal Staffing& CommentResolution

MAJCOMCommander approval

AF Gatekeeperreceives MNS

Afterapproval

HQ AO assigned

Staffing to otherMAJCOMs , UnifiedCINCs, and otherservices (as required)

Commentresolution

O-6Levelreview

Flag Review

AFROCvalidation /approval

AcquisitionSystem decision

AF Chief

JROC

Jointprocess

As required

MAJCOMCommander approval

Staffing to otherMAJCOMs , UnifiedCINCs, and otherservices (as required)

Commentresolution

O-6Levelreview

Flag Review

AFROCvalidation /approval

AF Chief

JROC

Jointprocess

As required

AF Gatekeeperreceives MNS

HQ AO assigned

InternalStaffing

Afterapproval

AcquisitionSystem



Identification!Screening!

Concept!Development!

Business Case!Development!

Feedback!Process Flow!

Source: J. R. Withlin, “Best Practices in User Needs/Requirements Generation”, MS Thesis, MIT 2000

Identification Small multidisciplinary teams

Adequate funding

Multiple requirements ID methods used

Independent assessment of solution

Screening Senior level decision

Active portfolio management

Strategic plan and resource constraints guide prioritization

Concept Requirements given as variables within desired range

Team remains intact throughout process

Data driven tradeoff analysis - use of prototypes

Business Case Clear, concise product

concept, architecture and concept of employment

Based upon: •  Product lifecycle

strategy •  Fit with product

portfolio •  Returns to

organization Closure of Technical AND Business Case is Mandatory

Observed Best Practices


No Silver Bullets

•  No single “silver bullet” best practice was found—front end process steps and business and organizational enablers are highly correlated with one another in a holistic process

•  “Picking and choosing” to perform one or a few of “excellent” activities does not ensure front end process maturity—all activities are essential to a mature front end process


Conceptual Design

•  Good front end processes and Systems Engineering do not tell you what the best form for the product is

•  A key to creating the right products are design tools for the conceptual design phase which can handle: •  Evolving user preferences •  Imprecise specifications of product parameters •  Varying levels of technology maturity •  Market and funding uncertainties •  Evolving regulatory, political and other matters

Source: Hugh McManus, “Introduction to Tradespace Exploration”, MIT Space System Architecture Class, 2002


Architecture Tradespace Analysis: Avoiding Point Designs

Cost

Utility

Tradespace exploration enables big picture understanding

Differing types of trades

1. Local point solution trades

2. Multiple points with trades

3. Frontier solution set

Designi = {X1, X2, X3,…,Xj}

4. Full tradespace exploration


Tradespace Reveals Promising Architectures

Design = f()"•  Propulsion sys"•  Fuel load"•  grappling

system"

Utility = f()"•  grappling

capability"•  mass

accelearted"•  timeliness"

SPACETUG"•  General purpose orbit transfer vehicles "


Reveals Limiting Physical or Mission constraints

Hits “wall” of either physics (can’t change!) or utility (can)

Different propulsion

systems and grappling/!

observation capabilities!

Lines show increasing fuel mass fraction!

Cos

t (M

$)


Assessing Changing Requirements

Space Tug example: added requirement for rapid response

drastically lowers utility of electric propulsion designs

User needs change, so Utilities recalculated

Cos

t (M

$)

Cos

t (M

$)


Comparing Point Designs

Designs from traditional process!

Tradespace helps compare

“apples and oranges” concepts

Provides a context for

understanding alternatives

Cos

t (M

$)


Understanding Uncertainties

•  Often learn a lot by simple examination •  Better: Explicitly look at sensitivity of models to uncertainties

•  Clouds are possible locations of a single design •  Uncertainties can be market, policy, or technical •  Mitigate with portfolio, real options methods

Cos

t (M

$)


Car Tradespace

Attribute Weighting Factor

Passengers 0.5 City MPG 1 Overall MPG 0.3 Reliability 0.9 Comfort 0.7 Safety 1 Handling 0.6 Cargo 0.4 Power 0.6 Mileage 0.6 Sum 6.6

City MPG

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50

Reliability

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5


Integrated Concurrent Engineering (ICE)

•  ICE techniques from Caltech and JPL •  Very rapid design iterations •  Reduced time for new designs from 4

weeks to 4 hours (Stagney 2003) •  Linked analytical tools with human

experts in the loop •  Result is conceptual design at more

detailed level than seen in architecture studies

•  Allows understanding and exploration of design alternatives

A process creating preliminary designs very fast

Reality check on chosen architectures aids transition to detailed design


ICE Process

Thermal

Structures

Communication

Command and Data Handling

Configuration

Power Propulsion

Attitude Determination

and Control

Mission Systems

ICE-Maker Server

Cost

Reliability

MATE

ICE Process Leader

“Chairs” consist of computer tool AND

human expert

Verbal or online chat between chairs

synchronizes actions

Electronic communication

between tools and server

Key system attributes passed to MATE chair, helps to drive design session

•  Directed Design Sessions allow very fast production of preliminary designs

•  Traditionally, design to requirements

•  Integration with MATE allows utility of designs to be assessed real time


ICE Allows quick definition of vehicles for these architectures

Bipropellant Cryogenic

Electric – One way Electric – Return Trip

Wet Mass: 11689 kg Wet Mass: 6238 kg

Wet Mass: 997 kg Wet Mass: 1112 kg

SPACETUG Tug Family (designed in a day)


MATE+ICE Example: Space Tug

Structures & Mechanisms

18%

Thermal5%

Mating System

27%

Propellant36%

Link1%

Propulsion (dry)2%

Power11%

C&DH0%

MATE tradespace

Utility = f(complexity, ΔV, speed) ICE Result Source: Hugh McManus and Dan Hastings, “Integrated Concurrent Engineering and MATE-CON”, MIT Space Systems Architecture Class, 2004


A Note on (Multi-Disciplinary) Optimization

•  Models of the fidelity for MATE or ICE modeling may be numerically optimized

•  This may be a good way of exploring very large spaces •  It may also be a good way of honing a good solution •  It is NOT a substitute for decision-maker centered

trade space exploration •  Poorly behaved mathematical problems •  Uncertainty and fidelity issues •  Objective functions often revised based on learning from

the trade space •  etc…


A Note on Set-Based Concurrent Engineering (SBCE)

•  The Toyota Product Development System (TPDS) uses Set-Based Concurrent Engineering to both make preliminary design choices and refine designs to completion

•  Basic idea is to delay decisions, carrying multiple designs forward where practical. Trick is timing: •  Chassis decision made on decade-long cycle •  Muffler decisions made in test lot after full-scale production

has started •  Set-Based design complements trade-space

understanding - keep options open in areas of high risk and/or low cost

•  In TPDS, Chief Engineer owns the “trade-space” knowledge

See Ward, Lean Product and Process Design, LEI, 2007


Barriers to Good Front End Process

•  Current organization structures do not support good process - and organizational change is hard

•  Front-end processes are often orphaned: •  Underfunded •  Institutional owner unclear •  No defined role in corporate strategy and/or

acquisition policy •  Engineering culture resists concurrent teams •  Individual vs. team rewards •  Overburdened specialists

Solution - Enterprise Lean Engineering Focus


Increased knowledge (including understanding of uncertainties) allows better decisions

Changing the Picture

Classic decision impacts New paradigm decision impacts


Engineering for Lifecycle Value

•  Picking the right product for the customer is only one factor in creating value

•  Product needs to be •  manufacturable •  affordable •  profitable •  safe, sustainable, disposable…

Engineering impacts all of these factors


What is Systems Engineering?

•  Systems engineering is a branch of engineering that concentrates on the design and application of the whole as distinct from the parts….. looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspects. (Simon Ramo)


What is Systems Engineering?

It is also a set of techniques (or process) for •  translating stakeholder needs into

functional requirements, •  Tracing physical requirements for any

given solution to functional requirements •  decomposing physical requirements

from system to subsystem to component level, and •  assuring requirements are met through

validation and verification


Payoff

from NASA Systems Engineering Handbook (poor quality courtesy NASA)

Adequate front-end investment avoids overruns!


Best Practice: Use Systems Engineering Tools!

•  No Silver Bullet: •  Tools and methods can be difficult, clumsy, or

over-specific •  Can lead to use of tools after the fact to create

traceable record of decision or to satisfy contract

•  Newer tools (e.g. INCOSE Systems Engineering Handbook Version 3) responsive to these issues - adaptable to a variety of programs


Strong Synergy Between Lean and System Engineering

•  INCOSE Lean Enablers for Systems Engineering •  Application of Lean Principles

to Systems Engineering by pulling from existing body of work

•  Detailed best practices for systems engineers to be lean and promote lean throughout programs

•  INCOSE best product 2009 •  Shingo research prize 2010

2010 Best Research

2009 Best Product


Integrated Product and Process Development - IPPD

•  Preferred approach to develop a producible design meeting value expectations

•  Utilizes •  Systems Engineering •  Translates customer needs and requirements into product

architecture and set of specifications •  Integrated Product Teams (IPTs) •  Incorporates knowledge about all lifecycle phases

•  Integrated tools •  3D CAD/CAM modeling, digital sims, common data bases

•  Training

Capable people, processes and tools are required


Integrated Product Teams (IPT) Drive Enterprise Integration

•  Integrated, preferably co-located, teams of folks across the key functions necessary to complete a job

•  IPT should be the primary responsibility of all members (their first priority, “on call” if working elsewhere)

•  IPT members share a common set of technical tools and data

•  Avoids mistakes due to poor assumptions, lack of knowledge, or lack of communication

IPT environment allows free information flow– a key enabler of an efficient, high-quality process


IPT Formation

•  Leadership and membership varies with project phase •  Includes all relevant functional stakeholder groups

Copyright ©1993 McDonnell Douglas Corporation

continuity of personnel of great value


Lack of Continuity of Team Leadership Correlates with

Unplanned Rework

Source: “Improving the Software Upgrade Value Stream”, Ippolito andl Murman, AIAA Paper 2005-1252


Enabling Tools

•  Integrated tool sets to reduce wastes of handoffs and waiting and increase quality •  Mechanical (3-D solids based design) •  VLSIC toolsets •  Software development environments

•  Design for manufacturing, assembly, and more - DFX •  Dimensional management/variability reduction •  Common subsystems/parts / specifications / design

reuse •  Production simulation (and software equivalents)

All of these tools enabled by people working together in Integrated Product Teams (IPTs)

Source: “Lean Engineering”, LAI Lean Academy™, V4, 2006


Smart Fastener

Hardware

Layout Composite CAD

Part Surfacer

Assembly Models

Parametric Solid Models

BTP Release

Virtual Reality Reviews

Assy/Manf Simulation

Integrated Digital Tools from Concept to Hardware

Common data base replaces disconnected

legacy tools, paper, mock-ups

Source: John Coyle, The Boeing Company


Lifecycle Integration Through DFX

•  Design For {X}: the “ilities” •  Manufacturability (fabrication and assembly) •  Testability •  Maintainability •  Reliability •  Sustainability •  Upgradability •  Environmental compatability •  Disposability •  Other ilities

• X needs to be “designed in” not “patched on”


Design for Quality

•  Variability reduction •  Key Characteristics •  Variation simulation analysis (VSA) •  Design for processes in control •  Statistical process control (SPC)

•  Advanced technology assembly/determinant assembly •  Self locating parts •  Precise holes and surfaces

All phases and areas of engineering must address quality. This is just one example of mechanical design.


•  Coordinated datums and tools

•  Geometric dimensioning and tolerancing

•  Process capability data

•  3-D statistical modeling

•  Focus on the significant few

•  Key processes •  Control charting •  Process improvement •  Feedback to design

Statistical Process Control in

Manufacturing

Dimensional Management in Product Development

Key Characteristics

Variability Reduction

Lean manufacturing requires robust designs and capable processes!


Dimensional Management Enabled by Key Characteristics

Key Characteristics: Critical few product features that significantly affect quality, performance, or cost

System KCs

Feature KCs

Subassembly KCs

Source: Anna C.Thornton, Variation Risk Management, John Wiley & Sons, Inc. 2004

Concentrate Dimensional Management effort where it matters - on KC’s


Benefits of Variability Reduction: Floor Beams for Commercial Aircraft

!747 !777!Assembly strategy !Tooling !Toolless!Hard tools !28 !0!Soft tools !2/part # !1/part #!Major assembly steps !10 !5!Assembly hrs !100% !47%!Process capability ! Cpk<1 (3.0σ ) ! Cpk>1.5 (4.5σ )!Number of shims !18 !0 !

Source:J.P. Koonmen, “Implementing Precision Assembly Techniques in the Commercial Aircraft Industry”, Master’s thesis, MIT (1994), and J.C.Hopps, “Lean Manufacturing Practices in the Defense Aircraft Industry”, Master’s Thesis, MIT (1994)

Source: www.boeing.com


Take Aways

•  Front end processes and tools key to creating the right product

•  Lean Systems Engineering, IPPD/IPT organization, and DFX drive continue the “front loading” through lifecycle value



Reminder: Top Differentiators

1.  High level of upfront project preparation •  Scoping of project •  Staffing of project •  Handling of “Fuzzy Front End”

2.  Focus on project team •  Emphasize on Project Organization over Line Organization •  Strong project leadership

3.  Keep eyes on the ball •  Exploration of customer needs at each step of the project •  Close customer integration, constant feedback loops



References •  Wirthlin, R. J., “Best Practices in User Needs/Requirements Generation”, Master’s

Thesis in Engineering and Management, MIT, Feb. 2000. (see http://lean.mit.edu) http://lean.mit.edu/teleconferences/download-document/208-best-practices-in-user-needs/requirements-generation.html

•  Oppenheim, B. W., Murman, E. M. & Secor, D. A., “Lean Enablers for Systems Engineering,” J. Systems Engineering, 2010. http://cse.lmu.edu/Assets/Lean+Enablers.pdf

•  Ross, A. and Hastings, D., The tradespace exploration paradigm, Proc. INCOSE, Rochester, NY, July 2005.

•  McManus, H. L. and Schuman, T. E., "Understanding the Orbital Transfer Vehicle Trade Space," AIAA Paper 2003-6370, Sept. 2003.

•  McManus, H. L. and Hastings, D. E., "A Framework for Understanding Uncertainty and its Mitigation and Exploitation in Complex Systems." IEEE Engineering Management Review, Vol. 34, No. 3, Third Quarter 2006, pp. 81-94.

•  Ippolito, B. and Murman, E.M., “Improving the Software Upgrade Value Stream”, AIAA Paper 2005-1252, 43rd Aerospace Sciences Meeting, Reno, NV Jan 2005

•  Thornton, A. C., Variation Risk Management, John Wiley & Sons, Inc. 2004.


Acknowledgements

•  Rob Wirthlin, AFIT •  Al Haggerty, Retired Boeing/MIT •  Hugh McManus, Metis Design/MIT •  Earll Murman, MIT •  Eric Rebentisch, MIT

Principles of Lean Product Development


Principles of Lean Product Development for Politechnika Wrocławska 2013 Slide 2 Most content © 2011 Massachusetts Institute of Technology

Learning Objectives

At the end of this module, you will be able to: •  Recognize three major areas of focus for Lean PD

systems •  Recognize and discuss eleven core components

of a lean PD system •  Describe some examples of these lean

components in a product development system •  Recognize that elements of a lean PD system can/

should function as solutions to PD performance challenges


Root Cause Analysis (RCA) Approaches

•  Pareto analysis (list causes, identify largest) •  VSM bursts are equivalent

•  5-whys (e.g., Ishikawa (fishbone) diagrams or tables) •  Move towards processes, use data and analysis to verify

and document causes •  Use categories (8M, 8P*, multiple views, etc.) to force

exploration of a broad range of causes •  Other potentially helpful tools: FMEA, fault-tree

analysis, depending on context and focus

* 8M (manufacturing): Machine (technology), Method (process), Material, Man/Mind Power, Measurement, Milieu/Mother Nature, Management/Money Power, & Maintenance. 8P (services): Product/Service, Price, Place, Promotion, People(key person), Process, Physical Evidence, Productivity & Quality

Point of RCA is ultimately to get to corrective action(s) —ideally part of a PDCA or lean learning Cycle


Measurements Personnel Materials

Methods Environment Machines

Cause and Effect Diagram Also called Ishikawa or Fishbone diagram

Effect or problem

Primary Cause

Primary Cause

Secondary Cause

Suggested major

categories

A root cause analysis

tool, often supported by 5 Whys


Root Cause/Corrective Action Cycle

1.  Identify wastes 2.  Identify root causes 3.  Define corrective actions 4.  Select and implement corrective actions 5.  Measure effectiveness of corrective actions 6.  Adjust; Control; Repeat

•  Most corrective actions are root cause or problem-specific •  Received “Lean Practices” are generic prescriptions for

improved operations and performance—do they all (and always) apply?

Waste/ Problem

Bad Process/ Practice

Root Cause

Corrective Action

Identify Identify

define

Implement

Eliminate


General Root Causes of Waste in PD Systems

48 Business: changes in political scenario"48 Business: changes in social scenario"48 Business: ecological/environmental factors"48 Measurement: no or impractical measurement system"48 Structure: scattered structure"47 People: low discipline"46 Requirements: conflicting requirements not resolved"46 Requirements: incomplete or incorrect picture of customer needs"46 Requirements: no/poor requirements management"46 Requirements: poor translation of requirements into specs"46 Verification & Validation: bad testing"46 Verification & Validation: late verification"46 Verification & Validation: premature validation"46 Execution: doing without knowing or understanding"46 Market: there is no dominant design for product"46 Tech Solution: complex product architecture with excessive interfaces

Wastes (10 categories, 28 sub-categories) • Overproduction • Waiting • Transportation • Overprocessing • Inventory • Motion • Defects • Correcting • Wishful thinking • Happenings 67 Communication: ambiguity or multiple understandings"59 Standard Process: unclear/absent task ownership"57 Execution: lack of shared vision"56 Integration: Inconsistency between plans or plans' parts"53 Tool: complex equipment, tool or technique"53 Tool: lack of integrated solution that meets the requirements of all users"53 Structure: unclear or mismatching policies, roles, and rules"51 Execution: priorities not clearly defined"50 Strategy: missing or unclear objectives/targets"50 Tech Solution: lack of concurrent engineering"50 Execution: inadequate information delivered"50 Execution: poor knowledge transfer"50 Strategy: technology development concurrent with development of product"50 Execution: poor change management"50 Execution: poor WIP version management"50 Strategy: lack of solid strategy"49 People: teamwork issues"48 Business: changes in economical scenario" Source: Pessôa, “Weaving the Waste Net”, 2008 White

Paper – LAI 08-01

Top Causes of PD Wastes (ranked, from 156 total)


Lean Practices as Countermeasures (Corrective Actions) for PD Problems

•  We’ve defined PD wastes and explored methods to identify them

•  We’ve discussed root causes and RCA methods

•  Are there Lean Practices that counter these root causes? •  What are the current prevailing claims about

Lean PD practices? •  What problems are they good for solving?


Invest

People

Time

Manufacturability

Functionality/Usability

Serviceability/Recycling

Minimize waste!

Inputs Outputs

Maximize value!

Minimizing system inputs and maximizing system outputs to maximize return on investment

Product Development

Process

Waste and value in product development


Our Motivation and Focus

•  Motivation: •  Lean PD thinking is relatively recent, emergent—

empirical evidence is still somewhat limited •  Many claims about what Lean PD comprises—

what are the attributes of a lean PD system? •  What is actually being done in organizations

attempting lean PD? •  Step 1: Review recent publications on Lean PD

•  Identify a core set of espoused Lean PD system components


Literature Review Identified Superset of Lean PD System Components

Process standardization

Rapid prototyp., simul. and testing

Product variety management

Supplier integration

Simultaneous engineering

Specialist career path

Strong project manager

Cross-project knowledge transfer

Responsibil.-based plann. and contr.

Workload leveling

Set-based engineering

Lean PD Component Clark et al. 1987

Womack et al. 1991

Karlsson1996

Ward 2001

Kennedy 2003

Morgan, Liker 2006

Brown 2007

Schuh 2008

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X


11 Lean PD System Components Are the Basis for Empirical Research


Rapid prototyping, simulation and testing







Responsibility-based planning and control

Workload leveling


1

2

3

4

5

6

7

8

9

10

11


Workload Leveling










Workload leveling


Resources and capacities are planned on a project and

cross-project basis. In the course of the project,

required resources are controlled frequently and

flexibly adapted in the case of occurring bottlenecks.

1

2

3

4

5

6

7

8

9

10

11


Leveled Workload Unleveled Workload

Req

uire

d C

apac

ity

Proc

ess

Man

agem

ent

General idea of Workload Leveling


What Problems Does the Workload Leveling Solution Address?

Symptoms: • Difficulty in coordination/handoffs • Late deliveries/overdue inputs • Excessive inventory at key points in process • Firefighting and stress

Root causes: • Overloading key resources


Strong Project Manager










Workload leveling


Product development projects are led by an

experienced project leader, who is largely

responsible for defining customer value and securing

the success of the project from concept to market.

1

2

3

4

5

6

7

8

9

10

11


Toyota Chief Engineer •  The chief engineer (CE) is an entrepreneurial position in a

large bureaucratic organization. •  The "Heavyweight Program Manager"—a super-engineer

AND leader •  The most admired position within Toyota, even more

than a director or vice-president •  The CE is the person responsible to senior management for

the success of a new product line, and for ensuring value delivery to the customer. •  Focuses on integration across disciplines and functions •  Does not have formal authority over the engineers

working on the program but has ultimate responsibility for the success of the design, development, and sale of the car

•  Is responsible for: •  Overseeing design projects •  Making sure they are on time, on budget

•  Ultimate responsibility: •  Delivering value to the customer

See Morgan and Liker


Toyota Chief Engineer, Cont.

•  Chief engineer role borrowed from the aeronautics sector and adapted by Toyota

•  Characteristics valued in a CE: •  visceral feel for what customers want •  exceptional engineering skills •  intuitive yet grounded in facts •  innovative yet skeptical of unproven technology •  visionary yet practical •  hard-driving teacher, motivator, and disciplinarian, yet a

patient listener •  no compromise attitude to achieving breakthrough

targets •  exceptional communicator •  always ready to get his or her hands dirty

See Morgan and Liker


Leadership Role in Enabling Continuous Learning/Improvement

•  Primary Lean leadership tasks: •  Facilitate continuous learning in subordinates

•  Actively “pull” improvements by setting expectations •  Mentor observing/experimenting/improving behaviors •  Facilitating implementation of improvements where

necessary •  All leaders actively involved in the process.

•  High-involvement ideas systems attributes •  Impediments to making improvements streamlined/

eliminated •  Timely, constructive evaluation and feedback •  Rapid prototyping/implementation •  Peer-review to ensure quality

See Spear; Robinson et al


What Problems Does the Chief Engineer Solution Address?

Symptoms: •  Product misses market targets, fails to delight customers •  Unclear product plan, missed milestones •  Program limps along as design fails to converge •  Technology maturation on critical path causes schedule slips •  Poor handoffs across functions cause rework, schedule slips

Root causes: •  Failure to establish customer needs/requirements and

communicate them across program •  Poor communication across organizational boundaries •  Incentives/rewards flow through functional silos •  Failure to establish shared vision of program value & outcome •  Poor technology maturation and transition process


Specialist Career Path










Workload leveling


Engineers are given the opportunity to advance in

their technical domain, based on personal coaching

and frequent feedback by their superiors.

1

2

3

4

5

6

7

8

9

10

11


What Problems Does the Specialist Career Path Solution Address?

Symptoms: •  Technically undifferentiated products •  Recurring technical problems on programs •  Limited to no change in engineering productivity over time •  Turnover in technical staff diminishes technical depth over

time

Root causes: •  No culture of leadership responsibility for mentoring and

teaching technical skills •  Unclear and conflicting incentives for technical staff •  Failure to formally reward and value technical excellence


Responsibility-based Planning and Control










Workload leveling


Development engineers are locally responsible for planning, execution and

control of detailed product development

activities.

1

2

3

4

5

6

7

8

9

10

11


Responsibility-based planning Top-down planning

* * * * * * * Month

* * * * * * * * *

Month * * * * * * *

Project planner and project leader determine milestones and detailed activities for engineering workstreams

Project leader sets major milestones

Engineer details workstreams and estimates duration

Iterative loop

Top-down planning vs. responsibility-based planning


What Problems Does the Responsibility-Based Planning

Solution Address?

Symptoms: •  Poor handoffs across functions/processes results in rework

and schedule slips •  Poor first-pass yield on technical processes •  Low rates of professional employee involvement in

continuous process improvement

Root causes: •  Rigidly-defined work roles and rules •  Hierarchical organizational culture •  Reward based on criteria other than performance •  Lack of respect for people


Cross-project Knowledge Transfer










Workload leveling


Successful methods, designs and tools as well as areas for improvement are

documented on a cross-project basis and actively

used and refined in subsequent projects.

1

2

3

4

5

6

7

8

9

10

11


Effective Knowledge Capture Enables Reuse

•  Key element of standard work •  Domain expert is owner •  Keep it simple/usable •  Define:

•  Part performance over a range •  Performance limitations •  Failure modes with root causes

and countermeasures •  Graphical display is better

•  Simplify and update continuously •  Benefits from product standard

architecture

Source: Ward; Images from Marsiglio, Gildersleeve


What Problems Does the Cross-project Knowledge Transfer Solution Address?

Symptoms: • The same technical problems keep cropping up across the organization without permanent fixes • Engineering productivity is stagnant • Limited number of go-to people in the organization who can get things done • Program success is unpredictable and highly variable across the portfolio Root causes: • Knowledge is the primary (only) source of power for engineers • Knowledge capture is clumsy and dependent upon the good will (and perhaps spare time) of the technical staff • Reuse of knowledge and designs is un- or under-valued


Simultaneous Engineering










Workload leveling


Production, quality assurance and purchasing departments are integrated into development activities

at an early stage. The design of production processes and

facilities is conducted in parallel to the development

of the product.

1

2

3

4

5

6

7

8

9

10

11


* * * * * * * * * * * Week

* * * * * *

System testing Integration Module testing

Process design

Module design Evaluation Concept

Sequ

entia

l En

gine

erin

g

* * * Week

* * * * * * * * * * * * * *

System testing Integration

Concept

Process design

Evaluation Module design Module testing

Sim

ulta

neou

s En

gine

erin

g

Sequential vs. simultaneous engineering


What Problems Does the Simultaneous Engineering Solution Address?

Symptoms: •  Poor transitions to production result in delays, scrap/rework,

and high COGS •  Slow ramp-up to volume production as designs are refined on

the factory floor •  Poor asset scheduling or conflicts result in bottlenecks

•  Poor process yields affect product quality and warrantee costs Root causes: •  Engineering physically and professionally distant from

manufacturing •  Poor communication across organizational boundaries •  Manufacturing has lower status in the organization •  Failure to capture and share manufacturing process

information outside of manufacturing


Supplier Integration










Workload leveling


Suppliers of critical parts are identified early in the project,

integrated into the development process and

actively supported to improve their performance.

1

2

3

4

5

6

7

8

9

10

11


What Problems Does the Supplier Integration Solution Address?

Symptoms: •  Poor supplier delivery performance (cost, schedule) •  Poor quality or unmet technical performance in procured

parts •  Program delays attributable to procured parts

•  Routine “surprises” from suppliers during program execution Root causes: •  Cost is overriding criteria for selecting suppliers •  Arms-length relationships with suppliers because of desire to

maximize market and bargaining power •  Lack of awareness of product architecture vulnerabilities to

supplied content •  Organizational arrogance


Product Variety Management










Workload leveling


There are targets for the use of off-the-shelf components and reuse of parts as well as

standardized modules and product platforms.

1

2

3

4

5

6

7

8

9

10

11


Product Variety

Management

Use of commodities

Reuse of parts

Definition of modules

Definition of product

platforms

Major characteristics of product variety management


What Problems Does the Product Variety Management Solution Address?

Symptoms: •  Long cycle time to develop new products •  High lifecycle costs for users/consumers •  Limited product portfolio leads to weakened market power •  Failure to effectively respond to emergent market

opportunities •  Large numbers of unique parts, spares, inventory

Root causes: •  Program-by-program focus •  Low investment in non-recurring product architecture

development •  Lack of portfolio-level coordination mechanisms with

enforcement powers over programs


Rapid Prototyping, Simulation and Testing










Workload leveling


For a fast and reliable evaluation of concepts and

drafts, rapid prototyping technologies, computer

aided simulation, methods for fast physical modeling and flexible manufacturing

are used.

1

2

3

4

5

6

7

8

9

10

11


Plan

Do

Check

Act

Define requirements

Execute design

task

Simulate and test

Change or refine design?

Micro-level product design cycle


What Problems Does the Rapid Prototyping, Simulation and Testing Solution Address?

Symptoms: •  Long development cycle times •  Low first-pass yield on design processes results in rework

and schedule delays •  Infrequent (batched) tests lead to long rework loops and

significant schedule slips or compromised product performance

Root causes: •  Lack of a culture that encourages experimental problem-

solving during product development •  Limited investment in tools for low-cost experimentation


Process Standardization










Workload leveling


For planning, executing and documenting projects,

standardized processes, tools and methods are used.

1

2

3

4

5

6

7

8

9

10

11


Organization Learning Kernel

See Spear and Bowen, Decoding The DNA of The Toyota Production System, HBR, September-October, 1999

1.  Specifications document all work processes and include content, sequence, timing and outcome

2.  Connections with clear YES/NO signals directly link every customer and supplier

3.  Every product and service travels a single, simple and direct flow path

4.  Workers at the lowest feasible level, guided by a teacher, improve their own work processes using scientific methods

5.  Integrated failure tests automatically signal deviations for every activity, connection and flow path

Widespread application of scientific approach to problem-solving defines Toyota operating culture


Standard Work a Prerequisite in the Scientific Approach

•  Elements: •  Workflow maps (flows, swimlanes, dependencies) •  Activity description (task description, work instructions,

tools, SIPOC) •  Tools and methods (validated tools with range of

applicability, instructions) •  Design criteria (intent and basis for specifics) •  Design standards (preferred configurations and processes) •  Lessons Learned (revisions to methods, history,

performance) •  Practitioner capabilities (assess ability of engineers to

perform standard work without supervision or review) •  Standard work allows experimentation and continuous process

improvement

See HBS case N2-604-084 (2003) for a description of engineering standard work at Pratt & Whitney


What Problems Does the Process Standardization Solution Address?

Symptoms: •  Long development cycle times •  High levels of design and analysis rework resulting from poor

first-pass yields •  State of completion of the development program is unclear,

especially early-on •  Difficult to accurately lay out plans for new programs •  Design productivity is stagnant

•  Apparent lack of design capacity Root causes: •  Poor process discipline in engineering •  Lack of detailed understanding of the design process •  Ill-defined measurements and rewards for design performance


Set-based Engineering










Workload leveling


When developing a product module, a large number of alternative solutions are considered early in the

process. The set of solutions is subsequently narrowed

based on simultaneous development and testing of

the alternatives.

1

2

3

4

5

6

7

8

9

10

11


Solution for a module

Poin

t-bas

ed

Engi

neer

ing

Set-b

ased

En

gine

erin

g

Project milestones Iterations

Point-based vs. set-based engineering


Set-Based Engineering

Core element of Toyota PD process; Key aspects include: •  Intentionally develop multiple solutions to design before

selecting preferred concept •  Encourage boundary-spanning interactions among

engineers •  Develop tools for trade-off analysis among different

perspectives •  e.g., parametric models, ICE, etc. •  Can be manipulated/modified by users and serve as a

communication medium •  Capture and maintain knowledge (models, tools, checklists)

that demonstrate different solutions •  Plan time and resources at front end of PD process to allow

participants to explore alternative solutions


What Problems Does the Set-Based Engineering Solution Address?

Symptoms: •  Long product development cycle times •  Designs hard to change/adapt after initial definition (but drift

as they struggle to converge) •  Build-test-fix rework cycles result in schedule slips •  Final designs not quite optimal, if the optima is even

understood Root causes: •  Failure to invest in standardized design tools and product

architectures •  Lack of problem-solving (e.g., design, analysis) depth •  Rush to product solutions spurred by desire to demonstrate

progress •  Lack of realistic appreciation for and management of risks and

uncertainties in the product


Concluding Thoughts

When presented with a Lean practice or solution, get in the habit of asking these questions:

•  What problem is this practice intended to fix? •  Is that the problem I need to fix? •  Am I sure I know what the problem is that I need

to fix? •  Is this exactly the right fix, or is it good enough

until I can find a better one, or do I need to design my own fix?

•  How many people in my organization can answer these questions and provide the answers?


Acknowledgements

•  Joern Hoppmann, ETH Zurich •  Josef Oehmen, MIT •  Eric Rebentisch, MIT


References •  Pessôa, Marcus, “Weaving the waste net: a model to the product development

system low performance drivers and its causes”, LAI White Paper – LAI 08-01, January 2008.

•  Hoppmann, Joern, “The Lean Innovation Roadmap – A Systematic Approach to Introducing Lean in Product Development Processes and Establishing a Learning Organization”, Diplom Thesis, June 2009.

•  Hoppmann, Joern, et al. “Efficient Introduction of Lean in Product Development: Results of the Survey” LAI Benchmarking Report, June 2009.

•  Ward, Allen, “Lean Product and Process Development”, Lean Enterprise Institute, 2007

•  Marsiglio, Ron, “Introduction to Knowledge Based Product Development”, Lean Product and Process Development Exchange, Denver CO April 2008.

•  Gildersleeve, Rich, “Delivering Results Through Lean Product Development”, Lean Product and Process Development Exchange, Denver CO April 2008.

•  Spear, Steven, “Learning to Lead at Toyota”, Harvard Business Review, May 2004

•  Spear, Steven and H. Kent Bowen, “Decoding the DNA of the Toyota Production System”, Harvard Business Review, Oct 1999

•  Robinson, Alan and Dean Schroeder, “Ideas Are Free”, Berrett Koehler, 2006

Enterprise Product Development System Design


Enterprise Product Development System Design v2.3 for Politechnika Wrocławska 2013 Slide 2 Most content © 2011 Massachusetts Institute of Technology

Learning Objectives

At the end of this module, you will be able to: •  Recognize the different contingencies that

influence the application of specific lean practices

•  Explain how three example lean product development system designs vary from one another and why •  The challenges they address •  Their attributes •  Their outcomes


Applying a Lean Philosophy to General PD Processes

•  How to obtain lean benefits from PD processes in a context different from automobile production? •  Best practices can generally be directly

adopted in a new setting when the underlying operating logic is the same

•  Successful adoption within a different context often requires reinterpretation and adaptation of processes, relationships, and artifacts

•  What factors determine which known lean practices apply under which circumstances?


Basic Questions for Assessing Lean PD Systems

•  Some fundamental PD system design questions: •  Does the process perform reliably, consistently, accurately? •  Is the process capable of delivering what is needed? •  Does the process have enough capacity to meet demand? •  Does the output delivered meet the expectations of the

downstream customer? •  Is the output delivered when and where it is needed? •  Are enterprise functions, processes, and interests aligned?

•  Generalizing: •  Can we ensure reliable and predictable behavior from the

process locally (i.e., how variable is it?) •  …so that we can coordinate across the system more

effectively (i.e., are interdependencies a significant issue)?


Some Contingencies to Consider in Lean PD System Design

•  Input variability •  Task variety •  Requirements novelty

•  Process variability •  Process maturity and expected quality of outputs •  Knowledge capture/reuse

•  Complexity •  Coupling and interdependencies across functions and

handoffs •  Product architecture

•  What is the objective? •  Low cost? Fast? High quality? All/part?


Three Cases Show How Contingencies Influence Organizational Design

1.  Low variety tasks with local interdependencies

2.  Somewhat complex tasks with global interdependencies

3.  High variability work—removed from standard execution routines

•  Note: each of these cases benefit greatly from standardized product architecture—particularly (1) and (2)—but we’ll focus primarily on process design


Example #1: Increase Throughput of Routine Work

•  Scenario: production support requires timely approval of engineering changes to meet demands of products moving through manufacturing operations

•  Example: Production support center •  Approach: use value stream map to identify non-

value adding activities, and long-cycle time processes. Standardize work as much as possible to eliminate variation and long decision delays

•  Solution: dedicated production support organization with streamlined processes, standard work, visual control, shortened cycle time, and high outcome predictability


Complex Process Requires Iteration

 Engineering release process prior state


Request for Engineering Action

Received and Entered Into Data Base"

IPT Lead Validates Package and Takes

to DCC for FAMSCO"

IPT Lead or Designer Carries Job to Preplanner

Tooling "

Designer Writes CR/EDA & Obtains Job No., ECPN No. "

(If Reqʼd)"

Designer Identifies Impacted Drawings"Plus Outstanding "

PS, NCI"

Design Investigates SOC and

Determines Proper Solution"

Eng Completes CR Evaluation and Returns to CCB"

CCB Gives Final Approval of CR"

C/A"

CR"

Designer Coordinates With All Functional IPT

Members "(As Required)"

Designer Searches Data Base for

Outstanding PS and Tags/C/A"

Designer Marks up Drawings of

Outstanding PS, NCI and Idʼs Next

to Change"

Designer Marks up F/D and CSPL to

Identify All Changes"

Designer Identifies ALL

AFFECTED IPT Members and Disciplines to

Review the Marked-up

Drawing"

Reviewers Mark up F/D , CSPL and Sign Above the

Title Block"

Designer (Using Checksheet As a

Guide) Self Inspects the Package for

Completeness and Proper

Coordination"

Preplanner Prepares PPA and Signs DRR CR/EDA"

IPT Lead/designer Carries Package to Material Preplanner"And Writes AMO If

Required"

DCC/FAMSCO Establishes S/S

and Gives IPT Lead Engineering Release Date"

Based on Need Date IPT Leader

Delivers First Package to the

First ʻIn-box"̓

Linearized Process Enables Flow


Package Is"Reviewed and Marked

up by 1st Inbox"

Markups Are Incorporated by Design If Markup From 1st Inbox Is

Significant Discuss With IPT Members"

Package Is Delivered to Release"

Center"IPT Lead Reviews Package and Signs"

Single Piece Flow"

Checker Reviews Package and Signs"

Unique Technology Reviews Package and

Signs"

Manufacturing Reviews Package and

Signs"M&P Reviews

Package and Signs"Product Support

Reviews Package and Signs"

Structures Lead Reviews Package and

Signs"

Release Check Reviews Package and

Signs"Package Released"

Single piece flow achieved! !

Same work, longer chain, but…


Process After Lean Process Before Lean

Single Piece flow, concurrent engineering, co-location"

Parallel, Co-located Process Even Better


Cycle-Time Process Steps Number of Handoffs Travel Distance

75% 40% 75% 90%

F-16 Lean Build-To-Package Support Center

849 BTP packages from 7/7/99 to 1/17/00 "


•  Reduced Rework from 66% to <3% "•  Reduced Number of Signatures 63%"

Typical Result:"

Cycle time"reduced and"lower std. dev."

More predictable"process"

Standard, Predictable Process


Support Engineering Ideal State VSM

•  Maximum parallelism to minimize cycle time •  Collocation to maximize communication •  Planned iteration to deal with

interdependencies

Log in

Design

Analysis

Verification Review

Work

Job Release

INTEGRATED CONCURRENT �SUPPORT ENG. CENTER �

Balance


X"

Released BTP,"Available at Point of Use"

Production"Problem"

BTP"Support"

Center"(BSC)"

Canopy"

Hydraulics"

Ldg Gear"M&P"

Fuel Sys"

Stress"

Buyer" Tool Design"

Program"Structures"

ECS Instl"

Fire Control Sys" Elect Planner"

Arm Sys"Planner"

Harness Def" Avionics"

ECS Sys"

Wiring Instl"

Parts Engrg"

Dispersed BTP Technical Expertise Pool"Frac & Fat"

Equip Instl"

Escape Sys"

Life Suppt"

Labs"

Maintainability"

Safety"

Propulsion"

Customers"

Tool Mfgrg"

TMP"

Coproduction"

Scheduling"

MRP Planner"

DCMC"

NC Programmer"

PP&C"

Process Control"CRB"

PQA"

Assets Allocated to "Activities not People"

Requires Culture Change


Example #2: Increase Throughput for Highly Interdependent Process

•  Scenario: product architecture-spanning activities require inputs from multiple functions, resulting in long loops and decision cycles

•  Example: Integrated Concurrent Engineering (ICE) •  Approach: use value stream map to understand

interdependencies and long iteration loop processes that lengthen cycle time. Co-locate decision-making as much as possible to eliminate long decision delays

•  Solution: co-located integrated product teams that contain domain experts with access to domain tools/knowledge to streamline decision cycles, accelerate trade-off analysis cycles


Change harder when work crosses boundaries

DONE

CHECK

STRESS

FIX FORMAT

FEM?

CHECK CHECK

FEM. MODEL MARGIN

CALC

FIX FORMAT 2

LOADS MATL. DATA

BLESS? MAJOR PROB?

FIX STRESS REDLINES

REVIEW REDLINES MORE

FEM?

A

B

1-12(4) 100 % c. 60 %

75+ % 1-12(4) 1-12(4) 1-10 (4) 1-10 (1)

1-32(17) 0-1 (1) 1-32(14) 0-1 (1)

1-5(3) 1-6 (4)

0-1 (1)

1-10 (1)

1-5 (3)

ETC.(!) Y

N N

N N

Y Y Y

B

Slow iterations, waiting

Late start

Incomplete data

Big bad loop

Loads, Matl.

Quality

Stress

Design


RTCE: “Real-Time Concurrent Engineering”

Case Study: •  Team chartered in the

Product Development Group at a Major Aerospace Company, Fall 2001

•  About 15 Engineering Specialists collaborate with Marketing and other Managers in carefully scripted, 4-hour, real-time design sessions See Stagney (March 2003) presentation at LAI plenary

conference product development team meeting


RTCE Team Experience

Tremendous Success in the First 9 months! •  Completed at least 20 new product proposals •  Trimmed 33% lead time from their standard process •  Created new designs in as little as 4 hours – compared to up to

4 weeks previously •  Distinct Competitive Advantage in time-sensitive situations

•  Higher quality designs are being produced •  More detail, earlier in process

•  Sharing over 7000 design variables in real time •  Objective decisions •  Focus on System Design - no sub-optimization •  Efficient Process and Motivated Team

See Stagney (March 2003)

Pure RTCE work faded after a few years due to cultural inertia and “return to the norm”


“Agile” development

•  Used primarily in software

•  Small teams •  Rapid, nested

iterations •  Continuous customer

feedback

•  Related methods (e.g. IDEO) used for rapid mechanical design

VersionOne, Inc., used under Creative Commons Attribution-Share Alike 3.0 License


B 777: Integrated Product Development

Design Innovations

•  Largest twin jet with 90K lb thrust engines

•  Fully digital definition & digital mock-ups

•  238 Design-Build Teams w / engineering, manufacturing, and all stakeholders

•  ARINC 629 data bus

Outcomes •  Delivered on

schedule and service ready

•  90% reduction in drawing changes & material rework

•  Happy customers

LE Practices •  Customer at Seattle! •  Architected for

derivatives •  “Working Together”

• Supplier integration • Multifunctional design teams

• Open/honest comm. •  Integrated design tools •  DFMA, DFX •  Quality focus in eng’g

Design Drivers

•  New York-Beijing Range

•  “Service ready” • ETOPS • Dispatch reliability • Composites

•  Development time

Context •  Competition with

MD11, A330/340 •  Time to market

Source: NASA

Source: Haggerty & Murman, ICAS 2006


Balance

Integrated Product Center Ideal State VSM

•  Some parallelism to simplify process •  Upfront work to minimize rework

Management Management

Design

Job Release

Systems Integration

Systems Upfront

work

Analysis

Verification Review

FAIL

FAIL

PASS

PASS

Review

Log in TEAM-BASED DESIGN CENTER �


Example #3: Increase Productivity for Highly Uncertain Process

•  Scenario: immature technology, uncertain requirements, or high task variety cause high process variability, low predictability of outcomes, and coordination challenges for a larger program

•  Example: Dedicated tiger team •  Approach: Remove difficult problems off the

critical program execution path, generate experiments, prototype, and iterate build-test-fix cycles to converge on an effective solution

•  Solution: Small team with experienced, multi-skilled participants address tasks that have potential for significant impact on execution in the rest of the organization. Generally use segregated, unconventional processes


Examples

•  Iterations/spiral development •  Use multiple iterations to mature product to

achieve performance or affordability objectives •  Toyota Module development teams •  Senior engineers from functional disciplines

perform product/process analyses as part of product definition phase before detailed design begins

•  Skunk works •  Remove novel product applications from

mainstream enterprise acquisition, development, and fielding processes


Example Toyota Practices

•  Kentou studies •  Front-end analysis by senior engineers define the

product concept so as to be compatible with enterprise capabilities—before detailed design begins

•  Mizen Boushi •  Develop “eyes for risk” in early stages of product design

•  Set-based Concurrent Engineering •  Assess and evaluate multiple solution concepts within a

product space before selecting the preferred solution •  Technology Development process •  Develop new technologies in a separate organization;

Chief engineer “pulls” mature technology into production programs (e.g., Prius)


Not New: Some of Kelly Johnson’s Rules

•  Skunk Works manager must be delegated practically complete control of his program in all aspects.

•  Use a small number of good people •  There must be a minimum number of reports required, but

important work must be recorded thoroughly. •  Don't duplicate so much inspection. •  The contractor must be delegated the authority to test their

final product in flight. They can and must test it in the initial stages. If they don't, they rapidly lose their competency to design other vehicles.

•  There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

• 


Advanced R& D Example: HondaJet

Overview • 4-6 pax Advanced VLJ • Large cabin volume • 1,180 nm range • 420 KTAS @ 30K ft. • Jan 1998 program start • Dec 2003 first flight

Value Delivered • Technology proven for:

• Laminar flow wing • Laminar flow fuselage • Engine installation

• Product launched July 2006 for $3.65M VLJ

• Over 100 orders Processes

• Customer needs drove technical design

• DFX for choices aircraft “will live with”

• IPPD • New technology only

where needed. • Co-location, no walls • Rapid communication &

decisions, no meetings • 2 yr risk reduction study

People • Customer engaged one

year before program launch.

• Chief Engineer driven • Small co-located team:

25 engineers, 10 techs • Flat organization • Engineers did design,

production, testing • Genchi genbutsu • Vision aligned the team

Tools • Rapid simulation tools

for early studies • Rapid prototyping wind

tunnel models • Simple/partial mockups

for engineer learning • SOA computational

simulation & testing • Obeya - big room

Sources:Warwick, G., “Opening doors: Car maker Honda’s aircraft research and development facility gears up for the HondaJet”, Flight International, Dec 1, 2007. Personal communication with M. Fujino, Dec. 2007

https://hondajet.honda.com


Scenario #1 Low variety tasks

with local interdependencies

Scenario #2 Somewhat complex

tasks with global interdependencies

Scenario #3 High variability work—

removed from standard execution routines

Input variability Low Low/Med High

Process variability Low Med/High Med/High

Complexity Low/Med Med/High Med/High

Objective Fast Response— a little higher cost process here saves in a much higher cost manufacturing process

Reduce cost and cycle time— Want process quality/coordination to be high to reduce potential loopbacks

Reduce variability for other execution paths

Summary


Managing The Exogenous Factors

•  Exogenous factors that can increase organizational complexity and undermine lean •  Product variety •  Product complexity/interdependencies •  Product risk

•  The previous examples have shown that they can be accommodated by appropriate organization design and use of lean principles •  Potentially at the risk of increased complexity in execution

•  Another lean principle that addresses these is to manage the product architecture and product portfolio to tailor levels of variety, complexity, and risk to match organizational capabilities and strengths •  Standard and modular product architectures reduce overall

portfolio complexity and risk in part through knowledge reuse •  Toyota is very effective at enabling stable core execution

processes through a variety of practices, including product family management


Scenario #1 Low variety tasks with

local interdependencies

Scenario #2 Somewhat complex tasks with global

interdependencies

Scenario #3 High variability work—

removed from standard execution

routines

Scenario #4?

Input variability

Low Low/Med High

Process variability

Low Med/High Med/High

Complexity Low/Med Med/High Med/High

Objective Fast Response—a little higher cost process here saves in a much higher cost manufacturing process

Reduce cost and cycle time—Want process quality/coordination to be high to reduce potential loopbacks

Reduce variability for other execution paths

Question

Can you think of another scenario based

on your exper-ience?


Take-aways

•  Performance of specific PD processes can be improved dramatically through focused design of processes •  Start with objectives in mind, VSM as a starting point to

understand the nature of the task and challenges •  Many existing tools and processes can be more effective with

proper architecture and coordination •  Enterprise performance enhanced from integrated design

and execution of many high-performing PD processes •  Make inputs, outputs crossing functional boundaries predictable •  Coordinate activities across boundaries (visual, communication,

shared understanding, etc.) to minimize disruptions to flow of work in PD system

•  Develop and balance capacity with stabilized/managed demands •  Product architecture is another important variable in

managing overall PD enterprise productivity


Acknowledgements

•  Hugh McManus, Metis Design/MIT •  Earll Murman, MIT •  Eric Rebentisch, MIT

Elements of Lean Engineering Introduction · 2010 Best Research 2009 2009 Best Product 2011 2010+...

Documents

Transcript of Elements of Lean Engineering Introduction · 2010 Best Research 2009 2009 Best Product 2011 2010+...