Massachusetts Institute of Technology
Lean, Systems Thinking &
Cost Estimation
Dr. Ricardo Valerdi
Dec 15, 2010
MIT Harvard Club de Colombia/IMOCOM
Metropolitan Club, Bogotá, Colombia
lean.mit.edu
Theory is when you know everything, but nothing works.
Practice is when everything works, but no one knows why.
MIT is where theory and practice come together...
Nothing works and no one knows why.
- on the door of a
laboratory at MIT
2
lean.mit.edu
Roadmap
Lean Simulation
Systems thinking and systems engineering
COSYSMO
Valerdi, R., The Constructive Systems Engineering Cost Model: Quantifying the Costs of Systems
Engineering Effort in Complex Systems, VDM Verlag, 2008
lean.mit.edu
3
MIT
• OpenCourseWare – 2,000 free courses
online (ocw.mit.edu), 100 million visits
• Prof. Peter Diamond, Nobel Prize in
Economic Sciences
• David H. Koch Institute for Integrative
Cancer Research (Bldg 76)
lean.mit.edu
4
Enabling Enterprise Excellence
lean.mit.edu
5
1993 Genesis of the
Lean Advancement Initiative
U.S. Air Force asked:
Can the concepts,
principles and practices of
the Toyota Production
System be applied to the
military aircraft industry?
Yes!
lean.mit.edu
Historical Industrial Paradigms
1885
1913
1955-1990
1993-...
Craft Production
Mass Production
Toyota Production
System
Lean Enterprise
Machine then harden
Fit on assembly
Customization
Highly skilled
workforce
Low production rates
High cost
Parts inter-changeability
Moving production line
Production engineering
“Workers don’t like
to think”
Unskilled labor
High production rates
Low cost
Persistent quality
problems
Inflexible models
Worker as problem
solver
Worker as process
owner enabled by:
-- Training
-- Upstream quality
-- Minimal inventory
-- Just-in-time
Eliminate waste
Responsive to change
Low cost
Improving productivity
High quality product
“Lean” is elimination of waste and
efficient creation of enterprise value
lean.mit.edu
“Lean” applied to all
functions in
enterprise value
stream
Optimization of value
delivered to all
stakeholders and
enterprises in value
chain
Low cost
Improving productivity
High quality product
Greater value for
stakeholders
We We
Share
A Goal:
Share
A Goal: Enterprise Excellence
lean.mit.edu
lean.mit.edu
LAI Operating Model
Knowledge Exchange Events
Transformation Events
•
•
•
•
Enterprise transformation focus
Enterprise level training
Roadmap for Enterprise transformation
Fee for service model
DEPLOYMENT
Enable Transformation
Exchange Knowledge
Measure Value
Create
collaborative
value for
customers
Enhance
Membership
lean.mit.edu
Educational Network
• Learn from doing
• Research validated
• Impacts future research
• Contributed SMEs
• Learn from doing
• Collaborations
• Benchmarking
• Sharing Lessons
Learned
• Neutral broker
• Website
• Active community
of practice
• Annual Conference
• Workshops, seminars, roundtables & tutorials
• A membership benefit via point system
• Available to customers, suppliers and
consultants
• Events are self-supporting
KNOWLEDGE
CREATION
RELATIONSHIPS
Accelerate Deployment
Engage all Stakeholders
Collaborate to Transform
Conduct Enterprise
Research
Develop Transformation
Products
• Access
• Knowledge transfer
• Collective action
Expand Lean
knowledge
• Applied research
• Best practices
• Transformation
strategies
• Change management
• Future enterprise
design
Products and tools
Publications
Lean Enterprise Value
Simulation
• A simulation of a complex
aerospace enterprise
• Philosophy draws heavily on LAI
research and the recent book
Lean Enterprise Value
• Content and cases based on LAI
member experience
lean.mit.edu
Toyota Production System
Best Quality — Lowest Cost — Shortest Lead Time
Best Safety — High Morale
Through shortening the production flow by eliminating waste
Just-in-Time
Right part, right
amount, right time
•
•
•
•
•
Takt time planning
Continuous flow
Pull system
Quick changeover
Integrated logistics
People and Teamwork
• Selection
• Common goals
• Ringi decision
making
• Cross-trained
Continuous Improvement
Waste Reduction
• Genchi
Genbutsu
• 5 whys
Leveled Production (heijunka)
Stable and Standardized Processes
Visual Management
Toyota Way Philosophy
From Liker, Jeffrey, The Toyota Way, McGraw Hill, 2004, p. 33
lean.mit.edu
• Eyes for waste
• Problem
solving
Jidoka
(in-station quality)
Make problems visible
• Automatic stops
• Andon
• Person-machine
separation
• Error-proofing
• In-station quality control
• Solve root cause of
problems (5 whys)
Value Added and Non-Value Added
Value Added Activity
• Any activity that
transforms or shapes (for
the first time) material or
information to meet
customer requirements
Non-Value Added Activity
(Waste)
• Those activities that take
time or resources, but do
not meet customer
requirements
Lean relentlessly seeks to eliminate any processes or activities that
don’t contribute to something valued by the customer (or stakeholders
in the enterprise)
lean.mit.edu
Seven Types of Waste
1. Over-production
Creating too much material or information
2. Inventory
Having more material or information than you
need
3. Transportation
Moving material or information
4. Unnecessary
Movement
Moving people to access or process material or
information
5. Waiting
Waiting for material or information, or material
or information waiting to be processed
6. Defective Outputs
Errors or mistakes causing the effort to be
redone to correct the problem
7. Over-processing
Processing more than necessary to produce the
desired output
lean.mit.edu
5S
Before
• Sort
• Straighten
• Scrub
• Systematize
• Standardize
A prerequisite for establishing visibility of
wastes and visual control
lean.mit.edu
Photos from John Tile, BAE Systems, The Distributed Leadership of Lean
to the Office & Engineering Environment, LAI Plenary Conference, April 2006
After
5 Whys—Root Cause Analysis
Root cause analysis can be exhaustive!
– Portion of 32-page example shown here
lean.mit.edu
lean.mit.edu
Suppliers
Manufacturing
Customer
Acceptance
Plant B
Plant A
Design
Change
Request
2nd Tier
Design
1st Tier
Analysis
Plant C
Engineering
Design
In/Out Box
Design
Analysis
Final
Assembly
Verification
Systems
Engineering
Engineering
required to
redesign plane or
production system
MFG Table
Customer
Plant D
Final Assy
Plant C
Wings
lean.mit.edu
Plant A
Tail
Plant B
Fuselage
Mfg Table
Plant A
Tail
Build to Specification
Mat A
1 2X8 White Plate
2 2X4 White Bricks
1 2X2 White Brick
2 1X2 Lt Grey Bricks
1 2X3 Black Slope
•Source parts come from suppliers
•Finished assembly has 7 total parts
•Feeds to assembly in Plant B (fuselage)
lean.mit.edu
Mfg Table
Plant D
Final Assy
Build to Specification
Mat D
2 Wing Assy (Plant C)
1 Fuselage (Plant B)
•Source parts come from other plants
•Finished assembly has 3 assemblies
(38 total total parts in initial state)
•Ships to customer test/acceptance
lean.mit.edu

and how
MATLegacy Design
to do it:
Process
Complexity
Hourglass
Seconds
Co
m p le x ityHo
u rg la s s Se
c onds
1
2
3-4
3-4
5-6
5-6
30
60
120
120
180
180
Review
Tells you what to do:
Get job fr om Design In Box and sign in
Do design process:
Add yellow dot to job
Flip appropr iate hour glass and wait*
Tr y to pass review:
Roll one six-sided die, and check
Pass: sign off; send job to Analysis In Box
Fail: sign off; send job to Design In Box
*fo r v e ry c o m p l e x j o b s , fl i p m o re th a n o nc e ! (e .g . 9 =
lean.mit.edu
+
²≤ 3
3+
Too pass,
one
T
p ass, roll
ro ll
o ndie
e dand
ie anscore
d sco re
≤
3
+
number
of
yellow
dots
jobo n
Š 3 + n u mb er o f y ello w don
o ts
Costs
Inventory (per dot)
Carr ying (per round)
Cap. Improvements:
Upgrade
1 y e l l o w, 1 b l u e )
Move
Pr ocess (per dot)
© 2 0 0 3 M a ss a c h u s e tts In s tit u te o f T e c h n o l og y
1
30
60
30
5

Legacy Analysis
Process
Complexity
Hourglass
Seconds
Co
m p le x ityHo
u rg la s s Se
c onds
Different mats have
different rules
30
60
120
120
180
180
1
2
3
Review
²≤ 22++
Get job fr om Analysis In Box, sign in
Do analysis pr ocess:
Add red dot to job
Flip appropr iate hour glass and wait*
Tr y to pass review:
Roll one six-sided die, and check
Pass: sign off; send job:
Major to Systems,
Minor to Ver ification and Test In Box
Fail: sign off; send job to Design In Box
*fo r v e ry c o m p l e x j o b s , fl i p m o re th a n o nc e ! (e .g . 5 =
lean.mit.edu
+
+
Too pass,
one
T
p ass, roll
ro ll
o ndie
e dand
ie anscore
d sco re
≤
2
+
number
of
red
and
blue
Š 2 + n u mb er o f red an d b lu e
ddots
o tson
o njobjo b
Costs
Inventory (per dot)
Carr ying (per round)
Cap. Improvements:
Upgrade
Move
1 y e l l o w, 1 b l u e )
Pr ocess (per dot)
© 2 0 0 3 M a ss a c h u s e tts In s tit u te o f T e c h n o l og y
1
60
90
30
5
lean.mit.edu
Order/Fulfillment Review
lean.mit.edu
Enterprise Optimization
Profit
Profit
Profit
# Parts
# Parts
cap
$price
cap
$price
# jobs
cap
$price/job
# outside jobs
•
•
•
•
lean.mit.edu
Profit
Capacity balance, stability will maximize production
Financial balance (win-win-win) through transfer pricing
Multiple stakeholders and value streams
Identify key leverage points for performance and balance
# Planes
cap
$price
Return on Invested Capital
Sales
-Recurring Expenses
Gross Profit
Operating Profit
-Operating Costs
lean.mit.edu
=ROIC
Invested Capital
Manufacturing Cost Distribution
• Healthy
• Low
deadweight
• Carrying costs
reasonable
• Parts are
biggest cost assembling
them is added
value
lean.mit.edu
PD Cost Distribution
• Not good
• Deadweight
and Penalties
• Carrying costs
large
• Variable cost
(dots =
engineering
work) smaller
lean.mit.edu
SN Cost Distribution
• So-so
• Deadweight
and Penalties
OK
• Carrying costs
large
• Total costs >>
Variable costs
lean.mit.edu
Enterprise Cost Distribution
• Roll up—NOT an
average
• Carrying and other
costs overwhelm true
variable costs (raw
material and
engineering talent)
• March on Moscow
effect evident…
– Not obvious from this
representation where
is the value is being
dissipated
lean.mit.edu
Financial Data: Typical
Manufacturing Cost Distribution
• Round 2
• Financially
OK- made 3
planes at high
cost and price
• Costs all over
the place
lean.mit.edu
Local Lean
• Round 6
• Six Aircraft
• Less
deadweight
and penalties
• Higher %
variable costs
• Lower price
lean.mit.edu
Enterprise Lean
• Round 11
• 11 Aircraft
• Very little
deadweight and
penalties
• Carrying costs
diluted across
more planes
• Much lower
price, high profit
lean.mit.edu
Systems Thinking
“Utilizing modal
elements to consider
the componential,
relational, contextual,
and dynamic
elements of the
system of interest.”
Davidz, H. L. and Nightingale, D. J. “Enabling Systems Thinking To Accelerate
the Development of Senior Systems Engineers,” Systems Engineering, Vol.
11, No. 1, 2008.
lean.mit.edu
35
lean.mit.edu
Systems Thinking: A Latent Construct
• Five learning disciplines (Senge 1990)
– Personal mastery, mental models, shared vision,
team learning and systems thinking
• Seven critical skills of systems thinking (Richmond 1993)
– Dynamic, closed-loop, generic, structural, operational,
continuum, and scientific
• Thirty systems thinking laws (Frank 2000)
– Synergy, gradual process, life-cycle thinking, solution
exploration, etc.
• Four foundations of systems methodology (Gharajedaghi
2006)
– Holistic thinking, operational thinking, systems
theories and interactive design
lean.mit.edu
Systems Thinking Competencies
1. Ability to define the “universe” appropriately – the system operates in
this universe
2. Ability to define the overall system appropriately – defining the right
boundaries
3. Ability to see relationships – within the system and between the
system and universe
4. Ability to see things holistically – within and across relationships
5. Ability to understand complexity – how relationships yield uncertain,
dynamic, nonlinear states and situations
6. Ability to communicate across disciplines – to bring multiple
perspectives to bear
7. Ability to take advantage of a broad range of concepts, principles,
models, methods and tools – because any one view is inevitably
wrong
lean.mit.edu
“Maybe pushing on that wall to the right will give some space.”
lean.mit.edu
39
“Oops!”
lean.mit.edu
40
Sjors Witjes, Pablo Muñoz Specht, Carolina Montoya Rodríguez, The Measurement of the Development of Systems and General
Thinking in Agricultural Areas of Colombia: Preliminary Results, Los Andes University.
lean.mit.edu
41
Brooks’ Law
Adding people to a late project makes it later
lean.mit.edu
42
Systems Engineering
“An interdisciplinary approach and means to
enable the realization of successful
systems. It focuses on defining customer
needs and required functionality early in
the development cycle, documenting
requirements, then proceeding with design
synthesis and system validation while
considering the complete problem.”
- International Council on Systems
Engineering (www.incose.org)
lean.mit.edu
43
Systems Engineering
•
•
•
Acquisition and Supply
•
– Supply Process
– Acquisition Process
Technical Management
•
– Planning Process
– Assessment Process
– Control Process
System Design
– Requirements Definition Process
– Solution Definition Process
Product Realization
– Implementation Process
– Transition to Use Process
Technical Evaluation
– Systems Analysis Process
– Requirements Validation Process
– System Verification Process
– End Products Validation Process
EIA/ANSI 632, Processes for Engineering a System, 1999.
lean.mit.edu
44
COSYSMO Origins
Systems Engineering
(Warfield 1956)
1950
Software Cost Modeling
(Boehm 1981)
1980
CMMI*
(Humphrey 1989)
1990
*Capability Maturity Model Integrated (Software Engineering Institute, Carnegie Mellon University)
Warfield, J. N., Systems Engineering, United States Department of Commerce PB111801, 1956.
Boehm, B. W., Software Engineering Economics, Prentice Hall, 1981.
Humphrey, W. Managing the Software Process. Addison-Wesley, 1989.
lean.mit.edu
45
COSYSMO Scope
• Addresses first four phases of the system
engineering lifecycle (per ISO/IEC 15288)
Conceptualize
Develop
Oper Test Transition
to
& Eval
Operation
Operate,
Maintain,
or
Enhance
Replace
or
Dismantle
• Considers standard Systems Engineering
Work Breakdown Structure tasks (per
EIA/ANSI 632)
lean.mit.edu
46
COSYSMO Operational Concept
# Requirements
# Interfaces
# Scenarios
# Algorithms
+
3 Adj. Factors
Size
Drivers
Effort
Multipliers
- Application factors
-8 factors
- Team factors
-6 factors
lean.mit.edu
COSYSMO
Effort
Calibration
47
COSYSMO Model Form
E
PM NS

 14
 A    ( we,k  e,k  wn ,k  n ,k  wd ,k  d ,k )    EM j
 k
 j 1
Where:
PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data
k = {REQ, IF, ALG, SCN}
wx = weight for “easy”, “nominal”, or “difficult” size driver
 x = quantity of “k” size driver
Ex = represents diseconomies of scale
EM = effort multiplier for the jth cost driver. The geometric product results in an
overall effort adjustment factor to the nominal effort.
lean.mit.edu
48
Cost Driver Clusters
UNDERSTANDING FACTORS
– Requirements understanding
– Architecture understanding
– Stakeholder team cohesion
– Personnel experience/continuity
COMPLEXITY FACTORS
– Level of service requirements
– Technology Risk
– # of Recursive Levels in the Design
– Documentation Match to Life Cycle Needs
PEOPLE FACTORS
– Personnel/team capability
– Process capability
ENVIRONMENT FACTORS
– Multisite coordination
– Tool support
OPERATIONS FACTORS
– # and Diversity of Installations/Platforms
– Migration complexity
lean.mit.edu
49
Stakeholder team cohesion
Represents a multi-attribute parameter which includes leadership, shared vision,
diversity of stakeholders, approval cycles, group dynamics, IPT framework, team
dynamics, trust, and amount of change in responsibilities. It further represents the
heterogeneity in stakeholder community of the end users, customers,
implementers, and development team.
1.5
1.22
1.00
0.81
0.65
Very Low
Low
Nominal
High
Very High
Culture
Stakeholders
with diverse
expertise, task
nature,
language,
culture,
infrastructure
Highly
heterogeneous
stakeholder
communities
Heterogeneous
stakeholder
community
Some similarities
in language and
culture
Shared project
culture
Strong team
cohesion and
project culture
Multiple
similarities in
language and
expertise
Virtually
homogeneous
stakeholder
communities
Institutionalized
project culture
Compatibility
Highly
conflicting
organizational
objectives
Converging
organizational
objectives
Compatible
organizational
objectives
Clear roles &
responsibilities
Strong mutual
advantage to
collaboration
Familiarity and
trust
Lack of trust
Willing to
collaborate, little
experience
Some familiarity
and trust
Extensive
successful
collaboration
Very high level of
familiarity and trust
Viewpoint
lean.mit.edu
50
Technology Risk
The maturity, readiness, and obsolescence of the technology being
implemented. Immature or obsolescent technology will require more Systems
Engineering effort.
Viewpoint
Very Low
Low
Nominal
High
Very High
Lack of
Maturity
Technology
proven and
widely used
throughout
industry
Proven through
actual use and
ready for
widespread
adoption
Proven on pilot
projects and
ready to roll-out
for production
jobs
Ready for pilot use
Still in the
laboratory
Lack of
Readiness
Mission
proven (TRL
9)
Concept qualified
(TRL 8)
Concept has
been
demonstrated
(TRL 7)
Proof of concept
validated (TRL 5 &
6)
Concept defined
(TRL 3 & 4)
- Technology is
the state-of-thepractice
- Emerging
technology
could compete
in future
- Technology is
stale
- New and better
technology is on
the horizon in the
near-term
- Technology is
outdated and use
should be avoided
in new systems
- Spare parts
supply is scarce
Obsolescen
ce
lean.mit.edu
Migration complexity
This cost driver rates the extent to which the legacy system affects the migration
complexity, if any. Legacy system components, databases, workflows,
environments, etc., may affect the new system implementation due to new
technology introductions, planned upgrades, increased performance, business
process reengineering, etc.
Viewpoint
Nominal
High
Legacy
contractor
Self; legacy system is well
documented. Original team
largely available
Self; original
development team not
available; most
documentation
available
Different
contractor; limited
documentation
Original contractor
out of business; no
documentation
available
Effect of legacy
system on new
system
Everything is new; legacy
system is completely
replaced or non-existent
Migration is restricted
to integration only
Migration is related
to integration and
development
Migration is related
to integration,
development,
architecture and
design
lean.mit.edu
Very High
Extra High
Cost Driver Rating Scales
Very
Low
Low
Nominal
High
Very High
Requirements Understanding
1.87
1.37
1.00
0.77
0.60
3.12
Architecture Understanding
1.64
1.28
1.00
0.81
0.65
2.52
Level of Service Requirements
0.62
0.79
1.00
1.36
1.85
2.98
1.00
1.25
1.55
Migration Complexity
Extra
High
1.93
EMR
1.93
Technology Risk
0.67
0.82
1.00
1.32
1.75
2.61
Documentation
0.78
0.88
1.00
1.13
1.28
1.64
1.00
1.23
1.52
# and diversity of installations/platforms
1.87
1.87
# of recursive levels in the design
0.76
0.87
1.00
1.21
1.47
1.93
Stakeholder team cohesion
1.50
1.22
1.00
0.81
0.65
2.31
Personnel/team capability
1.50
1.22
1.00
0.81
0.65
2.31
Personnel experience/continuity
1.48
1.22
1.00
0.82
0.67
2.21
Process capability
1.47
1.21
1.00
0.88
0.77
0.68
2.16
Multisite coordination
1.39
1.18
1.00
0.90
0.80
0.72
1.93
Tool support
1.39
1.18
1.00
0.85
0.72
lean.mit.edu
1.93
53
Before Local Calibration
lean.mit.edu
54
After Local Calibration
lean.mit.edu
55
Model Prediction Accuracy
PRED(30)
PRED(25)
PRED(20)
PRED(30) = 100%
lean.mit.edu
PRED(25) = 57%
56
Impact
10 theses
Model
Academic Curricula
E

 14
PM NS  A    ( we,k  e,k  wn ,k  n ,k  wd ,k  d ,k )    EM j
 k
 j 1
Academic
prototype
Commercial Implementations
Policy & Contracts
Proprietary Implementations
SEEMaP
COSYSMO-R
Intelligence Community
Sheppard Mullin, LLC
lean.mit.edu
SECOST
57
lean.mit.edu