| 🔍 > Lean Terms Directory |
Symptoms
In the medical world, a symptom is just the visible evidence of a disease or injury. For example, swollen painful joints may be a symptom of arthritis, or nausea might be a symptom of food poisoning.
In continuous improvement, symptoms are similar. They are the “tells” that let you know that there is something that is just not right with a process or product. They are often the only way to identify an underlying problem-the root cause of an issue. A specific type of symptom is the abnormal condition. It is-an indicator that something is disrupting the smooth operation of a process.
There are two main takeaways regarding symptoms in Lean. The first is that you have to learn to identify them. The problem is that we have convinced ourselves that many symptoms are not really indicators of a problem, but rather just the way things are. For example, we may not look at a pile of boxes as a symptom of a problem with inventory management or as a hedge against poor quality, but rather as just the material we need to do business.
As a result, if we are not extremely open to identifying our current conditions as symptoms of problems, we will never go after solutions.
The second issue is that we frequently try to treat the symptom itself, rather than try to prevent the root cause. This is the equivalent of squeezing a balloon. Clamp your hand around one end, and it pops out at the other. When you treat a symptom, instead of the underlying problem, other symptoms have a way of popping up in another location.
So, the better way of dealing with a problem is to go after the root of the problem—the thing causing all the symptoms in the first place.
Why isn’t this done more frequently? After all, it sounds obvious.
- It can be hard to find the root cause. Sometimes symptoms appear to be the underlying problem.
- Root causes are often harder to fix than symptoms.
- Some people link the problem to a symptom rather than the root cause. For example, they may recognize having to search for a specific box as something that is wrong, but might not conclude that the box is hard to find because of the large pile of excess inventory it is buried in. Perhaps they see it instead as a problem with the warehouse management system.
So, be particularly open-minded about what you define as a symptom and be relentless in the way you go after the root cause of the problem.
2 Comments
Mark Romelfanger · February 16, 2011 at 12:40 pm
I would like to know your opinion of the dreaded “human error” response as a root cause.
I have been a quality assurance practioner for 30 years, and I have been educated by what the quality community advocates, but in your mind, or any one elses, is human error ever a true root cause?
I beleive that, in my old age, I can actually justify it in certain limited cases, given the culture and nature of employee thats found in todays market place.
Are there any books or publications about this subject?
Thank You
Mark Romelfanger
Jeff Hajek · February 16, 2011 at 12:49 pm
Mark,
I think you can attribute human error to isolated, one-off types of problems. Everyone has a bad day, or can be distracted by personal problems, or the like.
But for the most part, I think that any problem that is repeated, or that comes from multiple people is a system or process problem.
When I am facilitating kaizen events, I don’t let people use human error as a root cause, so I also don’t generally like to use ‘better training’ as a countermeasure unless it is clear that a solid process is not well known.
Probably the most zealous advocate of what you are talking about is Deming. Out of the Crisis is a bit dated in style and some of the references, but the infomation about process vs. people is spot on.
Thanks for commenting.
Jeff