Manufacturing
ISEN 645
FA2016
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
Class2 is focused on a primer on
the nature of the Lean.
5: 26/28SEP Flow JIT; Cells; SMED; Leveling
The LPS design is a reflection of 6: 3/5OCT Flow / Control Factory Physics Principles; 3EQN/4GRAPHS
the engineering artifacts that are
used to represent it. This is not 7: 10/12OCT Control Kanban; CONWIP; integrated IC & PC
without peril. The key is
communication. We want an 8: 17/19OCT Control Buffer engineering (time, capacity, inventory)
operating LPS – not just the
design. LPS design is an 9: 24/26OCT Lean supply chain Principles; Beer game
application of System Engineering
(SE). 10: 31OCT/2NOV Lean supply chain Integration with the PS
We leverage a SE method called 11: 7/9NOV Perfection: Lean 6σ DMAIC VOC; SIPOC; C/E chaining
IDEF0 to assist in our visualization
of the essential characteristics of 12: 14/16NOV Perfection: Lean 6σ DMAIC Gauge R&R; SMED; SPC
the PS.
We are preparing to cover the core 15: 7DEC* (WED) Project briefings Schedule and timing TBD
principles of Lean – in turn.
16: Final 9DEC 0730-0930a
31AUG Lecture Plan
0: Review
1: Lean Primer
2: The Production System and a methodology for achieving Lean in the Production System
3: IDEF0 and AI0WIN
Quiz1 is Monday 5SEP
HW1 Assignment (Due 7SEP)
M0 (module 0):
Review
G.K. Chesterton makes distinct the practical man from the thinking man: “A practical man means a
645 – the intention man accustomed to merely daily practices, to the way things commonly work. When things will not
work, you must have the thinker, the man who has some doctrine about why they work at all.”
• The end game is to understand why lean is important as a PS paradigm AND to know what is and how to develop a LPS design
• A LPS design is a collection of engineering artifacts and associated rationale that collectively are called “the LPS design”
• When pressed to characterized a concept or thing I like to frame the resulting characterization by leveraging Kipling’s Six Honest Serving Men
• There are many definitions that could rightly be used to characterized “what” the LPS design is – each PS design situation that we encounter may
call for certain design facets and features more so than others
• My intention is to introduce and exercise your understanding and usage of, through practice, the most commonly used LPS design artifacts that
are employed in LPS designs
• How do I arrive at “most commonly used”? My reading of the literature, texts (written and adopted by other ABET certified ISEN degree granting
institutions), notes from engineering scholars and practitioners at leading universities, coupled with my own experience in communicating and
implementing designs in industry
• 645 is largely directed at the task of “how” we put a LPS design together and “why” it is worth doing in the first place
• This is predicated on knowing what a PS is AND how one characterizes a PS in the first place
• The “characterizations” alluded to here are what I termed “engineering artifacts”. Each artifact attempts to convey a critical facet of the LPS
design. Coupled with the obligatory “stage directions” they communicate the what, why, where, when, how, and who required for the
implementation and operation of the LPS. As in any SE effort we move from understanding the nature of the problem to the specification of the
solution to the building of the solution to the operation to the refinement etc – we follow the system lifecycle; the LPS above all things is a system.
• If everything just described were deterministic and straightforward then they would simply print it on the back of a cereal box and the need for
LPS engineering and PS engineering would be history. Apparently this is not the case. Regardless of how well known and internalized Newton’s
laws of motion are – the university system still feels compelled to make them part of an engineer’s well balanced cerebral diet. Defining,
architecting, building, operating, remediating, … systems - is not without peril. While I do not personally cotton to Machiavelli, nor his name
being on the same page with Chesterton, nevertheless – his reflection on those who build and manage “systems” is worth note:
“It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more
dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the
preservation of the old institution and merely lukewarm defenders in those who gain by the new ones. ”
645 Synopsis
*
1. A description of what the student will be able to do
2. The conditions under which the student will perform the task.
3. The criteria for evaluating student performance.
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.
What Lean is v What Lean is like and sometimes discussed by production systems that
exhibit characteristics of Lean
• Recall Aristotle’s distinction between what a thing is (its essence) versus what a
thing is like (based on its characteristics); the characteristics were described by
Aristotle as “accidental” in the sense that they were not integral to the thing –
unlike the essence which stood under (sub stans) the characteristics
• Why useful here? – because a PS being lean is not due to checking off a few items
on a checklist (though checklists are useful); lean design is more about removal
than addition - removal to attain what was there originally
• A production system can be designed to be lean and when something prevents
that lean design from being realized then we have a cause to address
• Working backward then we can identify the causes that prevent lean and
engineer their elimination from the production system – we then achieve the
lean production system – the ideal production system – the system that was
always present but was invisible due to the waste in the system
The Lean Production System has always been there – we just need to remove the waste to see it.
The production system…
• Many types exist, we define ours broadly to mean 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.
• The 5-P’s: Plant, Process, People, Parts, Product
• The scope required for PS design is broad by necessity. We are
interested in the “value chain” – from customer demand back to
customer satisfaction
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.
• Lean is…
• The Ideal way
• About continuous waste identification and removal
• About productivity
• Systems thinking
• Continuous learning
• Both revolution and evolution
• Distributed decisions
• Green
• Compression
• A Principle-centric approach
• The Toyota Way
• The DNA of the TPS
The “DNA” of the TPS (Bicheno and Holweg)
• A classic article in the HBR by Spear and Bowen (1999) “Decoding the DNA of
the Toyota Production System”
• TPS is widely seen as the “ground zero” for Lean
• Four rules capture the essence of the Toyota Production System (TPS)
• Rule1: All work shall be highly specified as to content, sequence, timing, and outcome.
• Rule2: Every customer-supplier connection must be direct, and there must be an
unambiguous Y/N way to send requests and receive responses.
• Rule3: The pathway for every direct product and service must be simple and direct.
• Rule4: Any improvement must be made IAW the scientific method, under the
guidance of a teacher, at the lowest possible level in the organization.
Lots of production
Lots of systems
Enough ISENs? A former Department Head at a Top 10 ISEN program related to me a
continual issue for their job-interviewing graduates to be…
• This course is full of new terms many of which are Japanese as we would
expect given Lean’s origin [Toyota Production System]
• We will get to both the terms and to their definitions in time; this task is
very important since many of the terms are LOADED but get tossed around
casually in conversation
• Today we focus on the nature of Lean
• You will be introduced to most of the terminology as you read Lean Thinking
• Every source that I have mentioned in the syllabus has a glossary for review
A quick look at the ‘system’
Which brings us face to face with the oft used term - System
And it’s not just any system that we are focused on, but the – Production System
Coming to TERMS
“…a thing that we know what it is if we are not asked to define it.”
• Production – the purposeful action of transforming inputs into desired outputs
• System [wiki] – a bounded transformation process, that is, a process or collection
of processes that transforms inputs into outputs. Inputs are consumed; outputs
are produced
For ISENs models are critical. Systems Engineering methods make the
process of model development repeatable, reliable, and the resulting model
a standard for communication.
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
A0
More
General
A1
A-O (Parent)
A-O
A2
A3
A4
A0 2 A-O More
A41 3
4
Detailed
A42
(Child)
A43
Enterprise
as a system Rummler-Brache
- method for
Business
mapping and
depiction worth
knowing
I KEEP six honest serving-men
(They taught me all I knew);
Their names and What and Why and When
And How and Where and Who.
Back to Lean
The need
The origin
The Body of Knowledge
So, we’ll need methods and models, but…
• 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
The Age of the ISEN [man achieves production system prowess]…
Source: www.lean.org
Worth repeating what Lean is driving towards…
• Demand-Pull at the Takt rate,
• Single-piece flow [no build up of work
during production; stop if issues],
• Balanced work across the work centers
at or near the Takt rate,
• Strict kanban control for pulls and
moves,
• Model-mix leveled production [not
batch],
• Cycle/buffer/safety stocks to handle
remaining variations
• Plus Cultural change – a we’re never
good enough, never rest attitude of
continuous waste elimination and
system improvement.
Overview of the Lean BoK
Body of Knowledge
Principles
Tools
Method of Application
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.
Tool time…
• Production dashboard
• Monitor operation to design
• Monitor common sources of issues
• 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:
***Of course, designing a system [that is subject to stochastic behavior] such that the rate in = rate out will
get us thrown in jail by the unstable system police, so we will still need to WIP variability into shape …
• But Lean’s use of the TAKT [the customer’s desired product receipt rate] means that the entire system should be
designed to operate as closely to that TAKT rate as possible [actually faster, more later] leveling the production rate.
• The key is the phrase “as closely … as possible”
• Buffers are the system designer’s mechanism to handle variation
• Capital is tied up in buffers … thus the reality is that we will design some forms of extra WIP to guard against the
corrupting influence of variability – and there are many sources of variability at play in a production system
Tick: Don't ever try to swim against the mighty tide of justice.
• We must guard against the dreaded “Type III error – solving the wrong problem”
• The authors relate a story about the Boeing 777 moving assembly line which realized a reduced throughput
[by using the longest Takt time] to accommodate the most complex models on the same line …
• The line certainly embodied the Mixed-Model, Single-Piece flow characteristics
• But we need to keep in mind that there are trade-offs between the characteristics of Lean, TPS, and the
realities of the system that we are engineering.
Time to consult the “Oracle of Delphi”
• Is TPS-like Lean achievable?
• Within what broader science is Lean positioned?
• So, if in doubt – get the Factory Physics text out
• Variability is the norm, better prepare for it
• The drive towards zero buffers may be misleading – drive towards
minimum cost may be better
• Kanban may not be in the cards - CONWIP offers a variability eating,
system stabilizing control paradigm
• Lean is not selective – it cuts horizontally and vertically throughout
the enterprise
• Lean is Technical and Cultural – we will examine both
A Warning…
• Gemba (”real place” – for manufacturing this is the shop floor) can help, but the
manufacturing production system may be too large and complex to easily “go to
the source of and see” – thus models and descriptions can take on a life of their
own.
• No easy fix – just a warning based on the instructor’s experience
In summary… Define
Value
Design
Value
Stream
Create Flow
Instrument
for Pull
Drive to
Perfection
M2:
The Lean Production System development methodology
Lean Review: At its Core…
*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 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
TPS had superior foundations prior to their installation of JIT in 1961.
So failure of Lean efforts may be a matter of expecting too much
Lean Precursors from a PS that is not prepared for the ensuing Lean transformation.
[Wilson outlines several levels of maturity for the issue areas identified below…]
• Before we place the Lean keys into the ignition we need to have some
system issues under control:
• Stability and Quality
• Machine and Line Availability
• Problem-solving Talent
• Continuous Improvement Philosophy
• Standardizing
For the most part Lean is TPS, but there are differences, we will discuss this shortly.
Two pillars of the TPS…
The synchronous, waste-
free, self-correcting
application of man and
Quantity Control through machine
Just in Time Jidoka
JIT, as you will find, has a large, vocal set of detractors – the statement that quantity control and the drive to single piece flow enables
quality control (and vice-versa) meets with skepticism (the ensuing argument is both technical and cultural)
TPS – at its core was designed to eliminate
Muda TPS was instrumented to stay lean
So, TPS set the bar very high – but it is no secret – so why not systematize it and engineer a methodology to generate more Production
Systems that exhibit these qualities? … thus we have a Lean Production System Design and Implementation Methodology
The Lean Methodology is a characterization of what to do
and serves as a basis for planning a Lean Transformation
• Activities [to perform in order to ‘do’ Lean] – we cannot Lean without some
action. Each function or action or activity performs a transformation;
transforming inputs to outputs… so we’ll need to identify the Inputs that are
transformed into the Outputs by the transformation or function. Of course the
actions do not occur without some Resources or Mechanisms [tools, people,
technologies] for how those functions perform those transformations of input
into output. Finally we need to identify guidance that will Control the activity.
• Our characterization should allow us to drill down into more detailed actions -
decompositions
• And it helps to visualize this entire characterization
• Thus we will build an Activity Model using IDEF0 [a method for producing
activity models] to characterize this Lean methodology
In fact, we will continue to evolve and refine our characterization of this Methodology, but let’s get a start…
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
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
A draft of our Lean Methodology
IDEF0
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.
What is the Context, Purpose, and Viewpoint for this model?
Context:
Viewpoint:
Purpose:
Once more, with feeling … and sans waste
A note…
• As we progress through the course material and exercises we will revisit the
“methodology” – tune it, decompose it into the detailed activities that generate
the various artifacts, and also identify HOW we will create those artifacts using
the Lean Tools.
• Further – the IDEF0 method is useful for characterizing many functional
transformations. For example we could use IDEF0 to model the activities
performed to produce a master’s student from ISEN or the activates required to
host a football game or the activities required to produce a president or the
activities required to produce a car, boat, airplane, burrito, …
• IDEF0 is a SE method that is useful in characterizing particular facets of a system:
the key transformations (inputs to outputs), how those transformations are
controlled (controls), what is performing those transformations (mechanisms).
• Thus – when we have a production system that we need to study – it makes sense
to model that PS using a method that has been well vetted and is in the public
domain … IDEF0
M2: Takeaways
• Getting to the TPS is a battle
• We need a design methodology to make sure we are on track
• IDEF0 provides a platform for activity modeling
• 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.
Get the IDEF0 method report from:
www.idef.com
M3a:
IDEF0 - a System Engineering Method Primer
Function modeling
Characterization of a “System”
• A collection of elements so arranged as to
• Perform a function
• Exhibit a behavior
It must be remembered that there is nothing more
difficult to plan, more doubtful of success, nor more
dangerous to manage than the creation of a new
system … For the initiator has the enmity of all who
should profit by the preservation of the old
institution and merely lukewarm defenders in those
who would gain by the new one.
- Machiavelli
The Prince [1513]
Why model?
• A structured way of reaching consensus among
people on the function a system performs and the
relationship to other aspects of the system.
• Why [do we perform these activities]
• What [is being done now]
• How [is it performed]
• Provide the structure for organizing specifications
• Provide the basis for analysis
• Record key decisions
Methods
• Help ensure the modeling is REPEATABLE
• Are intended for a particular USE
• Have a simple, but powerful SYNTAX
• Have well understood SEMANTICS
• Are based upon BEST practice
Integration DEFinition (IDEF methods)
• Address different aspects of a problem, or provide
different views of the same problem
• Facilitate acquisition, analysis, design, and
experimentation through enhanced communication
• Provide standard language of communication
• Raise performance level of novice practitioners to that of
experienced practitioners
• Support integration of team activity
Original IDEF Methods
• Original ICAM plan was to create an integrated
family of 8 IDEFs (IDEFØ to IDEF7)
• The resulting methods products:
• Function/Activity Modeling (IDEFØ)
• Information Modeling (IDEF1)
• Data Modeling (IDEF1X)
• Dynamics Modeling (IDEF2)
Activity Modeling with IDEF0
• 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.
Context
• The context defines the boundaries of your model
or what you will include in the model.
Personnel Regulations
Department Policy
Supervisor Instructions
Employee/ Position Data Manning Conditions
comes from outside the model. Applicant Data
Customer Request Perform Personnel Action
Personnel
Employee/Position Data Reports
Actions
Personnel Regulations
Department Policy
Purpose: Supervisor Instructions
Manning Conditions
To document the activities Applicant Data
associated with managing Perform
Customer Request Personnel Action
Personnel Actions and Personnel
Employee/Position Data Reports
identify non-value added Actions
activities that might be
eliminated.
Supplies & Equipment
Personnel Regulations
Department Policy
Purpose: Supervisor Instructions
Manning Conditions
To document the activities Applicant Data
associated with managing Perform
Customer Request Personnel Action
Personnel Actions and Personnel
Employee/Position Data Reports
identify non-value added Actions
activities that might be
eliminated.
Supplies & Equipment
Viewpoint: Personnel Officer
Personnel Office Staff
Information System
Purpose & Viewpoint Interaction
• Different purpose and viewpoint result in different
models.
Purpose
Non-value added Non-value added
Personnel Actions Separation Actions
Viewpoint
a few personnel a single type of
Personnel actions personnel action
Clerk accomplished by and a small set of
multiple activities activities
3a: IDEF0 overview: Takeaways
• IDEF0 provides a means for representing a time/sequence-of-
execution independent description of functions and their key inter-
relationships (input, output, control, mechanism and composition).
• Purpose, Viewpoint, and Context (PVC) statements establish the
framework for understanding and using a model
• ALL Architectural models require PVC statements
M3b:
IDEF0 elements
IDEF0 Graphical Modeling
Language
Diagram Syntax
Controls
Mechanisms
Activity
• A decision, action, function, or operation.
Represented by a box and labeled as a verb phrase.
Activity
(Verb Phrase)
Hint: 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.
Input
• Any real object, knowledge, or data needed to
perform an activity and transformed through the
completion of the activity.
Input Activity
(Verb Phrase)
Output
• Any real object, knowledge, or data resulting from
the completion of the activity.
Control
Control
Mechanism
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.
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
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.
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...
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
Activity Hierarchy
• Each activity in a model is uniquely identified with
an Activity Number (A0, A1, A12, etc.).
• Each activity can be uniquely placed within a
model according to its relative decomposition
number.
• An activity is depicted only once in an activity
model.
Activity Hierarchy within a Model
A0 Perform Personnel Actions
A0 A1 Hire People
A11 Review Applicant Information
A12 Verify Past Employment
A1 A2 A3 A4 A5 A13 Interview Applicant
A2 Fire People
A11 A21 A31 A41 A51 A21 Review Work History
A22 Create Dismissal Documents
A12 A22 A32 A42 A52 A23 Counsel Employee
A3 Promote People
A0
A-0 A1 3
A2
A3
A0
2 4 A-O 2 4 A-O
A11 3 A0 A31 3
A12 4 4
A32
A13 A33
A1 A3
Concept Hierarchy within a Model
• Concepts (inputs, controls, outputs, and
mechanisms) are not uniquely identified within a
model, but are identified between parent and
child activities.
• Each concept is identified by a letter and number
combination that specifies the concept’s relative
position on the parent diagram.
Concept Hierarchy within a Model
C1
Company guidelines
Process guidelines
Purchase request Process Order
request
I1 A1
Invoice guidelines
Process
Invoice invoice Payment
A2
O2
Ledger guidelines
Apply
purchase to Correct ledger
books O1
A3
These designations are
called ICOM codes.
Accounting staff
M1
ICOM Codes: Preserving 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
( )
( )
( )
( )
( )
( )
( )
( )
( )
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
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” This join means that “Acc ount Entries ”
(p rod uced by Box 1) are comp osed ar e created by some from “Deliver”
of “Custom er Rec ord s” (need ed by “Prod ucts” (Box 2) and /or some from
box 2) and “Price & Tax Tables” “Do Billing” (Box 3).
(need ed by Box 3).
Kee p 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
1. Kit
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
• 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
Journals
Edit Edited journals
journals
Manuscripts
Process guidelines
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
2 Tempo ral Funtions o f the same time period. Data use d during a
(e.g., “initialize operations”) time period.
4 Comuunicational Functions that use the same data. Data acte d upo n by the
same activity.
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.
M3c: Takeaways
• Strive to create clear models with high communication value –
grounded in facts!
• The first model you create is probably wrong. Don’t be afraid to
change it.
• Evaluate the quality as well as the accuracy
• Enter Context, Viewpoint, and Purpose before you start.
• Enter glossary as you go along
• Use the pools to aid in your modeling
• Don’t just start formulating diagrams
• Save versions frequently as there is no “undo”
M3d:
AI0WIN – tool support for developing and documenting IDEF0 models
“W1M7.avi” was uploaded to the week1 folder to provide and overview of the tool
AI0Win Overview
• Starting a new Repository
• Starting a new Model
• Browsing a model
• Populating the Pools
• Creating a Diagram
• Linking up activities with concepts
• Using Matrix Views
• Documenting a Model
• Manipulating Models
AI0WIN
• I have uploaded a “silent” movie that was developed by Dr. Richard
Mayer that goes very carefully through the use of AI0WIN for the
definition and development of IDEF0 models.
• The tool is capable of fully documenting the model – which is a
critical facet to design or any modeling effort for that matter.
• Visio also has an IDEF0 modeling template – but as for the integrated
documentation of the model – you will have to develop that
separately
M3d: Takeaways
• See the movie file uploaded and titled W1M7
• The tool itself has been placed in the ISE cloud available via your
CITRIX account
Next time…
• Quiz1: Covering the 5-core principles of lean; examples