Lean notes 1 cr 15/10/08
Observation: A common American adage is ‗Don‘t fix it if it ain‘t broken.‘ (or ‗Leave well enough alone‘)
Lean and other continous-improv‘t systems take the opposite view, that it‘s always broken or to some extent broken or
at least less than ideally constituted.
To put in perspectiv though, in real (professional) life -- unless one‘s main job is to implement Lean, usually as far as
improvement efforts are concerned, improvement opportunities are of 2 kinds as it were: glaringly obvious, vs. hidden.
One usually only sees & is concerned with / could possibly get resources to address etc. the former - eg. the
couple of initiatives I was involved with at FDI. But this is actually NOT what Lean is all about -- Lean explicitly
says the thing is always broken, always room for improvement, and looking for improvt is Job # 1 (~ old Ford advert)
Also- remember Machiavelli : ... nothing more difficult to take in hand, more perilous .. more uncertain than
take the lead in introducing a new order. See more on motivation, pitfalls of change etc. esp #12 below
1. Lean watchwords:
- customer-focused strategy, unrelenting focus on generating cust. value
- being in business means to sell prods & srvs to customers
- value-creation is the name of the game
- customer is the only true arbiter of value
- philosophy & practice of continuous, incremental improvement
formula: simplify and/or eliminate, then automate and integrate
- producing exactly what‘s needed* at the right time* (* all flowing from meeting cust. demand)
- perpetual motion - in pursuit of value-added effectiveness
- finding & eliminating waste wherever possible
- waste is the exact opposite of value creation
- ‗go to gemba‘ = go to where the action actually is
- respecting people
- e.g. Lean org‘s are not hierarchical, they‘re flat, flexible str‘s along lines of value creation
Everyone is involved in these dynamic teams, everyone has something to contribute to the whole
See below for other insights on value of people in Lean org.
- long-term view. Lean is a journey, not an instant fix.
Lean is also not a 1-size-fits-all thing: each org. must find its own way, adapt what it needs, using the Lean
principles & tools discussed below
Lot of Lean taken from Japanese experience, esp. Toyota (TPS)
The culture of Lean:
- business activities are viewed as processes, in terms of creating cust. value, and absence of wasteful non-
- Value-Stream Maps communicate Lean perceptions and progress throughout the org.
Other Lean comms include:
- short, efficient team meetings at gemba
- concise process flow diagrams
- flexible comms centres
- graphical analyses, pictures of things key to value-creation/waste-elimination, visual -- signs & clues
- Kaizen events are mounted to brainstorm waste elimination, and effect improvements via PDCA (Plan-Do-
Check-Act -- see below)
- jidoka = quality is built in at source : defects are identified as soon as poss in the prod. chain, and immed.
sent back to the preceeding step, and the preceding step investigated with a view to immed & lasting correction
Based on exper. at FDI & other, and books Lean Thinking Womack & Jones, Lean Toolbox Bicheno & Holweg, Lean for
Dummies Sayer & Williams, Lean Software Development - Poppendieck(s). Numbering and sections here follow the .. Dummies
Re. value of people in Lean: Lean puts as much emphasis on the people in the org. as on the methods, tools, technques. The
process must engage everyone, continually educate, train them, challenge & empower them. Employees must be made to feel safe & secure
in weork envir & job situations. They must be stimulated, incentivised, celebrated & compensated. . . . People are highly valued in Lean org.
They are in fact more imp. than tools, methods etc. . . Co‘s that [are trying to do Lean and] have failed to recognised this have done so with
Conversely, once improvts effected/ waste eliminated / quality invested, Lean work settles down to routine,
standardised tasks & activities (within overall continuous improv‘t, continued Kaizen etc.--in fact stdised work=
baseline from which improvements are made)
- promote, encourage, enable continual improvement suggestions from all levels
- build long-lasting rel‘nships w team members, suppliers/srvc providers, customers
Also conversely, as cust. is the only true arbiter of value, same is true of quality - see eg. QFD nx sect./#7 below
Lean 'cousins' TQM 6σ Th.of Constr‘s TPM ISO 900x BPM
To these I would add VBM
2. Basic Lean concepts (and sub-concepts, tools)
- understanding, evaluating customer value
- Quality Function Deployment (QFD) - see below
- value stream
- Value-Stream Map - current state, identifying VA / NVA steps
- ideal state (hopefully with max. VA / min. NVA)
- Kaizen activities to close gap between the two
- takt time ~ ‗critical path‘ -- taken in terms of cust. demand & value (formal def
below) [maybe ‗critical path‘ is not a correct analogy for takt . . think about this ]
- flow of (intermediate/final)products/ services, value etc.
- production flow diagram
- pull of products/ services etc. thru system
- do not produce more than will be actually used/ needed
- implement kanban = signal to produce more when what has been produced starts to run low
- level scheduling practices keep system operating at steady, achievable pace (KIM keep it moving)
- simplicity is a watchword in all this (KISS..)
- striving for perfection
- approp. measurement systems for Lean
- traditional cost accounting is not Lean-aligned, since (in the Sayer‘s account) ―cost centres‖ are simply
brought into the accting equation, rather than being highlighted & subject to eliminative efforts
- rather, eg. schemes like Balanced Scorecard tracks many areas that may impinge on business health
people, delivery, safety, quality etc. are evaluated more/less from viewpoint of their final benefit or cost (VA
/ NVA) to the business‘ goals, product/srvc etc.
Muda, Mura, Muri
Muda = waste. 7 forms of waste:
Waiting Delay ‗TWODIME‘
Defect Correction/ repair/rejects
Extra processing * Overprocessing
Type-1 muda = NVA actions, but which are some other reason deemed nec. for the co.
(usually can‘t be elim. immed.)
Type-2 muda = NVA actions, and are not nec. (prime targets for elim.)
Mura = unevenness, lack of consistency
Muri = overdoing
build in quality at source (jidoka) is consistent with philosophy of gemba (observe process at source, so to speak),
also with process flow, building up volume from cust demand etc., and generally with push to simplify everything
* Lean Master Shigeo Shingo defined an 8th form of waste: underutilisation of people -- in the sense of waste
of human potential, to not allow people to contribute fully their talents, ideas, energy to the work environment
(... but then what of ‗TWODIME‘ ? . . )
Flow & Value Stream
3. VALUE (as seen via Cust.’s eyes . . )
Value defined. An activity is VA iff : [note-- these are STRICT criteria - see ex‘s below ]
- Cust must be willing to pay for the activity (ie. will pay for prod / srvc which is result of activity)
- Must transform prod/ srvc in some way
- Must be done correctly the first time
eg. VA when..
Examples of VA : - at carwash someone actually washes the car
- at hospital you‘re actually being treated
- on assembly line someone is actually putting parts together
eg. NVA steps:
examples of NVA : - carwash: take order move car cashier queue excess water cust. waiting lounge
- hospital: check-in waiting fill out forms inconclusive
tests hospital food
- factory: parts bins parts-travel machine setup
supervisors parts reject bin
Some of these and many like this may seem to be VA, but they are not -- such processes must be studied to see
how they can be eliminated or at least significantly mitigated
Understand who your cust. is
Understand who your cust. isn’t :
- not your co‘s execs
- not prod/proj/.. ‗stakeholders‘
Levels of cust. values :
- Kano modeling
Cust, value must be constantly, on-going evaluated -- cust‘s are always changing, today‘s wants become
tomorrow‘s needs etc. Basic techniques like VSM, QFD, hoshin, Bal.sc'card (#10 below) must each have their
periodic (as freq. as practical) review schedules
4. Value Stream Mapping (VSM)
[ high-level ‗macro‘ VS diagram in #3 - f3-4 -- comment on this .81 (and .113) ]
Ex. of Value Stream Map .73 (f4-1)
Remember, this diagram and all its elements are portraying a value stream and all its attributes, where:
value stream = flow of materials and information through a process to deliver a prod / srvc to cust.
Here‘s where quality comes in -- why of core importance in Lean
The important aspects of f4-1 are:
- individual symbols are explained .78
- sequence of boxes towards the bottom = actual work steps of the process (see attr‘s below)
- single-line arrows in top ½ of diagram = information flow (some of these kanbans?)
- task boxes (steps of the process) attr‘s :
- CT (or C/T ) cycle time = proper process time to do 1 unit
- C/O change-over time = Period required to prepare a device, machine, process, or system
for it to change from prod-ucing the last good piece of the last batch to producing the first
good piece of the new batch
or: The period required to change a workstation from a state of readiness for one operation
to a state of readiness for another
- Lot # pcs. per period (pd. .. ) – # pcs between C/Os or whatever
- Avail availability, stated in secs. - [I have to guess at this-couldn’t find defn of manuf.tool avail’ty:]
Is this = MTBF? Actually, I finally did find 1 def., for Uninterr.
Power Supplies: Avail = MTBF / (MTBF + MTTR)
(MeanTimeBetwFail, MeanTimeToRepair) mmm... not sure re. this
- Uptime atns
- "sawtooth" line at bottom :
- upper no‘s lead times (=NVA) = pre-/post-/in-
between processes times (eg. typically movement, transport)
- lower no‘s unit process times (=VA) = ~ C/T
also mentioned ( .75) is:
- box score = summary stmt of the key oper‘nal metrics of the process
I think Box Score in f4-1 = the 3 boxes in top ½, starting ‗Lead
Time...‘ ‗1 Shift/Day...‘ and ‘10,080 pcs/mth...‘
See also .84 f4-3 box score here = at lower right
[term comes from box score in sports events statistics summaries]
- takt time = formally: avail product‘n time / cust. demand
(~ pace of product‘n tied to cust consumption)
or semi-formally: total product‘n time per unit
note- | in f4-1 this = inventory symbol
(triangle in T4-1)
5. Charting the Course - Using VSMs
# 5 constructs and works with VSM & other sources to build up picture of what needs to be done.
Along this way we get :
Getting to the Current-State VSM, and moving towards Future-State
Questions, questions, questions :
- start with the customer-- always. Eg. what are the issues the cust. currently has?
Fishbone diagram, or Cause-effect diagr. or Ishikawa diag.
Def. (constr. of) fishbone diag:
sub-factors, attr‘s etc.
of main factor main factor
Each attr can have
own sub-factors, etc.
so this is recursive
E.g . 96 (at right, take out word "Late", this then becomes a "neutral" diagram of factors of cust. deliv., though
fishbone diagr. is usually used in sense of identifying factors contributing to sub-good performance...)
Using fishbone diagram:
5 Whys ie. to troubleshoot a problematic factor, just be like a kid and keep asking ‗Why‘ . . .
Then, after looking at ‗external‘ factors (from cust.), look next |"inside" at own org., processes etc. Build the
Current-State VSM. Ask any/all the questions on Pp. :
- 97 Muda
98 genl, ‗Sensei‘-type qns
Turning toward the Future
Once have a ‗critical mass‘ of questions + beginning to see answers, start to make 2 kinds of future-oriented VSM:
Ideal-State VSM a t n s. Except: Why look at this perfect view at all, in hard-nose real-life business?
Because this is the only way you can break free of current constraints, the only way to
really get ahead of competition etc.
- More grounded, more realistic view of what can be done with relatively small changes, focused plan etc
- Start marking up the Current-State VSM (or maybe mark up a copy of this). Use these as guide/signposts :
- bottleneck process process with max. C/T
- pacemaker operation = the single operation that produces to takt time. This op. sets the pace for ev-
erything else in the VS. This op (and only this op) gets the production schedule.
Upstream of p.m, production is only enough to replenish what p.m. needs
Downstream must produce in a continuous, uninterrupted flow out the door
(unless a ‘supermarket’ storage area is reqd for finished goods--see nx)
- supermarket In-process inventory needed where continuous flow cannot be realised.
(supermkt is tightly controlled inventory)
- st'dised work see above. Includes takt time.
- work module aggregated op‘ns fit into a compact area, which capable of performing all/almost
all work reqd t deliver VS‘s prod/srvc
- kanban signal to pull through (produce) the next lot of whatever which is only now reqd u/strm
- heijunka workload leveling/ product‘n smoothing = organise work scheds so there‘s little
variation fr day to day etc. Heijunka makes poss. continuous flow, kanban, min. inv.
[think re. heijunka for min.: if flow not smooth, the max. jags mean these bits are not optimal,
something is wrong/wasteful...]
A standard Future-State VSM markup is Kaizen burst, which indicates a planned change intervention into
As always the golden rule in any change environment, bite off at a time only as much as you/ org. are likely to
be able to chew - Lean is an iterative process: in the PDCA cycle, carry forward 1 or 2 changes, observe &
Kaizen is not itself a specific technique, rather a general approach, a philosophy -- see 118 - 9 for some
aspects of this
(Remember, ‗Kaizen‘ etymology: kai ~ change, zen ~ to see, or gain wisdom from doing )
The essence of Kaizen is continuous drive toward improvement, either:
- notice some area of improvement or fixing that could be done (eliminate muda)
- imagine something that could be a positive addition to the current regime
. 121, 123-4 :
Plan-Do-Check-Act -- the Lean operating framework for implementing Kaizen; the framework Lean project
methodology -- ie. this is how CHANGE is implemented :
[ The context of PDCA is standardised work -- procedures, routines etc. that are definitely in place in the current
system. St‘dised work, eg. is portrayed in the Current-State VSM.
How establish work st‘d‘n in first place? See SDCA .121 ]
Plan Identify change to be made (ie. break-out from the current standard -- notice prob. / imagine new ).
Create plan for effecting the change, define steps, predict results
Do Carry out the plan first in a trial/test mode, on small scale, under controlled conditions
Check Examine the results of the trial. Is the process/product etc. improved? By how much? If not, go
back, try again. If so, confirm it is worth expanding the new scenario
Act Implement the full change: Make this the new standard procedure
When required change is larger -- Kaikaku is the name for this
Kaizen workshop, or Kaizen event / Kaizen blitz
See .127 - 131 Kaizen event is a key way to target specific changes
In the following are a lot of specific graphical techniques. I notate these specific tools in a big table (on landscape
- format page) beginning on p. 7 below. Else I notate them immed following below.
To read this, maybe divide window in 2 etc..
7. Cust, VS Tools * * I'm going to subst. "technique" for "tool"
5 Ws and 1 H ( .143)
what when why where who how
Generally useful, either when proactively probing or problem solving
8. Flow, Pull Technqs
5S - move toward ‗the visual workplace‘
sort into 3 Rs: retain return (to where belongs) rid
straighten Find place for everything, and put it there
scrub Both literally - deep-clean all work areas. Also I‘m interp. this also as - remove all non-work
stuff from everywhere - eg. in software, keep a tidy house all thru there
systematize Now everything‘s been sorted-straightened-scrubd: put in systems & sched‘s to keep that way
standardize (from descr, seems similar to std'ize)
also, some have added a 6th S :
safety this is central to envir. in which people are respected
Note-- 5S applicable not just to shop floor, but all levels. See eg. .243 discusses 5S at Exec. level
10. Management Technqs
( . 191-2 good general overview of perspective, philosophy of Lean for mgmt. )
Hoshin (Balanced planning)
Hoshin is the Lean planning / policy dev‘t system of choice. ["hoshin kanri " means direction setting ]
in nutshell: hoshin = org. makes plans, then do regular std‘isd self-checking, self-analysis
Two pronged approach: - strategic planning, alignment (2-5 year plann horizon)
- everyday op‘ns fundamentals and ongoing mgmt & review attention
Also - everyone is in on the plans, everyone at all levels knows what‘s going on . .
Also cross-functional participation / buy-in
Hoshin planning = 7 step process :
- Identify the key bus. issues of the org.
- Estab. measurable bus. objectives which address the key issues
- Define overall vision & goals
- Develop goal-supporting strategies
- Develop tactics & objectives that facilitate each strategy; designate an owner for each strategy
- Implement performance measures for every bus. process
- Measure bus. fundamentals (bus. fund. = the basic elts that define the success of a key bus. process,
eg. safety, people, quality, responsiveness, cost )
Hoshin review-- Hoshin reports (‗tables‘)
Hoshin table - structure:
Header author, scope of plan
Situation meaning of planned items
Objective (what is to be achieved)
Milestones on road to objective
Strategies how obj‘vs are achieved
Measures to check the strategies are being achieved
The different hoshin tables are :
Hoshin review table Plan of a single objective & its strategies
Strategy implem. table For each strategy, display of the status of strategy, in terms of:
- the tactics implementing the strategy
- the people involved in each tactic, and their exact responsibilities
- timeline of each tactic -- usually presented as a Gantt Chart
- perfor‘ce measures
- review how & when for the implem plans
Bus. fundamentals table Monitor BFs* via their corresp. Metrics (* see BF defin. above)
Annual planning table Master record of org‘s objectives & strategies.
(APT) APT is passed down to each success‘v next org. level, w. each level providing its
supporting plan to support the overall plan
Advice: Diff orgs have been successful in using Issues Teams or Mgmt Quality teams: these are headed by
the functional mgrs or senior leaders closest to each partic. issue
Observation: The levelled APT looks like what has been used at couple of my recent orgs, e.g.
- FDI PMO appeared to have pgmme Master Timelines/Scope sheet, under which were the more
detail level project plans and release plans etc. Administered via Clarity
- VFI used Clarity again I think to link our proj plans to higher level reporting etc.
Use of hoshin plan, Annual review
Std. ~ about a year senior mgmt. granularity
Remember this master plan has levelled depth, and participation both within and between functional bus. units
- For those objetcvs successfully completed -- Analyse to see what went right; see if supporting strategies &
perform‘ce measures were effectv. Also note any exceptional results & their background :
Reviews are critical to capturing knowledge of how to achieve and exceed goals, and lodging this kn. in the org.
This kn. (not just the good results) is highlighted to the org.
- For those objetcvs not attained -- get to the reasons for the deviation, detailed examination of supporting
data of all assoc. strategies etc.
Strategy owners should identify what their teams would have changed to have been more successful: this
learning can then be incorporated into future hoshin. This learning is also highlighted.
[CS: In the latter case of learning - sometimes learning from painful errs, this really points up fact this must be an
―egoless‖ org: players at all levels must be encouraged that the truth is more important than anything else, that
part of their value to the org. is upholding the truth. See footnote 1 for this picture of where people sit in Lean org.
see also eg. gemba walk below.
(Actually, little pgh top p.244 is v. good observation on non-Lean behav. at Exec. level) ]
Review is conducted at all levels of org., at end of which reach consensus for new planning etc.
See p. 196 - 7 for more bumf on hoshin review.
Balanced scorecard see f10-1 . 198
4 major components: ---------------------------- rationale ---------------------------------
category To: answer this question:
- financial (of course) succeed financially . . . how should we appear to shareholders?
- customer achieve co. vision . . . how should we appear to customers?
- process satisfy cust‘s & shareholders . . what bus. processes must be excellent?
- learning, growth achieve co. vision . . . how sustain ability to change & improve?
Develop metrics in each these areas. General focus on same underlying principles as Lean:
- Customer focus, in partic. cust defines quality
- Measurements & controls - structured approach
- Quality implemented at source
- Continuous improvement
- Engagement, empowerment, devel‘t of all workers & mgmt
Part of the ―balance‖ of bal. sc'card is equal focus on strategic/vision/etc. and operational/int. processes,
thus a natural tool for Lean (interestingly bal. sc'card invented early 90‘s, maybe ~same time as Lean
See more in my KN stuff on Bal. sc'card (.doc actually in D:\#### ALL ## STUFF ## FROM ## RM ## MACHINE
####\C\New HUNT\ALL.zip\COMMUNICATIONS1\Req 479142(SCCons).doc)
Management Dashboards (f10-2 . 200)
(this idea derived fr the old EIS Exec Info. systems of 80s )
also called Bus Activity Monitoring (BAM)
I of course know all about dashboards . . . .
See . 200 - 1 for more details
Spider charts (Radar chts.) (f10-3,4 . 202-3)
- simple graphical idea -- see .202-3
'Go and see' - Gemba rules OK
Genchi genbutsu Go to the actual scene (genchi) and confirm the actual happenings or things (genbutsu)
(ex‘s given: - Colin Powell‘s visit to wrecked areas of Asian tsunami in 2005 ==> changed US aid to
other(my ex‘s) - Pres. Bush‘s visit (finally) to New Orleans after the floods in 2005 ==> finally aid started
pour into New Or.
- visits of various scientific and gov. officials after the Hiroshima atomic bombing ==> world
started to see the awfulness of these weapons... )
= structured ‗management by walking around‘
How a gemba walk is done :
- focus on a single item or theme, eg. safety or housekeeping (first 3 of 5Ss)
- (CS:) Do plan these with subject staff (at least reasonably warn them ahead of the walk, advise what you‘re
focusing on . .)
Other points of gemba walk .205, eg.
- build relationships w the org, break down barriers to change
- train others to observe = good educational method
- review A3s, team perfrm‘ce, andons etc.
- tie observed perfm‘ce metric to the hoshin plan etc.
Over & above specific objectives of a given walk, the overall benefit of these is building rapport among whole org.,
breaking doen barriers to chg(as obs. above), even turning around initally competitive motivations, tendencies
toward isolation/‖empire building‖ etc, towards much more cooperative, synergistic envir., empowered at all
Walks should over time cover the entire org, inside & out. The various walk ‗themes‘ should be planned,
catalogued, reviewed etc.
Covered on .206 - 8. The only thing Ill comment on here is -- stmt that: Bus Proc Mgmt (BPM) = enterprise-
level integration of bus (cross-)functional lines, and other enterpr. Systems ERP, MRP, CRM etc. is ―a key
enabler of the Lean enterprise of the future.‖
"tool", tech'q area usage
7. Cust, VS technqs.
Quality Function User requirements transition From VOC(voice of cust.) assemble User requirements; take
Deployment toward process these & translate into succesive* info. other parts of org can use
* prod design proc. design proc controls
Each stage above is a matrix of What v. How : matrix entries =
What / How matrix strength of W-H reln in each case
Kano modeling Cust. satisfaction Rate ‗satisfiers‘ along needs, wants, delighters
Benchmarking Competition evaluation Along diff params, rate yourself against competition inc. best-in-
world; identify gaps; take steps (Kaizen etc.) to close gaps
VSM quantities Using the VSM takt time, box score, lead time :
focus on these, look for opportunities to reduce
Spaghetti diagram Traffic flow analysis (this is one of the gemba exercises..) see
7 qualitative tools (estab. Jap.Union ofSci’tsts&Eng.) : [also see mindworks, also Sayer-recommended
Relations diagram Show the Relations building out from a - usually used to get to bottom of an Issue (=the central concept)
Affinity diagram Thematic grouping Often used in barinstorming sessions, to organise deluge of o'wise
Tree diagr. = Whole into parts typical = WBS
Matrix diagr. x-ref two lists (not exactly sure why this here - a matrix is a very generalised tool,
used everywhere [maybe that‘s exactly why here..] )
Ex. is Wh /How matrix above
Matrix Data Anal chart compare mult. items v. mult. eg. sales volume v. cust.satisf., or material perf 'ce v. cost
(MDAC can be hard to do - often
replaced with Prioritisation mx.
"tool", tech'q area usage
Process Decision Risk analysis = a left-to-right going tree diagram: for each activity(tree node)
Progress chart (PDPC) ident poss risks & their mitigations -- ideally, this display reveals
how mitigations will counter risks.
Great for seeing risk in new entities (new products, facilities, lines
of bus. etc)
Activity Network (aka. activity mapping display activity attr‘s eg. timing, critical path, dependency.
PERT cht.) Q: How differ fr. Gantt Cht?
A3 cht. Issue docu‘n 1-pg report of an issue + resolution plan
8. Flow and Pull
Group technology product/production commonalities Product family = members contain close similarities &/or
production process steps
Work cells ('WC') These naturally arise from group tech. analysis
Monuments blockage to flow This is a seemingly unavoidable fixed resource which is not
optimally placed. Sayer offers some "workarounds" etc.
Load balancing /
POUS (point-of-use comment on .158: POUS is really corollary of 5S
the WC etc.
Visual work areas "Ah, I see what's happening now" [CS: I would also say visualisation is a central concept in Lean,
applied to mgmt below(see), also this is what POUS, WCs, 5S,
also gemba etc. all lead up to ]
Set based development [this definitely related to Lean - similar basis as group tech, ]
See last 6 pages below for further SBD details
Quality at source:
Source inspection = review work before pass onto next note- inspection is deemed a form of muda . . .
Progressive = work is reviewed at beginning of
inspection next stage
Poka-yoke = error-proofing Physically preventing
"tool", tech'q area usage
Equip't maintenance etc
Quick-change (SMED) SMED = single-minute exchange of die
Plann. for every part
Kanban and MRP
9. 'Perfection' technqs.
Standardised work = the foundation for improvement
Rules for std'zd work - Adjust to human ease & effectv ness,
not machine efficiency
- Repetitiv work - std'ze
- Equipt, systems-keep in condtn
- Std'zd worksheets - keep visible &
- Revise regularly
Implementing std'zd work
Focus on Time take measurements - cycle time v. takt
time: What‘s the gap?
Check WIP = minimise (WIP) is inv. muda
"tool", tech'q area usage
Publish stds. Once you‘ve stabilised equipt, process & inv. 0061nd set the
operating procs in published std, std‘sd work can now begin.
Set on top of std‘sd work are the following :
Monitor, measure, Goal is now to maintain std‘sd work level, as a steady background
manage against which :
Adjust & update Use Kaizen & other techn. to do improvts etc.
Visual management tools ‗Manage by eye‘
Cartoons ‗Lean co‘s often use simple cartoon drawings throughout docs,
meetings, facilities, oper‘ns
Andon a signal of imp. or failure info. effectively, an at-gemba RAG
Display board vital co. operating info. Ex‘s - see f9-1 .176
Cross-training cht. ~ skills matrix
Pictogram ~ see where problems are occurring eg. police ‗murder map‘
7 basic tools of quality :
Fishbone diagram tracing causes back (see above)
Pareto cht. see max/min contributors to a situation = simple graph(usually bar gph) of values sorted in
Check sheets any std. way as-it‘s-happening eg. f9-5
process info is gatherd & displayed
Scatter plots simple plot of hits against 2 scales - eg. f9-6
Bar chart . . .
Histogram frequency of occurrence
Control cht. display of some value or process over Control chart is considered the single most imp tool of statistical
time quality control.
See eg. f9-10
The Lean Enterprise
I sort of skimmed & scanned through this whole part. Some observations I slotted-in above (pg refs > p.200)
Other misc. obs‘ns :
12 Power to the People talks about motivation, the problems of introducing change etc.
Firstly, again remember Machiavelli : ... there is nothing more difficult to take in hand, more perilous to conduct
or more uncertain in its success than to take the lead in the introduction of a new order. The Prince Ch.6
[note- this is followed by: The innovator makes enemies of all those who prospered under the old order, while only lukewarm support
is forthcoming from those who think they might benefit under the new—partly from fear of their adversaries, who have the existing regime and
law on their side, and partly because men are incredulous, never really trusting new things unless they have tested them by experience.
- ‗Communications in action‘ .240 gives a pretty good Lean flavour of a worked example of an initial project step
- Lean principles applied to management . 243
13 Go Lean: Implem Strategy... gives strategies for implementing Lean <--- pretty good, come back to this
at some point
14 Lean in the Enterprise gives other areas - not just heavy manufacturing - where Lean can rule :
- ie. service industries, eg. finance & accting, contracts, procurement, legal, HR, IT
Typical wasteage in these includes:
= role in Lean org. - resp. for end-to-end Lean improv‘ts & maint. of 1 or more VSs
Lean in the Support fns . 273 - 7
This sect. basically says Lean can – and should – be applied across the board, to:
- finance & admin.
- travel, copy ctr, mail room
Lean in IT . 276 - 7
- IT has been anything BUT Lean "in nearly every sense" (-- the great un-Lean) :
- rife w. NVA work
- lots of nonstandard work
- the home of batch processing
- redundant processing
- push flow
and above all :
- major disconnect from customers and consumers.
Summarise potential areas of IT improvement :
- Customer focus ―For over 25 years the users have been too disjointed and too disconnected from
IT. Of all the clasic rifts that have divided the enterprise, this ranks near the top.‖
Lean however has the methods & tools etc. to bridge this gap. blahh
- Reducing NVA activity Streamline all IT proc, elim. Outdated processes, paper reports, multiple handling
of info etc.
- Single piece flow This actually is a plus for IT: etc Build on this.
- Cust. pull Give tentative in observing we‘re now ~ at the point of being able to supply
customised indiv. needs. ―Info can now be processed and delivered at the rate of
- End of batching JFGROI .
In this transition from red to black above, there‘s lots of potential now for IT to walk out of its traditional place as
Lean Product Devel. . 277 - 87
More presure than ever to bring ―innovative, high-quality prods & srvs to mkt rapidly.‖
- checklist of current ProdDev bugbears . 278
- (long..) list of Lean techniques that can now be brought to bear on ProdDev t14-1 .278-9
This section goes on, in terms of (sect. headings):
Prod Devel: The systems approach
Hearing the VOC
Front-loading the engineering process
Genchi genbutsu: Go and see
Finally- A few words about software development = more tips, pointers for that rabble of wild cowboys :
- Avoid bloatware Apply Pareto‘s Law (80/20 rule)
- Need for speed Trade in any NVA models you may have for sleek VA-only.
Go for sw that is modular, flexible, extendible; teams that are small, fast, focusd
- "Agilability" JIT software is the goal
- Hear the customer, hear the customer's customer
- Continuous, incremental deliv.
- Stds & practices
- Visual feedback Visual status, reporting, metrics, controls [not to mention screen mockups, data
This list seems to be pretty well ~ Agile, XP, even iterative/spiral models.
J F get rid of it
Also ~ CMM
Lean Supplier Mgmt.
~ Similar treatment to Lean Prod Mgmt -- JFDI see . 287 - 90
Lean Production Proc.
This is where Lean started, got much of its vocab etc. KEEP DOING IT . 290 - 1
Lean Customer Mgt.
Yup again. . 292 - 3
Lean and the Quality org.
Lean properly applied, can result be otherwise? .294
15 Lean across Industry Final summary of Lean atns 295 - 312
Part of Tens
16 Ten best practices of Lean arranged in the following in a KWIC (or KWOC ) list
Customer Feel the Force (of the . . . )
Long term-ism Step by step, inch by inch
Value Stream Follow the ..
Breadth approach - methods Eat your vegetables [dont just cheery-pick Lean things you like..]
Breadth approach - attention Turn over a rock [apply Lean thruout org., at all levels]
People First! Always!!
Genchi Gambutsu Go and see
Art of Simplicity (say no more)
At a Glance high sensory, visual env. Even outsider should understand the status
17 Ten Pitfalls to avoid (can you guess the meaning of these headings?)
Same-old Same-old Sr. Mgmt
Cherry picking (see Breadth - methods abuv)
Beans are beans Lean journey may take little while to hit bottom line
Shell game Don‘t just move the muda somewhere else(ie.some other Dept.) - don‘t sweep
under carpet (or out to driveway--it's still on your turf)
Grease monkeys (read this section to find out the cryptic clue)
Stuck in the middle again " " " "
Lean Six Sigma
Keyword out of context (my TLA)
Japanese terms & other ‗tech.‘ terms part of Lean culture : [note- this is the 1st thing I wrote when starting
to get into Lean -- some / most of this may now be superseded by the 14 new pgs of notes above]
andon board visual mgmt technique
gemba place where activities are actually happening
eg. actual observance of a process (preferably by an ‗external‘ impartial observer)
jidoka quality is built in at source
kaizen continuous improvement
kanban pull signal - replenishment trigger
Kano model the 3-layer representation of cust. reqts, in terms of Needs Wants Delighters
Basically- fulfilling Needs merely* reaches level of neither satisfied nor dissatisfied,
want-fulfilment is a linear relationship to cust satisfaction,
and fulfilling cust. Delighters is an exponential** relationship to satisfaction
* asymptotic relationship of fulfilling need to cust satisfaction
** expon. is math opposite to asymptotic
type-1 muda actions that are non-value-added, but are for some other reason deemed necessary for the co.
type-2 muda actions that are non-value-added, and are also unnecessary for the co.
the 7 forms of waste: transport waiting overproduction defect inventory motion extra processing
poka-yoke physical prevention of process mistakes
eg. different size pumps at filling stn., to prevent wrong fuelling
takt time actual total production time to produce 1 unit of product/supply
defined as: Available Production Time / Cust. Demand (eg. figs quoted per day)
eg. 1 lot of salads delivered daily to local groceries ~ 3 hrs. prod. time (=10800 secs.)
cust demand = 200 salads per day. Takt time = 10800 / 200 = 54 secs.
Set-based x (where x = development / design / thinking etc.)
Prelim: Comment from Wikip article on Lean Sw devel 1.pre
targetedconvergence: SBT 1.tg-sb
Targeted Convergence 1.tg
Wikip: Th of Constr. 2.wik-
Lean Product Development 5.LPD
SB concurr. Eng. 6.SBD
LfD - Th of Constr. 6.lfd-toc
Conclusion - What SB seems to be about 6.conc
I‘ve tried to find articles, notes etc. on set-based x. What I‘ve found is :
In Wikip article on Lean Sw devel (section: Amplify learning), mention: ―Another idea in the communication and
learning process with a Customer is set-based development – this concentrates on communicating the
constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via dialog
with the Customer.
In article http://www.targetedconvergence.com/setbasedthinking.html the following :
In a nutshell, Set-Based Thinking™ is the shift from developing and testing the design for a particular project to
testing, learning, and considering a larger set of possible designs. Rather than only thinking about the specific
specifications that the development project needs to satisfy, you think deeply about the ranges of reasonable
values around those specified. By investing in that learning up front (when development is relatively inexpensive),
you buy your organization flexibility that pays off big later when development is relatively expensive.
Furthermore, by learning that set and capturing it properly so that you can use that knowledge later in the project,
you can also use that knowledge in the next project. In that way, your organization will only need to learn a
particular set once and will be able to use that Set-Based Knowledge in every project that follows. Toyota is able
to produce superior designs in a fraction of the time as their competitors because they've effectively been
developing the Camry for 50 years.
We have developed sophisticated tools and methods to help engineers map out and capture their Set-Based
Knowledge such that it will be reusable. We have incorporated the essential elements of Learning-First Product
Development, such as the LAMDA learning cycle and A3 thinking, to form practical approaches that you can
apply immediately for Set-Based Problem Solving and Set-Based Trade-Off Analysis.
We offer a set of Workshops to fully teach Set-Based Thinking™; and a sophisicatedSoftware solution to take
what was learned to the next level. Our software is not necessary to implement what you are taught in our
training; but we do believe the value added by the software will make it a compelling choice to all graduates of the
Set-Based Thinking™ workshops.
After some time of building up its Set-Based Knowledge, your team will be able to move to the next level of
capability, Targeted Convergence™, allowing them to fully leverage that knowledge into their product
designs (and the end of specifications as you know them).
Targeted Convergence :
After some time practicing Set-Based Thinking™ techniques, you will have built up a powerful body of Set-
Based Knowledge that can be leveraged in future designs. With that in place, your team will be able to learn
Targeted Convergence™ techniques that help apply the full value of that knowledge to your designs.
With Targeted Convergence™, you stop building to specifications; in fact, the specs emerge along with the
design, based on your learning about your customers, your products, and the technologies your products are
based upon. Replacing specs at the beginning of projects are targets: targets express sets or ranges of customer
interests that you want the product to end up within, though you may not yet be sure what is possible or
That lack of knowledge about what's possible given today's technology, what's compatible within a single product
design, and what are the most desirable trade-offs to your customers, we call "Knowledge Gaps". The first step in
planning out a development project will be indentifying those Knowlege Gaps (Knowledge Gap Analysis™) so
that you can make plans to fill those gaps; and so that your design efforts can proceed forward, leaving open sets
of possibilities until those gaps are filled.
The development process is thus transformed into a process of convergence from all that you know is possible
and compatible, to the particular design decisions and specifications for a specific product that best satisfy those
targets that were laid out at the start of the project.
Note that learning has become central to the process. The process starts with what you know from past projects,
identifies what you need to learn first, and then proceeds only as you learn what you need to know to make
decisions. And with Set-Based Thinking™ techniques as a foundation, all of that learning will be captured for the
benefit of all future projects, resulting in a steep and steady increase in product development
performance. Learning-First Product Development! (Its no wonder Toyota is outperforming the next five
most profitable car makers combined.)
TCC offers the same pair of services for Targeted Convergence that we did with Set-Based Thinking™: a
semester-long experiential training course and a software solutionto elevate that capability to its fullest.
Note that it is not necessary for your whole company to move to Targeted Convergence™ in unison. Rather, each
team, as they have built up sufficient Set-Based Knowledge, will be able to take the next step to Targeted
Convergence™ at their own pace. And significant incremental value will be delivered with each additional team
that moves to that.
Finally, the Wikipedia article on Theory of Constraints :
1. Basic principles of TOC
The principles are treated as axioms. Goldratt provides, some indication on why he chose these as basic
assumptions or principles upon which to base TOC. The first two are a derivation of Newton's words: natura valde
simplex est et sibi consona (nature is exceedingly simple and conformable to herself), while the third is a bridge
on how to deal with human reactions and motivations.
he first principle: Convergence, also called "Inherent Simplicity" states that "The more complex a system is to
describe, the simpler it is to manage." Or that the more interconnected a system is the fewer degrees of freedom
it has, and consequently the fewer points must be touched (managed) to impact the whole system. A corollary of
this principle is that every organization has at least one constraint active in any given point of time (otherwise it
would achieve infinite performance relative to its goal). The more complex and interconnected the organization is
the fewer constraints it will have.
The second principle: Consistency, also called "There are No Conflicts in Nature" states that "If two
interpretations of a natural phenomenon are in conflict, one or possibly both must be wrong". That is, when in an
organization with a common goal, two parts are in conflict (or in a dilemma) this means that the reasoning that led
to the conflict must contain at least one flawed assumption.
The third principle: Respect, also called "People are not Stupid" states that "Even when people do things that
seem stupid they have a reason for that behavior". In other words, this principle is stating that people are not
2. Basic processes
2.1 The five focusing steps
Theory of Constraints is based on the premise that the rate of goal achievement is limited by at least one
constraining process. Only by increasing throughput (flow) at the bottleneck process can overall throughput be
increased. The five focusing steps aim to ensure ongoing improvement efforts are centered around the
Assuming the goal of the organization has been articulated (e.g., "Make money now and in the future") the steps
1. Identify the constraint (the resource/policy that prevents the organization from obtaining more of the goal)
2. Decide how to exploit the constraint (make sure the constraint's time is not wasted doing things that it should
3. Subordinate all other processes to the above decision (align the whole system/organization to support the
decision made above)
4. Elevate the constraint (if required/possible, permanently increase capacity of the constraint; "buy more")
5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the
The focusing steps, or this Process of Ongoing Improvement has been applied to Manufacturing, Project
Management, Supply Chain / Distribution generated specific solutions. Other tools (mainly the TP) also led to
TOC applications in the fields of Marketing and Sales, and Finance. The solution as applied to each of these
areas are listed below.
Within manufacturing operations and operations management, the solution seeks to pull materials through the
system, rather than push them into the system. The primary methodology use is Drum-Buffer-Rope (DBR), and
a variation called Simplified Drum-Buffer-Rope (S-DBR).
Drum-Buffer-Rope is a manufacturing execution methodology, named for its three components. The drum is the
physical constraint of the plant: the work center or machine or operation that limits the ability of the entire system
to produce more. The rest of the plant follows the beat of the drum. They make sure the drum has work and that
anything the drum has processed does not get wasted. 
The buffer protects the drum, so that it always has work flowing to it. Buffers in DBR have time as their unit of
measure, rather than quantity of material. This makes the priority system operate strictly based on the time an
order is expected to be at the buffered operation. Traditional DBR usually calls for buffers at several points in the
system: the constraint, synchronization points and at shipping. S-DBR requires only a single buffer at
The rope is the work release mechanism for the plant. Only at "buffer time" before an order is due does it get
released into the plant. Pulling work into the system earlier than a buffer time guarantees high work-in-process
and slows down the entire system.
3.2 Plant types
There are four primary types of plants in the TOC lexicon. Draw the flow of material from the bottom of a page to
the top, and you get the four types. They specify the general flow of materials through a system, and they provide
some hints about where to look for typical problems. The four types can be combined in many ways in larger
I-Plant: Material flows in a sequence, such as in an assembly line. The primary work is done in a straight
sequence of events (one-to-one). The constraint is the slowest operation.
A-Plant: The general flow of material is many-to-one, such as in a plant where many sub-assemblies
converge for a final assembly. The primary problem in A-plants is in synchronizing the converging lines so
that each supplies the final assembly point at the right time.
V-Plant: The general flow of material is one-to-many, such as a plant that takes one raw material and can
make many final products. Classic examples are meat rendering plants or a steel manufacturer. The primary
problem in V-plants is "robbing" where one operation (A) immediately after a diverging point "steals" materials
meant for the other operation (B). Once the material has been processed by A, it cannot come back and be
run through B without significant rework.
T-Plant: The general flow is that of an I-Plant (or has multiple lines), which then splits into many
assemblies (many-to-many). Most manufactured parts are used in multiple assemblies and nearly all
assemblies use multiple parts. Customized devices, such as computers, are good examples. T-plants suffer
from both synchronization problems of A-plants (parts aren't all available for an assembly) and the robbing
problems of V-plants (one assembly steals parts that could have been used in another).
3.3 Supply chain / logistics
The solution for supply chain is to move to a replenishment to consumption model, rather than a forecast model.
TOC-VMI (vendor managed inventory)
There was a Wikip editorial note here that this section could do with some expansion . .
3.4 Finance and accounting
The solution for finance and accounting is to apply holistic thinking to the finance application. This has been
termed throughput accounting. Throughput accounting suggests that one examine the impact of investments
and operational changes in terms of the impact on the throughput of the business. It is an alternative to cost
The primary measures for a TOC view of finance and accounting are: Throughput (T), Operating Expense (OE)
and Investment (I). Throughput is calculated from Sales (S) - Totally Variable Cost (TVC). Totally Variable Cost
usually considers the cost of raw materials that go into creating the item sold.
3.5 Project management
Critical Chain Project Management is utilized in this area. Based on the realization that all projects look like A-
plants: all operations must converge to a final deliverable. As such, synchronization of activities is a common
problem that CCPM seeks to address
3.6 Marketing and sales
While originally focused on manufacturing and logistics, TOC has expanded lately into sales management and
marketing. Its role is explicitly acknowledged in the field of sales process engineering. For effective sales
management one can apply Drum Buffer Rope to the sales process similar to the way it is applied to operations
(see Reengineering the Sales Process book reference below). This technique is appropriate when your constraint
is in the sales process itself or you just want an effective sales management technique and includes the topics
of funnel management and conversion rates. citation needed
4. The TOC thinking processes
Main article: Thinking Processes (Theory of Constraints)
The Thinking Processes are a set of tools to help managers walk through the steps of initiating and
implementing a project. When used in a logical flow, the Thinking Processes help walk through a buy-in process:
1. Gain agreement on the problem
2. Gain agreement on the direction for a solution
3. Gain agreement that the solution solves the problem
4. Agree to overcome any potential negative ramifications
5. Agree to overcome any obstacles to implementation
TOC practitioners sometimes refer to these in the negative as working through layers of resistance to a change.
5. Development and practice
TOC was initiated by Dr. Eliyahu M. Goldratt, being still the main driving force behind the development and
practice of TOC. There is a network of individuals and small companies loosely coupled as practitioners around
the world. TOC is sometimes referred to as "Constraint Management". TOC is a large body of knowledge with a
strong guiding philosophy of growth.
The TOC has a group of adherents who believe that its applicability goes much beyond its origin of factory
scheduling. Regardless of how valid this belief might be, the TOC is not part of the mainstream curriculum in
business or Operations Research programs.
Criticisms that have been levelled against TOC include:
6.1 Effectiveness of Drum-Buffer-Rope
While TOC has been compared favorably to linear programming techniques , D. Trietsch from University of
Auckland argues that DBR methodology is inferior to competing methodologies. 
6.2 Unacknowledged debt
Duncan (as cited by Steyn)  says that TOC borrows heavily from systems dynamics developed
by Forrester in the 1950s and from statistical process control which dates back to World War II. And Noreen
Smith and Mackey, in their independent report on TOC, point out that several key concepts in TOC "have been
topics in management accounting textbooks for decades." 
People claim citation needed Goldratt's books fail to acknowledge that TOC borrows from more than 40 years of
previous Management Science research and practice, particularly from PERT/CPM and JIT. A rebuttal to these
criticisms is offered in Goldratt's "What is the Theory of Constraints and How Should it be Implemented?", and in
his audio program, "Beyond The Goal". In these, Goldratt discusses the history of disciplinary sciences, compares
the strengths and weaknesses of the various disciplines, and acknowledges the sources of information and
inspiration for the Thinking Processes and Critical Chain methodologies.
7. See also
Liebig's law of the minimum
List of Theory of Constraints topics
Systems thinking — Critical systems thinking — Joint decision traps
Twelve leverage points by Donella Meadows
Quantum Improvement Method
Article differentiating TDS(Toyota Dev Sys) set-based dev (and a couple of other seemingly very fine dist.) :
= http://leansoftwareengineering.com/2007/12/20/what-is-lean-product-development/ (article by
What is Lean Product Development?
[pgh1] Michael Kennedy did his readers a real service by calling his excellent book Product Development for the
Lean Enterprise instead of the more obvious Lean Product Development. In that book, Kennedy describes the
set-based principles of the Toyota Development System, and how they may be applied to any product
development business. TDS is a fascinating system, equally as innovative and interesting as the Toyota
Production System, but also very different in the mechanism of its operation.
 On the other hand, my own journey down the road of lean development started with Donald
Reinertsen‘s Managing the Design Factory. Don‘s description of Lean Product Development is more like the
application of lean production principles to product development, breaking the work into small pieces, managing
capacity, measuring flow, and delivering value incrementally. It is this view of lean that my friend David Anderson
expounded upon in his book Agile Management for Software Engineering.
 The difference between TDS and TPS creates a lot of confusion in discussions about Lean Product Develop‘t.
Does LPD mean product development targeted to lean production systems? Or does it mean the principles of
lean production applied to product development? These two definitions have very different consequences.
 If it wasn‘t already clear, I am decidedly in the camp of lean production principles applied to product
development workflows. Even though I think TDS is ingenious, and I wholeheartedly endorse set-based thinking, I
do not consider TDS to be Lean Product Development. To me, lean development is a means to an end. That end
is evolutionary design, and lean production fits that end in a way that set-based development does not. Which is
not to say that there is not a strong evolutionary interpretation of SBD, as large-scale open source development is
exactly that. But I‘m not really speaking to the open source audience here. I expect my readers are largely of the
enterprise variety, building products or IT systems to spec and for hire. And evolution with such finite resources
 Observant readers have probably noticed that I don‘t talk much about Mary and Tom Poppendieck here. I feel
a little bit bad about that, because I think they deserve credit and respect. I think they have done the software
profession a tremendous service by popularizing the relevance of lean principles to software development. But
they have also done a couple of things that bother me, including blurring the definition between set-based, time-
boxed methods like TDS and continuous workflow methods like TPS. The consequence of this is that people can
(and do) weasel out of lean principles by hiding behind the weakest interpretation. By conflating these definitions,
the Poppendiecks, perhaps unwittingly, encourage their readers to claim to be lean while avoiding actually doing
it. One of the greatest offenses I see again and again is the rationalization of ―craftsmanship‖ under the auspices
In contrast, Womack and Jones (and Roos) were not at all ambiguous about what is Lean and what is not. Jim
Womack, who coined the expression, ―lean production,‖ to describe the principles behind the Toyota Production
System, explicitly defined lean production as neither craft production nor mass production. Not craft production is
part of the definition of lean, and he dedicates whole chapters in his books to why craft production is inferior:
Our advice to any company practising ―craftsmanship‖ of this sort in any manufacturing activity,
automotive or otherwise, is simple and emphatic: Stamp it out.
- The Machine that Changed the World, The Strange Case of the ―Craft‖ Producers
Now, I realize that development is not manufacturing. But using that as an excuse to rationalize craft methods is
overwhelmingly contrary to philosophy of lean. I am not saying that you shouldn‘t practice craft development if
that‘s what you want to do. But claiming that it is lean to do so is either ignorant or outrageously dishonest.
Standard Work is not an optional practice. Craftsmanship means doing it your way, Standard Work means doing
it our way. If you‘re not doing Standard Work, you‘re not doing Lean. Period.
There is a series of blog comments following this: see the actual article (cited above)
~ ~ ~ ~ ~
Some comments on above:
on the one hand.. pgh on the other.. pgh
TDS SB / TB 1,4 TPS L[P]D 4
evolutionary, continuous workflow 4
Abbrev’s: application of LP to product devel = break work 2
TDS Toyota Devel. Sys to small pieces, manage capacity, measure flow
TPS " Produc‘n " deliver value incrementally
LPD Lean Product Devel. Don Reinertsen(Mnging the Design Factory), 2
LD " "
David Anderson (Agile Mgmt for Sw Dev),
LP " Produc‘n
SB set-based (and Ladas himself)
All in all, I‘m not quite sure what Ladas‘ distinction between TPS, TDS, evolutionary, continuous workflow, SB / TB
is all about . . .
~ ~ ~ ~ ~
Seeming really good article demonstrating set-based concurrent eng. :
LfD sect. on Th. of Constraints :
Theory of Constraints (TOC) is based on the premise that productivity (or the rate of revenue generation) is
always limited at the point of at least one constraining process -- a bottleneck. Only by increasing throughput at
the bottleneck process can overall throughput be be increased. TOC is sometimes referred to as constraint
TOC focuses on removing the constraints that limit an organisation's performance from achieving its full potential.
TOC with its emphasis on process flow and waste reduction, is an effective toolset for Lean practitioners in
emphasising bottlenecks in the value stream. TOC is particularly useful with its focus on throughput.
Conclusion -- What SB seems to be about
There seem to be 2 main ideas in all this :
i design progress via moving forward a set of possible design(constraint) possibilities
ii (a) identify the bottleneck constraint: (b) see if this can be removed, if so remove it and return to (a) [if not
removed - not sure . . ]
Actually, the ‗difference‘ here is that i. states the overall premise of SB, ii. outlines a method to implement it