The "Plan for Every Food" in my household involves different policies for buying coffee beans and fresh raspberries. These simple examples show that thinking in terms of Economic Order Quantity (EOQ) isn't always wrong, and Just-In-Time (JIT) isn't always right. You need to set appropriate policies for screws, steel bars, engines, microchips, and all other items you may need, and review these policies periodically as circumstances change.
"More robots means lower unemployment and better trade performance. [...] The United States does not lose jobs because there is not enough work to be done but rather because U.S. industry is not competitive with foreign producers. More robots will help fix this."
It doesn't mean robots are bad, only that they are not a panacea. Toyota's Global Body Line is designed to use welding robots where they are justified, and manual welding where not, using the same fixtures.
In an auto parts plant in Japan, I remember seeing a machining cell with old machines served by robots. A few yards away were new, automated lines that didn't use robots.
It looked very much as if the old cell with new robots was the result of incremental automation, and that the lessons learned had been applied in the design of the new lines.
Robots are tools. If you know how to use them, they will help you; if you don't, buying more is just a waste of money.
"In the first six to 12 months, get the turkeys out. Don’t drag your feet."
The problem with this approach is that, at the outset of Lean transformation, management doesn't know what it's doing. It's not the managers' fault, but the skills of leading a Lean transformation in this particular organization have to be learned along the way.
More often than not, the author's version of "addressing the issue early" means firing loyal employees for disagreeing with something you later realize was wrong. And the message it sends is not one of commitment but of a mixture of brutality, incompetence and disrespect.
"A 'how to' outline for executives trying to do an effective Gemba Walk"
No disagreement with what Michael Bremer is saying, but I would emphasize observation skills more.
One exercise Kei Abe came up with is the bug hunt. You take a team of managers to the floor and give each one 20 red tags. They they have 20 minutes to attach the tags to such "bugs" as frayed cables, devices held with duct tape, puddles of lubricant, misplaced items, etc. They usually have no trouble using all 20 tags.
I also ask people to be like the Count in Sesame Street and count people walking, machines not working, etc. These activities have a data collection and validation value in their own right, but they also focus the eyes of participants and make them notice details they would otherwise miss.
Organizations that produce documents -- whether they are publications for sale, standard tests for schools, legal templates, or work instructions for production -- face challenges that differ from manufacturing, because data and materials don't flow the same way. The production of a document by a team is a process of collaborative editing, not a fixed sequence of standardized operations.
With electronic documents, you need a revision management system to prevent inconsistent updates, you need to cap the number of documents in process to control lead time, and you may need to improve the work flow or increase the team size if saturated.
Tools like 5S are irrelevant in this context, because the work takes place inside a computer network, not in the physical office, and setting up an effective network -- with the right software properly configured -- requires information systems professionals at the state of the art. What looks like rework in this context is a collaborative editing process that must be managed, not eliminated.
Frederick Taylor is an easy target. In a tweet last November Michael Ballé, as "@Thegembacoach" attributed to "taylorism" practices that I have never seen advocated in Taylor's writings. Enough of Taylor's own work is questionable that we don't need to pile on other people's bad ideas. Along with the chaff , however, there is wheat, and we have more to learn from the enduring part of Taylor's legacy than from what has been discredited.
"In the beginning Toyota created TPS, then came Motorola in 1986 with their six sigma process. In 1988 John Krafcik coined the term Lean in his paper entitled“Triumph of the Lean production system” which was quickly popularised by Womack, Roos and Jones in 1991 with the publication of their book “The machine that changed the world”. Then in 2002 Michael George and Robert Lawrence junior published their book entitled “Lean Six Sigma: Combining Six Sigma with Lean Speed”.
Ever since this point organisations have been attempting to mesh the 2 methodologies into one business improvement technique and failing."
Troy speaks from experience. Mine is similar, but I am not as negative on Six Sigma as he is. I think of Six Sigma as an approach that is useful within a range of applicability and is limited in scope.
This is a perennial topic in all groups related to Lean. In the TPS principles and practice discussion group on LinkedIn, Bertrand Olivar and Kris Hallan recently started new discussions on the sustainability of Kaizen event results and on the means of achieving them. Most contributors hold extreme positions, the majority saying that Kaizen events are a panacea, and a growing minority that they are worthless.
In this you-are-with-us-or-against-us atmosphere, it is a challenge to get a hearing for the nuanced position I hold, which I summarize as follows:
- Kaizen events are not part of TPS
- Kaizen events are a valuable tool
- Kaizen events are not a panacea.
- Content should dictate how projects are managed, not the other way around.
Because it is a recurring topic, I have already accumulated the a trail of posts about it, that are referenced at the end.