RE: Another value stream map

My interpretation of Bill's comments below is that he
is not proposing 'expediting' - if he were I agree
with Kent's comment, it will slow things down.
Instead, Bill is advocating performing tasks using
non-constraint (or constrained - read working at
maximum capacity) resources to provide short lead
times on some tasks or projects/products.

Expediting implies cue jumping. It says, this is so
important you have to do it next, ignore everything
else in the queue. The lead/cycle time for an
expedited request should be the same as your so called
"zero inventory flow" time i.e. when you have
implemented flow and have queues of precisely 1 unit
at each stage. Hence, a properly implemented expedite
request reflects the 'ideal' for an organization.

In the real world, it is impossible to get to zero
inventory because it implies no uncertainty, no
variance, no risk and no constraints. Every system has
a constraint - even if the constraint is external i.e.
the market.

Assuming that there is a constraint, then there are
non-constraints. If you can find a part, component,
project which can be pushed/pulled/flowed through the
system without passing through the constraint, then
you can work on that piece using a separate queuing
mechanism (you could call this jumping the constraint
queue but it isn't expediting in the traditional
sense). Because the non-constraints, by definition,
have extra capacity this is possible.

In some case, as Bill also points out the constraints
might be artificial, i.e. policy constraints -
everything must go through this or that review. By
identifying those things which do not need to be
processed through the contraint (in this case a policy
decision) then you are also reducing lead time but you
are not expediting.

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers


--- Kent Beck <[email protected]> wrote:
> The Goal talks about how proud a crummy
> manufacturing line was of their
> ability to expedite orders. In fact, they would
> routinely expedite 40%
> of all orders. This makes me wonder if the SWAT team
> approach is
> actually going in the wrong direction. If you got
> SIP from 180 to 30,
> the need for expediting would disappear. If you
> start expediting,
> average SIP will probably rise, creating the need
> for more expediting.
>  
> Kent
> 
> -----Original Message-----
> From:
>
sentto-8007113-331-1041625157-kent=threeriversinstitute.org@returns.grou
> ps.yahoo.com
>
[mailto:sentto-8007113-331-1041625157-kent=threeriversinstitute.org@retu
> rns.groups.yahoo.com] On Behalf Of Bill Wake
> <[email protected]>
> Sent: Friday, January 03, 2003 12:19 PM
> To: [email protected]
> Subject: [SIP] Another value stream map
> 
> 
> * There are requests that could be handled very
> quickly. We talked 
> about the feasibility of creating a team of 
> analyst+programmer+tester that would turn something
> around in a week 
> or two, and squeeze it into the next testing window.
> (I didn't get a 
> sense of what proportion of requests this might
> cover.) 
> 
> * Currently, all requests are treated as if they're
> risky from a 
> system performance point of view. It might be
> possible to split the 
> stream of requests into "expected to impact
> performance" and "not 
> expected to impact performance." The latter could
> get an abbreviated 
> performance test. (This idea could be combined with
> the previous 
> idea too.) 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/