Properly Applying Auto-Eject Isn’t Automatic
I’m working on improving the design of our machines for lean manufacturing, and hear that an auto-eject feature can support this work. If this is so, can you clarify how?
I was reflecting on this very question a few months ago, incongruously, as I was sitting at a table at a conference in Shanghai, in front of a pile of books to sign (which, let me say as an author, is more an occupational hazard than a sign of fortune and fame). We were late on our schedule and the idea was to go through signing the books as quickly as possible. One gentleman there was kindly trying to be helpful by taking the books off the pile, opening the first page and presenting it to me to sign. Quite a natural reflex when one lends a hand to accelerate a process by pushing it along. But this was not helping much. Let’s look at why.
In order to sign a book, I have to hold it so that (1) I can position it correctly to sign and (2) it doesn’t slip away as I apply the pen. Each time I was presented with the book the handoff caused an unnecessary fumble as I tried to grab and keep the page open and position it correctly. And, my signing hand was encumbered by the just-signed book that was still in front of me. After several of these mishaps it struck me that what I needed was an auto-eject (yes, I know, too much lean thinking, another occupational hazard). And so I asked the gentleman to help me get rid of the just-signed book rather than feeding me a new book to sign.
When we finally settled down to the new arrangement it went much faster – to my satisfaction (hypothesis confirmed, ha!) and his surprise. First we avoided the over-processing waste of me grabbing the open book and often reopening it again, and second, we eliminated a lot of muda movements. Considering the quick cycle involved in signing a book, we about halved the cycle, which does mean a lot when you have three huge piles sitting in front of you. It was funny, because, as on the shop floor, I was surprised at how greatly overall production can be improved by eliminating movement waste from a short cycle.
Auto-eject is essential for the simple reason that positioning a part is hard, and usually demands human judgment and in many cases, human experience; but ejecting a part is easy, as the action consists mostly of releasing the part from the fixture and pushing it gently into a receptacle. Getting a robot to position a part is always tricky and tolerates very little variation in both part and fixture. Actually, getting an operator to position a part correctly is no walk in the park either, which you find out when, for whatever reason, there is no direct line of sight. The operator inevitably fumbles if her hand can’t follow her eyes. Essentially, placing the part in the machine is where the real value is, not picking it out or starting the cycle.
You may wonder about the value of an auto-eject if the finished part is ejected from the machine and the operator then puts it into a finished parts container? Not much, I agree. In many factories we find operators standing in front of a machine with a container of components on their left and finished parts on their right. They pick up the main component and the other bits and bobs to assemble, they set all of it in the fixture, they take a step back to clear the safety light-guards, they push the button to start the cycle, wait for the machine to do its job, get the part out of the fixture and place it in the finished parts container. Auto-eject will gain a few seconds at the most on a cycle where most of the muda consists of waiting for the machine to do its stuff.
Here, we have to consider a second fundamental principle of lean: don’t tie operators to a machine and don’t create isolated islands. As long as one operator is tied to one machine, he will have to babysit it while it cycles. Some people try to cheat with rotating tables that reduce the waiting time (the operation of the machine is conducted at the back of the table) but, nonetheless, the operator is still feeding the machine and taking parts off. Essentially, no matter how much you improve this workstation, you won’t be able to use the productive time liberated other than by producing more, which would be overproduction--a big no-no. One tenth of a person is a person if they don’t have another value-adding job to do.
In order to get the benefit of any kaizen, we would then have to bring another machine close to the first one, and ask the operator to operate the first one, then the second. In the best of cases, this second operation would be conducted on the same part, so that more value is added (unfortunately, in many cases, you have to bring another part in, which creates all sorts of logistics difficulties). But say we’re lucky, we can bring the next operation on this part in the cell.
The idea now is that while the machine cycles, the operator can place the part in the second machine and start the second cycle. But wait a minute – where does the part come from? If the operator had to pull it out of the machine, she’d still have to wait for the machine to finish to get the part out. If not, she’d need a stock of parts between the machines. In that case, she still has to put it in the machine, and then out of the machine to place the second part. This is usually the case anyhow because machines are separated by safety lightguards, chicken wire, containers of components, electrical panels and so on.
If there is an auto-eject on the first machine, however, the operator can use the ejected part and place it in the second machine while the first operates. She is no longer tied to the machine. And, in fact, if the cell is designed without any barriers to the flow of parts between one machine and the next, the operator can simply push the auto-ejected part in the next fixture, and can probably deal with a third, fourth, fifth machine in the same cycle time, and with lowered ergonomic burden.
cell or Obstacle Course?
Like most things in lean, auto-eject in itself does not provide any special benefits. It’s the reflection of a deeper manufacturing thinking of a cell as a flow of parts. In most cases I know, industrial engineers design a process, then pick (or design) the equipment needed to realize each step of this process and arrange these machines in a production cell. Even when they’ve made a “lean design” effort of creating a “U-cell” to limit operator walking, we find that moving a part from one machine to the other is a real obstacle course, and that it takes most of the operator’s working time to do so, with large machines, heavily built and guarded, component racks between machines and the ubiquitous electrical cabinets (by the way, check those over-engineered poka-yokes that slow the process and give out false positives in order to make production even more challenging in the name of “lean”).
Lean thinking leads you to look at the process differently, think about the technical minimum solution to realize every step of the process, and then design a cell so that (1) the parts flows unhindered from one fixture to the other and (2) the operator can easily place the part in the next fixture without risking life and limb or straining themselves as they’ll do so several hundred times a shift.
Auto-eject is a critical aspect of designing a lean cell, which only makes sense in the context of applying lean thinking to the entire cell conception. Without it, it’s just one more device with limited benefits. The answer to the question is the same as always: start from the operator’s movements and look at the flow of parts. If you work with the operators themselves to find a better compromise for both you’ll get a leaner cell, where auto-eject will help disproportionately.
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?