You don’t give a diabetic more sugar on his/her diet so to normalize you have to give proper food that keeps insulin under control. The same is true for Lean. If the company is addicted to technology you need to detox before going forward. I would force at least 7 alternative designs (ala 3P method) and have at least 3-4 designs that are no automation no technology in terms of IT support.

It worked out great and as we detoxed from our automation addiction we introduced some new technologies like devices that would help move the computers. But the technologies were reliable!

Ankit
http://TheLeanWayConsulting.blogspot.com

1. lean and technology can work together
2. know the problem first, use technology only as a solution
3. keep it simple
4. prove the technology before unleashing on people
5. go and see, either the use or the problem, before trying to fix it

Thanks.

But let me comment with this slightly different twist on the survey material which is the foundation for this article to begin with. Both AMR Research and the Aberdeen Group provide sponsored research. The articles or reports written as a result of this research, and of course the research itself, are paid for by companies which sell the product or service being researched. Those companies can then cite this research as the authority which supports the value of that product or service to prospective clients. Gettin’ the picture?

I recently received a complimentary research report from Aberdeen on “Integrated Talent Management” (Abdereen’s “suggested value $399, but no charge to me, and for a limited time only). This report was prepared “in cooperation with” seven vendors of talent management software; all seven vendor names appeared in the email promotion as well as in the article itself. When was the last time we saw a research report sponsored by Pfizer on the efficacy of Viagra ™ that said the stuff doesn’t work?

So, perhaps that’s why the article, as you note, appears to be “a bit one-sided…”

And that’s the way I see it.
Adam Zak

Great question! It has prompted some great comments. I hope my comment is worthy of the others.

After having worked as general manager in a manufacturing environment during it’s lean journey and as general manager for a downstream production automation software company, I have to say that lean and technology depend on each other for best case success.

In my experience, many leaders of companies will mistakenly assume that, if software technology is installed, the software will seek out and discover the most efficient processes, thereby absolving the organization of the responsibility and time to develop solutions themselves. This is a thought process of laziness, the results of which are littered with software failures.

Lean is best served by line and staff personnel discovering and developing the most efficient processes themselves without the assistance of technology. The organization discovers the solutions as a team, own the solutions, and are more likely to gain and sustain a belief system in lean.

Where technology assists lean is in the continuity of ongoing implementation and discoveries of new idea suggestions for lean improvement. Software, in particular, downstream automation software, has the capability to make suggestions in real time, based on lean business rules. But until the business rules of lean are established, such software technology is incapable to make best suggestions.

There is a low risk tolerance for software techology in the manufacturing sector, which also creates the divisive effect of which your question speaks.

It’s always instructive to look at who funds the research report since the analyst firm’s work will always reflect the desired outcome of their customer at least to some degree. The survey results then aren’t a surprise.

The comments about software developers not getting out to understand the process in detail are well founded. And it will show up in ease of use and functionality of the software. I can’t tell you the amount I’ve learned from each customer that has resulted in new capabilities that expand on a more simplistic base. The challenge with a generic product is to maintain the proper balance between over-engineering and complexity vs. handling every unique situation.

I’d offer another consideration for the use of technology. Use the simplest technology possible. If you can do it on a whiteboard, that’s great. If you can do it in Excel, fine. But recognize that there are situations where the amount of data, the dynamics of rapid change, and the complexity of the situation will require a more sophisticated solution. Then it’s time to find the right technology that solves the problem. At the end of the day, technology is not an end in itself, only a means to move us closer to the ideal state.

And last, while lean should be technology agnostic, in practice it certainly isn’t. The anti-technology bias is very strong. Unfortunately the operative word is “bias” which connotes a unwillingness to consider other alternatives.

I’ve hear enough of the inside story of developing IT systems, even for advanced lean applications like those in the auto companies, to have a prejudice against them, even though there are some examples of information systems that are based on lean thinking. Highly paid “business analysts” and consultants sit in a room in an office building debating insignificant issues and burn money without ever setting foot in a plant. Meanwhile they perpetuate processes, like populating a whole new database for a model year change (taking the work of several people for several weeks) when it is now simply a set of engineering changes that take place in one point in time. It is simply another attribute of a product variation. This blindness is not only stupid, it shackles the company for the life of that system, which is usually about 20 years.

I continue to return to Jeff Liker’s story of the head of Motomachi who looked at the IT guy’s beautiful systems plan and swept it off the table telling him to come back after he’d produced something that would help them build cars. Toyota does use a lot of automation and IT, but it also tears it out where it is not doing any good.

Support the making of the product or service, work in the gemba, follow the process, make the system flexible and easy to change, prototype and release in a spiral fashion.

I’m suspicious of “intelligent” this or “optimized” that from the software world. I’m not anti-technology, but I believe strongly in the Toyota Way principle that you should only use well-tested technology that serves your people and your processes. Too many hospitals look for a silver bullet technology solution, maybe they’re worse than factories on this front, even.

Look at all the hype around Electronic Medical Records… you have the same promise and pitfalls as ERP in manufacturing, it’s a pretty similar sad tale oftentimes. Too many design and implementation decisions are made far away from the gemba, not involving the nurses or docs or other users… and we wonder why quality is poor and costs are high?