Yearly Archives: 2015

You are browsing the site archives by year.

According to a definition applicable to the insurance industry, an accident is an event which is not deliberately caused and which is not inevitable[1]. A typical insurance policy has a significant number of exclusions that are the “evitable” circumstances.

Logically, any situation which is reasonably evitable and which likely has harmful consequences ought to have been identified. bigstock-work-injury-clai-52aa87fb42b761a2c2c045ffb29402c7c8aa2d0a

Those of us who are the safety leads at our organizations have a lot riding on our shoulders. That pressure gives us a constant incentive to improve, because we can never do our job too well. This post highlights some of the questions we ask ourselves that ultimately ladder up to the larger question, “How can we do better?”

For example:

1. How many injuries have been recorded at your location(s) in the past year? 

The often cited adage “you can’t manage what you don’t measure” is pertinent here.

Data is king; knowing how many injuries have been recorded at all locations for your enterprise will not only enable comparisons between sites and an analysis of the common and different causes, but also can be used to motivate greater improvements at the lesser site(s).

2. Does that number include the near misses? Or aren’t they reported?

The expression “near miss” clearly indicates a close call, but all too frequently it occasions relief rather than analysis. This is because people look on the bright side and put the escape down to good luck. Overcoming this complacency is a challenge. The issue for the organization is that all too often these events are simply not reported, or reported too long after the event to enable an accurate re-construction of the event. This compromises the ability to derive any “lessons learned” that could generate appropriate improvements.

3. Would you know if the near misses hadn’t all been captured? 

The simple fact is that “you don’t know what you don’t know”; this situation calls for a process of acknowledgement, if not reward, so that the incident participants have no fear of punitive measures being applied when they report the circumstances of the near miss. This necessitates the clear communication of a “no blame” philosophy. If employees feel that they will suffer some negative consequence they will be loath to volunteer information about the near-miss incidents.    

 4. Is your record improving?

Unless the data is being promptly collected, accurately recorded, and analyzed, trending will not be possible and improvement not apparent. The objective is to have a demonstrable improvement evidenced by the statistical record. The accuracy of this data will depend not only on the creation of the “no blame” culture but also on the refinement of the methodology and tools employed in the investigation of incidents.

5. Have you set targets for improvement? bigstock-Dartboard-with-d-f4d3b5fe1b60fb34e4354eaa55ca093fa0e3729c

Establishing fresh targets and goals periodically is the only way to ensure the improvement is continuous. Even a site with an almost blemish-free record needs to be totally vigilant about the changes that are being undertaken there. Change is the only constant and, regretfully, is also an opportunity for hazards and harm to arise. The fresh targets ought to be reflected in the key performance indicators (KPIs) applicable to the respective safety roles for your enterprise.

6. Are there any unidentified hazards facing the personnel? 

Only systematic inspection and auditing processes will reveal previously unrecognized hazards. The certainty that you have minimized risks and hazards will grow proportionally as the employees who encounter the hazards demonstrate their ownership of the safety program. They have the ultimate control of the likely causes of their own potential harm. But whether the personnel have accepted ownership of the program or not, it is incumbent on the responsible officer to implement the specific hazard identification process. This will necessitate close engagement with the plant or equipment operators, technicians, or any person with an exposure to their work environment. Yes, that’s everybody.

There are also hazards of the interpersonal type that may never be apparent to the observer; bullying and stress are increasingly the causes of substantial claims for compensation and can only be detected by building a trusting relationship with the personnel and developing confidentiality protocols.

 7. How effectively are you learning the lessons from each “accident”? shutterstock_153987764-667d5faded20b810456293957c3c5a1b303e526f

The parlance “lessons learned” is commonplace but not consistently applied. These are words that express an intention to make improvements in the organization but all too often focus on the actors in the event rather than the systems and processes that are central to the business.

“Human error” is the categorical expression most commonly heard when blame is being attached and represents a plethora of mistakes that humans make. Discovering that precise error in this unique event and the reason(s) for it can add value and lead to preventive measures being implemented — but not in isolation, not as the so-called “root” cause.

Perfect knowledge, perfect understanding, and perfect operation by all humans in the enterprise are a fantasy. Humans are fallible and accidents will happen if the situation exists.

 

8. Which causes are “evitable”? 

The “evitable” causes are simply the known, designed, or planned components of the situation – the hardware, equipment, systems, and processes that are used in the production of the goods or service in question. These are all possible causes which, with a human interface, can create hazards with potential negative safety consequences. They are the opportunities for establishing controls or installing barriers that prevent harm.

The safety program needs to identify improvements to the systems or equipment, which would at least minimize the likelihood of a repeat occurrence given the fallibility of the human factor. What are the possible failure modes or the mis-operations that could occur?   

9. Can you demonstrate that you have thoroughly and methodically analyzed every event in order to prevent recurrence?

A thorough and methodical causal analysis is not possible without the creation of a cause map. This is best achieved through a mediated process involving the pertinent stakeholders and subject matter experts and identifying and arranging the proven causes in a logical manner. It needs to be both comprehensive and comprehensible to win the confidence of the decision makers who are looking for recommendations that will effectively modify, substitute, or eliminate the causes.

There are regulatory authorities that have expectations in this sphere and will want to see the assiduous application of a method that has proven to be effective regardless of the industry or problem-type.

[1] http://www.businessdictionary.com/definition/accident.html#ixzz3QpGESuXU

ARMS Reliability is here to help you answer these questions. Our free eBook “11 Problems With Your RCA Program And How To Fix Them” is a great first step to figuring out “How can we do better?” Download it here.

 

11Problems_Ebook_banner

Mientras que existen tres razones principales por las cuales las organizaciones típicamente ejecutan un Análisis de Causa Raíz a sus activos o equipos, existe una gran cantidad de indicadores adicionales por los que se debe realizar un RCA.Cartoon_Man/HardHat

Lo probable es que usted esté registrando mucha información valiosa acerca del desempeño de su equipo – información que puede revelar oportunidades para llevar a cabo un análisis de causa raíz, encontrar causas, e implementar soluciones que resuelvan problemas recurrentes y mejoren la operación. ¿Pero realmente está usando la información para ese propósito?

Primero, hablemos brevemente de las razones por las que típicamente se ejecuta un análisis de causa raíz:

1. Por obligación

Es probable que exista alguna regulación/requerimiento para registrar que usted está haciendo alguna cosa con respecto al problema ocurrido.

2. Usted alcanzó un límite disparador

Su propia compañía ha identificado disparadores de incidentes mayores que ameritan un análisis de causa raíz.

3. Porque usted lo desea

La oportunidad se ha presentado por si misma para hacer cambios de mejora. O quizás usted ha decidido que es hora de detener la pérdida constante de dinero.

El propósito de una industria es hacer dinero. Cualquier razón que impacte este objetivo es usualmente atacado por el análisis de causa raíz.

Mientras tenía una conversación con un ingeniero de confiabilidad en una facilidad petrolera, le pregunté cuántas oportunidades perdidas y paradas sufre la compañía en un año. Me respondió que alrededor de tres cuartos de billón de dólares, es decir $750.000.000. ¿No es acaso una razón importante para ejecutar un análisis de causa raíz? Tan solo un 10% impacta significativamente los cálculos de la compañía.

El impacto financiero no es consecuencia de un evento individual, sino de una multitud de eventos tanto mayores como menores.

Cada evento representa por si mismo una oportunidad de aprendizaje y de cambio para prevenir su recurrencia. Así es la vida… cosas pasan, pequeñas o grandes. Pero es un error de grandes proporciones el permitir que los eventos sigan ocurriendo de forma continua.

Mientras todo lo anterior son razones válidas para ejecutar un análisis de causa raíz, existen por lo menos 10 pistas reveladoras, relacionadas con equipos, que indican la necesidad de un RCA- muchas de las cuales pueden ser identificadas con la información que probablemente usted ya ha registrado.

A continuación diez signos reveladores, que indican la necesidad de llevar a cabo un Análisis de Causa Raíz:

  1. Aumento en los tiempos inactivos de planta, equipo o proceso.
  2. Aumento de fallas recurrentes.
  3. Aumento de horas extra debido a fallas no planeadas.
  4. Aumento de eventos disparadores.
  5. Menor disponibilidad de equipo.
  6. Alta cantidad de mantenimientos reactivos.
  7. Carencia de tiempo… simplemente no se pueden hacer las tareas necesarias.
  8. Aumento en el número de eventos graves… alcanzando el tope de la pirámide.
  9. “Detenciones” planeadas de mayor duración.
  10. Mayor frecuencia de “detenciones” requeridas.

Lo anterior implica que necesitamos adentrarnos más en el análisis de causa raíz antes que estos problemas crezcan como una bola de nieve.

While there are three main reasons organizations typically perform Root Cause Analysis (RCA) following an issue with their asset or equipment, there are a whole host of other indicators that RCA should be performed.Cartoon_Man/HardHat

Odds are, you’re recording a lot of valuable information about the performance of your equipment – information that could reveal opportunities to perform an RCA, find causes, and implement solutions that will solve recurring problems and improve operations. But are you using your recorded information to this extent?

First, let’s quickly talk about three reasons why RCA is typically performed:

1. Because you have to

There may be a regulatory requirement to demonstrate that you are doing something about a problem that’s occurred.

2. You have breached a trigger point

Your own company has identified the triggers for significant incidents that warrant root cause analysis.

3. Because you want to

An opportunity has presented itself to make changes for the better. Or perhaps you’ve decided you simply don’t want to lose so much money all the time.

At the core of all industry is the desire to make money. Anything that negatively impacts this goal is usually attacked by performing root cause analysis.Oil And Gas Pipelines

I was having a conversation with a reliability engineer at an oil and gas site, and I asked him what lost opportunity or downtime might cost that company over the course of a year. He said it was in the vicinity of three quarters of a billion dollars – $750,000,000. Is this a good enough reason to perform root cause analysis? Even a 10% change would have a huge impact on bottom line figures.

The monetary impact to the business was of course not due to any single event, but to a multitude of events both large and small.

Each event presents itself as an opportunity to learn and to make any changes necessary to prevent its reoccurrence. Once can be written off as happenstance… things happen, serious or minor, and that’s life. But to let it happen continuously means that something is seriously wrong.

While these are all valid reasons to perform an RCA, there are at least ten more tell-tale equipment-related clues that an RCA needs to happen – most of which can be identified through the information you’re probably already recording.

Here are ten tell-tale signs that your organisation needs to perform Root Cause Analysis:

  1. Increased downtime to plant, equipment or process.
  2. Increase in recurring failures.
  3. Increase in overtime due to unplanned failures.
  4. Increase in the number of trigger events.
  5. Less availability of equipment.
  6. High level of reactive maintenance.
  7. Lack of time… simply can’t do everything that needs doing.
  8. Increase in the number of serious events… nearing the top of the pyramid.
  9. Longer planned “shut” durations.
  10. More frequent “shut” requirement.

These indicators imply that we need to be doing more in the realm of root cause analysis before these issues snowball.

If you can identify with some of these pain points, download our eBook “11 Problems With Your RCA Process and How to Fix Them” in which we provide best practice advice on using RCA to help eliminate some of these problems.

11Problems_Ebook_banner_576x247_72ppi

Author: Ben Rowland

A colleague and I were discussing how his nine year old son had completed his Cub Scouts Cyclist Activity badge. We noticed how some of the bike maintenance tasks that had been identified were, shall we say, less than ‘optimal’.

Now you might say this is a bit unfair to judge a Cub Scout lesson through the eyes of a reliability professional (and you’d be right) but what was interesting is that we often see the same sorts of issues within the industry.

Click image to view larger

bike1

 

The first thing we noticed is the tasks aren’t really tasks, but a list of components; i.e. they tell you what to look at but not what to look for.

In other words, how a task is written is clearly very important.  In the example above “check the back tire” does not help us know what to look for. Is it there? Is it worn? Does it have air in it? Is it damaged? With vague work instructions like these maintainers are left to decide what to inspect for, which will inevitably lead to inconsistent maintenance.

Some of the examples above are better than others, “your helmet fits” for example, is more specific and much better than “check helmet.”

While working with clients to develop their maintenance plans, the RCM process we use ensures that each maintenance task addresses a specific failure mode, or modes. We can run a report that shows this link, which in turn allows the maintainer to understand the purpose of the inspection. The task can also be written in such a way as to focus the maintenance on identifying the potential failure.

Another issue with the tasks above is there isn’t any data or figures included in the task.  How much tire wear is acceptable? What is the minimum tread depth?  What pressure should the tire be at? Is there a minimum and maximum?

There also needs to be instruction as to how frequently to do the bicycle checks.  Every ride? Every month?  Things like checking your wheels are fitted tightly might need to be performed prior to every ride, but checking a chain for wear could be performed every few months. Not having this information can lead to items being under or over maintained, leading to possibly unsafe equipment condition or wasted effort.

“Okay then, you do it!”

Well it’s only fair after criticizing the Cub Scout’s effort that we have a go ourselves. So below is an example of how we might construct a FMEA and maintenance strategy for a bicycle, in the Availability Work Bench™ (AWB) RCM-Cost software¹:

Click image to view larger

AWB

We can see that for the failure mode ‘chain worn’ we’ve identified an inspection task to periodically check the chain for wear to address that failure mode. We’ve specified the method to use (a wear gauge, as opposed to a simple visual check or performing a measurement) and an acceptable limit (less than 75% worn).  This is a clear communication of what is required, minimizing the chances of ineffective maintenance.

“How do I choose which task to perform?”

In the example above I touched on the point that there may be a choice of maintenance tasks that could be performed, as well as whether or not to perform any maintenance at all.  The RCM process also helps us to choose an appropriate maintenance task and it is essentially a balance between the severity of the failure vs. the cost or effort to perform the maintenance. Often severity is thought of in terms of cost e.g. lost production, but it also covers the impact on safety or operational impact. The operating context of the equipment also affects the severity. The example below shows how we use the AWB software to select an optimal maintenance task interval.

Click image to view larger

Optimization Curve Image

Imagine we only ride our bike for getting around the town we live in for non-essential tasks, such as popping to the shops to buy some milk and a newspaper. In this case a punctured tire is not critical and we might decide not to carry a spare tube and tools to change it (pump, tire levers etc.) and instead to perform ‘breakdown maintenance’ i.e. walk the bike home and repair it there.  Now if we were instead on a vacation touring a remote location, far from any nearby towns, this ‘run to fail’ strategy would result in a very long walk and clearly not be suitable!

 Hidden Failures

So assuming we were carrying a spare tube, and relying on it in remote locations, what happens if there is a problem with the spare tube? “Did I remember to fix it after my last puncture?” What if there is a manufacturing defect?” Or “what if I didn’t find the thorn that caused the first puncture still stuck in the tire and got a second puncture?” These are called ‘hidden failures’ and require failure finding tasks in order to mitigate them.

 Operator Maintenance

We might also set our bicycle maintenance strategy assuming we do all the checks at home in the garage, but do we also need to consider operating checks?  For our bike this might include using our senses to listen for any abnormal noises, rattles, looseness, creaks or squeaks when riding the bike. We are also checking the operation of the gears and brakes through use, cleaning the bicycle down after use and oiling the chain afterwards to prevent corrosion. This is an example of ‘operator maintenance’.

How do we manage failures during use? If we notice something is wrong during use that we can’t fix, we would note it and arrange some planned maintenance at the bike shop before the warning becomes an actual failure that renders the bike out of action.  For operating failures that occur with little or no warning time we can address these in a number of ways; carrying spares (e.g. a spare inner tube), or tools to repair the failure out in the field (puncture repair kit).  We can also introduce re-designs (sealant in the tire to seal holes as they occur).

So there it is, writing an effective maintenance strategy can be as easy as riding a bike.

 

¹Availability Workbench™ is authored by Isograph Ltd. ARMS Reliability are authorized global distributors, re-sellers and implementers of the software application.

Click on the infographic for a PDF version. 

BarriersSolutions_Infographic_FINAL

FreeRCProDemo_banner

bigstock-Worker-in-cautio-c5a9f030be84f91768db6dc92fe28465c23388ff

Author: Jack Jager

While there are three main reasons organizations typically perform Root Cause Analysis (RCA) following an issue with their asset or equipment, there are a whole host of other indicators that RCA should be performed. bigstock-Worker-in-caution-sign-icon-th-92706563

Odds are, you’re recording a lot of valuable information about the performance of your equipment – information that could reveal opportunities to perform root cause analysis, find causes, and implement solutions that will solve recurring problems and improve operations. But are you using your recorded information to this extent?

First, let’s quickly talk about three reasons why root cause analysis is typically performed. 

1. Because you have to

There may be a regulatory requirement to demonstrate that you are doing something about a problem that’s occurred.                                    

2. You have breached a trigger point

Your own company has identified the triggers for significant incidents that warrant root cause analysis. 

3. Because you want to

An opportunity has presented itself to make changes for the better. Or perhaps you’ve decided you simply don’t want to lose so much money all the time.

At the core of all industry is the desire to make money. Anything that negatively impacts this goal is usually attacked by performing root cause analysis.

I was having a conversation with a reliability engineer at an oil and gas site, and I asked him what lost opportunity or downtime might cost that company over the course of a year. He said it was in the vicinity of three quarters of a billion dollars. $750,000,000. Is this a good enough reason to perform root cause analysis? Even a 10% change would have a huge impact on bottom line figures.

The monetary impact to the business was of course not due to any single event, but to a multitude of events both large and small.

Each event presents itself as an opportunity to learn and to make any changes necessary to prevent its reoccurrence. Once can be written off as happenstance… things happen, serious or minor, and that’s life. But to let it happen continuously means that something is seriously wrong.

While these are all valid reasons to perform root cause analysis, there are at least ten more tell-tale equipment-related clues that an RCA needs to happen – most of which can be identified through the information you’re probably already recording.

Here are ten tell-tale signs that your organization needs to perform Root Cause Analysis:

  1. Increased downtime to plant, equipment or process.
  2. Increase in recurring failures.
  3. Increase in overtime due to unplanned failures.
  4. Increase in the number of trigger events.
  5. Less availability of equipment.
  6. High level of reactive maintenance.
  7. Lack of time… simply can’t do everything that needs doing.
  8. Increase in the number of serious events… nearing the top of the pyramid.
  9. Longer planned “shut” durations.
  10. More frequent “shut” requirement.

These indicators imply that we need to be doing more in the realm of root cause analysis before these issues snowball.

If you can identify with some of these pain points, download our eBook “11 Problems With Your RCA Process and How to Fix Them” in which we provide best practice advice on using RCA to help eliminate some of these problems.

11Problems_Ebook_banner

Author: Ben Rowland

Surely if some is good, more is better? Like many things in life, there can be too much of a good thing when it comes to detail in an RCM study and finding the right balance can be tricky. Too little detail and you may miss things, too much and you could suffer from ‘analysis paralysis!’ B

So how do we know when we’ve ‘drilled down’ far enough to be thorough but not too far?

John Moubray summarised it nicely in his RCM 2 textbook:

“Failure Modes should be defined in enough detail for it to be possible to select a suitable failure management policy” (Moubray, 2007)

So what is a suitable failure management policy? The failure management policy is the approach chosen in order to mitigate the consequences of failure to an acceptable level.

Let’s consider two pumps; one is a large, complex gas compression pump and the other is a small air conditioning pump on a fork lift.

When trying to understand what the ‘suitable failure management policy’ is, it is necessary to take into account the ‘bigger picture’ of the equipment under consideration:

Function

What is the function of the machine? What is its purpose? Understanding this will help to understand the consequences of the failure, which in turn will help define the criticality.

Criticality

How critical is it if the failure occurs? Criticality is a product of the severity of the consequences of a failure multiplied and the frequency of occurrence.

In the case of large gas compression pump, a failure could result in product not being delivered, costing $1000’s per hour of downtime. Or for the forklift a/c pump it could be returning the forklift to be swapped for another in the fleet.

Repair vs. replace policy

Another aspect to consider is what is the corrective action? Is it feasible/cost effective to stock the spares and perform a repair activity in-situ, or to simply replace with a new unit?

For a large, expensive pump it would be more expensive to replace the entire unit than to replace a worn seal. Whereas for a small a/c pump it would be more cost effective to discard it and replace with a new one.

Hidden failure

Are the failures evident in normal operation, or do they require fault finding to be performed? Can the seals be seen to check for signs of leakage?

Operating context

How accessible is the equipment? Is scaffolding required? Is the plant required to be shut down? Does the equipment need to be partially dismantled e.g. removing guards etc? Is there any redundancy in place? Is the equipment in a remote location, or a challenging environment?

These are just some things to consider when considering what a ‘suitable failure management policy’ might be for your particular piece of equipment.

Back to our pump examples;
For the large gas compression pump, it is expensive to replace, critical if it fails and is accessible for in-situ repair during scheduled shut downs. In this case the FMEA would be far more detailed, including several failure modes, each with its own inspection or planned maintenance tasks, which would combine to form the ‘Failure Management Policy’ for this pump.

Image 1 How much detail

For the small AC pump on a forklift, let’s say it’s inaccessible for inspection, not critical if it fails and would be replaced rather than repaired. Our FMEA might only include a small number of failure modes, such as ‘Seal worn’, ‘Impellor worn’ and ‘Motor burnt out’ and our corresponding ‘Failure Management Policy’ would be ‘No scheduled maintenance’ and the corrective action would be to ‘Replace AC pump’.

Image 2 How much detail

In conclusion, it can be a challenge to know how much detail to go into when performing a FMEA analysis, but the aim is to go into enough detail to determine a suitable failure management policy. Considering the ‘bigger picture’ of the equipment you are analysing will help guide you as to the level of detail required.

alternate realitiesMuchas veces nuestras diferencias pueden ser una fuente de conflicto o confusión, pero en este artículo me gustaría explorar cómo pueden aprovecharse para resolver problemas en lugar de crearlos.

“Todo va a estar bien si tú lo haces a mi manera.” En algún momento todos hemos probablemente dicho o pensado algo como esto. O tal vez usted lo ha oído de alguien más (muy probable que de su pareja). ¿Cuál es el sentimiento base o cual es el problema aquí? Lo que realmente estamos diciendo es: “Si todo el mundo es igual que yo y pensamos de la misma manera, todo va a estar bien.” Desde luego que esto es imposible. La investigación en neurociencia nos dice que no hay dos cerebros que sean exactamente iguales, y para citar un artículo de Scientific American sobre este tema, “… si el aparato que detecta el mundo difiere entre dos individuos, entonces la experiencia consciente de los cerebros conectados a sus sensores, por tanto, no puede ser la misma”.

Los buenos solucionadores de problemas deben ser conscientes de esto para que no caigan en la trampa de suponer que todo el mundo sabe lo mismo, o que todo el mundo interpreta la información de la misma manera. Yo estaba cambiando los canales de televisión un día y vi un espectáculo interesante de gemelos siameses que comparten un solo cuerpo y la mayoría de los órganos, pero tienen cabezas completamente separadas (y por lo tanto sus cerebros). Cuando el entrevistador plantea una pregunta, cada gemelo respondió a su vez con diferentes respuestas. Esto provocó un desacuerdo entre ellos.

Estas dos personas compartían una crianza idéntica, estaban expuestos  a la vida y a los factores ambientales como cualquier humano, y sin embargo, todavía pensaban diferente. Si eso no te convence de que es imposible que dos cerebros distintos puedan compartir la misma perspectiva, entonces, ¡no estoy seguro de que lo hará!

He aquí un ejemplo de cómo dos personas pueden estar teniendo una conversación sobre lo mismo tema y sin embargo no estar hablando de lo mismo en absoluto. Durante un ejercicio común en una de mis clases, comenzó una discusión entusiasta acerca de los como limpiar los peces. Todos, excepto un estudiante brillante parecía estar en la misma página. Todo el mundo tenía la sensación de que esta persona estaba siendo difícil, pero algo dentro de mí recordó que debía obtener más información. Después de un par de preguntas de sondeo descubrimos que no teníamos el mismo punto de vista sobre el tema. Esta persona nunca había estado pescando y no entendía que “limpiar los peces” implicaba destriparlos y prepararlos para el consumo. Ella no podía entender el ejercicio debido a que su punto de vista de la limpieza era lavar y en general limpiar el exterior de algo, por lo que decía: ¿¡que tiene que ver un cuchillo con todo esto!?

Una observación más personal para respaldar este tema es una discusión que tuve con colegas acerca de la “Jerarquía de Controles” (se muestra en la foto a continuación como referencia).

Un colega dijo que el otro debe entender este concepto ya que tiene una formación en ingeniería, y todos los ingenieros sabrían esto. Tuve que informarles que yo también tengo una formación de 30 años en ingeniería, mantenimiento y confiabilidad, pero en realidad nunca había estado expuesto al término tampoco. Así que una vez más, la situación imposible de la perspectiva de cada uno es idéntica vuelve a relucir.

Pyramid_ARMSColours_SP

Mientras que hace su Análisis Causa Raíz, debe mantener el tema de la perspectiva en mente. Asegúrese de formular la definición del problema para que cada perspectiva tenga la oportunidad de ser escuchada, y que el problema es un reflejo de todas las perspectivas del equipo. Mientras se hace el Análisis Causa Raíz, talvez algunos no alcen la voz en la reunión, así que como Facilitador es su trabajo hacer que dichas personas externen su perspectiva y asegurarse entonces que sean escuchados.

En mi experiencia, puede tener un impacto significativo en la comprensión de una causa particular para el equipo. Aunque a veces lo que anhelamos es que todo el mundo vea las cosas exactamente como nosotros, teniendo en cuenta las realidades alternas de los demás es clave para construir una imagen más completa de su problema, lo que le permite encontrar la mejor solución.

Author: Kevin Stewart

RCAInvestigationScoreSheet_Mock-up

Audit is defined in the Merriam-Webster dictionary as:  “a methodical examination and review.” When we talk about auditing your Root Cause Analysis (RCA) investigations, we mean just that — a methodical examination and review. This is easier said than done, especially without some sort of standard to gauge against. If we establish a standard by which we gauge the quality of an RCA, the audit then becomes a simple matter of checking the RCA against the accepted standard and then determining how well it meets that standard. This post is all about helping you establish a standard, and we’ll even give you a free score sheet template to get you started.

Could you have the worst-looking RCA in the world and meet none of the criteria, but have an effective solution that:

  • prevents reoccurrence,
  • meets our goals and objectives,
  • is within our control, and
  • doesn’t cause other problems?

Sure, and it is hard to argue with success. I doubt anyone would say: “Even though this solution will prevent the problem from recurring, it comes from an RCA that doesn’t meet our stringent, high-quality metrics so we can’t use it.” This scenario is entirely possible, though the odds of it are unlikely. If we have a set of measures to check an RCA against to ensure it meets some quality standards, the probability of an effective solution coming from that RCA is greatly increased.

So what characteristics of an RCA are important?

Here are some questions to consider:

(If you need a refresher on some of these points, I’ve included the relevant page numbers from the eBook “RealityCharting™: Seven Steps to Effective Problem-Solving and Strategies for Personal Success” by Dean L. Gano.)

  • Do the causes pass the noun-verb test? (page 83)

noun-verb_relationships

  • Do the causes have a lot of unnecessary words or descriptors?
  • Do the causal elements pass all logic tests? (page 108)
    • Space-Time Logic Check
      • Do the causes of this effect exist at the same time?
      • Do the causes of this effect exist in the same place?
    • Causal Logic Check
      • If you remove this cause, will the effect still exist?
        If the answer to this question is no, then the cause is necessary for the causal relationship and should stay on the chart. If the answer is yes, it should be removed or repositioned.
  • Are there any rule violations? If so, what are they and do they pass the minimum standards? Rules to be included are:
    • Are any of the cause boxes empty?
    • Are there any unconnected causes floating around in the chart?
    • Has each cause been identified as an action or condition?
    • Does each effect meet the 2nd principle (causes exist in an infinite continuum – there is an action and a condition for each effect)?
    • Have all conjunctions been eliminated? Remember that “and” is often interpreted to mean “caused,” which can leave too much room for misunderstanding and error. (pages 67-68)
    • Does each cause have the appropriate supporting evidence to justify its inclusion in the chart?
    • Does each branch have some type of stop identified for it? Below are the five potential stops: (pages 88-89)
      • Question Mark – more information needed; an Action Item is created.
      • Desired Condition – there is no need to keep asking why.
      • Lack of Control – something over which you or your organization have no control, for example “laws of physics.”
      • New Primary Effect – a separate analysis is required.
      • Other Cause Paths More Productive – continuing down this path would be a waste of time.
  • Does the solution matrix fall into a typical mix such as:

AuditingYourRCA_Graphic

  • Have the solutions been judged against a standardized set of criteria with standard ranges to minimize the possibility of favorite solutions being chosen? (page 118-120)
  • Has each solution been assigned to a team member and given a due date?
  • Does the chart meet all of the four principles of causation? (page 36)
    • Causes and effects are the same thing.
    • Causes exist in an infinite continuum.
    • Each effect has at least two causes in the form of actions and conditions.
    • An effect exists only if its causes exist in the same space and time frame.
  • Does the problem definition establish a clear dollar value significance that will let management make informed choices and approvals?
    • If a dollar value is not appropriate (safety near miss or potential fatality) does the problem definition establish a significant value?
  • Have all of the action items been resolved? (Action items can include areas where more information is needed, there are evidence issues, or any manually entered items need to be resolved and deleted.)

The next step in developing an audit is to generate a checklist that your RCA will be gauged against.

This list can come from the items above, your own list, or a combination of the two. Once you have a list of items to audit against, you need to generate a ratings scale. This can be a pass/fail situation or a scale that gives a rating from 0 to 5 for each item. This can allow you to give partial credit for some items that may not quite meet the full standard.

Develop a score sheet with each item listed and a place to put a score for each one. Don’t forget to leave a space for notes from the reviewer to explain the reasons for partial credit. It’s handy to add some guidelines with each item to give the reviewer a gauge to score the item against. A sample of such guidelines might look like:

0 = Does not exist
1 = Some are in place but not correct
2 = Many are in place and some are correct
3 = All are in place but only some are correct
4 = All are in place and most are correct
5 = All are in place and correct

With guidelines like these easily available as a reference on your score sheet, it helps ensure consistency in the scoring, especially if multiple people will be scoring an RCA.

Now all you have to do is review an RCA against your list, score it, and have some sort of minimum for passing.

This will ensure that each RCA is measured against a consistent standard that can be repeated by multiple people, though there will always be differences if multiple people are auditing RCAs. Differences can be minimized by either having only one person doing the audit or calibrating the audit, or by bringing all personnel together and scoring several as group so that all auditors understand the scoring nuances.

While I’ve provided a pretty thorough list of what to check for when auditing an RCA, my experience is that an RCA can meet all of the requirements above and still have some issues. The biggest one is that the logic may be correct but the causes may not, so the RCA can pass the tests but it won’t actually fix the issue. The fact is, humans are involved and we make mistakes. Sometimes the errors can be caused by inexperienced investigators that need more practice. Other reasons for error are some of the filters that we talk about, such as time constraints, preconceived notions or biases, language issues, etc. This means that there is still a component that needs to be reviewed by someone for general integrity and for things that a computer just can’t look for. This person can be an external corporate person, a contractor, or an internal resource.

RealityCharting™ has tools that are available to the reviewer to assist them in critiquing the analysis such as rules check, action item report, causal element view, and most importantly there is a dashboard.

RCAInvestigationScoreSheet_Mock-up

FREE Instant Download

To assist you in creating your RCA score sheet, we’re offering a free template.

Author: Kevin Stewart

Oftentimes our differences can be a source of conflict and confusion, but in this article I’d like to explore how they can be harnessed to solve problems rather than create them. bigstock-different-points-a720d628f5a371060118883c47802a39fcd70d12

“Everything will be fine if you’ll just do it my way.” At some point we have all probably said or thought something like this. Or maybe you’ve heard it from someone else (quite possibly your significant other). What is the underlying feeling or issue here? What we’re really saying is: “If everyone was just like me and thought the way I did, everything would be fine.” Of course, this is impossible. Neuroscience research tells us that no two brains are exactly alike, and to quote an article from Scientific American on this topic, “…if the apparatus that senses the world differs between two individuals, then the conscious experience of the brains wired to these sensors cannot be the same either.”[1]

Good problem solvers need to be aware of this so they don’t fall into the trap of assuming that everyone knows what everyone else knows, or that everyone interprets information in the same way. I was channel surfing one day and spotted an interesting show about conjoined twins who share one body and most organs, but have completely separate heads (and therefore brains). When the interviewer posed a question, each twin responded in turn with different answers. This caused an ensuing disagreement between them.

These two people had as identical an upbringing and exposure to life and environmental factors as is humanly possible and yet they still thought differently.  If that doesn’t convince you that it’s impossible for two different brains to share the same perspective, I’m not sure what will!

Here’s an example of how two people can be having a conversation about the same thing and yet not be talking about the same thing at all. During a common exercise in one of my classes, a rousing discussion started about cleaning fish. Everyone except one bright student seemed to be on the same page. Everyone else got the feeling that this person was just being difficult, but something inside reminded me to get more information. After a few probing questions we discovered that we did not have the same perspective on the issue. This person had never been fishing and did not understand that “cleaning fish” implied gutting and preparing it for consumption. She couldn’t understand the exercise because her perspective of cleaning was to wash and in general clean the outside, so what did a knife have to do with it!

One more personal observation to cement this issue is a discussion I had with colleagues about the “Hierarchy of Controls” (pictured below for reference).

Pyramid_ARMSColoursOne colleague stated that another must understand this concept since he has an engineering background, and all engineers would know this. I had to inform them that I also have a 30-year background in engineering, maintenance, and reliability but actually had never been exposed to the term either. So once again, the impossible situation of everyone’s perspective being identical rears its head.

While doing your root cause analysis, keep the perspective issue in mind. Ensure that you formulate the problem definition so that each perspective has a chance to be heard, and that the problem is a reflection of all of the perspectives of the team. While doing the root cause analysis, some may not speak up in the meeting but will have a different perspective, so as a facilitator it is your job to draw it out and ensure it gets voiced.

In my experience it can have a significant impact on a team’s understanding of a particular cause. Though sometimes we might wish everyone saw things exactly as we do, allowing for others’ alternate realities is actually key to building a more complete picture of your problem, thereby allowing you to find the best solution.

[1] http://www.scientificamerican.com/article/think-different-jan-11/

publictraining