Showing posts with label Apollo. Show all posts
Showing posts with label Apollo. Show all posts

Thursday, 5 November 2015

RCM 9: If something goes wrong.

Once we designed and implanted our Reliability-Centered Maintenance program we can see that failures still remain in our equipment, some failures are unplanned and others are planned but our RCM plan is not able to avoid. What can we do?

We can repair the failure as soon as possible, but probably the failure occurs often, so we don't solve anything.

The solution is to perform a Root Cause Analysis - RCA that allows us to know the root cause of failures, so we can avoid the cause and prevent the failure occurs again. Exactly RCA is a process to isolate factors to produce failure and determine optimal actions to ensure the failure is not being repeated over again.

Several techniques can be used to perform Root Cause Analysis, from the easiest 5 Whys, of Lean Manufacturing methodology, that can be applied by the machine operators, to many complex techniques such as Events and Causal Charting, Change Analysis, Fishbone (Ishikawa) Diagrams, Fault Tree Analysis (FTA) or Failure Modes and Effects Analysis (FMEA) completed with interviews and tests.

Whatever the methodology, an effective process must meet the following criteria: define the problem, establish relationships between cause and problem, present evidence, explain how to prevent recurrence of the problem, assess measures and facilitate the writing of result reports. Methodologies listed before not always provide an acceptable response to these criteria, so the results are unsatisfactory.

Dean L. Gano, the inventor of Apollo RCA, proposes an evolution of this methodology in his last book RealityCharting – Seven Steps to Effective Problem-Solving and Strategies for Personal Success, it is based in seven steps:

1.      Define the problem. It must include answers related to What is the problem, When did it happen, Where did it happen and what is the significance of the problem, best in Dollars/Pounds/Euros.

2.  Determine the causal relationships. When we have identified the problem, we must identify a minimum of two causes, one of which should be an Action and other a Condition. In each cause, we must identify new causes or a reason to conclude the analysis line.
  
3.   Provide a graphical representation. To draw a graphic chart to show the logic succession of events and causes, it does easier to find relations among them.

4.  Provide evidence, of each cause, best if we have photos, data and test results to confirm both events and causes.

5.      Determine if causes are sufficient and necessary. It means to confirm the event should not occur without the cause, and to confirm the event doesn't need more causes.

6.    Identify effective solutions. When we have identified the sufficient and necessary causes we can propose solutions, they must meet the following criteria: Prevent recurrence, Be within your control, Meet your goals and objectives, and Not cause other problems that you are aware of. We assess solutions by costs-benefits analysis.

Monday, 19 October 2015

RCM 9: ¿Y si algo sale mal?

Una vez que hemos diseñado e implantado nuestro plan de Mantenimiento Centrado en Fiabilidad RCM nos encontraremos con que sigue habiendo fallos en los equipos, algunos que no habíamos previsto y otros que nuestro plan no es capaz de solucionar. ¿Qué podemos hacer entonces?

Podemos reparar el fallo lo antes posible, pero lo más probable es que el fallo se reproduzca, por lo que no solucionamos nada.

La solución es realizar un Análisis de Causa Raíz RCA que nos permita conocer la causa raíz del fallo, de manera que podamos solucionar esa causa y consigamos que el fallo no se vuelva a producir. Eso es exactamente un RCA, un proceso que permite aislar los factores que producen un fallo, una vez que los hemos identificado podremos determinar las acciones óptimas para asegurar que alguno de los factores necesarios no se vuelvan a repetir, de manera que la reproducción del fallo es imposible.

Existen varias técnicas, más o menos normalizadas, que pueden ser de utilidad para realizar análisis de causa raíz, desde la más sencilla 5 Whys (o 5 Porqués) tomada de la metodología Lean, que pueden aplicar los propios operarios en el momento de detectar el fallo, a metodologías más complicadas que requieren formación concreta, como pueden ser Diagramas de Causa y Efecto, Análisis de Cambios, Diagramas Fishbone (o Ishikawa), Análisis de Árbol de Fallos (FTA) o Análisis de Modos de Fallo y Efectos (FMEA), combinados con entrevistas y ensayos.

Cualquiera que sea la metodología que utilicemos debe aportar respuestas a las necesidades de definir el problema, definir todas las causas, proporcionar relaciones entre las causas y el problema, definir evidencias, explicar cómo evitar la recurrencia del problema, valorar las medidas preventivas y facilitar la realización de un informe de resultados. Las metodologías que hemos enumerado antes no siempre consiguen dar una respuesta aceptable a estos apartados, lo que puede hacer que el resultado no sea satisfactorio.

Dean L. Gano, creador de la metodología Apollo, propone una evolución de este método en su libro RealityCharting – Seven Steps to Effective Problem-Solving and Strategies for Personal Success, basada en siete pasos:

1.   Definir el problema. Que debe incluir respuestas a cuál es el problema, cuándo ocurre, dónde ocurre y cuál es el impacto del problema, preferiblemente valorándolo en Euros.

2.  Determinar las relaciones causales. Una vez que tenemos identificado el problema debemos identificar al menos dos causas, de las cuales al menos una será una condición del equipo y al menos una será una acción sobre el equipo, para cada causa debemos buscar nuevas causas o una razón, que finalizaría esa línea del análisis.
  
3.   Proporcionar una representación gráfica. Consiste en mostrar la sucesión de sucesos y causas de forma gráfica, de manera que se puedan ver claramente las relaciones entre ellas.

4.    Proporcionar evidencias, de cada una de las causas, mejor si tenemos fotografías, datos objetivos o pruebas que confirman los sucesos o las causas.

5.  Determinar si las causas son suficientes y necesarias. Es decir, confirmar que el suceso no puede ocurrir si no ocurren esas causas, y si no es necesario más causas.

6.   Identificar soluciones efectivas. Una vez identificadas las causas necesarias y suficientes se actúan sobre ellas, de manera que se prevenga la recurrencia, se controle el equipo, este cumpla con nuestros objetivos y no cause otros fallos. La efectividad de las medidas se evalúan comparando su coste con el coste del fallo.