¿ Análisis de Causa Raiz ? STING

No es un mal hábito si bien no justifica para nada el costo de implantación y formación invertido en la plataforma, debiéndose potenciar su uso para el análisis de causa raiz de fallos de las intervenciones realizadas sobre activos de planta.

En el trabajo con las plataformas de Gestión se suele tender hacia una actividad fundamentalmente administrativa, como apertura y cierre de OT´s, control de seguridad en trabajos subcontratados, seguimiento de partes de actividad, control de repuestos, ….

Por tanto, la metodología óptima de trabajo sería alimentar al sistema con esos datos diarios de actividades rutinarias, para posteriormente realizar análisis que aportarán algún valor a la actividad de mantenimiento.

Gestión de Mantenimiento Asistido por Ordenador (GMAO)

Existen multitud de plataformas desde las que realizar ese análisis de causa, por lo que generalizaremos con las utilidades de una de esas plataformas cierta metodología de trabajo. Los 3 conceptos clave de esta metodología serían:

Síntoma, Causa e Intervención

Síntoma

Es el dato que justifica la necesidad de una intervencion. Por ejemplo, un incremento en el nivel de vibración, o un anormal estado de lubricantes, …..

Causa

Se trata del origen (u orígenes) del síntoma que provocó la intervención. A veces puede confundirse con el concepto anterior, siendo la diferencia su diferente tiempo de aparición; el síntoma es conocido en la emisión de la Orden de Trabajo, mientras que la causa se conoce cuando esa OT es cerrada.

Como muestra, desalineación, falta de lubricación, …..

Intervención

Relación de actividades ejecutadas en el transcurso de la OT, incluyendo no sólo las puras acciones de reparación sino también los detalles de verificación y puesta a punto.

Por ejemplo, alineación de la cadena cinemática con sistema láser e informe, realización del protocolo de arranque de máquina, verificación de la intervencion mediante vibración.

Análisis de Causa Raiz

Sería preciso, por tanto, que cualquier plataforma de información disponga de herramientas para la

Parametrización y Codificación de Causa, Fallo e Intervención.

Como excepción citaríamos la

Intervención

cuyo elevado número de posibilidades puede obligar a introducir campos no incluidos dentro de las librerías que ofrezca el software.

A través de esa parametrización se deberían generar ciertos protocolos de trabajo para el personal de mantenimiento, tipo checklist, que deberán rellenarse en función de los detalles observados en cada trabajo. El documento de trabajo debería incluir los 3 epígrafes anteriormente indicados con la lista de posibilidades a rellenar en cada uno de ellos, siendo recomendable que en la parte relativa a intervenciones se dejara un amplio espacio para la opción de Otros.

Alimentando al software con estos datos, en cualquier momento podríamos efectuar el

análisis de causa raiz del fallo

con vistas filtradas o personalizadas en el programa. Típicamente estas combinaciones de vista y filtro se podría guardar como una herramienta personalizada para su uso posterior.

Ejemplo

Así, imaginemos que hemos creado una vista llamada estudio de síntoma-causa-intervención, accesible desde el menú correspondiente del programa, indicándose posteriormente el input, el síntoma y un rango de fechas, en este caso desgaste de material, y rango 21 Diciembre de 2010-21 de Diciembre de 2012.

La vista mostraría el porcentaje de veces que ha aparecido cada una de las causas históricas.

Por supuesto que el caso anteriormente indicado supondría la más básica de las opciones, puesto que esa vista podría utilizar como input varios síntomas y varios rangos de fechas.

También podría usar otros filtros de entrada como:

Tipo de intervención

• Mantenimiento programado
• Por inspección
• Reparación tras fallo

ID del equipo

• Bombas de Sala 5
• Motor M4433003

Con un incremento exponencial de las posibilidades de análisis.

Infografía Resumen

Gestión de la Información

Ya indicamos al inicio de la entrada que se habría de incrementar el grado de uso de estas utilidades avanzadas de los paquetes de GMAO por su elevado coste de adquisición e implantación.

Ahora bien, esta no es obviamente la razón fundamental de estas utilidades, y de su alimentación y uso, sino poder

Utilizar los Datos del programa

para un Procesos de Optimización como el indicado en nuestro diagrama de actividades.

Si nos remitimos al ejemplo mostrado en la gráfica anterior los datos porcentuales de aparición de cada tipo de causa habrían de servir como entrada:

1. Para cualquiera de las actividades de análisis de fallos (RCM, AMFEC, o TPM) descritas en nuestro portal, pudiéndose ponderar así la frecuencia de aparición de cada fallo del sistema
2. A la actividad correctiva del mantenimiento predictivo (recordar su secuencia, detección-análisis-corrección), garantizando así la eliminación de la causa de fallo para el futuro seguimiento.
3. Al sistema de planificacion del mantenimiento, puesto que para cada una de las causas de fallo podríamos determinar sus probabilidades de degradación.

¿Cómo Gestionas tus Datos Históricos?

La gestión de esta información debe realizarse de un modo como el indicado, puesto que aprovechamos de un modo óptimo las funcionalidades de las herramientas disponibles. Luego, cada usuario deberá elegir su propio procedimiento de trabajo en la plataforma, con sus filtros y vistas personalizadas. Pero lo importante es entender

Qué Valor Añadido Ofrece

ofrece cada Dato de Información.

En este caso concreto, nos referimos al análisis de causa raiz de fallos históricos y su realimentación a nuestros diferentes sistemas de mejora o control en mantenimiento. Pero pueden existir otras aplicaciones como obtener datos para el

Cálculo de KPI,

puesto que todos los datos económicos o de uso de recursos también suelen encontrarse en estas plataformas de GMAO.

Otros problemas frecuentes derivan bien del acceso controlado a este tipo de software, que nos impide el acceso a ciertos datos o bien de

Falta de Formación para el Uso de Herramientas del Programa.

La infografía que ves en la entrada sobre

análisis de causa raiz

es bonita, pues por eso la publico.

Realizada además con medios mínimos: un pequeño portátil y una vieja conexión de fibra, porque la conexión de red está «petada» por la tarjeta de red de ese dispositivo.

Y me siento orgulloso de ello.

¿Y tú?

¿te sientes orgulloso de algo?

en tu día a día; coméntalo si quieres en comentarios.

Yo de este tema del análisis de causa raíz tengo poca idea.

Y muchas veces de esa falta de interés, pues surge «una pequeña genialidad».

Si eres de lo que te gusta la infografía, pues observa lo siguiente:

¿Te interesa el protocolo ethernet?

Pues el siguiente gráfico te muestra conclusiones interesantes sobre el servidor de webempresa donde tengo esta web alojada.

Pues cada URL es un «mundo de posibilidades» en la red global de internet. Y en concreto en relación a la arquitectura cliente-servidor y me puedes contratar como comercial de software en linkedin; porque lo del informe es una «tapadera» para encontrar trabajo por cuenta ajena.

Recuerda que fui despedido con 20 días de indemnización sin posible denuncia por el robo de un equipo electrónico de mi coche cuando estaba en un garage en Madrid haciendo servicios.: