One question I see coming up a lot in various forums is how to deal with issues unique to very long takt times. By “very long” I usually hear about many hours, sometimes days, occasionally weeks. Because it comes up fairly often, I thought I would take a shot at addressing it here.
I think the biggest hurdle for people to get over is the issues are largely the same as shorter takt times. They are just harder to see because the work starts to lose a human time scale. The trick is to get it back onto a time scale that people can relate to.
By this I mean that a person, generally, loses a sense of how long something is taking once it goes beyond a dozen minutes or so. In contrast, the stereotypical automobile line has a takt of about 60 seconds. Once an auto assembly worker loses 3 or 4 seconds of time, there is really no way she will be able to complete the programmed work cycle without help or stopping the line for at least a few seconds.
As work cycles get longer, though, the work remaining until “done” gets more and more disassociated from “now” and the idea of the necessity to maintain a particular work pace becomes abstract. This is less of a technical issue than one of human psychology. People, in general. tend to believe they can finish something in time long after that is no longer true. (Ask any college freshman working on a term paper.)
The countermeasure is the same as a manager would apply to any long project: milestones.
When the takt times are relatively short, the “milestones” are the takt intervals themselves. Each takt time signals a stage of work that must be complete. If this is not true, the line will (should) be stopped at that point. (Remember – “Never pass along a defect” and this includes incomplete work.) The problem will be corrected, and the cause understood. Oh – actually this is not quite true. A Toyota assembly line has the work zone divided into 10 sub-intervals, and the worker has a good idea what work should be completed at what point.
However, since most of us are likely just beginning – If your takt time is longer than a couple of dozen minutes, then, define the work in stages. In one operation I suggested the following:
Take about 85% of your long takt time, and divide that into quarters. Define what job should normally be complete by the time each of those check points comes up. As an example – if the takt time was 100 minutes, then determine the expected work completion at 20, 45, 65 and 85 minutes. Give the Team Member a way to know where he is at that point vs. the expectation, and a way to call for help if he is off by even a little bit. He should also call for help before that point if he is disrupted by something that he knows will cause a delay.
This is just a starting point to start to stabilize the system and build your support structure. If you reach the point where things are running smoothly at this level of granularity, then cut those time intervals in half.
At each point you will find more problems. The problems are likely to be smaller, but there will be more of them. All of those problems are sources of friction, and therefore wasted motion and time, on your system.
BUT – before you start down this road, have a few things in place first.
- Establish credibility for the concept that you are genuinely doing this to see problems that are making the worker’s jobs difficult. If you use it, just once, to initiate a negative consequence for “not working fast enough” then forget it.
- Actually work the problems. This means work them to eliminate the causes. Put in a process for managing the problems, make it visible so that the people working can see you are working on them. Again, this is to maintain credibility. If problems get recorded and sunk into a black hole (like a database in a computer somewhere), then you are not assuring the people on the line that you actually care.
- Build your immediate responses (escalation) system. This mean team leaders (first responders) who can, and do, respond to help calls quickly. The only thing worse than having no way to call for help is to call and have no one respond. Again, the system loses credibility after about the third andon pull with no response.
- Don’t worry too much about every detail within the work interval. The important thing, at first is to make sure that the same things get done within that interval. Detailed sequence standardization will come in time.
Summary: The key to managing really long takt times is to break the work into time-based intervals, and manage to those, rather than the entire work cycle itself.
Mark,
I think you really hit the nail on the head at the end of your post, when you say, in summary, “the key to managing really long takt times is to break the work into time-based intervals…” I read a paper somewhere on lean manufacturing that suggested a similar ‘break down’ into what the author suggested to be ‘mini-intervals’ or something of that nature. Sorry I can’t remember where I read the paper but the concept was well explained.
The same strategy (time based intervals) works effectively on training operators on long cycle time jobs. Break it down into portions and train systematically on each portion until the whole job can be done independently. It goes hand in hand with takt time management. If your takt time progress marks are associated with job portions then the operator can easily guage whether they need to call for assistance.
One other factor people tend to forget goes back to the takt time calculation. Avaliable time/# need in the time period. I’ve been working with a solar inverter company that needed to produce 20 residential units per day (7hrs)with a 21 minute takt time. Working with takt times in seconds is so much easier and you can find so much more waste to take out. I dislike anything over 60 seconds and really hate anything over 10 minutes.
They where worried about not having enough space and the ability to ramp up the demand in their current facility. What I saw was no understanding of their true capacity. After doing a quick process walk, noting the “side of the barn, not through the window” cycle time of each work station, I concluded all the work could be completed in 20 minutes each day. What they had not considered was that they didn’t need the 420 minutes. All they needed was 20 work stations with the work balanced to 60 second cycle times in each station and 20 people for 20 minutes each morning to complete the work. It was a small startup at that point and they had 27 total people, so that was totally possible. We need to remember to make sure the available time assumptions are correct too.