Home > Community> The Lean Post> Ask Art: Is there a conflict between automation/IT and lean?

Ask Art: Is there a conflict between automation/IT and lean?

by Art Byrne
July 12, 2017

Ask Art: Is there a conflict between automation/IT and lean?

by Art Byrne
July 12, 2017 | Comments (11)

In today’s world, it certainly feels like automation and the use of digital technology can solve almost any problem. Both approaches can create great value and should be used where they make sense. And, when it comes to lean and automation or IT, I see no conflict with computer programs that can speed up and simplify work that traditionally may have been only done manually. New inventions and solutions have been at the heart of productivity gains since the industrial revolution, and I expect that not only will this trend continue but it will accelerate over time. In fact, I hope it will as it has been a key driver in raising millions of people out of poverty.

I will however caution people to be careful in how they blend lean practice with these tools. Over the years, in many industries, I have seen people frequently misuse an IT or automation solution by, to use lean speak, “automating the waste.” (Or as others have labled this, paving the cow paths.) You see this most frequently in industries with many small transactions, where keeping track of them requires the use of computers, such as banks, insurance companies, mortgage brokers, governments, universities and other similar businesses. Hospitals, with their needs for data management for both patient safety and meeting various regulations, are another good example.

In many of these businesses, when a problem arises the knee jerk reaction is to create another computer program to solve the problem. Get the IT people down here right away and tell them: “Here is what we need you to do, how fast can you get it done?” Sound familiar? In places like hospitals, this can not only be expensive but can create new problems. I have seen cases, for example, in hospitals that are organized and run by silos, where the various silos all implement new computer programs to solve their own problems, only to find that none of these programs can talk to other programs and even more money needs to be spent to get them to communicate.

Often a new, and completely unnecessary, computer program is developed to solve a problem that wouldn’t exist if other parts of the system did their work properly. I came across this in a life insurance company that I was helping with some kaizen work. At the time it took the company 48 days to underwrite (i.e. respond to a request for a quote) a new life policy. And they relied on an elaborate and costly (in money and manpower) computer program that tracked the status of all the underwriting requests in the system. They said they needed this program to answer the many requests they received from the insurance agents on the status of their policies. Of course this was only needed because it took them 48 days to get back to the agents with a quote. By using lean to shorten this lead-time, we were able to get most of the quotes turned around in less than 20 days, with a good trend to do it in 10 days. As a result, this program was no longer necessary. 

The same can happen in manufacturing companies where engineers love to develop high speed (and very costly) solutions as a first choice to almost any problem. Sometimes this can delay new product introductions or cause massive over capacity when the marketing forecast turns out to be way off the mark.  Conversely, if something changes in the product spec later on, the high speed automated line may turn out to be obsolete or require massive capital spending to produce to the new spec. If you ask most manufacturing engineers to cut the setup time on your equipment by 50%, they will often come back with some very expensive automated solution a long lead time. My experience with lean is that setup can be reduced by 90 percent during a one week kaizen without spending much money at all. How much can you even spend in one week?

The point here is that if you first use lean to find and remove the waste from your processes, then when you do decide to automate you will do it step by step. You will then spend a lot less money and automate only what makes sense to automate. Lean will give you a clear picture of where you are and what needs to be done. The same of course holds true for computer programs. A little value stream mapping and kaizen to get rid of the waste first will cut your costs and speed the response.

So yes, lean and automation or IT solutions are compatible, but only if you use lean first to eliminate the waste before you leap into expensive whiz-bang solutions.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.
Search Posts:
Key Concepts of Lean
Dave LaHote, David Meier, Ernie Richardson, Joe Murli, Karl Ohaus, Michael Hoseus, Tom Shuker & Tracey Richardson
Value-Stream Mapping: a Methodology for Sustainable System Improvement
Jim Luckman, Judy Worth, Karl Ohaus & Tom Shuker
The Work of Management
By Jim Lancaster
May 17, 2017 | 14 Comments
Was this post... Click all that apply
HELPFUL INTERESTING INSPIRING ACCURATE
15 people say YES
16 people say YES
6 people say YES
16 people say YES
11 Comments | Post a Comment
Sarah Topham July 12, 2017
3 People AGREE with this comment

Great article and well said!  I am the Lean Leader in IT in higher education and my trainings always include:  Eliminate - Simplify - Automate.  IT folks tend to do the reverse but many have found it very rewarding when they do eliminate the waste first.



Reply »

art byrne July 12, 2017

Sarah, thanks for your nice comments. Your training is good to focus on eliminating the waste and simplifying things before you automate. Unfortunately it is often difficult to get people to admit that there is any waste in the first place let alone having any idea of how to eliminate it. This is where the lean approach and many of the lean tools come into play. Having leadership from people like yourself however is always the key ingrediant. Art.



Reply »

Philip Holt July 12, 2017

Thank you Art,

A well balanced article, illustrating that it's not Lean or Automation but Lean AND Automation but bearing in mind what Drucker famously said: "There is nothing so useless as doing efficiently that which should not be done at all".

Thanks,

Philip



Reply »

art byrne July 12, 2017

Philip, thanks for your comments. I love your quote from Drucker. It couldn't be more true but getting people to admit they are doing something unnessary is very difficult. Think of all the detailed reports and systems that were created in response to some problem that happened years ago that are still being churned out despite the fact that no one reads them and that the problem might have gone away a long time ago. Art.



Reply »

Daniel Jones July 13, 2017
1 Person AGREES with this comment

One of the most helpful posts on this topic. Don't throw your lean knowledge away before automating and keep it simple. But if it. Helps then use it. Create a dialogue between those running the process with the hardware and software designers - rather than just let the experts design alternative solutions in isolation. Another example of common sense we don't use enough.



Reply »

art byrne July 13, 2017

Dan, thanks for the nice comments. Your right that using common sense is sometimes lacking when people rush to automate something that may not even be needed. I like the expression, "use your brain and not your wallet" as a way to describe the type of thinking needed. Eliminating the waste should always proceed any expensive IT or automation spending. Art.



Reply »

Gorm Bue Nielsen July 17, 2017

Great and relevant article.

This is actually the third time today I am referring to an old article by Michael Hammer, 1990. "Don't automate, obliterate".

The message is the same - clean up your processes before you pour out the "IT-concrete" on to your processes.

I fully agree on you key statement: Lean and IT-automation goes hand in hand, however - not all lean work has to end up in an automated IT-system.



Reply »

art byrne July 17, 2017

Gorm, thanks for your comments I'm glad you liked the post. I don't recall the Hammer article but I certainly agree with him. I also agree with you that not all lean work has to end up in an automated IT system. For example lets say you are having a hard time responding for requests for quotes on your product. It takes you 45 days on average so you create an expensive IT system just to keep track of all the quotes so that you can give customers an answer when they call to find out where their request for a quote is. Of course the only reason you need this IT system is because it takes you 45 days to respond. If you could reply in 5 days you wouldn't need the system and no one would be calling asking where their quote was. Art.



Reply »

Owen Berkeley-Hill July 18, 2017

Couldn't agree more! Having spent over 25 years in Ford's IT department I cannot help but resonate with what you have said. 

So why aren't all IT professionals taught Lean and problem solving? I suppose that would correct a steering defect that sverves immediately to cutting code when faced with a problem, but that would go against the IT culture which has an obsession with technology.



Reply »

art byrne July 18, 2017

Owen, thanks for your comments. You are right that changing the culture is the hardest part. If the IT department is told we need a new program to do such and such this is new work and a new challenge for them so it is unlikely that they would ask "why do you need this?" Even if they were good enough to do that the operating department either has what they think is a good reason or they just tell IT to shut up and do it. More waste gets automated this way. It should be a requirement that you have to ask the 5 whys before any new code gets written.Art.



Reply »

Raj Wall July 20, 2017

I would say the biggest problem for Lean and IT is that IT methodologists are making the same fundamental mistakes the auto manufacturers made in the ‘80’s: They see Kanban but miss Kaizen.

The big push in IT methodology today is “Agile”. A “new” agile method is called “Kanban”. When I coach IT teams I make a point to differentiate between Kanban the tool, and Kaizen the mindset. I relate the anecdote of Ohno-san and the Detroit executives. I explain that there is a hundred years of lessons learned to leverage. But as long as the big name methodology vendors push the idea that they invented the wheel yesterday, the industry will continue to suffer.



Reply »

Search Posts:
Key Concepts of Lean
Dave LaHote, David Meier, Ernie Richardson, Joe Murli, Karl Ohaus, Michael Hoseus, Tom Shuker & Tracey Richardson
Value-Stream Mapping: a Methodology for Sustainable System Improvement
Jim Luckman, Judy Worth, Karl Ohaus & Tom Shuker
The Work of Management
By Jim Lancaster
May 17, 2017 | 14 Comments