Friday, 20 November 2015

RCM 10: Lecciones Aprendidas

Muchos factores pueden salir mal durante la implantación de un proyecto de RCM, al igual que en otros tipos de proyectos es importante registrar las lecciones aprendidas, es decir del conocimiento adquirido a lo largo del proceso, normalmente en base a errores, para ser aprovechados en futuros proyectos.

A continuación incluyo algunos de las lecciones que he aprendido en la implantación de proyectos de RCM:

1. Alcance del proyecto. Es un punto que habitualmente causa conflictos entre los implicados en el proyecto, esto se debe a que tienen diferentes experiencias en RCM, y puesto que cada proyecto es diferente, es habitual que aparezcan discrepancias.

Este problema se ve incrementado si hay participación de externos, ya que implica costes adicionales al proyecto. Es muy importante definir correctamente el alcance del proyecto con los implicados, esto evitará malentendidos, aumentos de plazos y de costes.



2.   Grado de detalle. Se debe definir el grado de detalle, esto incluye tanto el detalle en el análisis de los equipos como en la descripción de las tareas y acciones que se van a implantar como consecuencia de los análisis.

Un grado de detalle demasiado bajo hace el análisis inservible por no concretar los resultados, un grado de detalle demasiado elevado lo hace inútil por dar como resultado un plan demasiado extenso, largo y costoso de realizar.

En lo referente al análisis de los equipos, siguiendo la norma ISO 14224, es recomendable analizar a nivel de componentes, dejando el  nivel de elementos para equipos especialmente críticos. En cuanto a la descripción de tareas, basta con que sean lo suficientemente precisas para que los operarios de mantenimiento las identifiquen correctamente, no es necesario que sustituyan a una orden de trabajo. Si se trata de una acción que supone un rediseño, es suficiente con que indique el objetivo, plazo y presupuesto de este.

3. Expectativas de los afectados. Es normal que los afectados tengan diferentes expectativas, en gran parte se puede solucionar este problema con una buena definición de los objetivos.

A menudo, los afectados creen que el resultado del análisis RCM es una reducción de los costes de mantenimiento, un incremento del número de tareas, la eliminación total de los fallos o la total sustitución del mantenimiento preventivo por predictivo.

Debemos tener en cuenta que RCM supone una optimización del mantenimiento para aumentar la fiabilidad al menor coste, por lo tanto no podemos predecir ni debemos imponer los resultados.   

4.  ¿Estamos haciendo realmente RCM? A menudo pensamos que estamos haciendo RCM pero no es así, no es RCM buscar una justificación al plan de mantenimiento actual, utilizar todas las tareas de mantenimiento recomendadas por el fabricante del equipo, o implantar mantenimiento predictivo.

Debemos tener claro que RCM supone seguir un procedimiento estructurado para, mediante árboles de decisión, producir un plan de mantenimiento que proporcione la máxima fiabilidad al menor coste.

5.   Formación de los afectados. Formar en RCM a todos los afectados por el proyecto es la mejor forma de evitar falsas expectativas y asegurar que realmente se está haciendo RCM.

La formación puede tener diferentes niveles de intensidad según el grado de implicación de los afectados, pero debe al menos servir para crear una cultura de fiabilidad y dejar claros los objetivos, alcance, grado de detalle y posibles resultados; llegando hasta un conocimiento profundo del procedimiento en el caso de los miembros de los equipos de análisis e implantación.

Para que cumpla estas funciones eficazmente, se recomienda realizar la formación al principio del proyecto.



6.  Mejora continua. El plan de mantenimiento RCM es un documento vivo que debe actualizarse continuamente, es un error pretender realizar un estudio que sirva durante una serie de años.

El plan debe actualizarse según se modifiquen las condiciones de trabajo, el entorno económico, los precios de venta del producto producido y los costes de materias primas y energía o, incluso, evolucionen las tecnologías de técnicas predictivas.

Además, se deben analizar mediante RCA e incluir en el plan todos los fallos funcionales que aparezcan y que no se han previsto en el proyecto de RCM, y los que sigan resultando recurrentes después de implantar el plan.

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 other 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 ocurrs 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 a 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 much 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 evidences, 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, 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 with 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 ocur 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.

7.  Implement and track solutions. Finally, solutions must be implanted and monitorized to check their effectiveness.