Lean notes

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

2

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-added(NVA) steps

- 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

everywhere etc.

- Kaizen events are mounted to brainstorm waste elimination, and effect improvements via PDCA (Plan-Do-

Check-Act -- see below)

3

- 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





1

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

book



2

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

disastrous consequences.

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



misc factors:



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

(a.k.a.)

Transport Conveyance

Waiting Delay ‗TWODIME‘

Overproduction

Defect Correction/ repair/rejects

Inventory

Motion Movement

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



3

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

4

- 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

inspections/testing conveyors

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.







4

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

centred

. around

- 97 Muda

98 genl, ‗Sensei‘-type qns

99 Quality

100 Supply

101-2 Engineering

103 Information





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.

Future-State VSM

- 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

standarised work.



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 &

measure results.









6. Kaizen

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









Tools ('techniques')



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)

(BFT)



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

(departments)



Annual review:

- 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

crystalising...)



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

area tenfold

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



Gemba walks



= 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

levels.

Walks should over time cover the entire org, inside & out. The various walk ‗themes‘ should be planned,

catalogued, reviewed etc.







Software tools

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









y

"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

by

Relations diagram Show the Relations building out from a - usually used to get to bottom of an Issue (=the central concept)

starting concept



Affinity diagram Thematic grouping Often used in barinstorming sessions, to organise deluge of o'wise

unrelated/unstr. Ideas



Tree diagr. = Whole into parts typical = WBS

Breakdown str.



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

(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

technqs.



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 /

bottlenecks



POUS (point-of-use comment on .158: POUS is really corollary of 5S

storage); arranging

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

stage

Progressive = work is reviewed at beginning of

inspection next stage



Poka-yoke = error-proofing Physically preventing

err.

"tool", tech'q area usage

Equip't maintenance etc

Autonomous maint.

Planned "

Predictive "

Quick-change (SMED) SMED = single-minute exchange of die



Pull

Production smoothing

with SMED

Kanban techniques

Supermarkets

Plann. for every part

(PFEP)

Kanban and MRP





9. 'Perfection' technqs.



Standardised work = the foundation for improvement

Spec'n stds

Subj stds

Tech stds

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 &

accessible

- Revise regularly

Implementing std'zd work

Check/stabilise equpt

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

ascending/descending order

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

correlation

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





y

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 :



Transactional Lean



- ie. service industries, eg. finance & accting, contracts, procurement, legal, HR, IT

Typical wasteage in these includes:

- time

- facilities

- energy

- people



Value-stream Manager

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

- accting

- contracts

- legal

- travel, copy ctr, mail room

- HR



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

- over-capacity

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

cust demand.‖

5

- 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

cost-centre only.







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

Concurrent engineering

Genchi genbutsu: Go and see

Rigorous standardisation

DFM

Built-in learning



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

prototypes etc.]



This list seems to be pretty well ~ Agile, XP, even iterative/spiral models.



5

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



6

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

Standardise everything



17 Ten Pitfalls to avoid (can you guess the meaning of these headings?)



Yawn

Same-old Same-old Sr. Mgmt

Quick fix

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)

Busy bees

Stuck in the middle again " " " "

Lean Six Sigma







6

Keyword out of context (my TLA)

y

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

kaizen blitz

kaizen event



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







muda waste

mura unevenness

muri overdoing

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





CONTENTS

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-

toc

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

compatible.

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[5],[6] 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.



1.1 Convergence



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.[4]



1.2 Consistency



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.



1.3 Respect



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

inherently irrational.



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

organization's constraints.

Assuming the goal of the organization has been articulated (e.g., "Make money now and in the future") the steps

are:

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

not do)

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

constraint.



3. Applications



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.



3.1 Operations



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),[1] and

a variation called Simplified Drum-Buffer-Rope (S-DBR).[7]

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. [1]

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.[1] S-DBR requires only a single buffer at

shipping.[7]

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.[1]



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

facilities.

 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-Distribution

 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

accounting.

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[8]. 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.



6. Criticism



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 [9], D. Trietsch from University of

Auckland argues that DBR methodology is inferior to competing methodologies. [10][11]



6.2 Unacknowledged debt

Duncan (as cited by Steyn) [12] 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." [13]

[ ]

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

 Linear programming

 List of Theory of Constraints topics

 Systems thinking — Critical systems thinking — Joint decision traps

 Twelve leverage points by Donella Meadows

 Constraint

 Thinklets

 Throughput

 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

Corey Ladas)



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.

[2] 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.

[3] 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.

[4] 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

means flow.

[5] 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

of Lean.

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)

TB time-box



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



= http://xp123.com/xplor/xp0611/index.shtml









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

management.



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

1.pre

1.tg-sb, 1.tg



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

2.wik-toc



Actually, the ‗difference‘ here is that i. states the overall premise of SB, ii. outlines a method to implement it