Lean notes

Document Sample
Lean notes Powered By Docstoc
					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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:19
posted:11/12/2011
language:English
pages:26