<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Lean Thinker &#187; Pacing</title>
	<atom:link href="http://theleanthinker.com/category/pacing/feed/" rel="self" type="application/rss+xml" />
	<link>http://theleanthinker.com</link>
	<description>Thoughts and insights from the shop floor.</description>
	<lastBuildDate>Sat, 12 May 2012 19:02:47 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Boeing Moving Line</title>
		<link>http://theleanthinker.com/2011/04/15/boeing-moving-line/</link>
		<comments>http://theleanthinker.com/2011/04/15/boeing-moving-line/#comments</comments>
		<pubDate>Sat, 16 Apr 2011 05:19:31 +0000</pubDate>
		<dc:creator>Mark Rosenthal</dc:creator>
				<category><![CDATA[Jidoka]]></category>
		<category><![CDATA[Pacing]]></category>
		<category><![CDATA[Quality]]></category>

		<guid isPermaLink="false">http://theleanthinker.com/2011/04/15/boeing-moving-line/</guid>
		<description><![CDATA[Boeing’s “PTQ” (Put Together Quickly) videos show a time lapse of an airliner in production. They have been producing the for years – certainly since I was working there. This one, though, shows something a little special. When I first started working there, the idea of a line stop was unthinkable. The plane moved on [...]<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2011/04/15/boeing-moving-line/">Boeing Moving Line</a></p>
]]></description>
			<content:encoded><![CDATA[<p>Boeing’s “PTQ” (Put Together Quickly) videos show a time lapse of an airliner in production. They have been producing the for years – certainly since I was working there.</p>
<p>This one, though, shows something a little special.</p>
<p>When I first started working there, the idea of a line stop was unthinkable. The plane moved on time, period. Any unfinished work “traveled” with the plane, along with the associated out-of-sequence tasks and rework involved.</p>
<p>The fact that the 737 is now built on a continuously moving assembly line in Renton is fairly well known.</p>
<p>But what struck me in this PTQ video is that one of the things highlighted in it is a <em>line stop</em>. It happens pretty quickly at about 1:57.</p>
<p>The video is also full of rich visual controls to allow the team to compare the actual flow vs. the intended flow. See many many you can spot.</p>
<div id="scid:5737277B-5D6D-4f48-ABFC-DD9C333F4C5D:353e3df9-0e50-4c02-8681-93ced6c6c003" class="wlWriterEditableSmartContent" style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px">
<div><object width="448" height="252"><param name="movie" value="http://www.youtube.com/v/Ihtl-SZLU9o?hl=en&amp;hd=1" /><embed type="application/x-shockwave-flash" width="448" height="252" src="http://www.youtube.com/v/Ihtl-SZLU9o?hl=en&amp;hd=1"></embed></object></div>
</div>
<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2011/04/15/boeing-moving-line/">Boeing Moving Line</a></p>
]]></content:encoded>
			<wfw:commentRss>http://theleanthinker.com/2011/04/15/boeing-moving-line/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>Taktzeit</title>
		<link>http://theleanthinker.com/2010/05/19/taktzeit/</link>
		<comments>http://theleanthinker.com/2010/05/19/taktzeit/#comments</comments>
		<pubDate>Wed, 19 May 2010 14:51:10 +0000</pubDate>
		<dc:creator>Mark Rosenthal</dc:creator>
				<category><![CDATA[Interesting Reading]]></category>
		<category><![CDATA[Pacing]]></category>
		<category><![CDATA[Takt]]></category>

		<guid isPermaLink="false">http://theleanthinker.com/2010/05/19/taktzeit/</guid>
		<description><![CDATA[Now and again someone wonders out loud why, in this lexicon of Japanese terms, we have the word “takt.” I had always passed along what I had heard – that the word was German, short for taktzeit and used in their factories to represent the pace of production. During WWII, the Germans had helped the [...]<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2010/05/19/taktzeit/">Taktzeit</a></p>
]]></description>
			<content:encoded><![CDATA[<p>Now and again someone wonders out loud why, in this lexicon of Japanese terms, we have the word “takt.”</p>
<p>I had always passed along what I had heard – that the word was German, short for <em>taktzeit</em> and used in their factories to represent the pace of production. During WWII, the Germans had helped the Japanese set up more efficient production lines, and the word migrated into Japanese usage.</p>
<p>All of this had been anecdotal.</p>
<p>
<a  href="http://www.alanhamby.com/factory1.shtml" onclick="javascript:pageTracker._trackPageview('/external/www.alanhamby.com/factory1.shtml');" ><img style="border-right-width: 0px; margin: 10px 15px 10px 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="factory_floor07" src="http://theleanthinker.com/wp-content/uploads/2010/05/factory_floor07.jpg" border="0" alt="factory_floor07" width="158" height="244" align="left" /></a>But today I ran across Alan Hamby’s phenomenally in-depth reference 
<a  href="http://www.alanhamby.com/tiger.html" onclick="javascript:pageTracker._trackPageview('/external/www.alanhamby.com/tiger.html');" >site on the German WWII Tiger Tank</a>. Alan has extensive detail on the 
<a  href="http://www.alanhamby.com/factory1.shtml" onclick="javascript:pageTracker._trackPageview('/external/www.alanhamby.com/factory1.shtml');" >Henschel Tiger Tank Factory</a>, and in some of the photos are signs indicating the number of the “takt” or production position.</p>
<p>But don’t stop here. Take a look at Alan’s site, and look at how this factory is set up and operated. This plant was set up to produce a Tiger I tank every six hours, and built a total of 1375 of them between 1942 and early 1945. Yes, there is a lot of waste, but bluntly, I have seen 21st century factories making products of similar size and complexity that are <em>far worse</em> than this.</p>
<p>The idea of pacing and balancing production is not new. By the time these photos were taken around 1943, the concept had been proven for over 20 years. Yet when I visit factories today this is a seemingly novel concept. I always wonder why today’s operations managers are not insisting on at <em>least</em> the efficiencies that were achieved by 1935.</p>
<p>Thanks to Alan for his kind permission to bootstrap from his research and use these rare photos here.</p>
<p>Just to be clear, though, having a pace for production does not make a line “lean.” Far from it. But it is a foundational element. It may not be sufficient, but it is (in nearly all cases) <em>necessary</em>. What makes it foundational element for improvement, however, is not so much the pacing and balancing aspect. Rather, the concept of takt time can be used as a way to structure improvement goals and targets in a way that is <em>meaningful</em> to the people doing the work.</p>
<p>We talk a lot (all to much, in my view) about metrics, but tend to think of the things management is interested in – like labor productivity. But the way you <em>get</em> labor productivity is to focus on the takt time, the total cycle time, and the stability of that cycle time. Those are the things that determine how much gets done by how many people. You can measure “labor productivity” all you want, but you can’t change it unless you get down another couple of levels. Fortunately (for us) 
<a  href="http://en.wikipedia.org/wiki/Albert_Speer#Minister_of_Armaments" onclick="javascript:pageTracker._trackPageview('/external/en.wikipedia.org/wiki/Albert_Speer?Minister_of_Armaments');" >Reichsminister Speer</a> didn’t figure that out.</p>
<p> </p>
<p>By the way, just to put things into perspective:</p>
<p>In 1943, Boeing Plant 2 was producing one B-17 bomber <em>an hour</em>, sixteen planes a day, six days a week. They did it by using a paced assembly line and continuously working to simply and improve the flow.</p>
<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2010/05/19/taktzeit/">Taktzeit</a></p>
]]></content:encoded>
			<wfw:commentRss>http://theleanthinker.com/2010/05/19/taktzeit/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>One-off and Customization</title>
		<link>http://theleanthinker.com/2008/08/06/one-off-and-customization/</link>
		<comments>http://theleanthinker.com/2008/08/06/one-off-and-customization/#comments</comments>
		<pubDate>Thu, 07 Aug 2008 05:23:57 +0000</pubDate>
		<dc:creator>Mark Rosenthal</dc:creator>
				<category><![CDATA[Jidoka]]></category>
		<category><![CDATA[Pacing]]></category>
		<category><![CDATA[Organizational Learning]]></category>

		<guid isPermaLink="false">http://theleanthinker.com/2008/08/06/one-off-and-customization/</guid>
		<description><![CDATA[One of the questions that comes up frequently in &#8220;lean&#8221; discussions is the issue of non-repetitive work. This is especially an issue with complex information processes such as bid proposals, estimates, etc. While it is true that breaking down and understanding truly repetitive work is easier, the same principles apply to more complex tasks. But [...]<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2008/08/06/one-off-and-customization/">One-off and Customization</a></p>
]]></description>
			<content:encoded><![CDATA[<p>One of the 
<a  href="http://theleanthinker.com/the-whiteboard-suggest-a-topic/#comment-5390" target="_blank">questions that comes up frequently</a> in &#8220;lean&#8221; discussions is the issue of non-repetitive work. This is especially an issue with complex information processes such as bid proposals, estimates, etc.</p>
<p>While it is true that breaking down and understanding truly repetitive work is easier, the same principles apply to more complex tasks.</p>
<p>But first, I&#8217;d like to challenge some thinking. If you were to tell me that &#8220;every time we do this it is totally custom,&#8221; my question would be &#8220;If it has never been done before, why can&#8217;t everyone do it just as well as you?&#8221; What makes up your expertise? Why do your customers come to you?</p>
<p>I&#8217;ll answer: Because you know how to do it. Obvious, right? But that&#8217;s the point. You have experience, <em>because you have done it before</em>. <em>You have a process of some kind. </em>And you carry out that process to produce your customized product.</p>
<p>Further, you have some kind of idea of what a &#8220;defect free product&#8221; is. You understand what you want to accomplish.</p>
<p>Complex operations are built up from simple ones. The tasks that are done over and over are these simple operations. These simple operations are great sources of waste because (typically) no one ever examines them.</p>
<p>The idea that &#8220;lean&#8221; only works for repetitive processes is largely the fault of the &#8220;lean industry.&#8221; It focuses so much on takt time and removing waste that it has not, so far, gotten to the actual heart of what makes continuous improvement work.</p>
<p>In an ideal repetitive process running to takt time, there are a number of key ingredients.</p>
<ul>
<li>There is a highly specified work sequence that calls out the content, timing, sequence and intended outcome of the work. EVERY time that work sequence is carried out, the <em>actual</em> content, sequence, timing and outcome is being compared to what was specified. ANY departure from the specified work (or result) is going to trigger some kind of <em>immediate</em> response to correct the immediate issue, and then start the process of problem solving to find the reason this happened. This is <em>
<a  href="http://theleanthinker.com/wp-content/uploads/2009/04/The-Essence-of-Jidoka-SME-Version.pdf" target="_blank" onclick="javascript:pageTracker._trackPageview('/downloads/wp-content/uploads/2009/04/The-Essence-of-Jidoka-SME-Version.pdf');" >jidoka</a></em>.</li>
<li>Although I mentioned timing above, the importance of time is elevated. Taiichi Ohno is quoted as saying &#8220;Time is the shadow of motion.&#8221; Ohno was a great student. The idea that it is important to study motion itself rather than focusing on time comes from the pioneer 
<a  href="http://en.wikipedia.org/wiki/Frank_Bunker_Gilbreth" target="_blank" onclick="javascript:pageTracker._trackPageview('/external/en.wikipedia.org/wiki/Frank_Bunker_Gilbreth');" >Frank Gilbreth</a>. In application, by specifying how long each <em>normal</em> operation should take, and checking the actual timing, it is possible to detect when unplanned motions creep into the work. <em>This is the purpose of takt time and work balance.</em> It is no more, and no less, than a tool for verifying planned vs. actual so that action can be taken <em>immediately</em> if there is a difference.</li>
<li>There is a specified amount of work-in-process. Each piece has a reason to be there. There is some means of detecting any departure from that standard, and any departure triggers an immediate response to understand why.</li>
</ul>
<p>As you scale up from a work cell to an entire factory, these mechanisms scale as well, but the principle is always the same:</p>
<ul>
<li>Tightly specify what you expect to do, when it should be done, who should do it, where it should happen, and how it should happen.</li>
<li>Tightly specify (understand) the intended &#8220;defect free&#8221; result of each step.</li>
<li>Have a way to verify, continuously, that what you are actually doing (and when, who, where and how) matches what you planned.</li>
<li><span style="text-decoration: line-through;">If</span> When you DETECT any departure from what you specified, STOP pretending you are still running to plan; FIX or CORRECT whatever got you off plan and get back on plan; then work to understand and SOLVE THE PROBLEM. This is how the organization learns and acquires what Deming calls &#8220;profound knowledge&#8221; of itself and its processes.</li>
</ul>
<p>In a complex one-off situation, you might never carry out that plan again. But plan carefully, applying everything you know&#8230; all of your expertise. Understand the elemental tasks that you do all of the time. Understand how long each should take. Understand what result you should get at each step.</p>
<p>As you carry out the plan, <span style="text-decoration: line-through;">if</span> when there are <span style="text-decoration: line-through;">unforeseen</span> real world issues, STOP long enough to understand their impact and start asking questions. First, what must we do to get this back on track?</p>
<p>If someone had to improvise, why? What knocked him off the plan or process?</p>
<p>If someone had to finish up work he got from upstream, why? Was the specification for a &#8220;defect free&#8221; transfer vague? Does it need clarification?</p>
<p>This can go on, but the bottom line is that most organizations with complex processes <em>expect</em> their people to accommodate and cope with noise in the system. They say &#8220;every time is different, we can&#8217;t possibly plan that well.&#8221;</p>
<p>The ones who are getting better every day say &#8220;We should be able to plan this perfectly. Why couldn&#8217;t we this time?&#8221; In simply asking that question, they get better each time they do it.</p>
<p>So &#8211; in the context of the original question. When putting together a complex bid and proposal, there are (I presume) steps you routinely go through. This is so even if you are not aware of what they are. Study those steps. Study the intermediate products. Understand where one step ends and the next begins. Understand what <em>must</em> be present (information, resources, etc.) for that step to execute successfully. If, at any point, those things are not there then STOP and understand WHY. Don&#8217;t just ask the people who SHOULD have those things to go find them.</p>
<p>You wouldn&#8217;t have an assembler on the shop floor hunt down missing parts. Don&#8217;t have a professional engineer hunt down information he should have received.</p>
<p>Check, at each intermediate step, that it was done as you expect.</p>
<p>At the end of the process, check that the bid is what you want it to be. If it needs rework (meaning someone didn&#8217;t approve it), understand why, and work on what information the process didn&#8217;t have the first time through. Next time, get it right.</p>
<p>The proposal itself is packaging. It is also your first cut at the plan for execution.</p>
<p>If you get the bid, and execute your plan, any departure from what you originally proposed should be understood. Why? What happened? What didn&#8217;t you see coming? Some things are truly different, and you are only estimating. But compare your actual vs. your estimate so that <em>next time</em> you can do a better job estimating.</p>
<p>There will always be imperfections. The question is in whether the organization chooses to bury them in waste or learn from them.</p>
<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2008/08/06/one-off-and-customization/">One-off and Customization</a></p>
]]></content:encoded>
			<wfw:commentRss>http://theleanthinker.com/2008/08/06/one-off-and-customization/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Accurate Forecasting</title>
		<link>http://theleanthinker.com/2008/04/28/accurate-forecasting/</link>
		<comments>http://theleanthinker.com/2008/04/28/accurate-forecasting/#comments</comments>
		<pubDate>Tue, 29 Apr 2008 02:41:43 +0000</pubDate>
		<dc:creator>Mark Rosenthal</dc:creator>
				<category><![CDATA[Consistency]]></category>
		<category><![CDATA[Pacing]]></category>
		<category><![CDATA[Heijunka]]></category>
		<category><![CDATA[Hoshin]]></category>
		<category><![CDATA[Organizational Learning]]></category>

		<guid isPermaLink="false">http://theleanthinker.com/?p=129</guid>
		<description><![CDATA[Why can&#8217;t we get a more accurate forecast from sales? Manufacturing managers the world over have the same complaint. Maybe the word &#8220;forecast&#8221; is tripping everyone up. A forecast is a prediction. Maybe it is based on some kind of market analysis, maybe even asking the dealers what they think they will sell. It could [...]<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2008/04/28/accurate-forecasting/">Accurate Forecasting</a></p>
]]></description>
			<content:encoded><![CDATA[<p><strong>Why can&#8217;t we get a more accurate forecast from sales?</strong><br />
Manufacturing managers the world over have the same complaint.</p>
<p>Maybe the word &#8220;forecast&#8221; is tripping everyone up.</p>
<p>A forecast is a prediction. Maybe it is based on some kind of market analysis, maybe even asking the dealers what they think they will sell. It could be based on a lot of things.</p>
<p>Once a forecast is complete, it is regarded as the best guess for how things will pan out, but those things are (felt to be) largely beyond our influence.</p>
<p>We forecast weather. How many hurricanes will we have this season? Will it rain on the outdoor wedding? Tides are forecast (accurately, but we can&#8217;t change them). </p>
<p>A <i>competitor&#8217;s</i> sales might be forecast, because we really don&#8217;t know their <i>plan</i>.</p>
<p>A sales forecast gets put together, approved, agreed, and entered into the data system.</p>
<p>Then two things happen.</p>
<p>Manufacturing bets the farm on it. They order long-lead parts, establish production plans, set factory capacity. They decide, based on that forecast, how much money is going to be <i>spent</i>, whether anything is actually sold or not. Those decisions often have to be made months in advance.</p>
<p>Meanwhile, all too often, sales has forgotten about the forecast, except perhaps, the top line sales figures. They work hard to sell whatever they can. They push for the big order. They offer the world to prospective customers. They will offer discounts, then push for higher unit volumes to close the dollar targets. Many times they operate on a quarterly (or worse) cycle.. as long as they have a great June, then April and May don&#8217;t matter so much.</p>
<p>Meanwhile, back in the factory, when April and May have been dry, they get slammed on June 4th, and end up expediting in parts (at great expense), and working overtime (at great cost), to make product that was sold at a discount.</p>
<p>This is no way to make money.</p>
<p>Let&#8217;s get back to what I think is the original issue &#8211; the word &#8220;forecast&#8221; meaning &#8220;prediction&#8221; (or &#8220;educated guess&#8221;).</p>
<p>Let&#8217;s change one word.<br />
Sales <strike>Forecast</strike> <em>Plan</em></p>
<p>That changes the entire meaning. </p>
<p>A &#8220;forecast&#8221; is a prediction of some event we have little or no control over.</p>
<p>A &#8220;plan,&#8221; on the other hand, is a set of actions which, if carried out as intended, are predicted to give a specific result. This is a different kind of prediction. This is the kind of prediction that an engineer makes. She analyzes her design, applies her considerable understanding of materials, structure, load transfers, then she <i>predicts</i> at what point that design will fail. If it is a brand new design, it is often tested to destruction (like a new airplane wing). This isn&#8217;t to test the design so much as to validate the models used for the prediction.</p>
<p>Sales isn&#8217;t engineering, I know that. It involves the most complex thing we know about &#8211; human psychology. </p>
<p>The sale planning process goes roughly like this:</p>
<ul>
<li>Financial, margin, volume targets to hit the higher level strategy for profit and growth.</li>
<li>What <i>must be sold, when, where</i> to hit those targets. There may be more than one set of options.</li>
<li>What must be done to achieve those numbers. This includes consideration for:
<ul>
<li>Unit volumes and mix. (Which are really the only thing the factory cares about.)</li>
<li>Total profit targets.</li>
<li>The margins that have to be held to hit those profits, at those volume and mixes. (Yes, sales is responsible for margins and profit.. how much money the company can actually <i>keep</i>, not just top line results. &#8220;We&#8217;ll sell it at a loss and make it up in volume&#8221; is not a long-term strategy to stay in business.)</li>
</ul>
</li>
<li>Then a process of looking realistically at what must be done, what can be done, deciding on a course of action, and producing a detailed plan to carry it out.</li>
</ul>
<p>That sales plan then plugs into a production plan. Where there are planned fluctuations, we can apply planned levels of buffer inventory &#8211; FIFO inventory, not just make-to-stock inventory, to allow a small time disconnect between when it is made and when it is shipped. This is part of <i>
<a  href="http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/">heijunka</a></i>. (This works in both make-to-order and make-to-stock models, only the mechanics differ.)</p>
<p>Now the entire organization can carry out PDCA.<br />
Are the activities in the sales plan being carried out, as planned, when planned?<br />
If not, why not?<br />
Are they producing the results that were <strike>intended</strike> predicted? (One-by-one confirmation.) No? OK, what have we learned that we can apply to making a better prediction next time? AND, most critically, <em>What else are we doing to do, because we still have to hit the numbers!</em></p>
<p>And hit the numbers we must. Not by the end of the quarter. By the end of the month to start. Then in two week increments. Then in one week increments. (And all of this assumes you are making and selling something that doesn&#8217;t spoil if it is sitting on the lot for a week.) </p>
<p>The sales plan is the <em>production plan for sales.</em> It is not a guess at how well they will do Just like the manufacturing production plan, it is a firm commitment on how they will support the organization&#8217;s overall goals. Yes, reality intrudes and plans rarely get carried off exactly as written. But the thinking that went into making the plan, and the commitment to deliver the results, means the organization, as a whole, is prepared to deal with the unexpected and still stay on track.</p>
<p>Is this idealistic? Absolutely. It is pursuit of perfection. But until the thinking is in place, we will be stuck where we are&#8230; waiting for something outside of our control and hoping.</p>
<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2008/04/28/accurate-forecasting/">Accurate Forecasting</a></p>
]]></content:encoded>
			<wfw:commentRss>http://theleanthinker.com/2008/04/28/accurate-forecasting/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>The Importance of Heijunka</title>
		<link>http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/</link>
		<comments>http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/#comments</comments>
		<pubDate>Mon, 03 Mar 2008 17:29:37 +0000</pubDate>
		<dc:creator>Mark Rosenthal</dc:creator>
				<category><![CDATA[Consistency]]></category>
		<category><![CDATA[Pacing]]></category>
		<category><![CDATA[Supply Chain]]></category>
		<category><![CDATA[Heijunka]]></category>
		<category><![CDATA[Jidoka]]></category>

		<guid isPermaLink="false">http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/</guid>
		<description><![CDATA[My friend Tom poses an interesting question to production managers: &#8220;If I ask you to produce different quantities and types of products every day, what quantity of people, materials, machines, and space do you need?” Of course the answer is usually, at best, inarticulate and, at worst, a blank stare. There isn&#8217;t any way to [...]<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/">The Importance of Heijunka</a></p>
]]></description>
			<content:encoded><![CDATA[<p>My friend Tom poses an interesting question to production managers:</p>
<blockquote><p>&#8220;If I ask you to produce different quantities and types of products every day, what quantity of people, materials, machines, and space do you need?” </p></blockquote>
<p>Of course the answer is usually, at best, inarticulate and, at worst, a blank stare. There isn&#8217;t any way to know. Add to this the well-established research of the &#8220;bullwhip effect&#8221; which amplifies the magnitude of these fluctuations as you move up the supply chain, and it is easy to see the suppliers are really set up to fail.</p>
<p>Then he asks another question:</p>
<blockquote><p>“If I ask you to produce the same quantities and types of products every day, or every hour, could you then answer the question?”</p></blockquote>
<p>And, of course, the answer is that this is a &#8220;no brainer.&#8221; It would be very easy.</p>
<p>So the rhetorical question to ask is: <em>Why does Toyota place such emphasis on heijunka?&#8221;</em><br />
But my question is &#8220;Why don&#8217;t we all do it?&#8221;</p>
<p>Heijunka is a process of dampening variation from the production schedule. In English it is called &#8220;production leveling.&#8221; It comes in two steps:</p>
<ul>
<li>Leveling the daily workload &#8211; smoothing out variations in the overall takt time.</li>
<li>Leveling the product mix within the daily work load &#8211; smoothing out variations in the demand from upstream processes.</li>
</ul>
<p>Production leveling, however, is difficult, and the management has to have the fortitude to do it. Honestly, most don&#8217;t. They don&#8217;t like to deliberately set the necessary inventory and backlog buffers into place. So I&#8217;d like to explore some of the consequences of <i>not</i> doing it and then ask if these costs are worth it.</p>
<h3>Consider this analogy.</h3>
<p>Take a look at what modifications are necessary for a vehicle to traverse a rough, irregular road. The suspension must be beefed up, more power is required, the drive train is far more complex for 4&#215;4. The road itself is unmarked, so the driver does not know where he is or where he is going without sophisticated navigation equipment. </p>
<p>Most of this additional hardware is actually unnecessary most of the time. But it <i>might</i> be needed, so it has to be there&#8230; just in case.</p>
<p>The driver of this vehicle is primarily concerned with what is right in front of the vehicle, and far less concerned about what is a mile (or even a few dozen meters) up the road. He will deal with that problem when he comes to it. Driving in this environment requires skill, training, experience, and continuous vigilance. People do this for recreation just for these reasons.</p>
<p>Now smooth out the road. Straighten out the hard curves. Give it some pavement. Put in signs so it is possible to navigate as you go. The same speed can be maintained by a vehicle which is lighter, has less power, a simpler drive system, a simpler suspension. Even though the engine is smaller, it is more efficient because it can run at a constant power output, the sudden accelerations are not necessary. Everything is easier.</p>
<p>The vehicle is much less expensive and much more efficient. The driver&#8217;s task is far simpler.</p>
<p>When you allow outside-induced variation to work its way through your system, you are putting potholes in the road. You are introducing sudden turns, sudden changes. Sometimes you are washing out entire bridges. People must be more and more vigilant and they simply miss more things. Their mental planning horizon shrinks to what they are working on right now, and maybe the next job. They certainly aren&#8217;t checking what they need tomorrow. They will worry about that in the morning.</p>
<h3>The Effect on Materials</h3>
<p>Even in the worst managed operations, people generally want to be able to provide what they are supposed to. They are motivated to be &#8220;good suppliers.&#8221; They also intrinsically understand that if they are idle (not producing) this is not good. Even if they are not provided with the tools and resources to do so, they will do the best they can to succeed &#8211; even if those things hurt the overall organization. </p>
<p>(I should note that most &#8220;management by measurement&#8221; systems actually encourage people to do things that hurt the overall organization, but that is another article.)</p>
<p>When these well meaning people encounter problems, they try to mitigate the effects of those problems with the resources they have available.</p>
<ul>
<li>If their upstream suppliers do not deliver reliably they will add inventory so they have what they need.</li>
<li>Likewise, if their upstream suppliers do not deliver good quality, they will add some more inventory to make sure they have enough good material.</li>
<li>If there is quality fallout within their own process, they will add inventory and up production to cover that. By the way, that increase of production also increases the demand on the upstream suppliers, sometimes in unpredictable ways.</li>
<li>If their customers have irregular demand patterns, they will add inventory so the customers can have what they need, when they need it.</li>
<li>If there is batch transportation either upstream or downstream from them, they have to accumulate inventory for shipping.</li>
<li>If there are on a different shift schedule from either their customer or supplier, inventory accumulates to accommodate the mismatch.</li>
</ul>
<p>Do you notice a theme here? The key point is: Without the system level view from their leadership, and without the problem solving support, <i>all they can do is add inventory to cope.</i></p>
<p>Without leveling, any variation in demand will propagate upstream. At each step, two things happen:</p>
<ol>
<li>Processes that accumulate and batch orders progressively add to the amplitude of the variation.</li>
<li>Irregularities within each process are <i>added to</i> the variation that comes from the customer.</li>
</ol>
<p>By the time this hits your supply base, it is a tsunami. First the beach goes dry as it looks like the order base has dried up. (This is why you need to constantly reassure your suppliers with a forecast &#8211; because they can&#8217;t see regularity in your orders.) Then all of that water comes rushing in at once &#8211; and your suppliers can&#8217;t cope. Worse, they may have allocated the capacity elsewhere because they were tired of waiting on you. Lead times go up, things get ugly.</p>
<p>But even internally, all of this self-protection just adds more and more noise to the system.<br />
So they add more and more inventory.</p>
<p>For a management team that is reluctant to deliberately add some inventory or backlog buffer to contain sources of variation and protect the rest of the system here is some news: Your people are already doing it, and in aggregate, they are adding FAR more inventory than would be needed with a systematic approach. They can only see the local problems, and each is just trying to be reliable &#8211; even if their efforts work in the opposite direction and actually <i>introduce more</i> variation into the system.</p>
<h3>The Effect on People</h3>
<p>I live in the Pacific Northwest of the USA. A fact of life living here is that, occasionally, the earth literally moves under our feet. I can tell you from experience that this is psychologically unsettling.</p>
<p>In our factories we do the same thing to people when the schedule changes every day. In the name of flexibility we shift requirements up and down. Add to that chasing shortages and hot list jobs around, and the daily work place is chaos. People are not sure if they are succeeding. Or, at best, they declare victory because they were not buried today.</p>
<p>Daily kaizen? That is just not going to happen in this environment. When you start talking about introducing flow, you threaten the self-protecting inventory buffers, and I can assure you that you will have a fight on your hands. Why? Because your people believe they need these buffers to get the job done &#8211; the job you want them to do. Now you are taking that away? Are you insane?</p>
<p>This is why it is critical to establish a basic takt as early as possible, then immediately start aligning the expectation to just meeting that takt.</p>
<p>Anything that keeps people from meeting takt becomes <i>a problem</i> and must be addressed. This is jidoka. Heijunka is a block in the foundation of the TPS &#8220;house&#8221; for a reason. Unless people are standing on solid ground, they can&#8217;t even consider anything like &#8220;just in time&#8221; or &#8220;stop and respond to problems&#8221; because they are spending all of their mental bandwidth just trying to figure out what is going on hour by hour.</p>
<h3>Conclusion</h3>
<p>When I was a military officer, we were trained in tactics designed to present our opponent with a constantly changing picture of what was happening. We wanted to inject as much confusion and uncertainty as possible. The mechanics of defeat on the battlefield are simple: The force subjected to this first shifts from action to reaction. They lose initiative, and therefore lose psychological control. Next the horizontal control linkages start breaking down. Each sub-unit starts to feel isolated from the others. They feel less a team and more on their own. Then, as more and more of their attention is shifted to self-preservation, the vertical chain of command breaks down. Each sub-unit is now mentally isolated and can be defeated in detail.</p>
<p>Ironically many factories are managed such that the workers on the shop floor are subjected to exactly these same conditions &#8211; and we wonder why they have a cynical view. We are defeating ourselves.</p>
<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/">The Importance of Heijunka</a></p>
]]></content:encoded>
			<wfw:commentRss>http://theleanthinker.com/2008/03/03/the-importance-of-heijunka/feed/</wfw:commentRss>
		<slash:comments>18</slash:comments>
		</item>
		<item>
		<title>Really Long Takt Times</title>
		<link>http://theleanthinker.com/2007/12/03/really-long-takt-times/</link>
		<comments>http://theleanthinker.com/2007/12/03/really-long-takt-times/#comments</comments>
		<pubDate>Mon, 03 Dec 2007 15:30:17 +0000</pubDate>
		<dc:creator>Mark Rosenthal</dc:creator>
				<category><![CDATA[Jidoka]]></category>
		<category><![CDATA[Pacing]]></category>
		<category><![CDATA[Andon]]></category>
		<category><![CDATA[Takt]]></category>

		<guid isPermaLink="false">http://theleanthinker.com/2007/12/03/really-long-takt-times/</guid>
		<description><![CDATA[One question I see coming up a lot in various forums is how to deal with issues unique to very long takt times. By &#8220;very long&#8221; I usually hear about many hours, sometimes days, occasionally weeks. Because it comes up fairly often, I thought I would take a shot at addressing it here. I think [...]<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2007/12/03/really-long-takt-times/">Really Long Takt Times</a></p>
]]></description>
			<content:encoded><![CDATA[<p>One question I see coming up a lot in various 
<a  href="http://lean.org" target="_blank" onclick="javascript:pageTracker._trackPageview('/external/lean.org');" >forums</a> is how to deal with issues unique to very long takt times. By &#8220;very long&#8221; I usually hear about many hours, sometimes days, occasionally weeks. Because it comes up fairly often, I thought I would take a shot at addressing it here.</p>
<p>I think the biggest hurdle for people to get over is the issues are largely the same as shorter takt times. They are just harder to see because the work starts to lose a human time scale. The trick is to get it <em>back</em> onto a time scale that people can relate to.</p>
<p>By this I mean that a person, generally, loses a sense of how long something is taking once it goes beyond a dozen minutes or so. In contrast, the stereotypical automobile line has a takt of about 60 seconds. Once an auto assembly worker loses 3 or 4 seconds of time, there is really no way she will be able to complete the programmed work cycle without help or stopping the line for at least a few seconds.</p>
<p>As work cycles get longer, though, the work remaining until &#8220;done&#8221; gets more and more disassociated from &#8220;now&#8221; and the idea of the necessity to maintain a particular work pace becomes abstract. This is less of a technical issue than one of human psychology. People, in general. tend to believe they can finish something in time long after that is no longer true. (Ask any college freshman working on a term paper.)</p>
<p>The countermeasure is the same as a manager would apply to any long project: milestones.</p>
<p>When the takt times are relatively short, the &#8220;milestones&#8221; are the takt intervals themselves. Each takt time signals a stage of work that must be complete. If this is not true, the line will (should) be stopped at that point. (Remember &#8211; &#8220;Never pass along a defect&#8221; and this includes incomplete work.) The problem will be corrected, and the cause understood. Oh &#8211; actually this is not quite true. A Toyota assembly line has the work zone divided into 10 sub-intervals, and the worker has a good idea what work should be completed at what point.</p>
<p>However, since most of us are likely just beginning &#8211; If your takt time is longer than a couple of dozen minutes, then, define the work in stages. In one operation I suggested the following:</p>
<p>Take about 85% of your long takt time, and divide <em>that</em> into quarters. Define what job should normally be complete by the time each of those check points comes up. As an example &#8211; if the takt time was 100 minutes, then determine the expected work completion at 20, 45, 65 and 85 minutes. Give the Team Member a way to know where he is at that point vs. the expectation, and a way to call for help if he is off by even a little bit. He should also call for help before that point if he is disrupted by something that he knows will cause a delay.</p>
<p>This is just a starting point to start to stabilize the system and build your support structure. If you reach the point where things are running smoothly at this level of granularity, then cut those time intervals in half.</p>
<p>At each point you will find more problems. The problems are likely to be smaller, but there will be more of them. All of those problems are sources of friction, and therefore wasted motion and time, on your system.</p>
<p>BUT &#8211; <em>before you start down this road</em>, have a few things in place first.</p>
<ul>
<li>Establish credibility for the concept that you are genuinely doing this to see problems that are making the worker&#8217;s jobs difficult. If you use it, just once, to initiate a negative consequence for &#8220;not working fast enough&#8221; then forget it.</li>
<li>Actually <em>work</em> the problems. This means work them to eliminate the causes. Put in a process for managing the problems, make it visible so that the people working can see you are working on them. Again, this is to maintain credibility. If problems get recorded and sunk into a black hole (like a database in a computer somewhere), then you are not assuring the people on the line that you actually <em>care.</em></li>
<li>Build your immediate responses (escalation) system. This mean team leaders (first responders) who can, and do, respond to help calls quickly. The only thing worse than having no way to call for help is to call and have no one respond. Again, the system loses credibility after about the third andon pull with no response.</li>
<li>Don&#8217;t worry too much about every detail within the work interval. The important thing, <em>at first</em> is to make sure that the same things get done within that interval. Detailed sequence standardization will come in time.</li>
</ul>
<p>Summary: The key to managing really long takt times is to break the work into time-based intervals, and manage to those, rather than the entire work cycle itself.</p>
<p>Fed from: <a href="http://theleanthinker.com">The Lean Thinker</a>.
Copyright &copy; 2012, Mark Rosenthal<br/><br/><a href="http://theleanthinker.com/2007/12/03/really-long-takt-times/">Really Long Takt Times</a></p>
]]></content:encoded>
			<wfw:commentRss>http://theleanthinker.com/2007/12/03/really-long-takt-times/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

