Interpretando los datos de falla

A continuación un aparte del  informe RCM de 1978 de los famosos Nowlen & Heap. En este se mencionan algunos problemas básicos de los datos  en los análisis de confiabilidad.

El problema de la interpretación de los datos de falla se complica aún más por la existencia de las diferentes políticas de registro de información entre una organización y otra. Por ejemplo, una compañía aérea puede clasificar un motor removido por problemas en los alabes de la turbina como una falla (esta clasificación sería coherente con nuestra definición de falla potencial). Esta remoción y otras parecidas a esta cuentan como fallas en los datos de falla. Otra compañía aérea podría clasificar dicha remoción como una “precaución” o inclusive como un “programado” (al descubrir una falla potencial se programaría  la remoción de la unidad al presentarse la primera oportunidad). En ambos casos la remoción no se registraría como una falla.

Diferencias similares se generan como resultado de la variación en los requerimientos de desempeño. La incapacidad de un ítem para cumplir con algunos requisitos específicos de desempeño es considerada una falla funcional. De este modo, las fallas funcionales (y también las fallas potenciales) se crean o se eliminan por las diferencias en los límites especificados; incluso en el mismo componente del equipo, lo que es una falla para una organización no necesariamente es una falla para la otra.  Estas diferencias no solo existen de una organización a otra, sino también dentro de una misma organización en un largo periodo de tiempo. El cambiar los procedimientos, la definición de fallas o cualquier estándar relacionado resultará en un cambio en la rata de fallas registradas. Otro factor que debe tenerse en cuenta es la diferencia en la orientación entre los fabricantes y los usuarios. Por un lado, una organización con operación tiende  a ver una falla como indeseable y espera que el fabricante mejore el producto para eliminar dichas ocurrencias. Por el otro lado, el fabricante considera que su responsabilidad es entregar un producto capaz de desempeñarse al nivel de confiabilidad garantizado (si existe) y bajo condiciones de esfuerzo específicas para el cual fue diseñado. Si más adelante el equipo es operado frecuentemente más allá de estas condiciones, el fabricante no querrá asumir responsabilidad de ninguna falla que pueda haber sido causada o acelerada por dicha operación.  Es por esto que los fabricantes tienden a investigar el historial de falla de las organizaciones operadoras para utilizarlas en sus pruebas de operación. El resultado es que los usuarios de los equipos, con cierta confusión entre ellos, hablan sobre lo que realmente presenciaron y vieron mientras que el fabricante habla sobre lo que debieron haber previsto.

Lo anterior resalta la importancia de tener una clara estrategia de información de confiabilidad. Dicha estrategia va más allá de la elaboración y aplicación de códigos de falla. Nuestra estrategia no solo debe relacionar órdenes de trabajo con los registros RCM adecuados sino que también debe incluir un entendimiento, teniendo en cuenta el contexto operacional, de lo que constituye una falla potencial, una falla funcional y una suspensión. No existe software que por sí solo (sin importar que tan sofisticado sea) pueda obviar el requerimiento de su organización de mantenimiento de desarrollar y divulgar un estándar que abarque una estrategia de información de confiabilidad (LRCM).

© 2011, Luis Hoyos Vásquez. All rights reserved.

This entry was posted in Datos y Muestras and tagged , , . Bookmark the permalink.