Using Takt Time to Find Problems Earlier | Zsolt Fabók

See on Scoop.itlean manufacturing

“The idea of takt time comes from car manufacturing. It shows the elapsed time between two completely assembled cars leaving the factory floor. If the takt time is 2 hours, it means that the factory produces 12 cars a day (24h/2h = 12)…”

Michel Baudin‘s comments:

A nice effort from a software developer to discuss the relevance of the concept of takt to his profession, or lack thereof. Unfortunately, he gets a few details wrong.

The first sentence is “The idea of takt time comes from car manufacturing.” Well, not exactly. Try aircraft manufacturing in Germany in the 1930s.

His example of a car manufacturing plant making 12 cars/day is a bit odd. I suppose such plants may exist in the extreme luxury end of the industry, but 1,000 cars/day at a takt time of 1 minute while working two shifts/day is more common.

“Car manufacturers are producing the same kind of car over and over again.” Well, not exactly. In the past 100 years, the industry has changed. You now make multiple models of cars on the same line, and each unit has its own build manifest with configuration options.

And car companies do not change the takt time every week. It’s more like every four months. Contrary to what the author says, the takt time is not a tool for throughput prediction. The throughput prediction is an input to the calculation of the takt time,  which is a tool to drive how you design and operate production lines. It is adjusted to reflect changes in demand, but not fluctuations, because changing the takt time of a line involves rebalancing the jobs in it.

Having worked in both worlds, I agree that car manufacturing practices are irrelevant to software development. Software development is development, not production. If you want similarity and management tools with crossover value, you should look instead at product development in other industries, not the production of existing products.

See on