Tag: JIT

Posted on

Takt Time: How Slow Can You Go?

A long, long time ago – in the days when computer programs were coded as holes in punch cards – I was in ROTC* in college. Twice a year we had a “PT” (Physical Training, I think) test that consisted of measured performance on five “events.” One of those events was a 2 mile run. To get a maximum score of 100 points, the participant had to complete the 2 mile run in 14 minutes and 9 seconds. Why? I have no idea. But that was the way it was.

Yes – this old school stopwatch reads exactly 42 seconds.

My buddy John and I enjoyed running, and would often work out together. Our school was in Potsdam, New York, a place known for rather brutal winters, so we ran on a 1/10 mile indoor track.

We practiced the PT test. John would track our total time for 2 miles (20 laps around the 1/10 mile track). I would measure lap times. Since 14 minutes is 840 seconds, we knew that if we could consistently make 42 second laps, we would complete two miles in 14 minutes, and get the maximum score with 9 seconds to spare.

The track had hash marks at each quarter point, so we knew we had to hit quarter 1 between 10 and 11 seconds, half way at 21, the 3/4 mark between 31 and 32, and the lap at 42. We would check and adjust our pace accordingly, striving to hit exact 42 second laps every time.

To be clear, we could hold that pace many times further than 2 miles. It wasn’t a matter of conditioning. We weren’t going all out. We were going fast enough. And that was the point.

When we took the test, other cadets were going all out, passing us, and turning in much faster times. Others would try to “pace themselves” and then sprint as fast as they could for that last lap. As a general rule, although the instructors were calling out elapsed times as people went by, these cadets weren’t all that aware of the speed they had to hold. They were just going as fast as they could.

Meanwhile, John and I, running together, and tracking our cycle times (lap times) vs the takt time (42 seconds / lap) would come in at pretty much exactly 14 minutes and get the same score as everyone who had finished ahead of us: 100 points.

After our timed run was done, we would keep running, offering encouragement and pacing for those cadets who were struggling a bit. Everyone finishes, nobody left behind.

A couple of the instructors were curious why we didn’t go for a faster time. And many times we did when we were just working out. We were capable of breaking 12 minutes – not competitive times in a track meet, but respectable. The simple fact was that going faster wasn’t necessary to accomplish the goal.

Takt Time and Cycle Time

This is the whole point of having a takt time. It answers the question, “How fast must we go?” It doesn’t answer “How fast can we go?” nor does it answer “How fast should we go?” I fact, John and I could have run those laps almost (but not quite) half a second slower than we did – which would have eaten into the 9 second buffer we established. Aside from making the math easier, that buffer also gave us a small margin for even something as bad as taking a stumble and standing back up. Also, of course, we could make up 5-10 seconds a lap if we really had to. But we never did. Time: 14:00. We were very consistent.

Rate vs. Output

I encounter a lot of production managers who are so conditioned to focus on the daily output that they don’t even think about the critical factor: How fast are you running vs. how fast do you need to run? In other words what is your rate of output vs. your takt time?

Instead they tend to, at best, count units of output without really paying attention to the time interval between one and the next. In the worst case many units are started at once, and people swarm from one operation to the next during the day – the equivalent of that mad sprint trying to make up as much time as possible. They don’t really know if they will succeed or not until the end of the day (or month!).

It Isn’t a Race

The “just” in “just-in-time” is “just enough resources” to “just make the output you need” in any given time interval. As the operation is streamlined, the same effort is able to accomplish more. Where to put that additional capacity (which costs nothing additional since it has been there all along) to create more value should be the challenge the organization is trying to meet.

My experience has been that managers and leaders often struggle to adopt this “rate” mindset and let go of chasing an inventory number. In the words of the late great philosopher Kenny Rogers – “There’ll be plenty of time for counting when the dealings done.”

*ROTC (Reserve Officers Training Corps) is a U.S. program where college students can earn a commission in the U.S. Armed Forces while earning their degree.

Posted on

More Cycle Time Questions from Search Results

A couple of more exam questions showed up in search results.

4. what can happen if the cycle time is much shorter than the takt time

The searcher didn’t even bother typing this one – just cut and paste the entire thing, including the question number.

Fortunately the answer is really easy:

Raiders of the Lost Ark warehouse

If you keep this up, you’ll need another building.

OK, here’s one that is a little more subtle:

185 units in 14 hours is what cycle time

Hmmm. My first thought is to go back to Who is Grading the Questions?

I think whoever wrote this question is looking for something like 14 hours  (840 minutes) / 185 units = 272 seconds / unit (more or less). But that’s an average, it isn’t a cycle time.

The Average Rate of Output is not “Cycle Time.”

The average doesn’t give you any more information than the original question. This is simply a rate of output: 185 units in 14 hours. Cycle time is the measured time to complete one cycle.

There might be a single cycle that produces a batch of 185 units. Let’s say, for example, in a cure oven process that takes 14 hours to load, run and unload. Then the cycle time is 14 hours.

If the pieces are moving in a sequence of operations, but in a lot (which is different from a batch), where Operations 1 is completed on all 185, then Operation 2 is completed on all 185, etc. and maybe that all takes 14 hours? I have no idea what the cycle time(s) for the operations are. Most of the time the units are waiting in queue for the other 184 items to be done at each operation.

If we have true one-by-one flow then I have at least 185 cycle times. Hopefully they are all about the same, but likely that isn’t the case.

Are we measuring exit cycles (the cadence of output at the end of the process), or operator or machine cycle times?

By taking the average we are obscuring all of this information. Calling the average the “cycle time” just makes it worse because it gives people the impression that they are the same.

Cycle time is not calculated. It is measured. You cannot determine cycle time by applying mathematical operations on numbers. You have to go observe with a stopwatch.

And finally:

within each four hours worked, workers can take a total of 48 minutes in allowance (so allowance factor is based on workday). if the observed time is 6 minutes, and performance rating is 95%, what is the standard time (in minutes; give three significant digits after the decimal point)?

Even if I could understand the question, down to thousandths of a minute? Seriously?

</rant> <!– Until next time –!>

 

 

Posted on

One-by-one, As Requested, When Requested

The world continues to move toward meeting customer’s true demand of one of something, when they want it, where they want it.

3D printing is one area where we can see the beginnings of a disruptive technology curve.

Laser printing has been around even longer.

Books are an area where the traditional mass-printing model is under assault from a number of directions.

Now On Demand Books is offering their Espresso Book Machine, fully automated production technology for a copy of a traditional paperback book. Check out the video.

Yes, the costs are higher for now, but in a niche market (which is where disruptive technology matures), that is less of an issue.

The trend is inevitable – it isn’t how fast you can go, it is how slow can you go while preserving the economy of scale. That is the challenge.

Posted on

What Follows “Yes, but…”

I am in the process of (finally!) reading Mike Rother’s great book Toyota Kata. The book has already gotten great reviews out there, and I am not going to contribute a lot more to that dialog except to say I think it is the first substantial addition to community knowledge about TPS since Steven Spear published his dissertation in 1999.

As I go, I am taking notes of thoughts that are provoked, and I will share a few of them as they come up.

Early in the book, Rother makes a clear distinction between managerial systems that try to cost justify each and every activity, and those which have their focus on an ideal future state.

He cites a number of examples of how the dialog in these companies is shaped by this vision, or lack of it. This is one:

Almost immediately the assembly manager responded and said, “We can’t do that,” and went on to explain why. “Our cable product is a component of an automobile safety system and because of that each time we change over to assembling a different cable we have to fill out lot traceability paperwork. We also have to take to the quality department the first new piece produced and delay production until the quality department gives us an approval. If we were to reduce the assembly lot size from five days to one day we would increase that paperwork and those production delays by a factor of five. Those extra none-value added activities would be waste and would increase our cost. We know that lean means eliminate waste, so reducing the lot size is not a good idea.”

The plant manager concurred, and therein lies a significant difference from Toyota. A Toyota plant manager would likely say something like this to the assembly manager: “You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving smaller lot size. Thank you for pointing that out. However, the fact that we want to reduce lot sizes is not optional nor open for discussion, because it moves us closer to our vision of one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress. Please go observe the current paperwork and inspection process and report back what you learn. After that I will ask you to make a proposal for how we can move to a one day lot size without increasing our cost.” [emphasis added]

To this hypothetical Toyota manager, the ideal state is achieving one-by-one flow, on demand, in sequence, as requested, without waste. He sees the drive toward this ideal state as the method to drive the next problems to the surface which, when solved, will remove a round of waste from the process.

There are a number of key points to take away from this.

Avoiding waste vs. removing waste. The assembly manager is confusing the avoidance of wasteful activity from removing wasteful activity from the process. The large lot sizes are avoiding wasteful activity, but it is still there, lurking under the surface as a barrier to further improvement.

One-by-one flow as a crucial goal. In this example, the concept of one-by-one (or one piece) flow worked exactly as it should. The discussion, or attempt, to implement the next step in that direction revealed the next barrier that must be addressed on the way. Without the imperative to reduce lot size toward that ideal, these reasons, justifications, barriers, excuses prevail and the wasteful activity remains. Yes, its effect can be mitigated by larger batches, but applying that logic, why not make the batches even larger?

It isn’t about what waste you can remove. It is about what wastes must be removed to achieve the next target condition. Having this sense of the ideal to define the direction of progress focuses the team on removing the next barrier to higher performance. This keeps things on a path toward higher system performance. Contrast this to the classic “drive by kaizen” approach where we go on waste safari and then look for opportunities where waste we can remove the most easily. This results in a patchwork of improvements that rarely find their way to the bottom line.

Cost justification would say leave the waste there. The cost justification for reducing lot sizes comes primarily from the reduction of inventory holding costs. Unfortunately, unless the inventory is insanely expensive (like jet engines), that alone rarely justifies the effort. But this thinking also stops any further opportunities for improvement in their tracks.

On the other hand, if the goal is to drive toward the ideal of one-by-one in a way that does not increase cost, then once this single-day lot size is achieved, they would be asking “What will it take to get to half a day?” Eventually they will be asking about every part every day. And then true mixed one-item-flow.

At each juncture an important thing happens. They must confront the next problem, and the next waste in the system. They must find a way to remove that wasteful activity without increasing cost. Eventually they will be making one cable each takt time, and following that, making the cables and installing them immediately.

To get there all of the inspections and traceability paperwork requirements will either be removed as no longer necessary or will be built in to the process itself. How will that be done? I don’t know. Nobody knows. That is the point. We can’t solve all of the problems ahead of time, nor can we solve them before they are discovered. The path to the ideal state is vague and unknowable when you begin. It is revealed step by step, as you take those steps.

The key is to have faith that, among all of the people in your operation, someone will find a way to crack that next problem.

This is how you harness people’s creativity.

In his classic JIT Implementation Handbook, Hirano says to force one piece flow to reveal the waste in the system. That was in 1988. Rother introduces the critical human element into the equation. One piece flow is not an abstract concept, it is a critical guide for management decision making.

Rother goes on to make other examples. In each case, the tool or technique – such as takt time or leveling – specifies how we want things to work. That provides a baseline for comparison so we can see the problems we need to work on next.

Here is another example. Ironically, while Rother uses it in his book, I have experienced it in real life. The factory is trying to introduce leveling. They set up a stock of finished goods. They set up a kanban leveling box, and they set up a fairly well thought out process of leveling the demand on the production stock, allowing the inventory to absorb the ups and downs. Their rule is that if the inventory hits a high or low limit, they will take action and assess what is happening.

Then the email arrives – “A big order arrived, and flushed out our inventory, we had to catch up, what do we do?”

After doing what is necessary to recover the system, this was a great opportunity to look at why orders arrive in big batches. In this case, I suspect it was an artifact of the company’s distribution network. The plant is at a critical crossroads.

Each of these examples leads me to the same thought.

The “Yes, but…” and the “Now what?” situations are going to happen. They prove the system is working to surface the next problem to be worked on. The reply that follows decides the fate of your improvement process.

You can reply the way the Toyota manager did in Rother’s example, and work hard to improve your process.

Or you can buy the Basic Story that is presented, and in effect agree that no further improvement is possible on this process, or that “lean doesn’t work for us because [put your “unique situation” here]”.

Which do you do?

Posted on

Job Shops

“We are a job shop.”

“We never do the same thing twice.”

These are common truths spoken by people who are struggling with how to apply lean production principles to their operation. They want to do better, but don’t see how something that originated in the relentless repetition of an automobile assembly line can work for them.

This is a reasonable reaction in the face of an overwhelming amount of literature and advice that is geared to these repetitive environments. An example of this is the common “elements of standard work” that come right out of Toyota and Shingijutsu:

  • Repeating work sequence (standard work)
  • Balanced to the takt time (which implies repetitive demand)
  • Standard work-in-process (or standard in-process stock)

Another example is “Takt, Flow and Pull” as the key elements of just-in-time production.

All of these things are absolutely true, but as instances of more fundamental principles.

Can lean production principles be applied to a job shop? Absolutely. It just requires someone with a bit more experience who knows how to interpret the situation and apply the principles rather than dogmatically apply a standard toolbox. It’s like the difference between the author who applies the basics of creating a compelling story, and the performer who expertly interprets the script written by others.

I have run into a fair number of “job shops” over the last 20 or so years. This is what I have observed:

A fair percentage of them actually have underlying repetition. It is just obscured by the job shop mentality. That is, they run them like job shops, so they become job shops. Even if only a portion of the work is repetitive, slicing this off and stabilizing it creates that much more mental bandwidth for dealing with the rest of it.

But even the true job shops, the ones who do custom work never to see that customer again are experts at what they do.

Expertise comes from experience.

Experience, in turn, comes from having done it many times before.

There is something they are good at. Each job may be custom, but it is built up from basic elements – the things they are experts at doing. Identifying those elements can clear out a lot of the seeming complexity. True process then emerges as they focus on how those elements are executed and organized, and paying attention to the interactions between them, the people, the customer. Then they work on getting better and better at creating stable processes that may only be carried out one time. But even then, there is knowledge to be gained that can be incorporated into doing it better next time, and that is the essence of kaizen.

Key point: If you are struggling with how to apply these principles, and aren’t getting answers that make sense to you, then (bluntly) you are talking to the wrong people. Keep at it until you find someone who can look at your situation and ask the right questions.

Posted on

Problems Hidden In The Open

We were down on the shop floor watching an assembly operation. The takt time was on the order of three hours. The assembler was new to the task, and the team leader periodically came by and asked if he was “doing OK.” The reply was always in the affirmative.

As the takt time wound down to under five minutes to completion, this operation was the only one not reporting “Done.”

The count down hit zero, things went red, the main line stopped, and the line stop time started ticking up.

The team leader, other assemblers, the supervisor began pitching in to assist. Between them, the job was completed in about 10 minutes, and the line restarted.

So, again, my favorite question:

What’s the problem?

Lets try breaking it down to four key questions.

  1. “What should be happening?”
  2. “What is actually happening?”

    3. The above two questions define the gap.

  3. “Why does the gap exist?”
  4. “What are we doing about it?”

These questions simply re-frame PDCA, but without so much abstraction.

So, in this situation:

What should be happening?
Two things come to mind immediately.

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

For this to work, though, the team member needs a clear and unambiguous way to answer a key question of his own: Am I on track to finish on time? Ideally the answer to this question is a clear “Yes” or a clear “No,” with no ambiguity or judgment involved. (Like any “Check” it should produce a binary result.)

On an automobile line with a takt time on the order of 55 seconds, the assembler can get a good sense of this. If he loses more than three or four seconds, he isn’t going to make it. But “a good sense” isn’t good enough.

Even in this fast-moving situation, you will see visual indicators that help the team member answer this question. Take a look at this photo.

toyota-assy

See the white hash marks along line at the bottom of the picture? Those mark off the moving line work zone into ten increments of about 5 ½ seconds. The assembler knows where he should be as he performs each task. If he is a hash mark behind, he isn’t going to finish on time. Pull the andon. We can safely say that, in this example, we have accomplished (1) and (2) above.

With longer takt times, it is much tougher for a human to have a good sense of how much time will be required to complete the remaining work. That makes it that much more critical that some kind of intermediate milestones are clearly established and linked to time.

What would be a reasonable increment for these checks? –> How far behind are you willing to let your worker get before someone else finds out? I’d say a good starting point is at the point when he can’t recover the time himself, the problem is no longer his. Following the standard work is the responsibility of the team member. Recovering to takt time is the team leader’s domain. At the very least, he is the one who pitches in and helps, or gets someone else to do so. But he can’t do this if he doesn’t know there is a problem.

So – what should be happening?

The team member must have continuous positive confirmation that he is on track to complete the work on time. With the failure of that positive confirmation, he should pull the andon and get assistance.

The team member must call for assistance (“pull the andon”) if his work falls behind the expected progress for any reason whatsoever.

What is actually happening?

In our example, the team member didn’t get help until it was too late. In fact, he verbally assured the team leader he was “OK” on a couple of occasions. The line stop was irrefutable evidence of a problem. That was a good thing. This company has a takt time, and runs to it. Think of what would have happened if they didn’t. It might take hours, or days, before this problem surfaced. (We are nowhere near the root cause yet. The line stop is just evidence of a problem, not the problem itself.)

Why does the gap exist?

It is a hell of a lot harder to answer this question than the other two. In this case, you are going to have to peel back a lot of layers before you get to the actual, systemic, root cause. But in the immediate sense, with a takt time bordering on three hours, there is really no realistic way a worker can judge if he has fallen too far behind to catch up. The fact that, in this case, the assembler was still learning the job, and that just compounds the situation.

From casual observation – when the team leader visited, he asked if things were OK and accepted the reply – I would start to investigate whether the team leader had a good sense himself of where the work should be at his regular check points… if he has regular check points at all.

But all of this is speculation, because after 10 minutes of watching the initial response to the line stop, our little group had moved on. I am mentioning these things as possibilities because you likely have the same issues in your shop. (And if you don’t have a rigorous sense of takt time, it is equally likely you don’t know about those issues even at the level we saw here. At least THIS company can see the evidence of the problem. That is a credit to their visual controls.)

What are we going to do about it?

Obviously there are a couple of immediate things that can be addressed to at least contain the problem. (That is, convert a hard line stop into multiple andon calls so the actual problems are seen earlier.)

I would want to establish a regular routine for the team leader’s checks. His leader standard work. At regular intervals, he should be checking progress of the work. How often? How far behind do you want the assembly to get before you are certain someone finds out about the problem? In this case, even every 20 minutes is less rigorous than the hash marks on the auto assembly line. But it would be a start.

So we have the team leader coming by every 20 minutes.

But he can’t just ask “How is it going?” We clearly saw that didn’t work. It isn’t that the assembler lied to him, it is that the assembler didn’t know because there was no standard.

What work should be complete 20 minutes into the work cycle? At 40 minutes? At 60? What verifiable facts can the team leader check by observation? There are a lot of ways to do this, most of them very simple and non-intrusive. Think it through.

But wait – now the team leader himself has standard work. What cues him to do it? Is he supposed to notice that 20 minutes has elapsed? In this case, the company already has a pretty sophisticated andon and sound system. It would be a pretty simple matter to put in an audible signal that told the team leader to make his checks. But, again, that is just one solution. I can think of a couple of others. Can you?

What is the team leader checking for? This is a critical question.

Think about it.

What was the original answer to “What should be happening?” (which is “the standard”)

We said:

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

We want the assembler himself to be checking #1.

So why do we have the team leader check?

So he can verify that the assembler is pulling the andon when he should. This is important because it is human nature not to ask for help until it is too late. This isn’t limited to factory floors. How many cardiac patients die because they ignored the warning symptoms for fear that it isn’t serious enough to get help?

It isn’t enough to ask the team member to call for help. You have to expect it, encourage it and require it.

Interestingly enough, as I was writing this post, John Shook posted his story about converting the culture at NUMMI.

A cornerstone of Respect for People is the conviction that all employees have the right to be successful every time they do their job. Part of doing their job is finding problems and making improvements. If we as management want people to be successful, to find problems, and make improvements, we have the obligation to provide the means to do so.

But, some of our GM colleagues questioned the wisdom of trying to install andon at NUMMI. “You intend to give these workers the right to stop the line?” they asked. Toyota’s answer: “No, we intend to give them the obligation to stop whenever they find a problem.” [emphasis added]

What was the problem in our example? We don’t know yet. We certainly can’t start looking for causes.

But the evidence of a problem was that the team member could not complete the work in the time expected. That is, he was not successful doing the job. And the line stopped because the support system failed to pick up the fact that he was falling behind until it was too late to recover.

It really does come down to respect for people.

Posted on

Reducing Inventory

Yesterday’s post on vendor managed inventory touched on a couple of things about “lean” and reducing inventory that I’d like to explore further.

All too often “inventory reduction” has been a way to “sell” a lean manufacturing implementation. The reduction of inventory becomes the objective. While this isn’t inherently a bad thing, it is all to easy to get caught up in the trap of “management by measurement” and do it the wrong way.

Reduced inventory is a result of good kaizen, but it isn’t the justification for doing it. The purpose of kaizen is to solve problems, specifically the problems that disrupt the smooth flow of work and creation of value. Solving those problems saves time – worker’s time, customer’s time, leader’s time because everything runs more smoothly and predictably.

The primary reason that inventory is there is because things aren’t smooth and predictable. Once they are, you can take some of it out.

The necessity to have inventory at any given point in the system is evidence of a problem that has not yet been solved. (Including, sometimes, simply having poor inventory management, which is another way of saying “overproduction.”)

By asking “What must we do to live without this piece of inventory?” you can uncover the next problem to solve, and then make a decision to solve it.

If it is solved, then inventory can be reduced. But it doesn’t happen automatically, you have to actually take it out of the system and keep it from coming back.

But in any case, this is a lot different than just shoving the ownership of the inventory onto someone else.

Posted on

Be A Perfect Supplier; Be A Perfect Customer

Operations that work to the “push” are well known for complex and interdependent problems. What looks like a problem in one area often has causes, or parts of causes, in other areas. Quality problems, delivery problems (late, too much, too little, wrong stuff), sub-optimizing attempts to reduce local cost.. all of these things propagate unchecked through the plant. To fix one area means having to fix almost all of the others at once. This initial improvement gridlock is pretty common.

When you start talking about implementing JIT in an environment like that, the pushback is visceral and, to be honest, legitimate. The only reason they get anything done is because the system runs to sloppy tolerances and doesn’t expect much. JIT demands a degree of mutual vulnerability, at least it seems that way when it is first presented.

The other really big psychological issue is that lean is often presented as a solution to all of these problems. Quite correctly, the survivalist shop floor supervisors don’t see that. And they are right. The problems do not go away when you implement flow. I sometimes find it surprising how many people don’t get that. All they see is fewer problems in operations that have flow, and they mix up cause and effect. Good flow is the result of solving the problems. Not the other way round, but I digress.

If you are dealing with this problem gridlock, where do you start? The first step is to contain the problems as close as possible to their sources.

The objective is to apply what temporary countermeasures are necessary to appear as a perfect supplier to your downstream customers; and the appear as a perfect customer to your upstream suppliers.

So what is a “perfect supplier?” That is probably the easier of the two logical questions to answer. A perfect supplier is capable of supplying what you need; when you needed it; with perfect quality; one-by-one; at takt.

What is a “perfect customer?” This one is a little harder, but it is good to look back at what makes a perfect supplier. Ask yourself – what things does the customer do that makes it difficult to be a good supplier? What does a bad customer look like?

  • They order or demand things in batches.
  • They give no advance notice about what they need.
  • Their demand is unpredictable and inconsistent.

A lot of this seeming unpredictability actually originates in the supplying process. I recall a case where the manager of a fabrication shop swore that his customer’s demands were totally random. At the assembly plants, though, they operated to takt with a steady mixed-model schedule. There was very little change from one day to the next. Why the big disconnect? The fabrication ship ran things in big batches, and set up big batch pull signals. Naturally those big batch pull signals would go a long time between trigger points, so they would seem to come back at arbitrary times, for huge amounts. Self-inflicted gunshot wound. Once they took the simple step of shipping things in smaller containers, a lot of that seeming instability went away. Smaller containers meant more frequent releases of pull orders, which gave them a cleaner picture of the demand picture. Think of it this way: The smaller the pixels on your screen, the more resolution you have in the image.

So that does the perfect customer look like? Level, predictable demand at takt with no major fluctuations.

Think of the purpose of heijunka or leveling production. Because customer demand arrives in spikes, batches, lumps, the leveling process is necessary to make that demand appear to be arriving exactly at takt time.

Although the books, such as Learning To See say there is only one pacemaker process or scheduling point, non-trivial flows frequently require re-establishing the pulse.

This is especially true if orders are batched up either through the ordering process itself or the delivery process. An example of this is a manual kanban process between an assembler and the supplier. Even though there is a paced assembly line and good leveling, kanban cards are collected and delivered to the supplying process in transportation-interval “chunks.” The supplier needs to have their own heijunka board to re-level the demand and pick at takt from the supermarkets. The alternative is that the demand arrives at the production cells in those same batches, and the smooth takt image is lost.

In a Previous Company we were working a project to establish pull on a trans-continental value stream that had five major operations, all in different geographic locations. To use the word “monument” does not even begin to describe the capital infrastructure involved, and there were a lot of these assets shared with other value streams, so relocating and directly connecting flows was out of the question. There were unreliable processes, big batches, transportation batches, end-using customers’ orders in huge, sudden surges based on their surge based business cycle. Step by step we isolated inventory buffers and ended up putting in heijunka to re-level the demand at nearly every stage of the process. It was big, ugly, cumbersome, but it worked to isolate problems within a process vs. pass them up and down stream.

The objective was simple: Use inventory buffers and heijunka to make each process in the chain appear as a perfect customer to its suppliers – always pulling exactly at takt. The consuming process “owned” the inventory buffers necessary to do this. Reason: Simple. The problems that cause them to be a less-than-perfect customer are theirs, so they own the inventory that is necessary to protect their suppliers from those problems. Likewise, that process owned whatever inventory was necessary them to appear to be a perfect supplier. They had to enable their customer to pull one-by-one, exactly at takt, from them, even if their problems kept them from producing that way.

Never mind that the downstream process didn’t actually consume at takt. THEIR inventory buffer translated their spiky signal into one which reflected the takt time.

All of this was very sophisticated and complicated, but in the long haul it worked. Megabucks of inventory came out of the system. Megabucks remained, but we knew exactly why it was there, and who had to solve what problems to reduce it.

If you can’t be a perfect customer, create the illusion that you are.

If you can’t be a perfect supplier, create the illusion that you are.

Then you own the problems yourself, you own the inventory-consequences of having those problems, and you control your own destiny.

Posted on

The Essence of Just-In-Time

The Essence of Just-In-Time

This is a working paper by Steven Spear of Harvard Business School. Spear’s PhD work was summarized in a landmark and well-circulated Harvard Business Review article titled “Decoding the DNA of the Toyota Production System.” I will leave it to the reader’s Google savvy to turn up the DNA article for yourself.

This working paper is much more raw than a finely edited HBR article. But it gets to the core research and conclusions without any fluff.

As you read it, compare what is described here with the focus of your own implementation.

Do you find any gaps?

I’ll comment more myself when I am not totally jet-lagged… I just got back from China. 😉