Root cause is never the person .... REALLY???

No body comes to work to commit a mistake. Everyone comes in to do a neat job.
So when you stop at operator error, you have really put a wrong person to a job. But how do you evaluate it.
Only by a systematic observation. If a person has to put 5 x 2 color marbles into a bag and make such 1000 bags in a day manually, then you cannot expect 100 % good bags, and point to operator error for a miss. Even your Quality General Manager will fail in this task.
Systematically if you see, distraction, speed of work, color recognition, hand eye co-ordination, routine tasks, mundane tasks, efficiency, motivation, .... and many other will contribute.
Why do you think banks have currency note counting machine now... We still count the notes from the ATM or the Bank teller counter right ...
It all depends on what you fix as limit, and be able to accept the performance.
When you simply stop at operator error as the root cause, perhaps you have still few steps left to take forward surely ~~~

 

Premise: When an employee can make a mistake and it gets shipped to the customer, the root cause is not the employee.

Ideas:
- People make mistakes. The system "should" catch the mistakes and correct them before shipping. (note the "should")
- but the catcher is often also a human who can miss it by mistake...the system should catch that too
- but the secondary is a person as well
- and the tertiary
And then of course they can be in collusion
And then of course a single person could know the system well enough to bypass it
and then, and then...

I think operator can be the root cause in two main areas:
- Intentionally bypassing the system (thus not a "mistake").
- Operator incompetence resulting in the operator not doing that job anymore

Management can't tell the future any more than anyone else...else we'd be in Vegas rather than working.
One of the tools used to "ensure competence" is removing incompetent people from the areas where they are not competent. We thought they were competent, but we were wrong.
I've been fooled too often here, even with a training and testing period, to overlook this facet.

When it is in the fab process, these errors should be caught later in the process and not shipped.
The farther down the workflow you are, the harder it is to catch the mistakes.
The two most damaging areas I have seen for incompetence to reside is in the QC inspection stage, and the shipping inspector.
...resulting in "Quis custodiet ipsos custodes? "

No one wants the RCA to read "we play the odds, and this is one of the 0.1% of times we lost"...so we say "Operator Error" instead.
By this reasoning, I would say it is allowable, but should be in the 0.1% of RCA reasons.

rambling over for now.......

 

Bad analogy, I concede.

...and in general I agree with your statement "lack of adequate inspection is not a root cause to anything". However, it is the implied corollary that tightening inspection is never an acceptable corrective action that I have issue with.

The bottom line here is improvement, right?
So if a company identifies a problem, decides more rigorous inspections is a viable solution, then monitors their system and finds that indeed there is improvements and no recurrences of the problem, what's the issue?

I'm always uncomfortable with absolutes ("operator is never the cause", "better inspection is never acceptable corrective action"), and I feel that making a case for these kinds of absolutes only detracts from the central goal which is improvement. Root cause is a useful tool, don't get me wrong. ...but as long as a company goes through the process of identification, action, and monitoring (for effectiveness of the action), I wouldn't necessarily focus on whether they reached the "true" root cause or not, as long as, at the end of the day, they can demonstrate improvement.

I imagine this is VERY common. Most people will put their best foot forward at the interview, training, and probation stages, then settle into a less-productive, less-rigorous state as the job becomes routine.

 

But you need to define the "problem." Is a one time mistake actually a problem? Say you ship 20,000 boxes per year. And you go 3 years and then one box gets the wrong label on it. Is that really a problem? Is it necessary to spend $1000s on automation or error proofing? Or is it a mountain out of a mole hill.

 

That's great. Until you get to beyond the physical possibilities. Say you have a customer design which pushes the limit of a material's physical properties. You run, literally "at the edge." Every so often, one part may crack. Your choice is now between the sieve of visual inspection or money the customer can't afford to change the entire product design.

 

The once in a blue moon occurrence, my observation, is more of a problem with my customer. And I think it is perspective. If I am labeling my process, and once in a blue moon I put the label on wrong, to me it feels like "Why is this such a big deal?" My suppliers feel the same - "c'mon man, it's once in a blue moon...." But my receiving dock feels differently. Once in a blue moon from a bunch of suppliers = pretty frequent for them. And it is a HUGH interruption to their work flow. They have an "offload rhythm" that is really interrupted by a mislabeling issue. So "onesies" can still be very aggravating. It's perspective.

 

THIS, exactly. That is a piece that gets left out all the time. Look at your Cp calculation. It's the ratio of design to production noise. The goal of production/quality is to reduce the noise. But too often design says "it's already been tested" and doesn't hold up their end of the bargain - can we increase the tolerance? If minor flaw = failure, there needs to be a real good reason why the design isn't made more robust.

 

This is tricky. Because it is the exceptions that seem to get us under the microscope of our suppliers. If we start performing poorly "overall" we get a visit from a customer SQ and they come in and tend to work with us pretty well. But if there is an exception .... we get an "army of experts" who start insisting on things that are typically unfeasible or too costly. Sadly, we very much make choices on our 8D controlling that reaction instead of always answering truthfully. Not saying we lie, but we darn sure will obfuscate at times.

At my location, there are some customer SQs I adore because they want to do it right, to advocate for improved quality as BevD says. But then there are others who frankly, I don't think they even understand quality basics, and come in and demand things that are costly, labor intensive, and non value added. Those customer SQs sort of force us into "get them off our back by whatever means necessary." I don't like those days.

 

What I mean is I remove Operator X and replace them with Operator Y and I no longer have a problem. I have actually seen this at my previous job. The process had a component of "art" to it. And some operators just couldn't run some jobs effectively. Others could.

 

Human error is a top level "event" if we may call that. The occurrence of this event could have been due to
a. Lack of awareness - Education/Training could be the solution. - Management issue
b. Lack of Understanding; there is awareness but not enough cognitive ability - Match peg to hole as ncwalker rightly points out. - A management issue
c. Environment; high temperature, humidity, dust, noise, poor lighting, inadequate protection.... This is again a management/administrative issue
d. Behavioral - This alone is directly Human related

Very often, in RCA reports, I have come across Human error as the root cause & training as the solution. A tried & tested way to get away from the human error-training trap is to carry out a multiple why-why analysis with
a. Technical stream
b. Administrative/Management stream
c. Culture or people stream

By following this approach, for a top event, we would have a technical reason, an administrative failure if there is one & behavioral issues as well. The solution would fall into one, two or all of these categories depending on the top event.

 

Adding to Jennifer's point, supervisors often don't have the power to move people around either. "Never take a no from someone without the power to say yes." Our small company doesn't have as hard a time with this because it's easier for management to see things, but it's still there. I can imagine how lost that would get in a big company.

 

This is all extremely interesting. And the human element always does add unpredictable complexity. Lots of good points made. There may BE a bad operator, but the company structure does not allow this to be changed readily. It may be a good operator with a bad supervisor. (Training in how to manage people isn't real prevalent in industry, it should be). I have found that whenever I have needed operators to change behavior, what always works is to draw the solution out of them. Even if you know right off because you have been doing it for years. And you KNOW this is the answer. You have to draw it out of the operators so they get behind it and own it. It can take months. And can be very frustrating. But done this way, it usually sticks. Walk out to the shop floor and TELL them this is the new way? Yeah, I'd give that two weeks tops.

 

Ooooooh. You got the point across in like, a dozen words. That's very good.

I would argue that driving a car is not a "process" in the sense we typically use the word. But it is an interesting point.

 

Frankly, after thinking about this for some time, root cause always comes down to a person (or people). At some point it is the people who design these systems/processes. They also change the system/process when there is an issue caused by a person. Go figure.

 

Never heard of "Angel's Advocacy" before...but maybe that applies here?
You summed up the 'People can be root causes' side well.
From the other side...

The design of the car and the inadequate automated control of driving are part of the 5-why. "Why was the person capable of driving unsafely?"
The person 'driving' the car should not have the capability to override limitations causing a dangerous scenario.
The speed should have a governor, the forward looking radar should not allow forward motion into another object, same with the rear, and auto-steering should take over when you try to cut me off prohibiting you from doing so.
The cost of such systems is minor when compared to the cost of accidents.

Note...I am not on "the other side"...just playing against Brad's advocacy...

 

Yes, I'd put forward a similar argument back in post #15, but Bev D countered (rightly so) by pointing out that it the contention is really over whether "operators" are ever the root-cause, not "people" (title of this thread notwithstanding.. ;P)

This case illustrate the limits of application of root-cause analysis to prevent problems, as they often conflict with logistic, economic, or social factors.

In principle, there is no reason why we couldn't prohibit all civilian cars from being physically capable of high-speeds, or high-acceleration. Cars would simply be designed to not be able to go faster than the highest posted speed-limit, or be capable of accelerating too quickly. This would, without question, prevent a significant number of fatal accidents. ...so why don't we? (rhetorical)