Lean Thinking and Lean

Manufacturing

ISEN 645
FA2016

Integrate Flow Monitor &

Define Design Instantiate
& Control Remediate
FA2016 Week Core Topic / Theme Technical focus

15week 1: 29/31AUG
2: 5/7SEP
Introduction to Lean
Value
Core principles and definitions
SE; IDEF0; PS design

Schedule 3: 12/14SEP
4: 19/21SEP
Value Stream
Value Stream / Flow
VSM; 8-Step design process; IDEF3
Line balancing; Task engineering
Class3 is focused on a modeling
method called IDEF0.
5: 26/28SEP Flow JIT; Cells; SMED; Leveling

Every system that we work with as 6: 3/5OCT Flow / Control Factory Physics Principles; 3EQN/4GRAPHS
engineers has a “concept of
operations” – IDEF0 (among its 7: 10/12OCT Control Kanban; CONWIP; integrated IC & PC
many uses) is ideal for depicting a
CONOPS and the core 8: 17/19OCT Control Buffer engineering (time, capacity, inventory)
transformative processes.
9: 24/26OCT Lean supply chain Principles; Beer game
So we can leverage IDEF0 to assist
in our visualization of the essential 10: 31OCT/2NOV Lean supply chain Integration with the PS
characteristics of the PS and its
operation – whether it is in 11: 7/9NOV Perfection: Lean 6σ DMAIC VOC; SIPOC; C/E chaining
existence or whether it is simply a
notional characterization. 12: 14/16NOV Perfection: Lean 6σ DMAIC Gauge R&R; SMED; SPC
In class3 we will spend time on the
method itself – and discuss the
13: 21NOV* (MON) Perfection: Gemba Kaizen Implementation planning applied
first homework assignment.
14: 28/30NOV Culture / LPS design - Epilogue Leadership
Class4 will focus on the “Value”
principle of lean. 15: 7DEC* (WED) Project briefings Schedule and timing TBD
16: Final 9DEC 0730-0930a
 ISEN 645: Knowledge, Skills, Experiences (KSE)
Knowledge (know-what) Skill (know-how) Experience (know-why + feedback) Quizzes (20%)
Homework (30%)
In- Class
Quiz Quiz Homework Project Project (50%)
Activity
PS definition (a system of systems) 1,2  IDEF0 (SE definition, visualization, …) 1,2 X
Lean definition (history and principles) 1  VSM (material flow; CONOPS for flow and control) 3 3 X The table at the
left is depicts the
LPS definition (lean manifested in the PS) 2  Cell layout (single-piece flow is the target) 4,10 X mapping
Value 2  Cell balancing (man-machine) 4 4,10 X between the
various KSEs and
Value Stream 3  Task engineering (methods and time study) 10 X the assessments.
Flow 4  SMED – rapid changeover 9 X
This is only a
Control 5  Pull based shop floor control (kanban, CONWIP) 6 6 X draft.
Perfection and 6σ 8  Production Leveling (EPE-interval) 5 5 X
This table will
Cases 2  Scheduling (line, batch) 5 5 X likely change
Resources 6  6σ tools (DMAIC)++ 8 8 X during the
semester – since
Implementation planning 10  Factory Physics (production science) 6 6 X I will be
Change management 9  VUT (variability propagation) 6 6 modifying the
assignments as
Toyota Production System (TPS) 1,2  Little’s law (WIP = SHIP * FLOW; “F=ma” for production) 6 6 X our discussion
 WIP engineering (critical WIP definition) 7 7 proceeds.

 Buffer engineering (inventory, capacity, time) 7 7 X

 Inventory trade-off curves 6 6
 Gemba – leadership centric cultural change 9 9 X
 Kaizen and the A3 9
ISEN 645: Critical for you to understand and internalize
• The production system [PS]
• We’d better know the scope and context of the system that we are Leaning
• Sources of waste in the production system [our targets]
• It is this system ‘audit’ that makes Lean believers
• Methods, techniques, and tools of waste accounting
• As non-technical as this sounds it is anything but
• Design principles and practices that mitigate waste and produce a Lean
production system
• Process, Queueing, simulation modeling are critical enablers in the design process
• A Culture that sustains the gains
• Lean is not a sometime thing – it is an all the time thing … it is a way of PS life

System, Waste, Design, Produce, Sustain

 The theme of ISEN 645 is lean production system design
ISEN 645 Synopsis…
Lean
• Lean Thinking and Lean principles
Manufacturing is the title, and
but the course is focused practices
on:
• The definition of Lean,
• The core principles of lean, Production system
Design Lean
Lean Production system
Production System
• The application of those
principles to production
system (manufacturing and
service) design and
operation, and Lean tools
• The methods, tools, and and
techniques for technologies
implementing lean
throughout the life-cycle of
the production system.
 NB: If the PS is already in

The LPS Design is communicated through existence, we often leverage

IDEF0 and VSM models to also
represent the current state or

design artifacts, key among these are: ASIS in order to facilitate analysis
and design of the future state or
TOBE LPS
• LPS CONOPS: leveraging IDEF0 to solidify the PS intention, scope, nature of the core transformative
processes that are used to deliver the valued product or service – the “concept of operations”
(CONOPS) for the LPS
• VSM: Highlights the essence of flow and control associated with the transformative processes;
scorecard on the depth of the “waste” problem
• Cell design – small batch, single piece flow is performed by dedicating production lines and
resources, right-sizing, layout, task engineering, line balancing, resource assignment, instrumenting
the process for monitoring, WIP control on the front and back ends
• Work authorization and flow control – push, pull, hybrid … material handling design
• “Supermarket” design – inventory is used to decouple processes, adhere to a customer service
level, and to serve as a check on variability … Factory physics and Buffer engineering applied
• Visual status and operation management in the gemba – PS health is a matter of maonitoring and
comparing the actual behavior to that as designed. Remediation occurs via countermeasure and
kaizen. Health monitoring and issue remediation is continuous. Creativity, innovation, and holistic
employee involvement are critical.
 Antoni Gaudí said, “Sagacity is superior to science. The word comes
from sapere which means to savor [to taste]; it refers to the fact. Wisdom is
wealth, it is a treasure; science provides us with certainty about what we
examine; it is required to keep counterfeit coins out of the treasure.”

5SEP Lecture Plan

0: Quiz & roster verification / Initial project team sign up (teams of 4max)
1: IDEF0 basics – review and the start towards a model quality checklist
2: IDEF0 example

WED 7SEP: HW1 due, HW2 assigned; The Value Principle

We don’t have to get to perfection to see value: G.K. Chesterton said, “The poet
only asks to get his head into the heavens. It is the logician who seeks to get the
heavens into his head. And it is his head that splits.”
M1:
Review
Lean is NOT…
• 6σ – but it is not mutually Lean PS
exclusive (ME) of it either
• Traditional PS design and design and
operation, but it is not ME of it operation
either

• Both Lean and classical PS

paradigms leverage 6σ – but 6σ
itself is an entirely different Traditional
concept. 6σ
PS design
• You may hear “Lean 6σ” spoken concepts
of - but they are distinct and
concepts. 6σ is used to support and tools
the operation of the LPS or the operation
PS in relation to its intended
function and delivery of value
 LPS design and operation…
• A production system is a purposeful set of planned transformations
• The production system must be designed, its core transformations must be planned to be effective
• A system is designed, its execution is planned
• ‘Planned’ means the what, why, how of the system requirements for effective production
• This planned transformation requires the development of planning ‘products’ that embody the planning
• This course is focused on designing production systems that are engineered to be repeatable and
reliable; part of the design process is directed at the planned execution of the resulting LPS

• We often design our production system for operation [as if we will operate it] in the steady state, but the
design, and the production system planning must be robust enough to handle the reality of transient
system behavior … as Dwight D. Eisenhower said:
“In preparing for battle, I have always found that plans are useless but planning is indispensable.”
Traditional PS planning and operation
• Forecasting
• Aggregate Planning
• Master Production Scheduling
• MRP – explode the BOM
• Scheduling
• Dispatching work
• Production Execution
• Monitoring and Controlling Execution
• Maintaining the PS
 Planning products applied
Marketing
Factory Physics: Hopp and Spearman
Parameters FORECASTING

Product/Process CAPACITY/FACILITY WORKFORCE Labor

Parameters PLANNING PLANNING Policies

Capacity Personnel
Plan Plan

Hierarchical Planning
AGGREGATE
PLANNING

Aggregate
Plan

WIP/QUOTA Customer
SETTING Demands

Master DEMAND
Production MANAGEMENT
Schedule

WIP SEQUENCING &

Position SCHEDULING

REAL-TIME Work
SIMULATION Schedule

Work SHOP FLOOR

Forecast CONTROL

PRODUCTION
TRACKING
 Production system planning
• What is the production system?
• What are its critical transformations?
• What is required to perform those transformations?
• How will those transformations be carried out?

• PSP is a rigorous approach to ensure that the production system operates in

a repeatable, reliable, and efficient manner

• PS Planning is an engineered framework of …

– planning products, and
– the methods and techniques for development of those products, plus
– patterns of application that have proved valuable in industry
 In one sentence:
Lean is the rigorous accounting for and
What is Lean – and why study it? continuous elimination of waste in the
production system.

• Core Characteristics of a Lean Production System:

• Single-piece flow v Mass, batch based production
• Customer demand Pull driven v MRP based push
• Quick change production lines v Mass produced
• Transportation only when pulled and authorized v push the pile
• Variation attacked, accounted for precisely with buffers v Overtime
• Quality issues halt the everything until resolved v inspection and rejection

• Regardless of how we characterize the Lean production system – the

origin of Lean is the found with the TPS…
The Toyota Production System
and why it makes a difference
• Ohno makes three key statements regarding the
TPS:
1. “The basis for the TPS is the absolute elimination of
waste.”
2. “Cost reduction is the goal.”
3. “After WWII our main concern was how to produce
high-quality goods. After 1955, the question became
how to make the exact quantity needed.”
• TPS is referred to as:
• “A Production System that is a quantity control system,
based on a foundation of quality, whose goal is cost
reduction, and the means to reduce cost is the absolute
elimination of waste.”
TPS Thinking is the basis
for Lean Thinking
The lean production system
• An intentional system, predicated on planned transformative
processes, leveraging a set of (possibly scare and/or shared)
resources, resulting in one or more clearly defined products
AND
• Operates non-stop to eliminate all forms of leadtime and the
associated waste that the customer is not willing to pay for.
We’ll need a way to represent key aspects of the system in order to describe it, account for its
elements, and study it
Systems Engineering methods and techniques can provide a ‘BOM’ and ‘MRI’ of the system
One very useful modeling method
that depicts the essence of input IDEF0 Diagram Syntax
to output transformations in a
system and the elements that
constrain those transformations is Controls If in doubt about what
IDEF0… the system is – then
model it

Inputs Function or Outputs

Activity
(Verb Phrase)

What’s IDEF0 mean again? –

Integration DEFinition Language;
the ‘0’ is an identifier for which
Mechanisms method is being used because an
entire family of IDEF methods
exists to support SE
Decomposition

A0
More
General
A1
A-O (Parent)
A-O
A2
A3
A4

A0 2 A-O More
A41 3
4
Detailed
A42
(Child)
A43

A4 IDEF0 is one way to visualize the

Production System, Lean
practitioners also rely on the VSM…
VSM…
Seeing the Value Stream

Is there a formal method for VSM

development? It’s a question worth
asking – without a method we are at
the mercy of the author and their
intention and convention.
So, we’ll need methods and models, but…

What’s driving the Need for Lean?

• PS Envy … catching up with the Toyota Production System [TPS]
• Continued lo$$ of the one resource that renews, grows, and sustains the PS and the Enterprise
• Too much $$$ capital tied up in:
• WIP [and there are many states of WIP]
• Labor
• Material
• Process information
• Management
• Space
• Facilities
• Equipment
• Tooling
• Material handling
• Processing
• Change over
• Engineering changes

• Essentially we start treating every resource as if it is scarce and the need for Lean Thinking becomes obvious
• The question then becomes how to systematically, repeatable, reliably, and continuously define, design,
implement, monitor, control, and refine the PS to be Lean?
• ISEN 645
Principles and Practices Womack & Jones

As Production System Engineers our job, in part, is to apply these principles to our PS, generate
requirements for achieving the desired LPS, then specify (using our engineering artifacts) solution
concepts that address these requirements. This must be done with rigor and precision – else the
communicative power of the design artifacts for what to do and how to do it will be lost.
 How to get Lean: *Five strategies and Five Tools to
Eliminate Seven Wastes [Wilson] * [Lean math: 5 x 5 = -7]

1. Synchronize supply to the

…and a quick note on Waste – many Lean BoKs
customer
identify 8 or 10 or 14 rather than 7; it is an
2. Synchronize production internally accounting exercise and categories will be categories
3. Create flow 1. TAKT calculation
4. Establish pull-demand systems
2. The basic time study
5. Standardize and sustain 1. Transportation
3. Balancing/Leveling analysis
4. Flow – “Meteor trail” – diagram 2. Waiting
We will revisit this again as
we begin a progression of 5. ASIS and TOBE VSMs 3. Overproduction
exercises to reinforce Lean 4. Defects
concepts; but it’s good to
note that this can all be 5. Inventory
done methodically and 6. Movement
rigorously – that is we can
engineer a Lean Production
7. Excess processing
System
What is this talk of Takt? [Lonnie Wilson p.223]
• The rate at which a customer would pick up [or pull] a product unit if they pulled that unit uniformly
throughout the day – assuming production is also performed uniformly throughout the day.
• Takt strives to eliminate the worst of all wastes: overproduction
• Takt drives true one-piece flow, pull-demand

𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 𝑤𝑜𝑟𝑘 𝑡𝑖𝑚𝑒

• 𝑇𝑎𝑘𝑡 = for a given work time interval
𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟 𝑑𝑒𝑚𝑎𝑛𝑑

• Example: 2 shifts per day of 10h each; 30min lunch and two 10min breaks per shift. Available work time
= 20h – 2*(50min) = 18.33h/day; further assume 252 working days/year. The customer agrees to
purchase 500,000 units per year. The Takt rate for a typical work week:

18.33ℎ 5𝑑 91.67ℎ 330,000𝑠

• 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 𝑤𝑜𝑟𝑘 𝑡𝑖𝑚𝑒 = ∙ = = “Mr. Spock, analysis…”:
𝑑𝑎𝑦 𝑤𝑒𝑒𝑘 𝑤𝑒𝑒𝑘 𝑤𝑒𝑒𝑘
Our Production System must produce one good
500,000𝑢𝑛𝑖𝑡𝑠 𝑦𝑒𝑎𝑟 9615𝑢𝑛𝑖𝑡𝑠 unit every 34.3sec in order to stay up with
• 𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟 𝑑𝑒𝑚𝑎𝑛𝑑 = ∙ =
𝑦𝑒𝑎𝑟 52𝑤𝑒𝑒𝑘𝑠 𝑤𝑒𝑒𝑘 customer demand – this is our synchronization
time with our supply to the customer [recall
330,000𝑠 𝑤𝑒𝑒𝑘 34.3𝑠
• 𝑇𝑎𝑘𝑡 = ∙ = the first of the five strategies].
𝑤𝑒𝑒𝑘 9615𝑢𝑛𝑖𝑡𝑠 𝑢𝑛𝑖𝑡
M1: Takeaways
• Lean, as a concept, was born through the reverse engineering of the
TPS
• The characteristics of lean are many but the essence is unchanged –
lean is value to the customer, value stream, flow, pull, and unceasing
desire for perfection
• 5-core principles at play
• The cold hard reality is that variability exists (in the demand, in the
process, in the resources) and is eaten through buffers (time,
capacity, inventory)
• Factory physics is the science behind lean
NB: recall the definition of the PS – intentional, purposeful collection of
transformative processes that achieve a valued product or service

Intentional?
Transformative processes?
Valued product or service?

We need a blueprint, an unambiguous way (or many ways) to represent

this characterization of the PS for communication

Our ultimate objective is to design, build, and operate the PS as designed

so as to achieve the intention and capitalize on the “value” to the
customer

M2:
IDEF0 – SE method for representing the key transformations of the PS
How to read an IDEF0… IDEF0 Diagram Syntax
If in doubt about what
the system is – then
Controls model it
What controls or triggers the activity

Inputs Function or Outputs

What is being transformed
Activity The outcome of the transformation;
(Verb Phrase) and byproducts of the transformation

Note: an output can act as either

an input into another activity or it
Mechanisms can be used to control another
These are the resources that are ‘doing’ the transformation activity
 IDEF0 is a very good method for providing
Decomposition definition of a system or concept. It
depicts the context, scope, purpose, and
the essential transformations plus their
constraints …

A0
More
General
A1
A-O (Parent)
A-O
A2
A3
A4

A0 2 A-O More
A41 3
4
Detailed
A42
(Child)
A43

A4
What we have to work with…
• Principles, tools, rules, artifacts of the activities, …
• What we’d like to do is focus on a clear set of activities that produce what we
want – which is a Lean Production System
• The method should produce a clear “thread” [the key transformations of
artifacts] through the activities that result in our objective
• We can then identify the controls and mechanisms that allow that “thread” to
occur
• The core thread for us is depicted by the evolution of the TOBE VSM

• Note – that many projects [to do Lean or anything for that matter] fail simply
because the team does not make an effort to manage the intermediate
products or artifacts or prepare for the byproducts that will be produced from
the effort – design rational is captured throughout the project.
 IDEF0 is a model development
method, but from another

We can use IDEF0 is a number of ways… perspective it is also a “tool” that

the engineer can leverage in
characterizing the system, pieces
of it, or simply the plan of action
for some action
• Characterize the PS; both the ASIS and the TOBE IDEF0 is a very useful tool for
• Depict the activities required to define customer value planning and defining
transformations of many types
• Depict the activities required to define the value stream
• Depict the activities required to perform a LPS development effort
• Model the activities required to achieve a degree from TAMU
• Model the processes involved in transforming a judge on TV show into a
presidential candidate
• Model the activities of the UN
• Model the CONOPS for an existing or candidate PS!!!
• Model the activities associated with the development of a CONOPS in general
• Model the generic activities required for the development of a system
Characterization of a “System”
• A collection of elements so arranged as to
• Perform a function
• Exhibit a behavior
Activity Modeling with IDEF0

. . .Creating System Function

Architectures
What is an Activity (IDEF0) Model?

• A representation of the activities and the

relationships between and among those activities
in an existing or planned system.
• A collection of diagrams, glossary, and text along with
the context, viewpoint, and purpose statements.
What is IDEF0?

• An activity modeling method.

• Supports descriptions at any desired level of detail
through Decompositions.
• Provides both a process and a language for
constructing a model of the activities and their
interrelationships.
What IDEF0 Represents
• Functions - Decisions, Actions, or Activities of the
domain
• Objects - Physical or conceptual of the domain
• Roles that objects stand-in relative to functions
• Relations between functions formed by objects
• Relations between functions formed by the
composition relationship
IDEF0 Provides ...
Customer Commission
Expectations for Analysis

Symptoms, Establish Customer Needs & Requirements

Concerns, Requirements
Opportunities Commission & Plans for
A1
Design & Trade Studies

Alternative Technologies Design Commission & Plans for Build

System
Knowledge of Previous Design
A2 Design

Raw Material Build Product

System
A3

Analysis Methods Design Methods Fabrication Methods

Do not forget to
define these for
every model that Establishing the Model Objectives
you build!!!

• Viewpoint
• Determines what can be seen and from what slant.
• Purpose
• Establishes the goal of the communication intended by
the model.
• Defines why the model is being developed.
• Specifies how the model will be used.
• Context
• Establishes the scope of a model.
• Establishes the subject as part of a larger whole.
• Creates a boundary with the environment.
Keep the Main Thing, the Main Thing
“Control” Finished Tool
product characteristics
requirements
“Input” “Output”

Specify
assembly
Parts Step-by-step
list instructions
“Mechanism”
Planner
This is transformed by the function to create this.

Arrows represent physical or conceptual

objects not sequence of activation
Minimal Requirements

Control

Activity Output
(Verb Phrase)
 Function Diagram Shows
Interrelations Between Functions
Company guidelines

Process guidelines
Process Order
Purchase request request
A1 Invoice guidelines

Process
Invoice invoice Payment
A2 Ledger guidelines

Apply
purchase to Correct ledger
books
A3

Accounting staff
Interactions may involve Feedback

System requirements Comments

Design

Draft
specification
Review
Approved
design
Components
New Student: An employee of the company that
has been directed, or volunteered, to participate in
training
Glossary ...
Instructor & Textbooks: The person responsible
for teaching students and the documents, books, or
other printed material used during the class

… documents the definition or characterization of one of the

IDEF0 components of your effort. Each component in your
model (both functions and concepts) must have a glossary entry!
What exactly do you mean by New Student?
It’s defined in the glossary.
Components

The input “personnel folder” is not an input to

the A134 activity “Monitor Supply
Text Elaboration ... Consumption” because this group of information
is not transformed in any way, or needed by these
activities.

… is associated with a “diagram”. It describes the things that

may not be apparent, but are necessary, to know to understand a
diagram.
Why are these inputs only on boxes 1 and 2, but not 3?
Summary so far…

• Inputs are transformed into outputs.

• Controls “influence” the activity but are not
transformed or consumed.
• Mechanisms “enable” the activity.
• All Activities must have at least one output and
one control
• All activities and all concepts must have a glossary
entry
Decomposition

A0
More
General
A1 A-O (Parent)
A-O
A2
A3
A4

A0 2 A-O More
A41 3
4
Detailed
A42
(Child)
A43

A4
Functional Decomposition
• Each activity is described as being composed of
distinguishable sub-activities.
• Meronomy “has parts” not “kind-of” relationships
between children and parent activities
• No decomposition by type
• A “parent” activity is decomposed into three to six
“child” activities.
• Each child can become a parent and be further
sub-divided.

(Wiki): A meronomy or partonomy is a type of hierarchy that deals with

part–whole relationships, in contrast to a taxonomy whose
categorization is based on discrete sets.
 Every Component
may be decomposed
in another diagram.
A-0
More General

1
Every Diagram
2
shows the “inside”
3
More Detailed
4 of a box on its Parent
A0 Diagram
1
This diagram is
the “parent” of 2
this diagram.
3

A4

A4 2
Functional Decomposition
• Each activity in the model is unique and not
represented multiple times.
• The Sales Dept., Accounting Dept., and Engineering
Dept. may all submit Monthly Expense Reports...

• ...but in the activity model there is only one activity

called “Create Monthly Expense Reports.”
Decomposition
Company guidelines
Budget guidelines

Maintain Correct ledger

Purchase request Accounts
Payable Payment
A0

Accounting staff
Decomposition
Company guidelines

Process guidelines
Process Order
Purchase request request
A1 Invoice guidelines

Process
Invoice invoice Payment
A2 Ledger guidelines

Apply
purchase to Correct ledger
books
A3

Accounting staff
 Always Preserve Context
Where did this go?
Budget guidelines

Company guidelines

Process guidelines
Purchase Process Order Where did this go?
request
request
A1 Invoice guidelines

Process
Invoice invoice Payment
A2 Ledger guidelines
Where did this come from?
Apply
purchase to
Correct ledger
books
A3

Accounting staff
Tunneling
Tunneled concepts ...
• Are intended to simplify a diagram.
• Communicate functional relationships between
activities without cluttering every diagram in-
between.
• Are not intended to be used as a means of
“eliminating” unnecessary concepts from a model.
 Tunneling
( )
( )

( )

( )

( )

( )
( )
( )

 A concept tunneled at the unconnected end indicates that the

concept will not be shown at a higher level.
 A concept tunneled at the connected end indicates that the
concept will not be shown at a lower level.
 Tunneling for clarity
Company guidelines
C1
Budget guidelines
( ) Company guidelines
Purchase Maintain Correct ledger
request Accounts
Payable Payment
A0 Process guidelines
Process Order

( )
Accounting staff
request
A1
Invoice guidelines

Process
( ) Invoice invoice Payment
A2
Ledger guidelines O2
Apply
purchase to Correct ledger
books A3
O1

Accounting staff
M1
Bundling & Unbundling

• Bundling allows us to group several concepts into a

larger “set” of concepts.
• Unbundling allows us to decompose a general
concept into its component concepts.
 Concept Aggregation and
Company guidelines
Decomposition
Budget guidelines
( )
Maintain Correct ledger
Purchase request Accounts
Payable Payment
A0
Company guidelines
Accounting staff

Process guidelines
Process
request
A1 Invoice guidelines

Process
invoice
A2 Ledger guidelines

Apply
purchase to
books
A3
Bundling (Branching and Joining)
This branch means that “Files”
(p rod uced by Box 1) are comp osed
of “Custom er Rec ord s” (need ed by
box 2) and “Price & Tax Tables”
(need ed by Box 3).
This join means that “Acc ount Entries ”
ar e created by some from “Deliver”
“Prod ucts” (Box 2) and /or some from
“Do Billing” (Box 3).

Keep Files
recor ds
1 Custom er Prices &
recor ds tax
tables
Ord er s Deliver
p rod ucts
2 Acc ount
entries

Transactions
Do
billing
3 Invoic es

This c hain of input and outp ut ar rows means

that “Ord ers ,” upon d elivery (Box 2), ar e
recor ded as “Trans actions ,” which, when billed
(Box 3), ar e reflected on “Invoices .”
If one were to build a checklist for
use in developing IDEF0 models
the following slides might help…
Model communication and quality
 Some Basic Rules
• 3-6 rule: Excluding the A-0 diagram, which has only one activity box,
all other diagrams should have no less than three and no more than six
Activity boxes.
• Minimal ICOM rule: Each activity box must have at least one control
and one output, but no more than six of each type of concept.
• V/P/C rule: Every diagram in a model must adhere to the model’s
overall viewpoint, purpose, and context.
Development Process
• Establish and refine CV&P
• Collect information and artifacts
• Identify candidate functions
• Identify candidate objects
• Group functions into clusters and
hierarchies
• Group objects into kind hierarchies
• Refine upwards and downwards
• Apply results
• Maintain
Establish and refine CV&P
• What are the boundaries?
• Determine what is in and out.
• Define the A-0.
• What is visible and what is not?
• What are the completion criteria?
• What decisions need to be made?

You won’t get it right the first time.

You’ll refine it during the course of doing the model.
Collect information and artifacts
• Identify sources and expert reviewers.
• Identify stake-holders.
• Interview.
• Go through all levels in the organization.
• Listen carefully.
• Take detailed notes.
• Collect as much as you can carry.
• Organize source material.
• Perform author-reader review cycle.
The Author-Reader Cycle
Library Coordinator

1. Kit

Model Author Expert Reviewer

2. Kit with
Reviewer
Comments

3. Kit with
Comments
and Author
Response
Identify Candidate Activities
• List Decisions, Actions, Activities.
• Behind each organization, there must be a series of
activities performed.
• Choose activity names carefully.
• Use common semantics.
• Consider name coining an art rather than a science.
• Organize into lists.
• By name similarity.
• By common objects involved.
• Validate with reviewer cycle.
 Well Formed Activity Labels Active verbs are best

• WE rule: When you create the label, as a test, place the word “We” in front
of the label. If the sentence you create is a well formed sentence, you
probably have a good label.
• Well Formed Labels Examples:
• Plan for Manufacturing
• We plan for manufacturing.
• Make and Administer Schedules and Budgets
• We make and administer schedules and budgets.
• Improper Activity Label Examples:
• Engineering
• We engineering. ???
• Production Schedule
• We production schedule. ???
 Identify Candidate Objects
• Pick out object references.
• Name coining is key for many model objects.
• Definite descriptors need to be converted to names.
• Nouns or noun phrases.
• Be careful of state descriptors.
• Organize the lists.
• By kind.
• By part-of relations.
• By subsumption relations.
• Validate with reviewer (author-reader) cycle.
 Clusters and Hierarchies
• Collect activities into composition hierarchies.
• Collect activities together that work on the same objects.
• Avoid (where possible) type hierarchies.
• Name the group of activities (if necessary).
• Strive for at least 3 activities per group and not more than 6.
• Identify missing members of the group (where possible).
“Part-of” and “Kind” Hierarchies
• Solidify name references.
• Harmonize terminology.
• Simplify diagrams.
• Guide modeler in identification of missing
activities.
• Construct new names for the super-kinds or
compositions.
• Validate with experts.
 Define Cells
• Associate objects with functions.
• Identify roles that objects play relative to a function.
• Input
• Output
• Control
• Mechanism
• Check object association on the next level of detail.
• Check object relevance on the same level.
Construct Diagrams
• Build what diagrams you can from the composition
relationships.
• Look for inconsistent or incoherent or incomplete
statements.
• Analyze for key missing relations.
• Complete the story as best able from source
material.
• Validate with experts.
Refine Upwards and Downwards
• Arrange diagrams in hierarchy.
• Check consistency of interfaces.
• Is the boundary clearly defined?
• Refine upwards.
• Do the leaf nodes contain information required to
address the modeling purpose?
• Refine downwards.
• Validate with experts.
 Model Division

• Divides modeling tasks for a team modeling effort.

• Reduces excessively large models into sub-models of a
more manageable scope.
• Allows for placing sub-model into same or different
projects.
Model Merge
• Combines separate models into a single overall
model.
• Handles automatically duplicate model
information according to user-specified criteria.
• Merges models from the same or different
projects.
• Provides a valuable aid for group modeling
projects.
Apply Results
• Arrange periodic review with stakeholders and
model users.
• Get buy-in and sign-off from all groups.
• Document model application.
• Gather requirements for additional model
definition.
• Gather requirements for model application.
• Requirements definition
• Data collection / organization
• Training / Orientation
Maintain
• Shelf life of models is directly proportional to the use of
the models.
• Models need to be maintained to continue to be useful.
• The reading of a model does not generally communicate
all the understanding that the team acquired in the
development of the model.
• Members of the team giving model walk-throughs
• Review of the source material and model evolution process
Successful Activity
Modeling
Understanding IDEFØ Diagrams
• Reading is done top-down.
• Functions show what must be accomplished hence
should be labeled with an active verb phrase.
• Arrows with one end unconnected indicate that the
concepts are supplied, consumed, or used outside the
scope of the diagram.
Understanding IDEFØ Diagrams
• Call arrows indicate a system that completely
performs the function.
• Relationships: an output that is used as an I,C, or M
by another function indicates that the function is
dependent on the former but not how or when.
• Multiple ICOMS do not indicate conjunction; this is
true as well for functions in a diagram.
Best Practice Guidelines
• Think control and constraint, not flow. The diagram
structure must show relationships that hold regardless of
sequence. Diagrams should say the right thing regardless
of what steps are taken first.
• When a diagram is cluttered, it is often an indication that
you put pieces of information that are at different levels of
details.
• Leave out questionable concepts.
Best Practice Guidelines
• A solid abstraction is both clearer and more powerful
than premature detail.
• A concept is a control unless it obviously serves as an
input (is it modified?) If in doubt, make it a control.
• Input/output: what is done.
• Control: why.
• Mechanism: how.
 Modeling Checklist
• In Facilitating system engineering, did it:
• Define What Activities are Performed?
• Define What is Needed to Perform those Activities?
• Determine What the Current System Does Right?
• Determine What the Current System Does Wrong?
• Define Activity Interfaces (Objects & Data)?
• Capture the Costs Related to the Activities?
Modeling Checklist

• In Facilitating Communication, did it:

• Enhance Domain Expert Understanding?
• Facilitate Consensus Decision-Making?
• Promote Effective Team Activity?
Model Quality Checklist
• Completeness
• Are all field-entries, labels, descriptions, purpose,
context, and viewpoint present?
• Conciseness
• Is the terminology used appropriate for the target
audience?
• Are some of the model elements redundant?
• Are all elements clearly distinct from one another?
Model Quality Checklist
• Consistency
• Is the terminology uniform throughout the model?
• Are the model elements traceable to the system being
modeled?
• Correctness
• Is the model an accurate description of the system
being modeled?
• Are implied relations and constraints traceable to
system constraints and relations?
Model Quality Checklist
• Complexity/Understandability
• Is the model clear to the reviewer?
• Is the information intended to be conveyed by the
model accurately depicted via the syntax?
Conclusion
• IDEF0 documents “what” the studied system does.
• IDEF0 identifies where the unreasonable expenses
are and where non-value added activities exist.
• IDEF0 concentrates upon functional dependencies,
not organizational, sequential, or cause-effect
relationships.
Summary
• Activity Modeling is an authoring process
• It is better to communicate clearly than to record
details
• Activity Modeling requires “coining” of terms for
naming activity and abstractions
• Model claims need to be backed up by source
material or SME statements
IDEF0 Advanced Topics and
Demonstrations
Avoid Decomposition by Type

• A form of logical binding between functions

because they fit into a common class but no
necessary functional relationship exists.

Journals
Edit Edited journals
journals
Manuscripts

Comic books Edit

comic
books
Edited
Edited mat erial
comic
books
 Avoid Decomposition by Type
Company guidelines

Process guidelines

Purchase request Maintain Order

Customers
A1 Invoice guidelines

Invoice Maintain Payment

Accounts
A2 Ledger guidelines

Maintain Correct ledger

Books
A3

Accounting staff
Inputs versus Controls or Mechanisms
• Inputs are transformed by the activity.
• Inputs and outputs elaborate “what” is done by an activity
• Mechanisms are resources that enable or facilitate the
performance of the activity. They may be consumed
but do not become a part of the output.
• Mechanisms elaborate “How” an activity is done.
• Controls specify conditions or circumstances that
govern the activity. At least one control is required.
• Controls often elaborate “Why” an activity is done.
• When in doubt, assign the control role to an object.
 Coupling and Cohesion

• “Coupling” refers to the connections between elements (functions or

data)
• “Cohesion” refers to the binding or internal-relatedness between
factors on a diagram.
• In general we want high cohesion
• In general we want low coupling – fewer links with high binding
Levels of Cohesion
Rating Level of Binding For Functions For Data

0 Coincid ental Rand om Rand om

Logic al Functions of the same set or typ e. Data of the same set
1 (e.g., “edit all input”) or type.

2 Temp or al Funtions of the sam e time p eriod. Data used d ur ing a

(e.g., “initializ e op erations”) time p er iod .

3 Proc ed ur al Functions ocurring in s ame p hase Data used d ur ing s ame

or iter ation. (e.g., first p ass of a p hase or iteration.
comp iler)

4 Com uunicational Functions that use the sam e data. Data acted up on by the
same ac tivity.

Sequential Functions that p erform sequentialData tr ansfor med by

5 trans form s of the s ame d ata. sequential functions .

Functional Functions that combine to p erformData associated with a

6 one func tion. single function.

Mos t
Desirable
Cohesion Evaluation – Look at the
diagram TEXT
• If the only reasonable way of describing a diagram is by using a
compound sentence, or a sentence containing a comma, or a
sentence containing more than one verb, then the diagram is
probably less than functional. It is probably sequential,
communicational, or logical in terms of cohesiveness.
• If the descriptive sentence contains such time-oriented words as
“first,” “next,” “after,” “then,” “start,” “step,” “when,” “until,” or “for
all,” then the diagram probably has temporal or procedural cohesion,
sometimes, but less often, such words are indicative of sequential
cohesion.
• If the predicate of the descriptive sentence does not contain a single
specific object following the verb, the diagram is probably logically
cohesive.
 Coupling Evaluation Rule of Thumb
• Count the entities on a diagram. If the total entities is greater than 4
times the number of boxes the diagram should be examined for high
coupling.
• Often mechanisms which are not sourced on a diagram are left out of the
entity count.
• Often coupling issues must be resolved on the parent diagram first.
M2: Takeaways
• Each PS (per the requirement of intentional and purposeful) has a CONOPS
• We need a way to visualize the LPS – at least the key transformations
• IDEF0 provides a platform for activity modeling (key transformations)
• We can leverage IDEF0 in the definition of our methodology – the core activities
that we need to perform in order to achieve a LPS
• IDEF0 is useful in its own right as a SE analysis and design method
• A production system is a great candidate for IDEF0 modeling since it has a clear
intention, a set of transformational activities, and a clear set of products. Add
resources, guidance, stir gently, and we have a PS design artifact that we can use
to focus our attention with.
• A checklist can be created by reviewing the rules and good model development
practices – the checklist helps us to produce models that communicate well
NB: recall the definition of the PS – intentional, purposeful collection of
transformative processes that achieve a valued product or service

Intentional?
Transformative processes?
Valued product or service?

We need a blueprint, an unambiguous way (or many ways) to represent

this characterization of the PS for communication

Our ultimate objective is to design, build, and operate the PS as designed

so as to achieve the intention and capitalize on the “value” to the
customer

M3:
IDEF0 – Examples
Some ideas towards an IDEF0 model development
checklist
• Documentation
• Viewpoint, purpose, context
• Glossary entries for each activity and ICOM
• …
• Diagram clarity
• 3-6 rule for activities per diagram
• Verb phrased labels for the activities
• Noun-phrased labels for the ICOMS
• …
• Model element clarity and consistency
• ICOMS leveled to the level of the activity
• Bundling / unbundling
• Tunneling
• Splits / joins
• …
• Model communication
• Avoids decomposition by type (manage A, manage B, manage C, …)
• Low coupling and high cohesion (NB: if we are depicting the ASIS the model may be attempting
communicate problems with the coupling and cohesion, however for designs we want to establish low
coupling and high cohesion)
• Example: ICOM count per diagram  # ICOMS > (4)(# activities) then we likely have high coupling issues
• See the table for further information on coupling and cohesion
• …
In general, for each artifact we create as part
of the “design” we need…
• Checklist for the role that artifact is playing in the design
• Example: if the artifact is representing a characterization of the principle “value” (the voice of the customer
translated throughout the PS) in our design, then what should we be attuned to ensure that our design
reflects, if not best practice, at least good practice – build a checklist and use it
• Checklist for the artifact itself
• Example, if we are using an IDEF0 model to characterize the CONOPS for the LPS then we need to use the
IDEF0 model checklist to ensure that it communicates as advertised
• The artifact itself
• The rationale – if it cannot be conveyed in the model itself – we may need to state our rationale
elsewhere
• Example: a VSM has no formal documentation requirements – yet without some type of annotation it is
difficult to understand why certain features are present (or not)

• NB: since the overall design is a compendium of design artifacts it is useful for the design
engineer to have a section at the front of the resulting design document that guides the reader
through the artifacts, their role in the design, and their interpretation for the design implementer
or builder.
 M3: Takeaways
• The best way to understand a tool is to practice
• Pick a PS
• Leverage the IDEF0 method in establishing a definition for that PS
• IDEF0 models provide a blueprint of the PS w/r/t the key transformative
activities or functions
• Coupled with a model development and QA checklist - the IDEF0 model
provides us with a solid LPS design artifact, one that we can then use to
communicate the LPS intention and transformation requirements to the
LPS development team
Next time…
• Lean Principle “Value” – establishing the VOC throughout the LPS

• Read Lean Thinking Part II – ch.6 “The Simple Case” (Lantech)

• HW1 assignment due by 2400h 7SEP
• HW2 assignment will be distributed on 7SEP
• Overview of Quiz2
 Assigned Sources leveraged:
• www.lean.org
• www.idef.com
• Factory Physics [Hopp and Spearman] 3rd edition 2008
• Factory Physics for Managers [Pound, Bell, Spearman] 2014
• Lean Engineering [Black and Phillips] 2013
• Lean Manufacturing [Lonnie Wilson] 2nd edition 2015
• Lean Thinking [Womack and Jones] 2003 edition
• Learning to See [Rother and Shook] v1.2 1999
• The Lean Toolbox [Bicheno and Holweg] 5th edition 2016
• Improving Production with Lean Thinking [Santos/Wysk/Torres] 2006
• Methods, Standards, and Work Design [Niebel] 12th edition 2007
• Applied Probability and Stochastic Processes [Feldman and Valdez-Flores] 2nd edition 2010
• Operations Research Models and Methods [Paul A. Jensen, Jonathan F. Bard] 2002 edition
• Principles of Operations Management [Heizer/Render] 7th edition
• Gemba Kaizen [Imai] 2nd Edition 2012