Tag: Pull

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

Home Appliance Utilization

Bob Hanover has a great little article about applying visual controls to household laundry on his “Thoughtput Solutions” site. (cute way to use TPS as the name for the company, too.)

The concept he outlines is the same one that is (or should be) used to trigger batch run points for kanban managed machines.

But I want to talk about machine utilization, especially of home appliances.

A modern home washing machine can cost anywhere from a few hundred dollars to over a thousand, depending on the make, model and features.

In a household like Bob’s, with two adults and seven kids, it makes sense to ensure this expensive machine is running to full capacity.

To keep the machine running, as each load is complete, the next one should be started, otherwise the machine will sit idle, and that would be bad… right?

Let’s do some math.

Typically a home washing machine completes its automatic cycle in just around half an hour.

Typically a home dryer completes its automatic cycle in around 45-50 minutes.

So, if you want avoid having the washer stand idle, what are you doing to do?

I’ll tell you what nobody does. Nobody keeps putting loads into the washer and piling up wet clothes to wait for the dryer. It is obvious that the dryer is pacing the process, and running loads through the washer faster than the dryer can take them would defy common sense. Wouldn’t it?

Yet we do this all of the time in factories.

Why?

Posted on

Why I Don’t Like Two-Bin Systems

On the surface, a “two bin system” seems a great, simple solution to a part resupply process that could otherwise get complex.

And, on the surface, I don’t argue with that.

But two-bin has some limitations. And because it is so simple to set up, those limitations are frequently not understood or taken into account.

What is “Two Bin?”

Although it may be obvious to all, I want to define “two bin” to reduce the chance that what is “obvious” is actually less so.

“Two bin” is a simple pull system. The parts are supplied by two rotating containers. When a bin is empty, it is returned to the supplying process to refill. The second bin supplies parts while the first one is being filled.

The same system can be applied to things much bigger than “bins.” I have seen carts carrying fabricated steel parts weighing many hundreds of pounds set up the same way.

When does it work?

In general, two-bin is OK when two criteria are met:

  1. The parts are relatively cheap. That is you don’t worry too much about having more than you actually need. This comes with a warning, however. It is easy to have a ton of money tied up in relatively small excesses of hundreds of parts. It does all add up.
  2. This is critical: The time to replenish and return a full bin is short compared to the time to use the parts contained in a full bin.

In this scenario, the first bin is empty, and long before the Team Member has emptied the second bin, the first one is safely returned and is behind it on the shelf.

So What’s The Problem?

There are problems at two levels. I am going to emphasize the practical one, then talk about the philosophical one.

At The Practical Level

First, let me explain how this system would work if it were being done with kanban cards as signals.

One of the rules of kanban cards is that the card is removed from the container when the first part is consumed. That is, the container is NOT empty.

In this type of system, the number of containers circulating is +1 over the number of cards circulating. If you think about it, this makes sense. Let’s say there are five cards circulating, and the container size is 10. If all of the full containers were on the rack, and one part is used from the first container, then the rules state that the card is removed and signals bringing another bin.

If production stops at that point, the worst-case scenario of kanban is realized: The card is returned with another bin of 10 parts. There are now 5 full bins on the shelf, each with a card attached, plus the one bin of 9 parts.

What this has to do with two-bin: Two bin is mathematically identical to a one-card kanban loop.

At a practical level: Do the math for kanban. If your system, with your replenishment quantity and times won’t work with one kanban card, a two-bin won’t work either.

At a Philosophical Level

The problem comes in in practice. Two-bin is easy to set up, and frequently the people doing so don’t do the math. And it usually works.

What results is a pull system that has locked down the number of circulating containers (two), and if there are perceived problems the reflex is to alter the quantity of parts in each bin.

If the system is running a little close to the edge, the materials people will up the parts quantity per-bin from, say, seven parts to ten parts.

Then the system fails.

Why?

With kanban, you signal for replenishment when the first part is removed from the bin. Having more parts in the bin means it takes longer to empty the bin. Your supplier has more time to return with a full bin.

With two-bin, you signal for replenishment when the last part is removed from the bin. Having more parts in the bin means it takes longer to empty the bin. Adding more parts to the bin delays the notification to your supplier that you have started using parts.

While it doesn’t always happen, there are cases when adding even a few parts to the bins will cause two-bin to fail because of this.

No matter what system you use, you must thoroughly understand how it works, why it works. You must think through (and try) every step of the process, not just talk about it.

You must ask questions and understand every detail:

  • If there are hundreds of bins, and they all have part-specific labels, how will they be sorted and routed to the appropriate supplying process?
  • How will the bins be used to visually manage the replenishment process?

These are questions with obvious answers in card systems (that use generic bins), but are frequently not well thought through in the rush to implement the “simpler” circulating bin systems.
Also keep in mind: If you are not constantly monitoring actual use, execution and results against your assumptions and expectations of what should be happening, you might be using pull, but you are not applying the Toyota Production System.

So?

  • Go ahead and use two-bin if you want to. Just do the math and make sure it will work for you.
  • However, if you use cards, or other signals, anywhere consider the complexity you are introducing with more than one system. The rules are different depending on the parts. Remember, you are asking your customers to keep track of all of this.
  • Generally speaking, if your system is operating close to the edge, it is better to use more containers that are smaller. Things will circulate more quickly, and your supplying process will have a much better picture of your consumption patterns.
  • Remember – your objective is to move closer to single-piece-flow. If you move away from that (with bigger containers) you are doing the opposite of kaizen.
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

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.