CRL 1 hora: 9/26
Introducción al marco de confiabilidad de Uptime Elements y al
sistema de gestión de activos APRENDE MÁS
Visite nuestro sitio en Español
Una Cultura de Confiabilidad ®
Ingeniería De Confiabilidad Para El Mantenimiento
Estándares RCM: ¿Herramienta útil o estrategia de
marketing?
Estándar RCM de la Sociedad de Ingenieros Automotrices
por JC Leverette
Publicado originalmente en Uptime Magazine, noviembre de 2007. Descargue la versión en PDF del artículo.
Uptime Magazine_Reliability_Nov_2007.pdf
El estándar de la Sociedad de Ingenieros Automotrices (SAE) sobre Mantenimiento Centrado en la
Confiabilidad (RCM), SAE JA1011, continúa generando mucha discusión donde se habla de RCM. Como era
de esperar, estuvo en el centro de algunas discusiones en el reciente Foro de Gerentes de RCM en
Honolulu, HI, donde se reunieron muchos líderes en el campo. El Foro tuvo una interesante sesión dedicada
a la importancia de un estándar RCM. La sesión se anunció como un panel de discusión centrado en SAE
JA1011 y su importancia en el mundo de RCM. Sin embargo, el panel contenía solo un grupo de expertos en
RCM de una visión particular del espectro de RCM. Si bien el panel ciertamente estaba bien informado y
presentó muy bien su versión de la historia, hay otros puntos de vista sobre la necesidad y cómo se debe
usar un estándar RCM.
usar un estándar RCM.
En los muchos foros en los que he visto discutir JA1011, hay una amplia gama de opiniones sobre su utilidad,
su propósito, de dónde viene y si es valioso o inútil, bueno o malo, o ninguno de los anteriores. También he
visto mucha información errónea relacionada con JA1011 y, lamentablemente, debates como el del Foro de
gerentes de RCM sin querer crean la impresión de que JA1011 fue creado por y para un grupo de defensores
de RCM. Mi intención al escribir este artículo es proporcionar dos cosas: 1) algunos datos sobre cómo y por
qué se desarrolló JA1011, y 2) algunas de mis propias opiniones sobre cómo se debe usar y no usar JA1011.
Los orígenes de JA1011
A principios de la década de 1990, el Departamento de Defensa (DoD) inició varias iniciativas para optimizar
su proceso de adquisición. Una de estas iniciativas fue la decisión de reducir la dependencia de los
estándares militares en las nuevas adquisiciones porque se percibían como costosas y onerosas para los
OEM. En cambio, el Departamento de Defensa quería utilizar estándares comerciales o de desempeño. Esta
decisión se implementó cancelando sistemáticamente una gran cantidad de estándares militares. Uno de los
cancelados fue MIL-STD-2173, que documentó el proceso RCM utilizado por Naval Air Systems Commend
(NAVAIR). Naturalmente, NAVAIR se interesó mucho en qué estándar comercial reemplazaría a MIL-STD-
2173.
En apoyo de esta iniciativa, un grupo denominado Asociación de confiabilidad, mantenibilidad y capacidad
de soporte (RMS), coordinó los esfuerzos de varias sociedades y organizaciones involucradas en el
desarrollo de estándares relacionados con la confiabilidad, la capacidad de mantenimiento y la capacidad
de soporte. RMS Partnership solicitó a SAE que liderara el desarrollo de un estándar RCM comercial ya que
no existía ningún equivalente comercial aceptable en ese momento. SAE fue seleccionada como la sociedad
relevante para este estándar debido a su enfoque en las industrias de movilidad y la mayoría de los
involucrados en ese momento estaban en la industria de la aviación. El requisito se pasó a SAE en Dallas, TX
en el verano de 1994.
Poco después de aceptar la responsabilidad, SAE creó un subcomité para comenzar el desarrollo de un
estándar RCM bajo su Comité de compatibilidad G-11. El subcomité RCM inicialmente estaba formado por
representantes de NAVAIR y varios contratistas del Departamento de Defensa. En ese momento, no había
ningún interés comercial en el estándar RCM aparte de los pocos fabricantes de equipos originales de
aviones que querían estar al tanto de lo que se les pediría que hicieran mientras construían aviones. Los
asistentes señalaron con algo de humor que el desarrollo de un estándar “comercial” estaba siendo
realizado casi exclusivamente por personal asociado con el gobierno de los EE. UU. y algunos contratistas
del gobierno.
Comenzamos por varios caminos diferentes en el desarrollo de este estándar, incluido uno dirigido por
"superiores" en SAE para desarrollar un estándar de "mantenimiento preventivo" en lugar de un "Estándar
RCM" porque, irónicamente, no pensaron que sería suficiente. interés en RCM para garantizar su propio
estándar. Se presenta una cita de uno de los correos electrónicos relacionados por su valor humorístico:
“Nosotros [el Comité de compatibilidad de SAE] no estamos interesados en una 'especificación RCM'.
Queremos una 'especificación de mantenimiento programado'. Una 'especificación RCM' tendría un alcance
demasiado limitado. No hay suficiente interés general en RCM para justificar la participación de SAE en tal
especificación”. Aunque no de la misma magnitud, esta declaración podría pasar a la historia como una de
las peores predicciones de la historia.
También nos encontramos en varios momentos tratando de corregir deficiencias conocidas o percibidas en
los procesos actuales, pero no pudimos ponernos de acuerdo sobre cómo corregirlas. Eventualmente,
llegamos a la conclusión de que realmente no había un proceso de RCM "estándar" y que un "estándar" no
era el lugar para desarrollar procedimientos nuevos y no probados. También decidimos ignorar la directiva
para crear un estándar de mantenimiento preventivo y comenzamos a decidirnos por la idea de crear un
conjunto de criterios que permitieran a los usuarios determinar si un proceso determinado se ajustaba a los
principios originales de RCM definidos por Nowlan y Heap. .
Al final del proceso, hicimos esfuerzos para buscar experiencia en la industria comercial a medida que
aumentaba el interés en RCM. A fines de 1997, John Moubray y algunos usuarios del proceso RCM2™ se
involucraron. A pesar de algunos debates animados a lo largo del camino, pudimos completar JA1011 en
1999. Aquellos que estuvieron involucrados pueden atestiguar que muchas lágrimas y sangre quedaron en
los pisos de las salas de reuniones a lo largo del camino. Sin embargo, creo que todos sentimos que el
producto final fue un compromiso cuidadosamente elaborado y elaborado que cumplió con la intención de
sus autores: un documento que identificaba los principios originales de RCM según lo definido por Nowlan y
Heap y en su mayor parte omitía las agendas comerciales.
El propósito de JA1011
SAE JA1011 existe hoy porque el DoD quería un estándar comercial para RCM. El objetivo principal en el
desarrollo de JA1011 fue proporcionar un documento al que el Departamento de Defensa pudiera hacer
referencia en los contratos que garantizaría que el Departamento de Defensa obtuviera lo que esperaban
cuando contrataron el análisis de RCM y no un proceso abreviado o completamente diferente que afirma ser
RCM. Aunque algunos tenían opiniones firmes sobre si estos procesos “alternativos” eran buenos o malos, la
mayoría de los autores de JA1011 no tenían la intención de emitir un juicio sobre todos estos otros procesos.
Un par de referencias a otros procesos entraron en el estándar; en retrospectiva, probablemente deberían
haberse dejado de lado. El propósito del estándar era definir el proceso de RCM como los involucrados lo
conocían, lo entendían y querían que permaneciera para su uso.
SAE define sus estándares como informes técnicos que son "una documentación de prácticas o
especificaciones de ingeniería ampliamente aceptadas para un material, producto, proceso, procedimiento o
método de prueba". Cualquiera que haya pasado tiempo en el campo de RCM sabe que hay una gran
cantidad de procesos con bastante variación que se denominan RCM. Aunque no había tantos en el
momento en que se inició JA1011, estaba claro que no había un solo proceso que se ajustara a la definición
descrita anteriormente. Quedó claro que, en lugar de identificar un proceso específico, la única alternativa
era identificar las características comunes de los procesos que los hacían RCM. Para estas características,
utilizamos como base el informe original de Nowlan y Heap, que acuñó el término RCM.
El propósito de SAE JA1011 es proporcionar una vara de medir para comparar procesos y ver si se adhieren a
los principios originales del informe de Nowlan y Heap. Su objetivo era proporcionar los requisitos mínimos
de un proceso RCM utilizando los principios identificados por Nowlan y Heap. Imaginamos que otros
propondrían soluciones creativas que mejoraran el proceso básico. Siempre que cumplieran con los
elementos mínimos de la norma, se alentaron y se fomentan las mejoras. JA1011 no pretendía reclamar el
término RCM ni determinar la validez o utilidad de los procesos que no lo cumplen. Si bien estoy seguro de
que la mayoría de los autores creen que RCM "real" sigue los principios establecidos por Nowlan y Heap, la
mayoría de nosotros no nos hacemos ilusiones de que las iniciales "RCM" no se pueden usar para describir
una cantidad de procesos. incluso si no están remotamente relacionados con el original. La solución es
simple: si desea que RCM se refiera a RCM compatible con SAE JA1011 en su aplicación, haga referencia de
esa manera en un contrato, solicitud de propuesta o declaración de trabajo.
Los usuarios de RCM deberían utilizar JA1011 como una herramienta para decidir si un proceso determinado
hará lo que ellos quieren que haga. Como todos los estándares, se puede "a medida" o modificar para usar
solo aquellos elementos que un usuario en particular encuentre útiles. Como vara de medir, se puede utilizar
para identificar las diferencias en los procesos que no cumplen. Depende del usuario decidir si esas
diferencias son buenas, malas o importan en absoluto. Los usuarios son libres de usarlo como lo deseen, o
no usarlo en absoluto. JA1011 no es obligatorio ni exigible a través de ningún otro medio que no sea la
referencia del contrato. No hay organizaciones que yo sepa que actualmente certifiquen el cumplimiento
con JA1011, por lo que, en última instancia, es responsabilidad del usuario decidir si un proceso en particular
cumple. Reclamaciones de aquellos que menosprecian otros procesos, diciendo que no cumplen con JA1011
y, por lo tanto, no tan bueno como el suyo, debe ser visto con sospecha. En mi opinión y experiencia, la
mayoría de los que critican otros procesos tienen muy poca idea de cómo se utilizan esos otros procesos y
si son apropiados para una aplicación determinada. Nuevamente, solo los usuarios están calificados para
tomar esa decisión.
Lo que JA1011 no hace
Uno de los temas discutidos por el panel en el foro de Gerentes de RCM fue lo que debería agregarse al
Estándar. Esa discusión fue uno de los principales motivadores para escribir este artículo, ya que uno de sus
puntos defendía exactamente la posición opuesta adoptada por los autores originales de JA1011 y
claramente violaba la definición de lo que debería estar en un estándar como se describe anteriormente.
La cuestión era cómo se debería realizar el análisis RCM. JA1011 deliberadamente no aborda cómo ejecutar
el proceso de análisis de RCM. El panel en Hawái abogó por que JA1011 se actualice para incluir la práctica
de usar "reuniones de facilitación" con representación de ciertos grupos clave y que todas las decisiones de
análisis se tomen de manera que se genere consenso. El hecho de que JA1011 no aborde este problema fue
bien discutido, intencional y completamente aceptado durante su desarrollo, incluso por el Sr. Moubray,
quien fue un incansable defensor de este método. No hubo en ese momento, ni hay ahora, una "amplia
aceptación" de que esta es la única forma aceptable de realizar RCM. Nuestra experiencia es todo lo
contrario. Hemos obtenido resultados de alta calidad utilizando varios métodos diferentes, incluidas
reuniones facilitadas y analistas individuales que solicitan la información requerida de todas las fuentes
relevantes. Para realizar un análisis competente, necesita experiencia y conocimiento en tres áreas
principales: conocimiento técnico del equipo en sí, conocimiento del entorno operativo y cómo se usa el
equipo, y conocimiento del proceso RCM y los principios de falla y confiabilidad relacionados. La mejor
manera de combinar estos elementos de conocimiento varía según la situación. La decisión de cómo realizar
RCM la toma mejor la organización que implementa un programa de RCM una vez que comprende lo que se
necesita para ejecutar el proceso. conocimiento técnico del equipo en sí, conocimiento del entorno
operativo y cómo se usa el equipo, y conocimiento del proceso RCM y los principios de confiabilidad y falla
relacionados. La mejor manera de combinar estos elementos de conocimiento varía según la situación. La
decisión de cómo realizar RCM la toma mejor la organización que implementa un programa de RCM una vez
que comprende lo que se necesita para ejecutar el proceso. conocimiento técnico del equipo en sí,
conocimiento del entorno operativo y cómo se usa el equipo, y conocimiento del proceso RCM y los
principios de confiabilidad y falla relacionados. La mejor manera de combinar estos elementos de
conocimiento varía según la situación. La decisión de cómo realizar RCM la toma mejor la organización que
implementa un programa de RCM una vez que comprende lo que se necesita para ejecutar el proceso.
Hay varios otros temas que se discutieron en el desarrollo de JA1011 y no se incluyeron en él por razones
similares. Dos ejemplos son un diagrama de lógica de decisión y cómo decidir a qué activos se les debe
aplicar RCM. Esos temas merecen una discusión significativa por sí solos. Los guardaré para otro día y otro
artículo.
En resumen, JA1011 estaba destinado a ser una herramienta para que los usuarios evaluaran todos los
diferentes procesos de RCM que probablemente encontrarían. Fue desarrollado para identificar si los
procesos que se denominan RCM se adhirieron a los principios originales de RCM definidos por Nowlan y
Heap. La forma en que los usuarios usan esa herramienta y lo que hacen con los resultados depende
totalmente de ellos.
JC Leverette es actualmente el Vicepresidente de Ingeniería y Logística de Andromeda Systems
Incorporated y lidera proyectos de RCM y otros proyectos de confiabilidad y mantenimiento en una amplia
gama de industrias. Anteriormente, fue ingeniero sénior en Naval Air Systems Command, donde participó en
varios proyectos de RCM, ayudó en el desarrollo de los procesos, políticas y herramientas actuales de
NAVAIR, y participó en el desarrollo de SAE JA1011. Ha estado involucrado en el campo de RCM por más de
18 años.
Nota del editor: IEC 60300-3-11:2009 Gestión de la confiabilidad - Parte 3-11: Guía de aplicación -
Mantenimiento centrado en la confiabilidad IEC 60300-3-11:2009 Gestión de la confiabilidad - Parte 3-11:
Guía de aplicación - El mantenimiento centrado en la confiabilidad también es un Norma Internacional que
puede ser considerada. - Terrence O'Hanlon
[Link]
