Was sind einige der Tools und Techniken, die Sie für die Ursachenanalyse in der kontinuierlichen Verbesserung verwenden?

acredito que o uso do Ishikawa traz muitos benefícios pois ajuda a identificar e visualizar as causas raízes de problemas de forma clara e sistemática, facilitando a tomada de decisões e implementação de soluções.

Fish one or Ishikawa diagrams are a wonderful tool! I would also add that a big part of this is determining your target or issue to solve. This is best determined using the 80/20 rule, but I also like using a tool called a “pick chart” to help let the team determine the goal or target. They write down their ideas for projects and place them on a four quadrant board that will show you ease of implementation along with cost associated. This will show you the most reasonable and feasible targets to start!

Cause and Effect Diagrams are also called Fishbone or Herringbone diagrams (in reference to their shape) or Ishikawa in reference to Kaoru Ishikawa the creator. This Cause and Effect diagram is ideally co-created in a workshop with process subject matter experts who help brainstorm the potential root causes of a business problem. The workshop should ideally be facilitated by someone with experience, such as a certified Lean Six Sigma Black Belt, to help create a healthy dialogue and ensure all participants share their thoughts and perspectives. While this can be digital, using chart paper on the meeting room walls, post it notes for potential root causes and round coloured stickers for voting still reigns as the best way to collaborate.

🛠Fishbone Diagram: Visualizes causes and effects, categorizing factors like people, equipment, and methods. 🔍5 Whys: Repeatedly asks "why" to uncover deeper layers of a problem. 📊Pareto Analysis: Prioritizes issues by identifying the most impactful factors, following the 80/20 rule. 📉Failure Mode and Effects Analysis (FMEA): Assesses potential failures and their impact, ranking by severity. 📈Root Cause Mapping: Graphically links issues to potential causes, useful for complex problems. 💬Brainstorming Sessions: Encourages diverse input, gathering insights from different perspectives.

O diagrama de Ishikawa, também conhecido como diagrama de espinha de peixe ou diagrama de causa e efeito, descreve as possíveis causas de um determinado problema ou resultado. O diagrama é chamado de espinha de peixe devido à sua forma, onde uma linha longa atravessa o centro e aponta para o resultado principal, também conhecido como "afirmação do problema". Os outros ramos se ramificam a partir do eixo central e representam as diferentes categorias de causas.

- Diagrama de Ishikawa (Espinha de Peixe): Identifica possíveis causas de um problema, explorando categorias como pessoas, processos, máquinas, materiais, meio ambiente e gestão. - 5 Porquês: Pergunta repetidamente "por que" um problema ocorreu para identificar a causa raiz, revelando as camadas subjacentes do problema. - Análise de Pareto: Identifica e prioriza os fatores que contribuem significativamente para um problema, permitindo focar nas causas mais impactantes. - Diagrama de Dispersão: Examina a relação entre duas variáveis, ajudando a identificar correlações e possíveis causas de variações em um processo.

I suppose this will seem simplistic, but it has always worked for me. First I would go out to the factory floor and look. I mean really look. I would talk to the operators and hear their thoughts. Really listen. I would take in all quantifiable and especially anecdotal observations. Then I would think about it. Not try to solve it right away, just think about it. Then I would go back and think more. While the plethora of tools espoused over the years might be useful, my experience is that teams are in such a breathless hurry to "solve" the problem they do all of the drills of "problem solving" and forget to think. Think! That which "goes without saying" usually goes without doing. Think first and much.

Normalmente, as ferrsmentas mais conhecidas são o Diagrama de Ishikawa e 5 Porquês. Uma combinação das duas ferramentas é uma ótima forma de se chegar às várias causas raízes do problema. Inicie criando seu Ishikawa com a equipe multifuncional. Levante as possíveis causas, e aponte as potenciais. Para cada causa potencial, vá para um 5 Porquês.

In my personal opinion, coming from someone who has worked at levels ranging from detailed "hands on" technical work to high level project and engineering management I have found that they can be both very inefficient and deceiving. Often the root cause can be easily lost in fine detail that is overlooked because those trying to analyze the problem are typically working it from too high level, and broad of perspective. In my opinion the analysis is best done by collaborating directly with someone or a group at the level where the problem occurred to view it (the problem) with as much fine detail as possible. Once the specific root cause is found, then potentially fit it into the broad perspective that the fishbone might have.

The fishbone diagram is a valuable tool for engineers to visually represent and analyze the causes of a problem. Its structured approach facilitates effective problem-solving, collaboration, and continuous improvement within engineering processes.

It's common (and absolutely fine) to also have multiple responses at each layer of "why?" questioning. It could be that your "5 Whys" activity might end up with something that resembles the roots of a tree branching out. But the important thing is the uncovering of the main reasons (multiple) of a problem occurring. But it's also very important to remember to be respectful and refrain from turning the conversations in a blameful direction. Doing so will hinder your ability to solve problems but instead will cause new problems that might be even harder to solve.

It would be fair to add that there is no "set" number of times you can ask a "why" question. What matters is that you get the "right" answer, meaning the answer should not only result in a clear understanding of what is not working, but preferably be fixable, at least partially. I've been asked by colleagues and clients when would one stop asking "why", and one way to identify the stopping point is when the further questioning leads one to a repeated answer.

Sometimes, the Five Whys is not the preferred way to reach the root cause on its own. The Five Whys assumes that there is only one answer to each "why" question, and then you ask "why" again. However, in reality, in many problems, when you ask "why," there might be two or three answers. That's why another method, like the Fishbone (Ishikawa) or Pareto, can be used. Afterward, you can take the vital few root causes identified and apply the "Five Whys" approach to them.

The 5Whys doesn’t limit to diving on a single front. For example, if a “Why” have two possibilities, can we uncover the cause based on the two tracks and determine the most probable? This could be the simplest tool that can be implemented on site to determine the cause while follow up with corrective actions.

Here are some tips for validating your 5 Whys. To validate your flow/logical reasoning: -Is it sequential? -Does it make sense if we read it backward (from the last to the first 'whys')? -Does it go beyond symptoms? -If we solve the last 'why,' does the problem recur? Now, considering the validation of your root cause: -By solving the cause, will the problem reoccur? -Does the cause belong to Ishikawa's 6Ms? Finally, to validate our actions: -Are they within our reach? -Do the actions cover the 6Ms identified? -Are they clearly outlined in an action plan? -Do they address the causes? -Do they resolve or alleviate the effects? By answering these questions, we'll have a solid understanding of the quality of the 5 Whys analysis conducted.

I have never heard of this technique, but in my experience agree with the approach. My specific experience dealing with quality issues was to first review all of the anomalies, then make a best attempt to create a reasonable number of general categories that they might best fit into, and begin separating each incident into whatever the category it best fit. With group collaboration, we it typical that the categories might change or merge into better ones along the process of analyzing the data (the data being the specific incidents or anomalies that were being addressed).

I have never heard of this technique, but in my experience agree with the approach. My specific experience dealing with quality issues was to first review all of the anomalies, then make a best attempt to create a reasonable number of general categories that they might best fit into, and begin separating each incident into whatever the category it best fit. With group collaboration, we it typical that the categories might change or merge into better ones along the process of analyzing the data (the data being the specific incidents or anomalies that were being addressed).

Os processos organizacionais na maioria das vezes são eficientes, mas isso não significa que não apresentem nenhum tipo de problema. Quando o problema aparece, precisamos identificar sua causa para que possamos resolvê-lo. Desta forma, uma técnica que teve origem no Japão e é utilizada pelas organizações é o 5 Porquês. Essa técnica serve para detectar a principal causa de um defeito ou problema, onde perguntamos 5 vezes o motivo de seu acontecimento. No entanto, não é necessário que sejam feitas exatamente 5 perguntas, desde que se chegue a real causa do problema.

Após o uso do brainstorming e do diagrama de ishikawa, sempre utilizo a ferramenta dos 5 porquês para chegar na causa raiz, utilizando as causas primárias. Com certeza algumas das possíveis causas listadas no diagrama de ishikawa serão as respostas para alguns dos por quês, então este é um momento de definir a sequência das causas. O mesmo pode ser feito com a árvore de causas.

What has worked for me in the past is to ask Why until you reach the "First Principle." a.k.a. the root. The first Principle is something that does not require further explanation or proof, like Newton's Laws of Physics, biases in psychology, properties of material etc. One of the biases I observe in RCA is if one already has a solution in mind. Then, the 5Why analysis will likely end at the cause where it has been addressed by that solution (Selective perception). Thus, if you think you have the root cause, ask yourself, "Is this the first principle? Or can I explain further?"

na minha visão, é crucial garantir a precisão e relevância dos dados selecionados no Gráfico de Pareto, pois este oferece benefícios significativos ao destacar as principais causas de problemas, demonstando visualmente as áreas prioritárias para intervenção, permitindo focar esforços onde têm maior impacto.

The Pareto chart is often the most useful chart of all. A data driven model that shows us exactly how to prioritize. It’s more objective that subjective. Spend your time on the things that get you the most ROI.

The Pareto Chart is a valuable tool for root cause analysis in continuous improvement. It combines a bar graph and a line graph to identify and prioritize the most significant causes of a problem. The bars represent the frequency or impact of issues, arranged in descending order, while the line shows the cumulative percentage. The Pareto principle, or the 80/20 rule, suggests that 80% of problems often stem from 20% of causes. By using a Pareto Chart, teams can focus their efforts on addressing the most impactful issues first, making the problem-solving process more efficient and effective.

I fully agree with KV regarding Pareto charting as probably the most useful tool of all. It provides the Quality Team with a visual representation of frequency and priority as long as the offending issues within the data stack have been carefully characterized before applying the Pareto. This may seem obvious, but in absence of careful scrutiny at this early stage of RCA, the Pareto output will be flawed, potentially sending the QA Team down a rabbit hole. Once valid data points have been clearly characterized and the Pareto has been run, its output can be paired with the real cost of intervention for each point to prioritize the efforts of the resolution team. Successful outcomes without getting caught up, chasing the few among the many.

O Diagrama de Pareto é baseado no princípio de Pareto, também conhecido como a regra 80/20. Esse princípio sugere que aproximadamente 80% dos efeitos são decorrentes de 20% das causas. Dessa forma, a análise do Diagrama de Pareto permite identificar os poucos fatores que têm maior impacto na ocorrência de um problema, auxiliando na tomada de decisões estratégicas e na alocação adequada de recursos para solucioná-los.

By visually representing the vital few factors that contribute to a majority of problems, organizations can strategically allocate resources and achieve significant efficiency gains. The chart's dynamic nature allows for continuous monitoring and adaptation, fostering a culture of continuous improvement. Armed with insights from the Pareto Chart, organizations can establish clear improvement priorities. Addressing the vital few issues first allows for a targeted and strategic approach to process enhancement. This prioritization ensures that efforts yield maximum benefits with minimal resources.

Focus on the few vital things, not the trivial things. R Koch The Pareto chart is focused on the Pareto Principle (80/20 rule). And helps prioritize issues by showing which factors are most significant. To create a Pareto chart, collect data on the frequency of different problems, such as type of customer complaints. Plot these problems on a bar graph, arranging them in descending order of frequency. For example if 80% of complaints are about billing issues, focus your improvements efforts there first. This tool highlights the most common issues that need addressing, allowing for targeted improvements. Note: verify and validate all data and that it aligns with the process to an extent that you’re confident you can act on it.

Na minha opinião, o Gráfico de Pareto é essencial. Ele nos ajuda a identificar os poucos fatores que causam a maioria dos problemas. Eu já vi como esse gráfico pode direcionar nossos esforços para as áreas que realmente importam, aumentando a eficiência e gerando resultados significativos. É uma ferramenta indispensável para quem busca excelência operacional.

El diagrama de Pareto es una herramienta esencial en mi día a día para priorizar las causas de paro. Me gusta usar dos enfoques diferentes: uno que considera la duración acumulada de las incidencias y otro que se enfoca en la cantidad de incidencias. Estos dos gráficos de Pareto proporcionan perspectivas complementarias, ayudándome a entender tanto la frecuencia como el impacto de los problemas. Esto es crucial para decidir en qué áreas concentrar nuestros esfuerzos de mejora y optimización, asegurando que abordamos las causas que realmente afectan la eficiencia.

Muito objetivo e prático, o gráfico de preto traz também uma visão mais estatística pro problema. Gosto muito de utilizá-lo para a definição sobre o que devo atacar primeiro, e também já serve como ferramenta de controle das ações.

I have used a variation on fault tree multiple times, it's not time consuming , allows for multiple causes to be in play. In my experience frequently if you follow it all the way through you find the different threads come to the same root cause.

Connecting Fault Tree Analysis with 5 Whys Analysis: First and foremost, it's always important to mention that we should use as many 'whys' as necessary. Additionally, for each new 'why' we address, we should consider multiple hypotheses and test them. This way, we can ensure that we progress towards the correct root cause, which may involve more than one cause, thus branching out the 5 Whys. This process is akin to testing all items in a Failure Tree. Robust 5 Whys analyses often contribute to the feed of failure trees and FMEAs (Failure Modes and Effects Analyses).

rvore de falhas é uma ferramenta que coloca os eventos relacionados em uma sequência lógica, permitindo entender qual foi a causa raiz que gerou o problema ou situação. Normalmente ela é feita por meio de diagramas, criando uma representação visual que ajuda a identificar qual foi a falha inicial que levou ao problema principal. Uma vez que a falha foi sinalizada, é preciso fazer uma análise dedutiva para descobrir sua origem e assim corrigir o problema na raiz, e não apenas sua consequência (a falha que gerou a necessidade da árvore).

“Problems are only opportunities in work clothes.” Henry J Kaiser The FTA is a top down, deductive failure analysis that focuses on identifying the potential causes of system failures. To apply FTA, start by defining the undesirable event, such as system crash. Draw a fault tree diagram with the top event at the top and possible causes branching downward using Boolean logic. For example, identify causes like software bugs, hardware failures, and user failures. Analyze each branch to identify and mitigate risks. Let’s take aviation, for instance, FTA can help identify potential failure points in safety critical systems and develop strategies to prevent them.

As an example of the need for root cause verification, consider an incorrectly delivered supply chain shipment. The root cause verification process identifies the underlying cause of errors, beyond immediate issues like lost shipments. Data entry errors, software glitches, and other complex problems can lead to recurring mistakes, which reshipping doesn't address. Root cause verification involves a thorough investigation to pinpoint the source of the error and implement a lasting solution. This improves efficiency, customer satisfaction, and bottom-line protection, vital for sustainable operational success in supply chain management.

Root cause verification is the cornerstone of efficient problem resolution and strategic decision-making It prevents the risk of investing time and resources in addressing symptoms rather than the actual issue. By confirming the true root cause, you ensure that solutions target the core problem, enhancing their efficacy. Additionally, this process aids in clear communication and documentation of findings, providing a compelling case for recommended actions.

Durante o processo de análise de causa raiz, é de suma importância verificar as hipóteses no local onde o problema (acontece). Somente assim se chega à causa exata.

In this situation Jack the 5 whys would be the best tool to use, I've been in fast paced aviation quality control situations (for spares and supply) and you have to drill down to the root cause quite quickly, the 5 whys will usually get you there without needing a long term analytical approach

Many tends to jump into using a tool or even demanding for data analytic to determine what’s the root cause. Can we look into the human aspect of determining the problem? Consider making a trip to the source of the problem, making a GEMBA （現場）to see the situation at the source, spend some time observing and talking to people without judgment. You might be surprised by what you could possibly find there.

Failure Mode Effect Analysis is another tool but this one is far more task intensive. More aerospace customers are requiring their suppliers to perform these analysis in order to predict potential failures and effects and develop a preventative, robust mitigation plan in place.

One that I did not see here was the Dictionary Game with the BOB (best of the best) and WOW (worst of the worst). Maybe the nomenclature has changed through the years and it is called something else now. I have used this method extensively. It is quick and simple to the optimizing even very complex problems.

If that’s a process problem, one can also map out the entire process and trace back when the problem hasn’t been created. Such approach helps to give clarity on where might be the issue and probability the dependency to determine the exact process which could contribute in creating the problem. Next, don’t get fixated to those tools available, trust your gut feeling too. There could be circumstances where you already know where’s the issue, don’t waste time running through all these, do a quick check to affirm your feeling.

Scatter plots may also be helpful in root cause analysis. We can identify how the different variables are related/correlated to each other. It will visually display the correlation between a problem and cause. This in turns helps in identifying which cause has a high impact on the problem and needs to be addressed first.

FMEA complements other analysis techniques by providing a framework to assess the impact of potential failures, helping prioritize which causes to address. #TIP: Combine FMEA with the fishbone diagram for a more robust analysis, identifying not only root causes but also evaluating the risk associated with each one.

these systems to me, are not practical. to me they are mostly long term solutions. i need to solve problems, short term. so analytic, solutions do no appeal to me. i have to solve the problem before we produce any more you know what. sorry to be so blunt

I agree, but… you should consider the ‘usual culprits’ technique first. It is very likely that the problem you have happened before and the solution is figured out already. Quite likely someone already developed some neural network model using expert inputs in the past too - they picked this up in the late nineties. Oh, also, you can look into knowledge management systems (e.g. Yammer), most corporations have them them these days. Don’t reinvent the wheel. Ok, enough free consulting for today. I’m sure this paragraph will give a lot of material for the generative AI to cheat from. Brave new world!

I am surprised that there was no mention of developing the Problem Statement. In my opinion, developing the Problem Statement is fundamental. Having a defined Problem Statement focuses the Team to work on conditions that were true, present and perfect in the event the Team is trying to identify Root Cause for, prevents brainstorming which takes time and valuable resources away from the Root Cause, removes biases in the Team from experience which if not used properly can be detrimental in RCA, defines the gap between the expected outcome and helps develop metrics to track the results of corrective and preventative actions taken. Start with understanding the loss and developing a Problem Statement, it will save a lot of heartache.