Kaizen Factory

Lean - Agile - Digitization & more

Quality Tools

Why Human Errors do not exist!

by 2 Comments

Human errors are human. Human errors do always occur. This is how it always has been. But is this really true when we are talking about system thinking and operational excellence? Well, it’s a question of the perspective how you are looking at processes.

Identifying an error as human error is just easy and very comfortable, because you don’t have to think about the deeper root cause of the problem any more. So many times I have seen Pareto Charts of a failure analysis as shown in the figure below.

Human errors are always number one and typically this leads to following additional problems:

  • Improvements of the processes will be seldom done.
  • Employees will be blamed for errors.
  • Employee engagement will drop.
  • Fire fighting will become a daily routine.

There is a famous quote from W. Edwards Deming:

94% of problems in business are system driven and only 6% are people driven.

How does Deming’s observation fit to all the Pareto Charts I have seen? Well, as mentioned above, it’s just a question of proper root cause analysis and applying the right problem solving techniques.

By simply applying problem solving techniques like the 5 Why’s methodology the Pareto Chart will significantly shift from human errors to the actual root causes. These root causes might be:

  • Insufficient or erroneous work instructions
  • Insufficient training levels
  • Insufficient maintenance strategy for the equipment
  • … and so on

In some industries, such as pharmaceutical industry, aerospace industry and nuclear industry, a lack of system thinking may become very dangerous on top. Therefore authorities like FDA (pharmaceutical), FAA (aerospace) or IAEA (nuclear) are emphasizing a more strict system thinking since a couple of years.

For example, now the IAEA is shifting focus and acknowledging that the individual behaviors and processes in place will only be as good as the organizational structure which supports them.

IAEA_Human_Error
Contribution of human errors to the occurrence of events (courtesy of the USDOE)

As a conclusion, talking about human errors is misleading and does not reflect a correct system thinking at all.

FMEA – a Data Base for Continuous Improvement

by 2 Comments

When the question pops up how to formalize continuous improvement activities, the request for tools and methods is not far away. One of the most used but also most neglected tools, actually it is process, is the Failure Mode & Effect Analysis (FMEA). In general there are two types of FMEAs, the System or Product FMEA and the Process FMEA.

Product and Process FMEA are two of the standard tools widely used in many industries, especially in automotive industry where FMEAs are part of the deliverables for the Production Part Approval Process (PPAP).

However, FMEAs are seen often as “nice to have” by the project teams without providing much value add to the development of the product or development of the production process. Certainly conducting FMEAs means a lot of work for the team, but it’s worthwhile.

The reason for seeing FMEAs as “nice to have” is that typically two things are done wrong with FMEA:

  • The selection of the right FMEA team.
  • Not seeing FMEA as part of the continuous improvement process.

In particular, the second issue means that in many cases FMEAs are done as a one time shot without updating the FMEA on a regular base when progress is made in the development process or lifetime of the product. This also implies that FMEAs are living documents. When you see an FMEA documentation where the last update was done many months or even years ago, you know something went really wrong with you continuous improvement process.

Much better is to handle FMEA as an 8-step continuous improvement process, very similar to the PDCA cycle or 8D process or Toyota A3 Report.

Just follow the basic 8 steps shown in the picture above and update the FMEA database every time you have new findings in your development process or during lifetime of the product. And, of course, reuse all this collected knowledge for further development of new products and production processes.

Anwendung von Qualitätswerkzeugen – eine Umfrage

by 1 Comment

Kürzlich wurden von der American Society of Quality (ASQ) die Ergebnisse einer Online-Umfrage veröffentlich. Eine der Fragen hat sich hierbei mit Qualitätswerkzeugen und deren Wichtigkeit für den Anwender beschäftigt. Die Frage lautete: Welches der grundlegenden sieben Qualitätswerkzeuge ist das Wichtigste für sie? Das Ergebnis dieser Umfrage ist der folgenden Tabelle zu entnehmen.

Auf den Plätzen eins bis drei finden wir hier das Cause-and-Effect Diagram, auch Ishikawa-Diagram oder Fishbone-Diagram genannt, sowie das Pareto-chart und das Control Chart.

Alle drei Werkzeuge werden typischer Weise bei der Ursachenfindung des Fehlers (Root-Cause-Analysis)angewendet, im Falle eines Six Sigma DMAIC Projektes also in der Analysephase. Bemerkenswert hierbei ist, dass das Fishbone-Diagram in der Umfrage den ersten Platz belegt. Dies mag damit zusammenhängen, dass dieses Werkzeug einfach zu verstehen ist und oft in Problemlösungsworkshops angewendet wird. Das Fishbone-Diagram kann hier visuell unterstützen, um die vielen möglichen Einflussgrößen auf einen beobachteten Effekt halbsweg strukturiert zu sammeln. Bei der Arbeit mit oder in einem interdisziplinären Team ist das nicht hoch genug zu bewerten. Jeder kennt schließlich Workshops mit einer größeren Anzahl von Teilnehmern und einer großen Anzahl an Ideen und zum Ende hat man sich doch nur ergebnislos im Kreis gedreht.

Das Pareto-Chart wurde in der Umfrage als das zweitwichtigste Qualitätswerkzeug bewertet. Tatsächlich ist das Pareto-Chart auch unentbehrlich, wenn man Priorisierungen vornehmen will und muss. Gemäß der 20-80 Regel lassen sich schnell die wesentlichen Fehlerarten ermitteln, die man unmittelbar attackieren sollte, um zu einem deutlich besseren Qualitätsergebnis zu kommen. Gleichzeitig ist das Pareto-Chart auch bei der Projektselektion wichtig, um “Boiling-the-Ocean” Projekte zu vermeiden, die mit einem großen Aufwand absehbar nur einen geringen Teil zur Lösung des Projektes beitragen.

Als Dritter im Bunde der wichtigsten Qualitätswerkzeuge wurde das Control Chart genannt. Hat man genügend Daten in einem Prozess, so kann man jederzeit eines der Control-Chart Typen auswählen, um zu überüfen, ob der Prozess noch unter Kontrolle ist oder ob sich gewisse Trends abzeichnen, die zu einem fehlerhaften Produkt oder einer fehlerhaften Dienstleistung führen. Sicherlich ist das Control-Chart das komplexeste der drei Werkzeuge; es bietet dafür jedoch eine hohe Informationstiefe. Im Übrigen lassen sich Control-Charts auf alles anwenden, was sich messen lässt. Control-Charts sind damit keineswegs nur auf die klassische “Statistische Prozesskontrolle” (SPC) beschränkt, wie sie z.B. in der metallverarbeitenden Industrie mit ihren Maschinenparks anzutreffen ist.