Anda di halaman 1dari 179

Lean Thinking and Lean

Manufacturing

ISEN 645
FA2016

Integrate Flow Monitor &


Define Design Instantiate
& Control Remediate
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.
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
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.

The IDEF0 model of the PS gives us


13: 21NOV* (MON) Perfection: Gemba Kaizen Implementation planning applied
a background against which we
can discuss the principles of Lean.
14: 28/30NOV Culture / LPS design - Epilogue Leadership

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

LPS concepts, principles, LPS engineering design


and practices artifacts LPS design

645 Content 645 Objectives 645 Goal


(Quizzes) (Homework) (Project)
A do it yourself learning objectives and outcomes
development kit for 645…

*
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.

 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


M0: Takeaways
• 15w course
• Will target several small lecture modules per week
• Tools will be leveraged using the ISE cloud
• Office hours on MW (3-4p); others by appointment
• Three core grades: Quizzes (20%), Homework (30%), Project (50%)
• QZ and HW each week; 1w for HW (upload via ecampus drop box)
• Project will be further defined Week2
• Many sources and resources – readings from Lean Thinking are critical
M1 (module1):
A Lean Primer
"There are these two This is Water Lean
young fish swimming along
and they happen to meet
an older fish swimming the
David Foster Wallace
other way...
When one hears “Lean” tossed around in
conversation it can have a puzzling effect. Is
… who nods at it a thing? a paradigm? a large mythological
them and says beast with “four, and therefore, quite distinct
"Morning, boys. nostrils?” (PP&M), is it an equation? is it from
How's the water?" MIT? HBS? is it a fad?…
And the two
We are often applying the definition of the
young fish swim thing we are living within …
on for a bit...
A Production System (PS) can be like this. The
ISEN is the physician for the PS. Skilled in
returning the patient (PS) back to health be it
the demand, raw materials, the WIP, the
processes, the product, the resources …
… and then eventually returning the PS back to a Lean PS.
one of them looks over
at the other and goes Lean is continuous or it is nothing. Lean is
"What the hell is not a project it is the medium through which
water?"... production systems operate. Lean, once
instantiated, is the system.
The literature on Lean is muddled… sometimes Lean is
being discussed as an exemplar of a system that is “Lean”

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.

• 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.
Bicheno and Holweg, The Lean
One of the better introductions to Toolbox, cover the various lean
definitions that have been posited

Lean… in thought and word over that last


several decades… (ch.2 pp.13-35)

• 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…

• JIT Knowing what we know –


navigating the blizzard of concepts,
• TQM paradigms, and buzzwords
Any chance a • Lean
good old ISEN is • BPR
in the mix here? • CPI An issue to be aware of: As we know - necessity
is the mother of invention… Organizations that
• 6-Sigma lack awareness of ISEN – or ISENs who lack
• Critical Chain awareness of what they know can fall victim to
reinventing ‘ISEN’ periodically and reintroducing
• Theory of Constraints it under various names.
• Pull
• MRP-II
• …
A Note on the Lean Lexicon…

• 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

For the ISEN the System is central


• It’s the job of the ISEN
to bring structure to the
chaos
• At issue is the boundary
• And it’s critical to
recognize that the
‘system’ of focus may be
part of a larger 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

Production system [Elsayed and Boucher] – collection of material, labor,


capital, and knowledge [and other ‘things that must be or are to be
enforced or present – essentially constraints’] that goes into the
[production] of a product. How the collection is brought together to
produce the product in any specific situation defines the system.
Systematized production. Ways to classify: by industry, by production flow
characteristics [continuous/discrete], by production technology, by
production size…

• Planning - The design of a desired future and of effectives ways of bringing it


about [Ackoff]
So there are ‘products’ of the planning effort
developed by methods, techniques, and
processes of their own
ISEN: We are accountable for the Production System
[PS] and its various Elements

Some things we know


about the system, some
we don’t, but the theme
of Lean is continuous
waste removal – and
what we don’t know or
take the time to account
for in our PS can hurt us.

Or as a famous SECDEF once said:


There are known knowns. These are things we know that we know. There are known unknowns.
That is to say, there are things that we know we don't know. But there are also unknown
unknowns. There are things we don't know we don't know.
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
• 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 Produce

• Reflection of a system [existing or proposed]


• using a set of well defined idealizations
• for a specific purpose
• from a particular viewpoint
• AS-IS, TO-BE, HOW-TO
• Depict problems
• Embody requirements
• Communicate to a diverse audience
• Industry movement toward model driven systems development, testing,
maintenance [marriage of requirement and specification]
Models Serve What Purpose?
• Derive the Logical Equivalent of the system under study
• system function is based upon logic
• concise, accurate schematic
• utilizes functional decomposition
• the most fundamental representation of the process

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

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.
A System of Systems [SoS]: The Enterprise is a System; the Production System[s] is a
major System within… A true Lean effort will Transform the entire Enterprise

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…

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
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…

• 5S [sort, systematize, shine, standardize, sustain]


• Value Stream Mapping
• Standardized Work
• Load Leveling
• Kaizen [continuous improvement]
• Kanban [visual authorization & control]
• Visual Workplace
• Quick Changeover
• Andon The tools are a mechanism to designing, producing, and
• Poka-yoke [mistake proofing] sustaining Lean Manufacturing Production Systems.
• One-piece flow
The repeated and sustained use of the tools can be a
• Cellular Manufacturing cultural changer and enabler in and of themselves.
Key artifacts of the value stream identification We will get familiar with
these engineering
and design process artifacts via exercises and
the project

• ASIS or Current State • Verification model


• Value Stream Map • Simulation model of the future state
• A model with an eye on the • Used to test System performance in light
identification of common forms of of variability and within the context of
waste various scarce resource scenarios

• Production dashboard
• Monitor operation to design
• Monitor common sources of issues

• TOBE or Future State


• Value Stream Map
• A model with an eye on flow
To reiterate … waste is found throughout
the enterprise
• Lean drives the enterprise towards a production system that is without waste
and that operates with watch-like precision and determinism
• It is the Value Stream that is the focus of our effort
• Careful accounting vectors us to the waste
• When we examine the value stream we will continuously examine the
underlying processes and activities … building a checklist will be very helpful
… examining each activity’s state conditions is also helpful
A single activity or process
State Conditions –
Transition
Entry Conditions – those conditions Exit Conditions –
Conditions – those
those conditions required for the those conditions
conditions
Entry required for the activity to remain required for the Transition
required for the
process or activity in an activity to
activity to
to start “operational” complete
transition
state
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𝑢𝑛𝑖𝑡𝑠 𝑢𝑛𝑖𝑡
The value of kanban is control. No work, no movement without authorization.

What about Kanban – you use that word a lot too?


It’s a card that authorizes work to
be performed or movement of Note: If Kanbans are over-used or used to control too
an asset  no card no action.
many facets of the PS then we could easily make the
Two Q’s: what to make & how control logic so complex that it begins to rival the
much (or what to move and how complexity of the production itself! … a self-induced
much)
form of waste.

Kanbans could be used to drive the entire supply chain.


What we seek, the reality, the culprit  σ2
• What we would really like to have is a production system that operates like a constant rate conveyor – that is
deterministic or without variability
• If that were the case then designing the system such the ***rate in = rate out would be sought …

Rate In Production System Transformation Rate Out

***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.

A quick note on that word, *levelling*


• Levelling is the production planner’s way of saying that regardless of the
lumpiness of the flow into or out of our PS – we will level the work being
performed
• There are two dominant ways to do this:
1. Level the demand – maintain a constant production rate
2. Level the capacity – maintain a constant utilization of the resources – this is how many PS
operate currently; this method of leveling can sometimes be at odds with lean
• Lean clearly opts for method 1 – using the takt time to identify the delivery rate if
the customer were demanding the product uniformly across the planning horizon
• “level” and “uniform” are interchangeable, though each production line or
product type might change what is meant by the “level”
The “House of Lean” is a metaphor. It is normally
Lean gets Organized… specialized for the implementation at hand.

• “Reverse engineering” the


TPS resulted in principles
for which key outcomes
and artifacts could be
identified that then provide
something tangible to drive
towards if one were to
mimic the TPS.
• Methods, techniques, and
tools [25+] followed…
• Without some framing the
Lean landscape would look
very convoluted
So, what’s the catch?
This is not a spectator sport
There is hope – Factory Physics provides deep roots, refuge,
and a warning
Factory Physics for Managers
And this too shall pass??? Ch.1 p.15-22

• What’s the reality regarding Lean Implementations and Transformations?


• WSJ [14JUN2012] “Where Process-Improvement Projects go Wrong.”
• 60% of 6σ efforts fail to yield expected benefits
• Forbes [5FEB2011] “Where Lean Programs Fail…”
• 2% of Lean efforts achieve their anticipated results [NB: may be biased due to the # kaizen events accounted for]
This brings up the issue of partial or fuzzy Lean implementations … lots of Kaizen events, but the core TPS foundations are
missing. For example replacing small batch sizes for large  batches are not single-piece flow…

• 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…

• We must Keep the Main Thing THE MAIN THING


• Lean Thinking is value stream driven, but once engaged in a Lean Manufacturing
effort the artifacts of the (Lean) effort can easily steal the show… Lean “war rooms”
make prominent the artifacts of the lean effort – in fact these artifacts can look so
compelling that they ‘become’ a replacement for the actual production system.
Models are better known for what they leave out than what they have in.
Models are sets of idealizations that provide a platform for engineering
activities, but models of course are not THE system.

• 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

• Lean is a systematic methodology for Waste removal and production system


operation precision
• Since it is a methodology there are:
• Rules, principles, and practices to follow
• Activities to perform [from definition through sustainment]
• Tools to leverage
• But it is not “one and done” – far from a spectator sport - Lean lives on,
continuously as we drive towards perfection

For Next Week, READ: Lean Thinking, Part I: Lean Principles


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: designs, just like blueprints in the ISE, ME, and CE worlds, are
versioned for later recall. LPS designs are no different. The corporate
memory is a reflection of the thinking that has been done to foster its
viability as a PS. The only way to guard against groundhog day, every
day, is to keep track of what was done and why … people move in an
organization, due to certain physiological constraints, they take their
brains with them. The “system” only knows what it has a record of –
artifacts stored. The corporate memory matters. Knowledge
repositories are almost never thought of until they are needed –
which of course is too late.

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

• In other words we need at least a minimally successful PS in place before


we can hope to achieve TPS-like Quantity Control … But the truth is that
many organizations are working these issues these simultaneously with the
Lean Transformation
Lean Production System Implementation Methodology
= Lean Thinking + Lean Engineering
• The compendium of principles and practices can look like a blizzard without some type of structure
• We need a roadmap
• A methodology will help us gather the key activities, principles, and tools of Lean into a description that can
be used as a prescription
• We start by examining an exemplar Lean system – the TPS
• Extract the best features/characteristics
• Identify the critical actions and tools that allow us to understand our current state and design a new PS that
exhibits those characteristics
• Develop the guidance to drive those critical actions
• Document this as a methodology – that is a characterization of what to do, how to do it, and why it is
necessary to do it…
• We’ll use an activity model [IDEF0 model] to help visualize and document the essence of that resulting
methodology  the roadmap to Lean
Highlights from the Toyota Production System [Wilson+…]
• Focus on quantity control to reduce cost by elimination of waste
• Built on a strong foundation of process and product quality
• Fully integrated
• Continually evolving
• Perpetuated by a culture that keeps the TPS viable
• Viable means that the culture ensures the PS survives and is responsible for
its own survival
• Cybernetics has more to say on the concept of system viability

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

This is the classic type of


graphic visual for how removing
wasteful inventory and extra
WIP exposes problems that can
then be attacked

Clear your field of vision, remove the Fog of uncertainty:


reduce inventory + [sort, set, shine, standardize, sustain]  reduced lead time  problems are more obvious  Attack

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

Eliminating Waste ( Muda )

First question the TPS asks is “What


does the customer want from this
process?” (both internal as well as
external customers).

This defines value.

Through the customer’s eyes, we


observe the process and separate the
value-added steps from the non-
value added steps.
Elimination of:
Other key facets of the TPS Muda (non-value-added)
Muri (overburdening people or equipment)
• Level out the workload (heijunka): Mura (unevenness)
• Demand uncertainty may lead to an uneven production schedule if one-piece-flow is followed literally.
• TPS realizes that strict build-to-order system will again build-up inventory and increase waste (Muda). As inventory is
removed - problems surface.
• TPS tries to even out the production by consolidating orders.
• Toyota achieves the combination of JIT and heijunka by following the principle of change-to-order (not build-to-order)
through delayed customization .
• Delayed customization - “Postponement or the delaying activities in the supply chain until customer orders are received with
the intention of customizing products, as opposed to performing those activities in anticipation of future orders.”
• Culture of stopping production to fix problems (jidoka):
• Traditional production view: “Do not shut down the assembly line!” TPS view: “If you are not shutting down the assembly
plant, it means that you have no problems.”
• Jidoka is also referred to as autonomation – equipment endowed with human intelligence to stop itself when it has a
problem. In-station quality is much more effective and less costly than inspecting and repairing quality problem after the
fact.
• Andon system:
• When the equipment shuts down because of a quality problem, flags or light, usually with accompanying music, signal that
help is needed to solve the problem. This signaling system is called the andon system.
• At Toyota, the andon is called a “fixed-position line stop system.”
• When a workstation in the assembly line signals a problem, the production line is not stopped immediately. The
manufacturing team has until the product moves to the next workstation to respond and address the problem, before the
andon turns red and stops the assembly line.
• If the problem is small enough that can be solved in the lead-time between two workstation, 100% quality is achieved
without stopping the line. If the problem is complex, the team leader can conclude that the line should stop.
• In TPS, the workstation detects the defects by using countermeasures and error-proofing ( poka-yoke ).
Jones and Womack [1990 The
Machine that Changed the
Lean v TPS – is there a difference? World] are generally credited
with coining the phrase “Lean
Manufacturing”

• “Lean Manufacturing” has become synonymous w TPS, but…


• Lonnie Wilson [pp.158-9] points out a couple of key distinctions
• The starting point – In 1955 Ohno already had a very sound and mature QC system in place.
Contrast that to Lean in 2015 – which makes explicit the need for quantity control AND quality
control.
• Cultural change and the subsequent Cultural environment and inertia to sustain – Ohno was
apparently very adept at this … “gains sustained”
• Necessity is the mother of invention – Ohno, commenting on the 65+ years of effort
that has become known as the TPS, identified what was needed “…out of
necessity”
• Not all Lean efforts are done to the level of TPS [more of a gold standard]
• In fact, a more common application of Lean is really mini-Lean:
• a production cell, with a pull system for production control, balanced at the Takt, flowing one-piece at a
time, with a system of Jidoka [visual signals and indicators of cell health]
• … closely approximating the scope for the Project this semester
AND… the TPS kicked off a revolution
• The genius was:
• Supplying VALUE to the customer
• Customer will buy it
• Adds form, fit, or function
• Reducing LEAD TIMES… [Little’s Law provides a guide for how]
• Production science tells us how
• Focusing on the absolute elimination of waste – especially inventory
• Most of the waste is not mathematical [Therbligs anyone?]
1. Over production
2. Waiting
3. Transportation NB: you often see an 8th form of waste listed
4. Overprocessing called “handling” – it really depends on the
5. Movement [a formal look at ergonomics can resolve these issues] scope you ascribe to the fusion of “movement”
and “transportation”. The list of 7 is directly
6. Inventory from Ohno (father of the TPS).
7. Making defective parts

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

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
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?

From the top…

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

. . .Creating System Function


Architectures
IDEF0
Function Modeling Method
Decisions, Actions, and Activities
What is an Activity 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.
Applications of Activity Modeling
• Document current activities for standardization
and provide guidelines for new activity users to
reduce the learning curve.
• Capture and analyze AS-IS activities.
• Design/Redesign activities for TO-BE scenarios.
• Project Planning TO-DO concensus.
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


Components
Context, Purpose, & Viewpoint
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.
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

Supplies & Equipment

Personnel Office Staff


Information System
Context

• Scopes the model and defines the boundaries.


• If the scope is too big, the model becomes too complex
and resource-intensive.
• If the scope is too small, the model becomes trivial.

Determining the context is


the most critical step in
Activity Modeling.
Purpose
• The purpose defines the reason to develop this
particular activity model.

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 Office Staff


Information System
Viewpoint
• The viewpoint describes the perspective of the
person or group developing the model.

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

all personnel a single type of


actions personnel action and
Personnel
accomplished by multiple activities
Officer
multiple activities

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

Inputs Function or Outputs


Activity
(Verb Phrase)

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.

Input Activity Output


(Verb Phrase)
Control
• Directs, guides, or initiates the activity. May also
combine in some way with input(s) to result in an
output.

Control

Input Activity Output


(Verb Phrase)
Mechanism
• Any resource (real object or system) used to
perform the activity.

Control

Input Activity Output


(Verb Phrase)

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.

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
Functional
Decomposition
Functional Decomposition
• Further defines an activity by dividing it into its
sub-activities.
• Ensures the gradual, systematic exposition of
detail required to understand and communicate
what activities are being performed.
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
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

A13 A43 A53 A31 Create Awards Package


A23 A33
A32 Arrange Ceremony

A44 A54 A33 Submit Paperwork


A24 A34 Insure Raise Action Completed

Node Tree Indented List

An activity is depicted only once in an activity model.


Diagram Numbering

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
( )
( )

( )

( )

( )

( )
( )
( )

 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” 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

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 .”
Some Basic Rules
• 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.
• Each activity box must have at least one control
and one output, but no more than six of each type
of concept.
• Every diagram in a model must adhere to the
model’s overall viewpoint, purpose, and context.
3b: IDEF0 model elements: Takeaways
• All finished diagrams other than the root (A-0) diagram must have no
less than 3 and no more than 6 activities.
• Avoid decomposition by “type”
• ICOMs support traceability from level to level in the model.
• Bundling and Tunneling reduce the clutter and improves the
readability of a diagram.
M3c:
IDEF0 model development
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

• 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, 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 Coincidental Random Random

Logical Functions o f the same set or type . Data of the same se t


1 (e.g., “edit all input”) or type.

2 Tempo ral Funtions o f the same time period. Data use d during a
(e.g., “initialize operations”) time period.

3 Procedural Functions o curring in same phase Data use d during same


or ite ration. (e .g., first pass of a phase or iteration.
compiler)

4 Comuunicational Functions that use the same data. Data acte d upo n by the
same activity.

Se que ntial Functions that perform sequential Data transfo rmed by


5 transfo rms o f the same data. sequential functions.

Functional Functions that combine to perform Data asso ciated with a


6 one function. 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.
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

• Lean Principle “Value” – establishing the VOC

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


• HW1 assignment has been uploaded and is due 7SEP
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

Anda mungkin juga menyukai