[go: up one dir, main page]

0% found this document useful (0 votes)
16 views64 pages

Lean II

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views64 pages

Lean II

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 64

16.885J/ESD.

35J - Nov 18, 2003

16.885J/ESD.35J
Aircraft Systems Engineering

Lean Systems Engineering II

November 18, 2003


Prof. Earll Murman
16.885J/ESD.35J - Nov 18, 2003

Systems Engineering and Lean Thinking


• Systems Engineering grew out of the space industry in response
to the need to deliver technically complex systems that worked
flawlessly upon first use
– SE has emphasized technical performance and risk management of
complex systems.
• Lean Thinking grew out of the Japanese automobile industry in
response to the need to deliver quality products with minimum use
of resources.
– Lean has emphasized waste minimization and flexibility in the
production of high quality affordable products with short development
and production lead times.
• Both processes evolved over time with the common goal of
delivering product or system lifecycle value to the customer.
16.885J/ESD.35J - Nov 18, 2003

Lean Systems Engineering


Value Phases

Value Value Value


Identification Proposition Delivery

Identify the Develop a robust Deliver on the promise


stakeholders and value proposition with good technical
their value to meet the and program
expectations expectations performance

• Lean Systems Engineering (LeanSE) applies the fundamentals


of lean thinking to systems engineering with the objective of
delivering best lifecycle value for complex systems and products.
• An example of lean thinking applied to systems engineering is the
use of IPPD and IPTs - see Lean Systems Engineering I lecture.
• Understanding and delivering value is the key concept to LeanSE
• A broad definition of value is how various stakeholders find
particular worth, utility, benefit, or reward in exchange for their
respective contributions to the enterprise.
16.885J/ESD.35J - Nov 18, 2003

Today’s Topics
• Recap of system engineering fundamentals
• Revisit fundamentals of lean thinking
– Value principles, the guide to applying lean thinking
– Lean Enterprise Model (LEM), a reference for
identifying evidence of lean thinking applied to an
enterprise
• Comparison of F/A-18E/F practices to the LEM
– An example of looking for evidence of LeanSE
• Examples of LeanSE extracted from various
Lean Aerospace Initiative research projects
16.885J/ESD.35J - Nov 18, 2003

Simplified Systems Engineering


Process Steps Production,
Delivery &
Needs:
Operation
•End user
•Customer
•Enterprise Validation
•Regulatory
Requirements Verification

Functional
Analysis Synthesis

Systems engineering process is applied recursively at


multiple levels: system, subsystem, component.
Source: Adapted f rom Jackson, S. Systems Engineering for Commercial Aircraft
16.885J/ESD.35J - Nov 18, 2003

Other Systems Engineering Elements

• Allocation of functions and “budgets” to


subsystems
• Interface management and control
• IPPD
• Trade studies
• Decision gates or milestones
– SRR, SDR, PDR, CDR,…
• Risk management
• Lifecycle perspective
16.885J/ESD.35J - Nov 18, 2003

Fundamentals For Developing a Lean Process


Value Phases

Value Value Value


Identification Proposition Delivery

• Specify value: Value is defined by customer in terms of


specific products & services
• Identify the value stream: Map out all end-to-end linked
actions, processes and functions necessary for
transforming inputs to outputs to identify and eliminate
waste (Value Stream Map or VSM)
• Make value flow continuously: Having eliminated waste,
make remaining value-creating steps “flow”
• Let customers pull value: Customer’s “pull” cascades all
the way back to the lowest level supplier, enabling just-in-
time production
• Pursue perfection: Pursue continuous process of
improvement striving for perfection
Source: James Womack and Daniel T. Jones, Lean Thinking (New York: Simon & Schuster, 1996).
16.885J/ESD.35J - Nov 18, 2003

Value - Slack’s definition


A more specific definition of value useful for system
development is given by Slack:
“Value is a measure of worth of a specific product or service by
a customer, and is a function of (1) the product’s usefulness in
satisfying a customer need, (2) the relative importance of the
need being satisfied, (3) the availability of the product relative
to when it is needed and (4) the cost of ownership to the
customer.”

(1) and (2) relate to Performance ( or quality)


(3) relates to Schedule
(4) relates to Cost/Price

Achieving Performance, Schedule, and Cost objectives with acceptable


risk is the generic challenge in developing products and systems.
Source: Slack, R, “The application of Lean Principles to the Military Aerospace Product Development
Process” MIT SM Thesis, Dec 1998
16.885J/ESD.35J - Nov 18, 2003

Examples of Value Metrics


Performance Cost Schedule
• Vehicle performance • Development • Acquisition
(range-payload, response time, or
speed, maneuver costs
parameters) lead time
• Production costs, – Recognition time
• Ilities (Quality, nonrecurring and – Initiation time
reliability, recurring
maintainability, – Product
upgradability) • Operation costs development
cycle time
• System compatibility • Upgrade or
(ATC, airport • Order to ship time
infrastructure, conversion costs – Lead time
mission • Disposal costs – Production cycle
management) time
• Environmental • In-service turn
(Noise, emissions, around time
total environmental
impact)
Value provides a multidimensional framework
16.885J/ESD.35J - Nov 18, 2003

Value: A Symbolic Representation


f p ( performance )
Value =
fc(cos t) • f (time )
t
• Similar to definition developed by value
engineers, value = function/cost
• Value defined by the customer for each system
or product
• Comprised of specific performance, cost,
schedule metrics with weightings representing
customer utility functions and normalizations for
consistency
Source: Murman, E.M., Walton, M., and Rebentisch, E. “Challenges in the Better, Faster, Cheaper Era of Aeronautical

Design, Engineering and Manufacturing”, The Aeronautical Journal, Oct 2000, pp 481-489
16.885J/ESD.35J - Nov 18, 2003

Waste Happens In Product Development


• Effort is wasted
– 40% of PD effort “pure waste”, 29% pure value
“necessary waste” (LAI PD workshop waste added
opinion survey)
necessary
– 30% of PD charged time “setup and
waste
waiting” (aero and auto industry survey)
• Time is wasted
– 62% of tasks idle at any given time
(LAI detailed member company study) task
active
– 50-90% task idle time found in Kaizen- task
type events idle

Cycle time and downstream costs are the keys


Source: “Seeing and Improving the Product Development Value Stream”, Hugh McManus LAI Executive
Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

Lean Enterprise Model Overview


Meta-Principles/Enterprise
Meta-Principles/EnterprisePrinciples
Principles

Enterprise
EnterpriseLevel
LevelMetrics
Metrics
Overarching
OverarchingPractices
Practices
Assure Seamless Optimize
Identify & Optimize
Identify & Optimize Assure Seamless OptimizeCapability
Capability&& Make Decisions at
Make Decisions at
Enterprise Flow Information Flow Utilization of People Lowest Possible Level
Enterprise Flow Information Flow Utilization of People Lowest Possible Level
Implement Integrated Develop Relationships
Implement Integrated Develop Relationships Promote
Product & Process Based on Mutual Trust &
Continuously Focus on
Continuously Focus on PromoteLean
Lean
Product & Process Based on Mutual Trust & the Customer Leadership at all Levels
Development Commitment the Customer Leadership at all Levels
Development Commitment
Maintain Challenge of Ensure Process
Maintain Challenge of Nurture a Learning Ensure Process Maximize Stability in a
Nurture a Learning Capability and Maximize Stability in a
Existing Processes Environment Capability and Changing Environment
Existing Processes Environment Maturation Changing Environment
Maturation

Metrics
Metrics -- Barriers
Barriers -- Interactions
Interactions

Enabling
Enabling and
andSupporting
SupportingPractices
Practices

LEM provides a baseline reference for benchmarking lean enterprises


Source: web.mit.edu/lean
16.885J/ESD.35J - Nov 18, 2003

Example - Analysis of the F/A-18E/F


• Lean Aerospace Initiative case study in Summer 2000
– Study team: Alexis Stanke (lead), Lt. Col. Rob Dare, Prof. Murman
– Documented in Stanke’s LAI Presentation 22 Sep 00 and SM Thesis
• Concentration on Product Development and Acquisition
– Data collection included interfaces with suppliers, production, logistics,
product and business support, and program management
– Secondary sources included production
• Over 80 people from 3 organizations interviewed
– NAVAIR - Navy Program Office
– Boeing, St. Louis - Prime Contractor
– Northrop Grumman, El Segundo - Principal Sub-Contractor
• Attended program meetings
• Collected program documentation
• Lived the program culture during the site visits
F/A-18E/F Super Hornet
The Most Capable and
Survivable Carrier-Based Combat Aircraft
Super Hornet Requirements
• 25% greater payload • Replace the A-6, F-14 and earlier
• 3 times greater ordnance bringback model Hornets
• 40% increase in unrefueled range • Reduced support costs
• 5 times more survivable • Strike fighter for multi-mission
• Designed for future growth effectiveness

Figure by MIT OCW.

Highly capable across the full mission spectrum CC02723003.ppt


16.885J/ESD.35J - Nov 18, 2003

Enterprise Principles
• Right Thing at the Right Place, the Right Time, and in the Right
Quantity
– Weapon system which meets and exceeds 1) technical
requirements, 2) cost, and 3) schedule goals
• F/A-18E/F changed the perspective that achieving 2 out
of 3 was good enough
– Program goals set at the contract award in 1992 were met
– Philosophy that the “airplane is the boss” when trades are
made
• Effective Relationships within the Value Stream
– Establish and maintain program credibility
– Hornet Industry Team
– Culture change within the organizations involved with the 18
Aircraft Agreement
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

Enterprise Principles cont.


• Continuous Improvement
– Numerous program management practices introduced
• Created strategies and practices that can be institutionalized
and adhered to
– Program trades were made with a long-term view of the path
ahead instead of looking for short-term rewards
– Early success of the program set high expectations for future
phases
• Optimal First Delivered Unit Quality
– OPEVAL report released in Feb. 00 with a rating of
“operationally effective and suitable”
– Sea Worthiness trial performance

Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

1: Identify and Optimize Enterprise Flow


“Optimize the flow of products and services, either
affecting or within the process, from concept design
through point of use.”

• Collocation of product and people


• Alignment of organizational structure to the product
work breakdown structure
• Common CAD modeling software used across the
enterprise
• Low Rate Expandable Tooling (LRET) minimized
number of jigs and movements
• Work content in production areas is reorganized to
prevent bottlenecks
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

2: Assure Seamless Information Flow


“Provide processes for seamless and timely transfer of and
access to pertinent information.”

• Open and honest communication


– Ask for help needed
• Internet technology and company web sites enable
sharing data and information within the enterprise
– Access to data is timely and efficient
– Databases are linked throughout the value chain
• Metrics shared weekly throughout the enterprise
• “Drop Dead” philosophy
– Documenting your job so that someone could come in
the next day and pick it up where you left off
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

3: Optimize Capability and Utilization of People


“Assure properly trained people are available when needed.”

• Using an 18 month production gap as an opportunity


for career and skill development programs
• IPT structure broadened functional responsibilities to
facilitate the development of a flexible workforce
• Choose the best person to solve the problem,
regardless of which part of the enterprise they are
from

Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

4: Make Decisions at Lowest Possible Level


“Design the organizational structure and management
systems to accelerate and enhance decision making at
the point of knowledge, application, and need.”

• Organization chart was aligned with the product work


breakdown structure to establish multi-disciplinary teams
• Joint Configuration Change Board (JCCB) is an example
of how responsibility for decisions is shared throughout
the value chain and how well-defined processes expedite
this decision process
• People are empowered to make decisions through the
flow down of requirements and metrics creating
Responsibility, Authority, and Accountability (RAA)

Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003
5: Implement Integrated Product and Process
Development
“Create products through an integrated team effort of people and
organizations which are knowledgeable of and responsible for all
phases of the product’s life cycle from concept definition through
development, production, deployment, operations and support,
and final disposal.”

• Systems engineering practices were used in product


design
• Requirements were established and flowed down to the
responsible teams (RAA)
• Risk management process is structured and shared
throughout the enterprise
• Design for manufacturing and assembly led to 42%
reduction of part count over C/D
– Low Rate Expandable Tooling (LRET) design and Variation
Simulation Analysis (VSA)
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

5: Implement Integrated Product and Process


Development - Continued
“Create products through an integrated team effort of people and
organizations which are knowledgeable of and responsible for
all phases of the product’s life cycle from concept definition
through development, production, deployment, operations and
support, and final disposal.”

• The capability for growth and adaptability was


designed in and continues to improve through the
Enhanced Forward Fuselage (EFF) redesign
• Many stakeholders were involved in pre-contract
planning
• Earned Value tracking of cost and schedule metrics
incorporated through the “perform to plan”
philosophy
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

6: Develop Relationships Based on Mutual Trust


and Commitment
“Establish stable and on-going cooperative relationships
within the extended enterprise, encompassing both
customers and suppliers.”

• Program leadership emphasis on maintaining credibility


• Leadership brings people together and facilitates working
together by preventing strong personalities from taking
over
• Labor-management partnerships are established through
High Performance Work Organizations (HPWO) where
issues can be worked by a team regardless of affiliation
• Many functions were involved in the program definition
process early and given an equal voice to establish
common objectives and cooperative relationships
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

7: Continuously Focus on the Customer


“Proactively understand and respond to the needs of the
internal and external customers.”

• Award fee periods each had unique criteria which were


understood at the beginning of each period to optimize
the flexibility of the contract to changing requirements
• Enterprise stakeholders worked effectively to resolve
issues found during test - Integrated Test Team
– Wing drop issue and solution
• Contractors supported customer’s requirements definition
process
• Organizational counterparts throughout the enterprise
with active working relationships
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

8: Promote Lean Leadership at All Levels


“Align and involve all stakeholders to achieve the
enterprise’s lean vision.”
• Leadership alignment across enterprise
• Management support mentality - turn the organization
chart upside down

• Program management training


– Boeing Program Management Best Practices
– Integrated command media to describe IPT processes
• Activities to implement lean practices in the production
areas
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

9: Maintain Challenges of Existing Processes


“Ensure a culture and systems that use quantitative
measurement and analysis to continuously improve
processes.”

• Cost Reduction Initiative (CRI) structure is a way to


generate, evaluate, and implement improvements
• Risk management process includes mitigation plans to fix
problems systematically using root cause analysis
• Jointly established targets for continuous improvement are
included on the 2030 roadmap, generated by the Hornet
Roadmap Team using a structured QFD process
• Management pushed to evaluate the alternative no growth
(in cost or weight) solution in terms of risk

Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

10: Nurture a Learning Environment


“Provide for the development and growth of both
organizations’ and individuals’ support of attaining lean
enterprise goals.”

• Lessons learned databases are used to capture,


communicate, and apply experience generated
learning
– Over 900 lessons learned from the A/B and C/D
models were incorporated in the E/F version
• Some benchmarking was done early in the program
• Knowledge is utilized throughout the enterprise
regardless of where it originates

Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

11: Ensure Process Capability and Maturity

“Establish and maintain processes capable of consistently


designing and producing the key characteristics of the
product or service.”

• Common databases, tools, and practices have been


defined throughout the value chain
• Enhanced Forward Fuselage (EFF) project is a large
scale example of exploiting process maturation for
cost benefit
• Process capability and maturity leveraged with other
programs
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

12: Maximize Stability in a Changing


Environment
“Establish strategies to maintain program stability in a
changing customer driven environment.”

• Program was never rebaselined


• Multi-year contract signed June 2000
• “Perform to Plan” philosophy led directly to the notable
schedule performance of the program
• Maintained stable workforce capability over an 18 month
production gap
• Program was structured to absorb changes with minimal
impact by using a Block upgrade strategy
• State of the art technology was properly judged,
facilitating programming high risk developments off
critical paths
Source: “Best Lifecycle Value, the F/A-18E/F, and the Lean Enterprise Model”, Alexis Stanke, LAI Product
Development Workshop, September 22, 2000
16.885J/ESD.35J - Nov 18, 2003

Summary of F/A-18E/F Case Study


• High correlation between F/A-18E/F observed
practices and the LEM Overarching and Enabling
Practices
– Additional enabling practices observed
• F/A-18E/F used a disciplined systems engineering
process including establishing and managing
requirements, IPPD, trade studies, risk management,
earned value, and more.
• F/A-18E/F achieved or exceeded all program goals
Observation:

The
TheF/A-18E/F
F/A-18E/Fprogram
programillustratess
illustratessthe
theapplication
applicationof
of
Lean
LeanSystems
SystemsEngineering.
Engineering.
16.885J/ESD.35J - Nov 18, 2003

Examples of Lean Systems Engineering


• Extracted from various Lean Aerospace
Initiative research projects
• Covering various phases of the lifecycle
– Requirements generation and flowdown
– Design synthesis
– Production
– Flight testing
• Cited references on LAI Website
web.mit.edu/lean
Question: What are the LEM principles and
practices evident in the following examples?
16.885J/ESD.35J - Nov 18, 2003

Best Practices in User


Needs/Requirements Generation -
Motivation
• Multiple projects are always competing for limited
resources in large organizations
• High percentage of product lifecycle cost is
determined in “front end” activities
• Prior research showed significant program cost
growth due to requirements problems
• Strong link between budget instability and poorly
performing front end process
• Significant performance improvements in commercial
firms in recent years attributed improving front end
processes
Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI
Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

Research Activity Summary


• Data collection part of Headquarters Air Force (HAF) 2002
reengineering team effort
• Multiple methods used for data collection
– 321 Interviews (~ 300 Military Specific)
– Benchmarking survey developed to collect process characteristics data
• 17 case studies total
– 9 military organizations
• 5 Military Services (one foreign)
– All AF MAJCOMs, 1 ALC, 3 Centers, ANG, AFRES
– Army TRADOC, Navy N-80, 81, 88, Marines
– French ‘Acquisition Service’
• 4 Joint Commands (USJFCOM, USSOCOM, USSPACECOM, NORAD)
• Several other military organizations provided background information
– 8 commercial organizations
•2 aerospace airframe •2 chemical/materials
•2 airlines •2 computer/software
Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI
Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

Company A’s Front End Process


Front-End Process Flow Business Case
Initial Concept Development
Identification Screening Development / Final Screen

Business
Market & Program Plan
Business
Initiation Commercial
Need, Research
New Ideas, Request
Technology
Developments Technical
Research
Feasibility Senior
Screening Phase Committee
Committee

Product
Operational Product
Proposal
List Launch
List
List
Lists maintained by Program Management for the committees

Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI
Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

USAF Front End Process


BUSINESS CASE
IDENTIFICATION INITIAL SCREENING CONCEPT DEVELOPMENT DEVELOPMENT / FINAL
SCREEN

Inputs

Mission MAJCOM AO shepherds MAJCOM


TPIPT area team commander approval phase zero commander approval

Mission Staffing to other Staffing to other


area plan MAJCOMs, Unified Prepare MAJCOM runs MAJCOMs, Unified
CINCs, & other services draft ORD AoA CINCs, and other
To other PPBS (as required) services (as required)
activities Analysis of
Inputs alternatives

Comment 0-6 level Comment 0-6 level


resolution review resolution review
AO activities/ AoA Office of
draft MNS final report aerospace
Flag review studies provides Flag review
guidance
Internal staffing
& comment resolution AFROC
AO prepares Internal AFROC
After As validation/ approval
final ORD staffing validation/ approval
approval required
As required
AF gatekeeper AF Gatekeeper
Joint AF chief After
receiver MNS receiver MNS
process approval Joint process AF chief

HQ AO assigned Acquisition JROC Acquisition


JROC
system decision HQ AO assigned system

F R O N T - E N D P R O C E S S F L O W

Figure by MIT OCW. Adapted from: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI Presentation, 1999.
16.885J/ESD.35J - Nov 18, 2003

Overall Requirements Process Maturity


4
Military
Commercial Non-Aerospace
Aerospace
3

0
y
av
N

F
o
a
SO
N

SJ
m

C
om

U
S

C
e

Source: “Best Practices in User


Needs/Requirements Generation”, Rob Wirthin
and Eric Rebentisch, LAI Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

Overall Framework View


Fundamental Business Environment

Process Enabler
People and Organizational Culture

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

Identification

Screening

Concept
Development

Business
Case
Process Flow Development
Feedback

Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI
Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

Case Observations: Key Front End Process Elements


• Requirements
– Use of multiple structured methods (QFD, DSM, etc.)
• Screening
– Front-end done within one organization that has total control
of resources
– Pre-negotiated exit criteria for potential solutions
• Concept Development
– Appropriate uses of prototypes/simulation
– All product features are given priorities to help in tradeoff
analysis
• Business Case Development
– Concept approval also commits resources of company to
project
Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI
Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

Case Observations (cont.): Key Enablers

• Organizational
– Cross-functional
– Teams are prevalent
– ‘Core’ team members and job stability
– Senior leadership engaged and makes
critical screening decisions
• Business Foundation
– Common database and integrated IT tools
– Emphasis on portfolio management
Source: “Best Practices in User Needs/Requirements Generation”, Rob Wirthin and Eric Rebentisch, LAI
Presentation, 1999
16.885J/ESD.35J - Nov 18, 2003

Improving the Software Upgrade Value


Stream - Study Overview
• 2 year study responding to LAI consortium desire for
software and requirements research
• Comprehensive look at government and industry practices
for deriving software requirements from system
requirements
• “Successful” software programs studied to glean candidate
best practices
• Lean Enterprise Model used as a guide
• Value stream view adopted
• Seven major research findings
• Recommended framework for improvement
Source: “Improving the Software Upgrade Value Stream”, Brian Ippolito and Earll Murman, LAI Executive
Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

Study Scope
• 10 mission critical software upgrade programs studied
• Four application domains
– Military avionics, military space ground terminal,
commercial aircraft, missile/munitions
• 128 surveys collected from program and process
leadership (program managers, chief engineers, end
users, software and systems leads...)
• 3 detailed case studies with 45 interviews
– Military Avionics, Commercial Auto-pilot, Military Space
Ground Terminal
• Extensive review of data with LAI consortium, study
participants, professional community
Source: “Improving the Software Upgrade Value Stream”, Brian Ippolito and Earll Murman, LAI Executive
Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

Software Development Processes


Value: "Estimate the value that each of the following contribute to developing software in a timely, cost
effective approach to meet the users needs."

Effective "How well do you think your program executed the following phases of software development.”

Very
7
Well Estimated Value of Each Phase
6
5
Average
4
3

Not Very
2
Well 1
Concept System Software Design, Code System Validation/
Development Requirements Requirements & Unit Test Integration Verification
Allocation Allocation

Mi ssi le/Muniti ons Military Avioni cs Commercia l Ai rcraft Mili tary Space Ground Termi na l

Although all phases of the software development process are deemed to add
value, they are not accomplished with the same level of effectiveness.
Source: “Improving the Software Upgrade Value Stream”, Brian Ippolito and Earll Murman, LAI Executive
Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

50
Correlation Between Rework and
45

40 Leadership Involvement
35

30

25

20

15

10

0
0 10 20 30 40 50 60 70
% of Program Process Leadership who worked in both Concept Definition
and SW Requirements Analysis

Positive correlation between reduction in unplanned requirements


changes and leadership involvement in both concept definition &
requirements analysis phases
Source: “Improving the Software Upgrade Value Stream”, Brian Ippolito and Earll Murman, LAI Executive
Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

Significant Increase in Information Sharing


(supplier-to-customer)
TYPES OF INFORMATION PROVIDED TO RESPONDING BUSINESS UNITS BY THEIR MOST
IMPORTANT SUPPLIERS ON A FORMAL BASIS, 1989 vs. 1993

100.00

90.00 88.46 Production Cost Data


83.33
SPC Data
80.00
Performance Improvement Actions
70.51 70.51
69.23 Longer-term Business Strategies &
70.00
Plans
Financial Information not Publicly
60.00 Available
Feedback on Purc/Supplier Mgmts
52.56 Operations
50.00 48.72

41.03
40.00

30.00

19.23 20.51
20.00 17.95 17.95

10.00

0.00
1989 (38,14,32,15,16,14) 1993 (55,65,69,55,41,54)
(N=78: Total number of responding business units)

Source: LAI Supplier Relations Survey, 1995


16.885J/ESD.35J - Nov 18, 2003

Early Supplier Integration into Design and


Development: Case Studies
“Old” Approach “Current” “Emerging”
Lean Lean
Prime
Rigid vertical Collaborative with rigid Virtual Team
FFF interfaces organizational w/o boundaries
and control interfaces
Prime

Prime
Key Suppliers
Key Suppliers Key Suppliers
Subtiers Subtiers

Subtiers

Arm’s length; interfaces totally Collaborative; but constrained by Collaborative and seamlessly
defined and controlled prior workshare arrangements integrated, enabling architectural
innovation
FINDING:
FINDING:“Virtual”
“Virtual”teaming
teamingacross
acrossmultiple
multipletiers
tiersof
ofthe
thesupply
supplychain
chainearly
earlyinindesign
designprocess
process
fostered
fosteredinnovation
innovationininproduct
productarchitecture
architecture(major
(majorchanges
changesininproduct
productform/structure,
form/structure,functional
functional
interfaces, system configuration ), resulting
interfaces, system configuration), resulting in in
• • 40-60%
40-60%cost
costavoidance
avoidance
• • 25%
25% reductioninincycle
reduction cycletime
time
• • Significant quality improvement
Significant quality improvement
Source: Bozdogan and Deyst, LAI Study
16.885J/ESD.35J - Nov 18, 2003

Database Commonality
35
„ Without Database „
Commonality
30
„
With Database
z Commonality
25 „
Œ Top Performers

20
„
15
Over Cost by Stage

„
z z z
10
centage of Programs

z
„ „ z Œ
5 Œ Œ Œ
z Œ
z Œ
0 Œ
Concept Concept Concept Preliminary Detailed Fab & Sales
R&D Definition Assessment Design Design Test O&S

Interoperability and/or commonality of design, manufacturability,


cost and other databases significantly reduces likelihood of cost
and schedule overruns in product development
Source: MIT Product Development Survey (1993-94)
16.885J/ESD.35J - Nov 18, 2003

What Level of Commonality Across


Project Lines Makes Most Sense
• Commonality generally makes the most sense at
the subsystem (LRU) level

System Level
Subsystem Level
(LRU)
Card Level (SRU)

Component
Level
Depends on system architecture
Source: “Managing Subsytems Commonality”, Matt Nuffort and Eric Rebentisch, LAI Presentation, Apr 10, 2001
16.885J/ESD.35J - Nov 18, 2003

Benefits of Subsystems Commonality:


Timeline
Shared Higher sparesReduced Greater
Reduced Higher availability complexity in
development tooling productivity interoperability
costs supply
Reduced Reduced Reduced Fewer
cycle time spares Higher Reduced maintenance
rework
Design reuse inventory reliability downtime hours

0 I II III

Reduced
Process DMS
Lower reuse Reduced
training Reduce Increased
risk Reduced equipment training
testing operator
Reduced time Economies of time competency
for source Faster scale
selection solutions to Reduced Reduced
Reduced support
problems inventory documentation
equipment
Source: “Managing Subsytems Commonality”, Matt Nufort and Eric Rebentisch, LAI Presentation, Apr 10, 2001
16.885J/ESD.35J - Nov 18, 2003

Conclusions Of Nuffort -
Rebentisch
• 21 programs studied, 84 interviews
• Data very sparse. Lots of “judgement” applied
• Subsystem commonality reduces subsystem
ownership cost
– 15-40 Percent savings in acquisition cost of
subsystem*
– 20-45 Percent savings in annual O&S costs*
* cost structure dependent
16.885J/ESD.35J - Nov 18, 2003

Lean Enterprise Thrusts


Lean
LeanEngineering
Engineering Traditional
••DMAPS
DMAPS
•Parametric
•Parametric3D
3DSolids
Solids
•Dimensional Management
•Dimensional Management

Cost
•Virtual
•VirtualManufacturing
Manufacturing
•Model
•Model BasedDefinition
Based Definition(Int/Ext)
(Int/Ext)
••DFMA Lean
DFMA
•Enables
•EnablesLean
LeanMfg.
Mfg.
•Enables
•EnablesLean
LeanSM&P
SM&P Units

Lean Manufacturing
Lean
LeanSupplier
SupplierManagement
Management
• Throughput Studies
• Variability Reduction/SPC ••Supplier
SupplierBase
BaseReduction
Reduction
• HPWOs ••Certified Suppliers
Certified Suppliers
• AIWs ••Suppliers
Suppliersas
asPartners
Partners
• Advanced Technology Assembly ••Electronic Commerce/CITIS
Electronic Commerce/CITIS
• Operator Verification ••IPT
IPTParticipation
Participation
Source: “Lean Engineering ”, John Coyle (Boeing), LAI Executive Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

Lean Engineering Product Definition Process


Significantly Reduce NonRecurring Cost & Cycle Time
Source: “Lean Engineering ”, John Coyle (Boeing), LAI Executive Board Presentation, June 1, 2000

Forward Fuselage DevelopmentTotal IPT Labor

Prototype EMD Wireframe


Wireframe with 2D Drawing • Modern Programs Feature DMAPS
Release Release Processes/Tools
Prototype
3D Solid • 3D Solid Model Master
Release Definition - No Drawings
• Detail Available Much Earlier
Staffing to Support Full, Data-Driven
Level IPT Decisions
• Daily VR Reviews
Prototype • Virtual Manufacturing
3D Solid
Release - 2000 * • Improved Supplier
Coordination and Concurrent
Procurement

Months from End of


Conceptual Design Phase
* Indicates results from vehicle of approximate size and work content of forward fuselage
16.885J/ESD.35J - Nov 18, 2003

Recurring Cost Reduction (Goal = 50%)


Source: “Lean Engineering ”, John Coyle (Boeing), LAI Executive Board Presentation, June 1, 2000

Additional Reduction in T1 via


Virtual Mfg. of Approx. 9 Units

48% Savings
Business As Usual

Mfg. Early DMAPS


Labor
(hrs) Reduction in
Work Content via
76% Slope Improved Design

83% Slope
0
-10 -5 1 5 10 15 20 25 30 35
Production Units
16.885J/ESD.35J - Nov 18, 2003
Lean Engineering Is Enabled by
Advanced Tools and Processes
Parametric Solids Integrated Product Teams Early Supplier
Involvement
Model Based Definition Integrated Data Packages
Release Packages Design for Process
Product/Tools Capability Advanced
Reduced Inspection/ Validated by Technology
Smart Inspection Simulation Assembly
Virtual Design Reviews/
Collaboration Standard Parts

Design for Manufacturing


and Assembly Common Product Data Storage
3-D Product Structure Application of New Technology
(BOM) A&M Standard
Tools
Dimensional Management/
Design for Affordability Value Stream Analysis
Key Characteristics
Design Linkage to Financials

Design for Flow


Source: “Lean Engineering ”, John Coyle (Boeing), LAI Executive Board Presentation, June 1, 2000
16.885J/ESD.35J - Nov 18, 2003

Precision Assembly
Process understanding key
to precision improvement

• Drive to 6 sigma processes


• Precision assembly
– Parts define location
– Reduced assembly tooling
– Remove trim and shim from assembly

Old Paradigm New Paradigm


Tooling defines part location Parts themselves define location

Source: J.P. Koonmen, “Implementing Precision Assembly Techniques in The Commercial Aircraft Industry” MIT
SM Thesis, 1994, and Hoppes (1995). Also See Lean Enterprise Value, pp 127-130
16.885J/ESD.35J - Nov 18, 2003

Toolless Assembly
Case Study Benefits
Category Old Paradigm New Paradigm
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
Quality .3 (> 1000) .7 (<20) *
(nonconformances/part)
* Early results with improving trend

Source: J.P. Koonmen, “Implementing Precision Assembly Techniques in The Commercial Aircraft Industry” MIT
SM Thesis, 1994, and Hoppes (1995). Also See Lean Enterprise Value, pp 127-130
16.885J/ESD.35J - Nov 18, 2003

Enablers of
Precision Assembly
• Design
– parts, assembly, assembly sequence,
tooling, ...
• Precision fabrication
– contour and features
• Common, CAD definition
• Measurement technology
• Lean production system
Source: J.P. Koonmen, “Implementing Precision Assembly Techniques in The Commercial Aircraft Industry” MIT
SM Thesis, 1994, and Hoppes (1995). Also See Lean Enterprise Value, pp 127-130
16.885J/ESD.35J - Nov 18, 2003

F-16 Lean Build-To-Package Support Center


Source: “Seeing and Improving the Product Development Value Stream”, Hugh McManus LAI Executive Board
Presentation, June 1, 2000

• Scope: Class II , ECP Supplemental,


Production Improvements, and Make-
It-Work Changes Initiated by
Production Requests
• Target Improvement: Reduce
Average Cycle-Time by 50%
• Operational: 1999
• Future Applications: Pursuing
Concept Installation in other areas

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


Category % Reduction
Cycle-Time 75%
Process Steps 40%
Number of Handoffs 75%
Travel Distance 90%
16.885J/ESD.35J - Nov 18, 2003
Build-To-Package Support Operational Concept

X
The Fighter Enterprise
Production System Flow
Production
Released BTP,
Problem
Available at Point of Use

BTP
Support Lean Principles Dictate
Center
Assets be Allocated to
(BSC)
Activities not People

Pull on Demand
Fuel Sys Fire Control Sys Harness Def Avionics Elect Planner MRP Planner Propulsion
Canopy TMP
NC Programmer Wiring Instl CRB Life Suppt Process Control
Buyer Tool Design ECS Instl
Coproduction
Labs M&P Parts Engrg Safety
PP&C Escape Sys Customers
Structures Ldg Gear
DCMC Stress ECS Sys
PQA Planner Maintainability
Program Frac & Fat Tool Mfgrg
Arm Sys Equip Instl
Scheduling Hydraulics
Dispersed BTP Technical Expertise Pool
Results From F16 16.885J/ESD.35J - Nov 18, 2003
Forward Fuselage BTPSC

Process Process
Before Lean After Lean
Prepare tool Forward to
order operations
Operations Operations
uses uses revised
Forward to Complete tool BTP/Tool
revised
planning Log/hold in order Accomplish planning
backlog processing tooling change
Operations
Prepare uses Forward to
design change revised operations
Forward to Log/hold in Log/hold in
planning
TMP backlog backlog

Log/hold in
backlog Forward to Prepare tool Forward to Forward to Prepare Prepare Prepare tool Accomplish
operations order TMP tool Mfg.. design change planning design change tooling change
change (if applicable) (if applicable)
Engr answer No Yes BTP Elements Worked Concurrently
Tool Prepare tool Complete
affected? design change tooling BTP

Forward to
engrg Prepare planning Log/hold in Log/hold in BTP integrator
change backlog backlog holds meeting

Operations
initiates Log/hold in Forward to Forward to
Request for Operations
backlog tool design MRP
action initiates Req.

Single Piece flow, concurrent engineering, co-location

Figure by MIT OCW. Adapted from: “Seeing and Improving the Product Development Value Stream”, Hugh McManus LAI Executive Board Presentation, June 1, 2000.
16.885J/ESD.35J - Nov 18, 2003

Key Cost Drivers for Aircraft Test and Evaluation


Flight Test
Aircraft = Engineers
Ground Test ~$100 M onsite (1 mo)
Article = ~$30-50 M = ~$1 M

Wind Tunnel Engineers @


Time (25,000 hrs) home (1 mo)
= ~$125 M = ~$2 M

Test and
Evaluation

•Approximate cost: $1 Million per day


Source: “Opportunities for Lean Thinking in Aircraft Flight Test and Evaluation ”, Carmen Carreras and Earll
Murman, Society of Flight Test Engineers, June 2002
16.885J/ESD.35J - Nov 18, 2003

Case Studies - Flutter Flight Testing


737-NG F22
C130J

T-6A

F/A-
Horizon 18E/F

Total of 22 days spent onsite


Source: “Opportunities for Lean Thinking in Aircraft Flight Test and Evaluation ”, Carmen Carreras and Earll
Murman, Society of Flight Test Engineers, June 2002
16.885J/ESD.35J - Nov 18, 2003

Case Study Findings


• Very little process data is being collected
• Upstream activities have a major impact on
efficiency of flight testing
– Late arrival of flight test article
• Lean practices are applicable to flight testing
– Approval of test plans are at too high a level
• Intersecting value streams (e.g. shared service
like telemetry and a particular flight test
program) can produce waste
– Resource conflicts, untimely services
Opportunities exist for applying lean thinking to flight testing.
Source: “Opportunities for Lean Thinking in Aircraft Flight Test and Evaluation ”, Carmen Carreras and Earll
Murman, Society of Flight Test Engineers, June 2002
16.885J/ESD.35J - Nov 18, 2003

Summary
• Lean Thinking applied to Systems
Engineering (aka Lean Systems
Engineering) indicates benefits
– Evidence of LeanSE programs
– Evidence of LeanSE throughout the
product lifecycle
• Plenty of opportunities for further LeanSE
• A focus on value creation is the key to
implementing LeanSE
Look for evidence of Lean System Engineering in your
case studies using the Lean Enterprise Model and
Simplified Systems Engineering Model
16.885J/ESD.35J - Nov 18, 2003

Statistical Process Control


• SPC is “The application of statistical techniques to
understand and analyze variation in a system”
• SPC is the heart of modern quality systems
• It relies on
– Continual measurement of process variables; e.g. hole
diameters, stock thickness, temperature control,…
– Using simple statistical analysis to analyze and display data
– Stabilizing all process to assure process capability
– Keeping design tolerances within known process capability
– Training of the entire workforce on SPC techniques
• The “ultimate goal” of SPC is to achieve processes that
have 6σ capability which translates into “fewer than 3.4
defects per million” (TI SPC Guidelines).

You might also like