Tuesday, February 4, 2014
Getting it Right
With every shiny, new business idea there are those that do it correctly, and those that merely shroud their business practices in a series of buzzwords and improperly tacked-on tools and metrics. In the articles this week, Starbucks found the right ways to fit lean manufacturing principles in to the way its drinks are made and the way that its behind-the-counter operations are arranged with great success. There are others however, that only applied a veneer of lean principles without allowing the philosophy to sink in and successfully integrate into business processes. In a blog post written by “The Old Lean Dude,” the author brings up several important points. He opens with the quote “Understanding little is better than misunderstanding a lot.” He goes on to describe a number of ways in which lean manufacturing and kaizen in general has been misinterpreted. The system itself has a number of relatively simple tools like checklists that are accessible and easy to implement in an organization. The issue that arises though, is that using these tools without finesse or forcing workers to use them arbitrarily creates more harm than good.
Darius Mehri writes of his own experience as a journalist working in Toyota production factory and offers a different critique. He found impetus to drive up efficiency and eliminate wasted effort created an incredibly intense working environment. Although the system he worked under delivered the efficiency that is often touted, it did so at the expense of the workers and the positive culture that is normally said to go hand in hand with employing the Toyota model. He actually directly contradicts the Spear and Bowen article, saying that the pressure and formulaic rigidity actually decreased creativity and worker engagement. 
This all begs the question, clearly there are right ways and wrong ways to implement new supply chain strategies, but how can they best be applied? In order to hone every process down to its most efficient state, a process can employ methods. One is to have the server at that stage in the process to work faster, and place the effort on the moving part that shapes whatever the unit happens to be at that stage. The other is to enable to the server with better logistics or tools to more efficiently modify whatever the work product is. Marrying these two methods together in an elegant way is likely to have the most positive results, but it also requires the right kind of thinking to be done correctly. Are there other examples of over-investing in the server support? The server? Who is the best at uniting the two successfully under a lean implementation?