Tag: Kanban

Posted on

Learning vs Teaching

Coincidently my experience this week ties in nicely to the last post.

I have a couple of teams working to develop pull systems through their respective work areas.

The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.

An alternative approach is to have a small group of experts design the system.

Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.

What I am watching this week is more organic.

First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.

The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.

They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.

Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.

Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.

They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.

They are figuring out how to make it more robust, without making it cumbersome or too complicated.

They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.

The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.

What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.

This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.

It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.

Oh – and I’m really glad this process works because that saves me from having to know the answers.

Posted on

Pull as Kaizen

Michael Ballé’s recent Gemba Coach column drives home the importance of understanding that all of the so-called “tools of lean” are really there to drive problem solving.

A well designed kanban system is (or at least should be) built to not simply provide a pull signal, but more importantly, to continuously ask, and answer:

  • “What is supposed to be happening?” (what is the target condition?)
  • “What is actually happening” (what is the current condition?)

and give at least a hint of the problem that needs to be addressed right now when there is an issue. As a minimum, what condition must be addressed right now, and the first “Why? to be investigated.

A couple of months ago I posed a hypothetical question about a team’s effort to put in a kanban process and asked for your thoughts and comments.

The scenario I described was, with one or two trivial changes, copied directly from pages 48 and 49 of the Lean Enterprise Institute’s latest workbook, Creating a Lean Fulfillment Stream.

Although the process as described would likely work (at least for a few items), I was really surprised to see an LEI book describe a process that explicitly and deliberately breaks the “rules of kanban” that they have published elsewhere, particularly in Lean Lexicon. The LEI did not make up the rules of kanban, they have been well established for decades. Thus, I have to admit that my first response was to question the credibility of the entire book (Lean Fulfillment Stream), even though there are many things in it that are worthwhile.

Many of you correctly called out issues with the mechanics. Now, in light of this new information, I would again like to invite comment.

If a good process should be set up to continuously ask, and reveal the answers to, those two questions, where does this kanban scheme come up short?

How would those issues cause problems with the processes that Ballé is describing in his column?

 

Posted on

Kaizen Scenario: Kanban Implementation

 

When improvement teams set up kanban loops, they often get very creative about how they actually operate. What follows is an example of one such loop, and then I am inviting comment and replies to some specific questions I have.

The process works like this:

  • The items are stored on a shelf in a warehouse. One item per carton. The carton is 60x60x90 cm and weighs about 70kg.
  • Next to a shelf there is a box containing the kanban cards for those items. The team is calling this box a “kanban post.”
  • One card represents a reorder for five units of inventory.
  • When a customer order is received, say for 35 units, the picker pulls the appropriate number of cartons to prepare for shipping.
  • Since there are 35 units in the order, and each card orders 5 units, he pulls 7 cards from the “kanban post.”
  • He takes the cards to the kanban administrator, who uses them to order new items from the factory.
  • When the replacement inventory comes in, it is sent to the shelf location, and the cards are returned to the kanban post.
  • The plan is to eventually apply this same process to the other parts in the warehouse (several hundred types of items)

You are a kaizen manager for the company. You are checking on your kaizen teams as they do their work, and discover they are implementing the above process. The kaizen workshop leader who is guiding this team works for you.

Questions:

What, if anything, would you think about this solution, and what, if anything, would you say to the kaizen team leader?

I am serious – I am looking for input here. I have my views, but I want to hear from others.

Posted on

A Systematic Approach to Part Shortages – Part 3

The third element of this organization’s successful drive to eliminate part shortages was a systematic approach to problem solving. They made it a process, managed just like any other process, rather than something people did when they had time. Even though this is “Part 3” of this series, in reality they put this into place at the same time, and actually a little ahead, of kanban and leveling.

The Morning Market

The idea of the “morning market” came from a chapter in Imai’s book “Gemba Kaizen.” He describes a process where the previous day’s defects are physically set out on a table and reviewed first thing in the morning – “while they are fresh” hence the analogy to the morning markets.

This organization had been trying to practice the concept of a morning market for a few weeks, and was beginning to get it into an actual process. Because supplier problems constituted a major cause of disruption, they set up a separate morning market for defective purchased parts.

That process branched yet again into a morning market for part shortages. And this evolved into a bit of a mental breakthrough.

They started looking at process defects.

Every shortage, every day, was recorded on the board.

Each morning the previous day’s shortages were reviewed. They were grouped into three categories based on knowledge of the cause – just like outlined in the book.

  • “A” problems – they knew the cause, knew the countermeasure, but had some excuse reason why it could not be implemented right away.
  • “B” problems – they knew the cause, but did not have a good countermeasure yet.
  • “C” problems – knew the symptom (parts weren’t there) but didn’t know why.

The mental breakthrough was systematically investigating the reason each and every shortage occurred. What they found was that in the vast majority of cases it was an internal process breakdown, rather than some problem at the supplier, that caused the shortage. This was a bit of a revelation.

They began systematically fixing their processes, one problem at a time.

Over time things got better. Simultaneously they were implementing the kanban system. Kanban comes with its own set of possible problems, like cards getting lost. Once again, when they found problems they went into the morning market and were systematically addressed.

After a few months into their kanban implementation, for example, they started turning in card audits with far less than 2% irregularities, and then it was not unusual for a card audit to find no problems at all. Why? They had addressed the reasons why cards end up somewhere other than where they should be. Instead of blaming people, they looked for why people acting in good faith would not follow the process.

This was also an attitude shift – assume a flaw in the process itself, or in communication, before looking for “who did it.”

Eventually the warehouse team had their own morning market. As did the receiving team. As did the parts picking team. As did assembly. Each looked at any case where they were not able to deliver exactly what their downstream customer needed.

About 8 months into this, another group in an adjacent building, was trying to work through their own issues. They came over for a tour. One of the supervisors, visibly shaken, came to me and said

“Now I get it. These people work together in a fundamentally different way.”

And they did. They worked as a team, focusing on the problems, not on each other.

And that, readers, is the goal of “lean manufacturing.” If you aren’t working toward that, then you aren’t really implementing anything.

Posted on

A Systematic Approach to Part Shortages – Part 2

For kanban to work well, there has to be a solid foundation under it. That foundation is production leveling or heijunka.

Before I get to far into this, though, I would like to point something out: At the mention of leveling, people who are only just learning about kanban will point out all of the good reasons why leveling is difficult. Here is a key point: The problems caused by running kanban without good leveling pale in comparison to the total chaos that ensues if you try to run MRP without leveling. I’ll stay out of that little rabbit hole until another day though.

Production leveling has two parts.

  1. Leveling the production volume.
  2. Leveling the production mix.

The operation I described in Part 1 was relatively small, so it was a simple matter to set up a totally manual system to do this. By small I mean they had two major assembly lines running at a rates on the order of 10 units / day. The product was about the size and complexity of a medium to large-sized photocopier (though not a photocopier). The assembly lines had about half a dozen positions each. There were several hundred parts from about as many suppliers. (Different story.)

The objective in leveling volume is for the production line to see demand as an image of the takt time, and to protect that signal from variation in actual orders and shipping. At the same time, the shipping dock was to see deliveries to the finished goods buffer at takt time, regardless of minor and medium problems in production.

To accomplish this they separated the “big lump” of inventory that typically existed in shipping into two physically separate buffers.

The Withdrawal Loop

Customers, unfortunately, rarely order at takt time. The purpose of the buffer in shipping was to absorb this variation and make the actual demand appear as if it arrived exactly at takt. The organization also tried to take out some of the bigger spikes in customer orders by working with dealers to get more transparency into actual customer order patterns; as well as trying to level actual promise-to-ship dates at least weekly if they couldn’t get it to daily. That helped a lot. A more sophisticated order entry system would have worked better, but that luxury wasn’t in place yet.

Back to the buffers. Each unit in shipping had a withdrawal kanban card attached to it. As orders were released, a unit would be pulled from this buffer and shipped. The withdrawal card went back to the production control department. Those cards were placed in the inventory management box. This box had series of slots that indicated authorized inventory levels. A card in one of the slots indicated inventory we didn’t have, an empty slot indicated inventory on-hand.

There were limit markers at near each end of the row of slots. As long a the end of the row of cards stayed between those limit markers, everything was regarded as OK. They did not try to chase a particular level of inventory with production.

The scheduled production rate was 10 units / day.

Each morning Production Control would take 10 cards from their box and put them into the leveling box in shipping. That box had slots that corresponded to times of day. The cards were evenly distributed at the takt-time interval. As that time came up, shipping would take the withdrawal card from the box, go to the end of the production line, attach their card to a unit, and move it to the shipping buffer.

This seemed like a lot of trouble, but it served a purpose. It was to hide the irregularities of shipping schedules and actual order dates from assembly. They saw a clean, paced signal exactly at takt time. The process was designed so that assembly saw a perfect customer, even if the customers were far from perfect.

If management didn’t like the size of the shipping buffer, they knew exactly what problem(s) must be solved to reduce it – they needed to improve the dealer ordering and management processes so dealers would stop using deep reorder points and ordering weeks worth of product at once.

The Production Loop

When units were withdrawn from the end of the line, they were actual pulled from a FIFO buffer. In this case, the buffer held about 4 hours of production. Why? Most problems in production were cleared within that time. Only a bigger problem would starve the buffer and affect the withdrawal loop. Thus the purpose of this buffer was to make assembly appear as a perfect supplier to their perfect customer. They could supply exactly at the agreed-upon takt time.

Each of these units had a production kanban card attached to it. When shipping came to pull a unit, they would pull the production card and leave it in a kanban post. They would attach their withdrawal card and take the unit. Thus switching the cards transfers ownership of the product from one loop to the next. Since a kanban card authorizes a specific quantity to be in a specific location, if someone wants to take something somewhere else they need to attach a card authorizing them to do so. That was the case here.

The production cards went to the front of the assembly line. There were three slots there. One green, one yellow, one red. If everything was running smoothly, the card would go into the green slot, and when the next unit was started, the card would be pulled from the box and attached to the unit.

If the line were a little bit behind, there might still be a card in the green slot. Then the next card would go into the yellow slot. This would automatically signal the assembly manager that there was something that needed some attention.

The next card would end up in the red slot. This was the point when, if they weren’t already there for a known problem, they were in “line stop” mode. Anyone who could be helping to clear the problem should be helping to clear the problem. Why? The money machine has stopped running. Everyone is now being paid only because the shareholders are lending them money. The idea is to get the money machine running as quickly as possible, and it is the most important thing. This was a simple phased escalation process, and was part of their overall andon / escalation system.

Did it work?

All I can say is that it worked a hell of a lot better than what they were doing before. It took two or three serious tries to get this into place and keep it working, and they probably fell off the wagon a couple of times after that. There were always immense pressures to “reduce inventory” at the end of the quarter, for example, which would have management directing to starve out the shipping buffer, or push it out early. But, in general, when it was working, overtime was lower, things were more predictable, problems were identified very quickly.

But…

Yes, it looks like a lot of manual work involved. But I want to be really clear – the total time spent moving all of these cards around was a fraction of the time that had previously been spent investigating status, working action messages, making calls to find out what was happening, etc, etc. For some reason people seem to think that deliberate activities raise the total amount of labor involved, and that somehow, the time spent running after information and chasing problems is free.

Setting a standard and following it injects an element of stability and calm into an otherwise chaotic workplace. Once this basic foundation is in place it is far easier to improve overall efficiency because now there is an actual process to improve.

Posted on

A Systematic Approach to Part Shortages – Part 1

The short story of assembly problems is lack of parts. Part shortages drive all kinds of waste, including: juggling the schedule; expediting; bigger lots or batches – and all of these things end up causing shortages later on in a self-reinforcing death spiral.

So how did an assembly shop which built about 10 units / day, and suffered between a dozen and 20 line-stopping part shortages a day end up eliminating all but a few (3-5) a week?

Three things, more or less at the same time. This post talks about the first:

Implement a kanban system to replace MRP ordering. They systematically studied how kanban is supposed to work, and, over a few months, put in a kanban system which I am proud to say was really pretty good. The assembly line was fed by kit carts which were picked at takt time from a small supermarket on the shop floor. The supermarket held a day or two of parts. The parts with local suppliers were replenished right from the receiving dock. Parts which had to still be purchased in larger quantities were stored in a warehouse area, and the shop floor supermarket was replenished from the warehouse daily.

The daily warehouse replenishment established the concept of isolating the problem. Their daily replenishment allowed them to set up the shop floor supermarket as if all of their suppliers were delivering daily.

All parts in the shop-floor supermarket and the warehouse were under kanban control. This means they had kanban cards physically attached to the parts (if they were separate) or the containers.

Some things they learned over time:

  • The rules of kanban state that the card should be pulled and placed in the post when the first part is removed from the container. The quickly learned this was far more likely to happen if they secured the card in a place where it was in the way of either opening the container (over the folding lid, for example) or had to be moved (e.g. picked up) to get the first part out. At that point the card is in the person’s hand and he has to put it somewhere.
  • The number 1 reason for lost cards was that “put it somewhere” was a pocket.
  • The number 1 reason why the card ended up in a pocket was that the kanban post was more than a step away from the place where the card was pulled. That meant the person put it in the pocket “for a second” while he got the parts.

In the above case the countermeasure was simple. Put kanban collection points everywhere where parts are handled.

  • The first time they tried putting a pull system in for parts ordering they hadn’t put in heijunka (production volume and mix leveling) first. That was a problem, and “problem” is an understatement.

The countermeasure was (obviously) to simultaneously implement a schedule leveling system to drive the upstream system at takt. More about that in Part 2.

  • They invariably had some parts where they had more than they needed.

The countermeasure was “black cards” (though I would have preferred bright orange cards) that signified “excess inventory.” These cards allowed them to maintain kanban control of all inventory, but they did not signal replenishment.

When a card was pulled, the shop floor coordinator would scan a barcode on the card. This scan triggered an order release to the supplier, and authorized the supplier to ship the indicated quantity.

Actual card from this organization being scanned.
Actual card from this organization being scanned.

They had agreements with the suppliers that there would be an email acknowledgment of the order within 2 hours. When the card was scanned, it was placed in a slot labeled with the time when the acknowledgment was expected. When (if) that time passed and the acknowledgment had not been received, the card went to the buyer who phoned the supplier. “Did you get my order? I need the acknowledgment within 2 hours like we agreed.”

This served two purposes. First, it verified receipt of the order and eliminated a known cause of shortages. Second it “trained” the suppliers that this time the customer actually expected them to honor the agreement. They really didn’t want that call from the buyer who had better things to do.

Once the acknowledgment was received, the card went to the receiving dock. Here it was placed in a slot that indicated the day (and later on, the time window) when those parts were supposed to arrive.

Like the above case, if the time passed, the card went to our poor hapless buyer. He phoned the supplier with a simple question: “Where’s my parts?”

This reinforced that, once again, there was an expectation to honor agreements. They really didn’t care that much (at this point) what the supplier’s lead time was. Only that it was honored. The main objective when starting out was simple consistent execution.

When the parts came in, the card was retrieved, matched with the order to verify, then scanned again to trigger a receipt transaction. If there were exceptions – guess what – another phone call.

The card was then attached to the container. Since the card specified the storage location, put-away was fairly straight forward. No location lookups required.

The previous condition had been that there was no matching of receipts against expectations. Thus if parts were late, or didn’t show up at all, no one noticed until they ran out. Big problem. By trapping and surfacing problems at the two main failure points in the system, most of those problems went away after a few months.

For the purists who are reading – yes, this process has some compromises and probably is a bit obsessive on checks. Call those training wheels until there is a sense of balance. All I can say is that it worked and, in the long run, ended up to be a lot less work than chasing down and expediting shortages all day.

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

Is The MRP Algorithm Fatally Flawed?

(Links updated Feb 24, 2010)

Robert Johnston, now at the University of Melbourne   holding the John Skarkey Chair of Information Systems and Organisation at the UCD School of Business in Ireland, did his PhD work at Monash University in Australia. His dissertation, “The Problem With Planning” presents a thought provoking thesis.

– Early robotics and computational intelligence models were built on a model which research at MIT debunked as unworkable in the 1980’s.

– The MRP algorithm uses the same model.

– Therefore, MRP is also unworkable.

Further, his dissertation goes on to postulate that the successful models currently being exploited by the latest research at MIT (which, by the way, are commercially exploited by the Roomba) share many similar characteristics with kanban systems.

I will extrapolate a bit and comment that kanban systems are a subset of a general shop floor information management model that is outlined in “Decoding the DNA of the Toyota Production System” by Spear and Bowen. Johnston’s work pre-dates Spear’s publication, so it is not referenced, but if you actually read Spear’s dissertation you can see the similarities in the details.

And yes, when I wrote to Dr. Johnston his first comment back was surprise that someone had actually read his dissertation. Take a look. Chapters 1-5 are mostly theoretical background and history. The interesting part starts at Chapter 6.