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.”[1] 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.[2]
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. [3]
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?
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.