Lean is a subset of profit improvement. Everything about lean will enhance profits, but there are a lot of profit enhancing ideas and strategies that have nothing to do with lean. I just thought I would point that out for the benefit of all of the folks out there who want to put every good idea under the lean umbrella.
In writing the blog one of my daily routines (beyond reading 40+ newspapers every morning) is to do a Google news search for ‘lean’. You might want to give it a try. You will find that most of the results are not actually news reports, but press releases from companies and people trying to promote their ‘lean-ness’. Among the legitimate news stories, you will find that many – probably most – of them fall under the cost reduction heading, but have nothing to do with lean.
Taichi Ohno said, “All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by eliminating the non-value adding wastes.” So the articles about increasing labor efficiencies, reducing the amount of excess material scrapped during production processes, minimizing carbon footprints and material going to landfills, and so much more have nothing to do with lean. They are probably good ideas. I don’t mean to discourage them – in fact I stand foursquare in favor of many of them – but they are not lean driven, not does the successful application of such ideas make an organization lean.
The problem seems to be taking the idea of “non-value adding wastes” out of context. In fact, any time you can reduce or eliminate a cost, and it does not detract from the value of the product you are selling, that cost was, by definition, a non-value adding waste. There is nothing new or lean about doing that. The history of work is one of ideas and technologies that eliminated non-value adding wastes, but the history of work is hardly one of continual evolution toward lean.
The debates and often confusion among and between lean and Six Sigma advocates stems from the fact that they get at the same root. When I went to Motorola University in the early days of Six Sigma and long before multi-colored belts were involved, the originators of the concept endlessly pounded on the mantra “The best quality producer is the shortest cycle time producer, and the shortest cycle time producer is always the best cost producer“. There is an awful lot done under the name of Six Sigma out of this context, as well.
The problem this dumping everything that reduces costs into the lean bucket causes is that it sends the message that organizations can become lean without making the fundamental changes in thinking and culture required to follow the Taichi Ohno and original Six Sigma principle. As a result, they leave the fantastic benefits of becoming truly lean on the table. It is also problematic and quite confusing when so many purveyors of knowledge, be they consultants or academics, miss this fundamental point and preach lean or Six Sigma outiside the context of cycle time and flow. They seriously mislead those who look to them for guidance and wisdom.
So how lean is your organization? Is inventory turning much faster? Is the time from beginning to end of core processes much shorter? Do your customers go from initiating contact with you to completion of that interaction much quicker? If the answer is no, then you are not particularly lean, no matter what you may have done to cut costs, reduce waste or improve the culture.
Eponine Pauchard says
This is an excellent reminder. I have translated this article in french on my blog, to share it with french speakers. Unfortunately, in french too, lean is a “à la mode” word and used everywhere. On Google search of “lean” in french today, I found the concept of “responsible lean” that would use the lean tools but with respect to people and inclusions of ergonomics and “sustainable lean” that would include the reduction of waste for the planet… Long way to go.
Rick Bohan says
What Bill said.
Christopher Mahan says
Whenever I talk about lean in software development, I always say: “The guy who delivers software to the user fastest will win.” They counter that the software needs to follow established methodologies in order to be bug-free and really meet customer requirements. I counter that if I do the fix while on the phone with the client, and push the software to the client so can see that what they asked for is working, I don’t need that whole rigamarole of IT processes.
They look shocked, but I reply: “In five minutes, you don’t have time to get fancy. Just do the simplest thing that will work and deliver that.”
The ability to do this comes from rigorous mental training and the recognition that if you can’t do it right now while fully focused on the customer, you probably can’t do it at all and you should tell them: “I can’t do it”. It’s frankly better than saying: “I’ll get it done” then not keeping your promise.
I’m a long-time reader of this blog. I’ve even bought and read the Evolving Excellence book. I’ve read Deming, and Ford, and some others like Matthew May. My wife is Japanese, and has a very good friend who works in HR in Japan. (He says Toyota takes the toyota way too seriously sometimes and they miss interesting people, ebcause of monoculture). I’ve worked in the restaurant business and IT for small and large companies.
I’ve looked at adapting lean to creating software, and I realized that using the brain is much more effective than any “tools” out there, since whatever the software is doing can be internalized in the brain. Essentially, I write the software in the mind, and once it works, I just type it out. The “tools” that one needs are all in the head already, but one must train oneself to use them. So to me lean in software means not offloading any mental process to physical processes (a form of outsourcing), because that only adds complexity, and makes the whole process of delivering software slower. Essentially, the brain becomes the software factory.
It’s not easy, but it can be done. And it makes the customer very, very happy.