1.1 ¿Qué es RCM?

RCM también se puede utilizar para formular decenas de soluciones que van mucho más
allá del mantenimiento. El nombre Mantenimiento centrado en la confiabilidad se presta
a un proceso que se utiliza para desarrollar el mantenimiento proactivo de un activo, pero
RCM también se puede utilizar para formular decenas de soluciones que van mucho más
allá del mantenimiento. Estas soluciones pueden ofrecer enormes beneficios a una
organización. Sin embargo, al aplicar RCM, muchas organizaciones se centran únicamente
en el desarrollo de un programa de mantenimiento proactivo. que no aprovecha al
máximo los poderosos principios de RCM. Este libro establece los principios de RCM de
una manera directa para que aquellos interesados en aplicar RCM puedan ser conscientes
no sólo de lo sencilla que puede ser la aplicación de RCM, sino también de lo poderosa que
es.
1.2 Elementos que influyen en un sistema
Es especialmente importante mirar más allá del mantenimiento proactivo porque hay
muchos elementos que influyen en un sistema, como se muestra en la Figura 1.1.

No importa cuál sea el equipo. Muchos factores tienen un efecto directo en el

rendimiento del equipo: el programa principal que se aplica, los procedimientos operativos
que se realizan, las publicaciones técnicas a las que se hace referencia , los programas de
capacitación a los que se asiste , las características de diseño que están en servicio , las
piezas de repuesto ( o la falta de ellas ) en las que se confía , con qué frecuencia se opera
un activo, dónde se requiere que el equipo funcione, y los procedimientos de emergencia
que existen. Si estas estrategias están bien desarrolladas, el equipo (y por lo tanto la
 organización) se beneficia. Si alguna de estas estrategias está mal concebida o es
inapropiada, el proceso por el cual el equipo juega un papel se resiente.
1.3 La esencia de RCM: Gestión de las consecuencias de las fallas
A menudo se cree erróneamente que los custodios de los equipos están en el negocio de
prevenir las fallas. Aunque es posible desarrollar estrategias que prevengan algunas fallas
(ver Capítulo 9). es casi imposible prevenir todas las fallas. Por ejemplo, ¿es posible
prevenir todas las fallas asociadas con un motor eléctrico? ¿Qué tal un arrancador de
automóvil, un equipo de aviónica o un motor de turbina? Ciertamente no. Por lo tanto, a
menudo se implementan otras estrategias para manejar las fallas que de otro modo serían
inevitables cuando ocurren. Por ejemplo, las organizaciones dependen en gran medida de
los procedimientos operativos, los procedimientos de emergencia, los programas de
capacitación y la redundancia en el diseño del equipo, como se muestra en la Figura 1.1.
Hay tres sistemas hidráulicos completamente redundantes en la mayoría de las aeronaves
comerciales porque se entiende que no se pueden prevenir todas las causas de falla de un
sistema hidráulico. Si uno de los tres sistemas falla, hay dos sistemas totalmente
redundantes disponibles para proporcionar la energía hidráulica necesaria para un vuelo
seguro. Debido a que no se pueden prevenir todas las fallas, los custodios responsables
deben implementar otras soluciones para tratar adecuadamente las fallas cuando ocurren.
En otras palabras, los custodios responsables se ocupan de gestionar las consecuencias de
las fallas, no necesariamente de prevenirlas.
1.4 Lo que RCM puede producir
Innumerables problemas, como procedimientos operativos incompletos o diseño de
equipo deficiente, pueden afectar negativamente el rendimiento del equipo. Por esa
razón, es increíblemente importante que estos problemas se identifiquen e incluyan en un
análisis RCM. Su inclusión permite analizar el asunto bajo los principios de RCM para
formular una solución técnicamente adecuada y eficaz. Uno de los principales productos
de un análisis RCM es el desarrollo de un programa de mantenimiento programado. Sin
embargo, como se muestra en la Figura 1.2. RCM puede ayudar a formular otras
soluciones, como el desarrollo de un plan de mantenimiento proactivo, nuevos
procedimientos operativos, actualizaciones de publicaciones técnicas, modificaciones de
programas de capacitación, rediseños de equipos, cambios de suministro, procedimientos
mejorados de solución de problemas y procedimientos de emergencia revisados. En el
contexto de RCM. estas otras soluciones se conocen como estrategias predeterminadas,
como se muestra en la Figura 1.3.
 Figura 1.2 Ejemplos de soluciones que RCM puede producir.

CAPÍTULO 1
1.5 La evolución de los principios de RCM
Es importante entender la evolución de RCM para poder apreciar la majestuosidad de sus
principios. La evolución de RCM se cuenta mejor como una historia, como me la contaron
a mí. La historia comienza a mediados de la década de 1950 en la industria de las
aerolíneas comerciales donde, en ese momento, se creía que casi todas las fallas estaban
directamente relacionadas con la edad operativa. En otras palabras, era más probable que
ocurrieran fallas a medida que aumentaba la edad operativa. La Figura 1.5 ilustra este
punto. El eje x representa la edad, que se puede medir en cualquier unidad, como el
tiempo del calendario, las horas de funcionamiento, las millas y los ciclos. El eje y
representa la probabilidad condicional de falla. La filosofía asociada con el patrón de fallas
es que, suponiendo que un elemento permanece en servicio y llega al final de su vida útil,
la probabilidad de falla aumenta considerablemente si permanece en servicio. En otras
palabras, como lo declararon Stanley Nowlan y Howard Heap de United Airlines, se creía
que "cada elemento de un equipo complejo tiene una 'edad correcta, por lo que es
necesaria una revisión completa para garantizar la seguridad y la confiabilidad operativa".
Se creía que lo sensato era revisar o reemplazar componentes antes de llegar al final de su
vida útil con la creencia de que esto evitaría fallas. La mentalidad de que era más probable
que ocurriera una falla a medida que aumentaba el tiempo de operación estaba
profundamente arraigada en los programas de mantenimiento. En ese momento,
aproximadamente el 85% de los componentes de la aeronave estaban sujetos a revisión o
reemplazo a intervalos fijos. Los programas de mantenimiento fueron muy altos en
revisiones programadas y reemplazos programados.
Se pusieron en servicio los nuevos planes de mantenimiento. Después de un período de
tiempo, notaron que sucedieron tres cosas.
1. En muy pocos casos las cosas mejoraron.
2. En muy pocos casos las cosas se mantuvieron igual.
3. Pero, en su mayor parte, las cosas empeoraron.
La Administración Federal de Aviación (FAA) y la industria. estaban frustrados por su
incapacidad para controlar la tasa de fallas al cambiar los intervalos de revisión y
reemplazo programados. Como resultado, se formó un grupo de trabajo a principios de la
década de 1960. A este equipo de pioneros se le encomendó la responsabilidad de
obtener una mejor comprensión de la relación entre la confiabilidad operativa y la política
de revisión y reemplazo. Identificaron que dos suposiciones estaban integradas en la
filosofía de mantenimiento actual.
Supuesto 1: La probabilidad de falla aumenta a medida que aumenta la edad operativa.
Suposición 2: Se supone que sabemos cuándo ocurrirán esas fallas. El equipo identificó
que la segunda suposición ya había sido cuestionada. En un intento por disminuir la tasa
de fallas, se acortaron los intervalos de revisión y reemplazo, como se muestra en la Figura
1.6.

Figura 1.6 Ejemplo de un intervalo de revisión reducido

Pero cuando se acortaron los intervalos, la tasa de fracaso aumentó. Luego se identificó
que era necesario cuestionar la primera suposición: la probabilidad de falla aumenta a
medida que aumenta la edad operativa.
Como resultado, se realizó una enorme cantidad de investigación. Electrónica, hidráulica,
neumática, motores y estructuras fueron analizados. Lo que se descubrió sacudió el
mundo del mantenimiento en ese momento. La investigación mostró que no había un
patrón de falla que describiera cómo se comportan los modos de falla. De hecho, hay seis
patrones de falla, como se ve en la Figura 1.7. Los patrones de falla A, B y C tienen algo en
común. Exhiben un fenómeno de falla relacionado con la edad. Del mismo modo, los
patrones de falla D, E y F tienen algo en común. Presentan aleatoriedad.
 Figura 1.7 Seis patrones de falla
Lo que fue especialmente impactante fue el porcentaje de modos de falla que se ajustaban
a cada patrón de falla. La figura 1.8 resume el porcentaje de modos de falla que se ajustan
a cada patrón de falla

Figura 1.8 Porcentajes de Modos de Falla que cumplieron a cada patrón de falla
En conjunto, solo el 11 por ciento de los modos de falla del sistema de la aeronave se
comportó de acuerdo con los patrones de falla A, B y C, donde la probabilidad de falla
aumenta con el aumento de la edad operativa.
Los patrones de falla A y B tienen una zona de desgaste bien definida; tiene sentido que los
modos de falla que se ajusten a estos patrones de falla puedan gestionarse de manera
efectiva con una revisión o reemplazo de intervalo fijo. Los patrones de falla A, B y C
generalmente se asocian con elementos simples que están sujetos, por ejemplo, a fatiga o
desgaste, como neumáticos, pastillas de freno y estructuras de aeronaves.
Sin embargo, el 89 por ciento restante de los modos de falla del sistema de la aeronave
ocurren aleatoriamente. Corresponden a los patrones de falla D, E y F. Después del breve
aumento en la probabilidad condicional de falla en el patrón D, así como el período de
mortalidad infantil presente en el patrón de falla F, el modo de falla tiene la misma
probabilidad de ocurrir en cualquier momento. intervalo en la vida útil esperada del
equipo. Por lo tanto, para el 89 % de los modos de falla, no tiene sentido realizar una
revisión o reemplazo de intervalo fijo porque la probabilidad de falla es constante. Estos
patrones de falla generalmente se asocian con equipos complejos como la electrónica, la
hidráulica y la neumática.
Dos problemas más notables
1. Solo el dos por ciento de los modos de falla se conformaron con el patrón de falla B,
como se muestra en la Figura 1.9, ¡sin embargo, este fue el patrón de falla que definió
la forma en que creían que se comportaba la falla del equipo!
2. Después del breve incremento en la probabilidad condicional de fracaso en el patrón
D, así como la mortalidad infantil período presente en el patrón de falla F, el 89 por
ciento de los modos de falla ocurren aleatoriamente, como se muestra en la figura
1.10.

Lo sorprendente fue que los planes de mantenimiento en uso se derivaron asumiendo que
casi todos los modos de falla se comportaban de acuerdo con el patrón de falla B. Sin
embargo, solo el dos por ciento de los modos de falla realmente se comportaban de esa
manera. Además, se demostró que la mayoría de los Modos de Falla ocurren
aleatoriamente. Por lo tanto, la revisión o el reemplazo de intervalo fijo técnicamente no
tenía sentido. Es decir, si un elemento se reemplaza hoy, tiene la misma probabilidad de
fallar mañana que un año después.

Más importante aún, no solo la gran mayoría de las revisiones y reemplazos programados
no tenían sentido, sino que sus esfuerzos por controlar la tasa de fallas con revisiones y
reemplazos a intervalos fijos fueron contraproducentes. Su estudio mostró que el 68 por
ciento de los modos de falla se comportaron de acuerdo con el patrón de falla F, como se
muestra en la Figura 1.11.

La mortalidad infantil (p. ej., componente instalado al revés, herramienta olvidada,

procedimientos operativos deficientes) desempeñó un papel importante en las altas tasas
de falta de confiabilidad. Por lo tanto, estas debilidades estaban empeorando las cosas con
revisiones y reemplazos programados. Como se muestra en la Figura 1.12, cada vez que se
realizaba una revisión o reemplazo programado, la
mortalidad infantil se reintrodujo en un sistema
estable.

Figura 1.12 Reintroducción de la mortalidad infantil

Esta investigación demostró de manera concluyente que la revisión o el reemplazo de

intervalo fijo no es técnicamente la acción correcta a tomar cuando la falla no es una
función de la edad operativa. De hecho, en la mayoría de los casos, la revisión y el
 reemplazo programados dañan la confiabilidad. Debido a que la mayoría de los modos de
falla ocurren aleatoriamente, la tasa de falla no se puede controlar realizando más
revisiones y reemplazos programados. Armado con estos hechos, se necesitaba desarrollar
una nueva forma de derivar las tareas de mantenimiento programadas, preparando el
escenario para el nacimiento de los principios de RCM.

1.6 El desarrollo de los principios de RCM

A partir de esta investigación, los principios de RCM se concibieron por primera vez dentro
de la industria de las aerolíneas comerciales. MSG-1, Manual:
La Evaluación de Mantenimiento y Desarrollo de Programas fue preparado por el Grupo
Directivo de Mantenimiento 747 y publicado en 1968. Este documento contenía el primer
uso de técnicas de diagrama de decisión para desarrollar un programa de mantenimiento
programado antes del servicio.
Las mejoras a MSG-1 llevaron al desarrollo de MSG-2: Documento de planificación del
programa de mantenimiento de aerolíneas/fabricantes, que se publicó en 1970. MSG-2 se
utilizó para desarrollar los programas de mantenimiento programados para Lockheed 1011
y Douglas DC-10. También se usó en aviones militares tácticos McDonnell F4J y Lockheed
P-3.
A mediados de la década de 1970, el Departamento de Defensa estaba interesado en
saber más sobre cómo se desarrollaban los planes de mantenimiento dentro de la
industria de las aerolíneas comerciales. En 1976 el departamento de Defensa encargó a
United Airlines que redactara un informe que detalló su proceso. Stanley Nowlan y
Howard Heap, ingenieros de United Airlines, escribió un libro sobre el proceso y lo llamó
Mantenimiento Centrado en la Confiabilidad. Su libro fue publicado en 1978. Para muchos,
Stanley Nowlan y Howard Heap son considerados dos de los pioneros más significativos del
proceso RCM. Su libro sigue siendo uno de los documentos más importantes jamás
escritos sobre mantenimiento de equipos.
Utilizando el libro de Nowlan y Heap como base para la actualización, en 1980 se publicó
MSG3, Desarrollo de mantenimiento programado del operador/fabricante. Desde
entonces, MSG-3 ha pasado por muchas actualizaciones. El MSG-3 continúa utilizándose
en la industria de las aerolíneas comerciales en la actualidad, pero aún tiene la intención
de desarrollar un programa de mantenimiento programado para las aeronaves antes del
servicio.
Desde que se publicó el libro de Nowlan y Heap, ha habido
 Ha habido varias actualizaciones al proceso de RCM, a saber, la identificación de
problemas ambientales. El difunto John Moubray fue otro gran pionero del proceso RCM;
hizo mucho para promover RCM en toda la industria comercial. Su libro RCM II se publicó
por primera vez en el Reino Unido en 1991 y en los Estados Unidos en 1992.
RCM optimizado y SAE JA1011
Aunque RCM es un proceso intensivo en recursos, los análisis se pueden completar de
manera eficiente si el proceso se usa correctamente con las personas adecuadas. Sin
embargo, a mediados de la década de 1990, comenzaron a aparecer versiones
simplificadas de RCM. Estas versiones a menudo omiten pasos clave en el proceso y
difieren significativamente de lo que pretendían originalmente Nowlan y Heap. Como
resultado, la Sociedad de Ingenieros Automotrices (SAE) publicó SAE JA1011, Criterios de
evaluación para procesos de mantenimiento centrado en confiabilidad (RCM) en 1999.
Este estándar reconocido internacionalmente describe los criterios que cualquier proceso
RCM debe incorporar para ser llamado RCM. SAE JA1011 se actualizó en 2009.
El proceso RCM definido en este libro cumple con SAE JA1011. Más importante aún, se
mantiene fiel a lo que originalmente pretendían los pioneros originales del proceso,
Stanley Nowlan y Howard Heap. Por lo tanto, este libro detalla True RCM.
1.7 Definición de RCM
RCM es un proceso notable y se puede definir de la siguiente manera.
Los términos base cero, estrategias de gestión de fallas y entorno operativo requieren una
explicación más detallada.
El Mantenimiento Centrado en la Confiabilidad es una base cero, proceso estructurado
utilizado para identificar la gestión de fallas estrategias requeridas para asegurar que un
activo cumpla con su misión requisitos en su entorno operativo en la forma más segura
y manera rentable.
Basado en cero
Cada análisis de RCM se lleva a cabo asumiendo que no se está realizando ningún
mantenimiento proactivo. En otras palabras, los modos de falla y los efectos de falla se
escriben asumiendo que no se hace nada para predecir o prevenir el modo de falla. De
esta manera, se pueden evaluar las consecuencias de cada modo de falla y se pueden
formular soluciones sin sesgo hacia lo que se está haciendo actualmente.
Estrategias de gestión de fallas
Tenga en cuenta que la definición establece que RCM se utiliza para identificar estrategias
de gestión de fallas, no tareas de mantenimiento. Como se explicó anteriormente, la
 gestión de activos requiere algo más que un simple mantenimiento programado. Por lo
tanto, RCM proporciona herramientas poderosas para desarrollar otras soluciones, como
se detalla en la Figura 1.2.
Entorno operativo
La forma en que se mantiene un activo depende mucho más de lo que es un activo.
Cuando se formulan soluciones para los activos, se deben5 considerar los siguientes
aspectos relacionados con el entorno operativo.
• Entorno físico en el que se utilizará el activo (p. ej., clima frío, clima desértico, entorno
controlado)
• Temporal operativo (p. ej., operación de 24 horas, el sistema funciona 6 horas cada día)
• Circunstancias bajo las cuales se operará el sistema (p. ej., independiente, uno de los
cuatro sistemas se ejecuta a la vez pero se rota todos los meses)
• Redundancia (p. ej., el sistema o cualquiera de sus componentes funcionan en presencia
de una copia de seguridad)
Estos problemas pueden influir en gran medida no solo en qué tareas de mantenimiento
se identifican y con qué frecuencia se realizan, sino también en otras soluciones, como el
diseño de equipos y los programas de capacitación. Por lo tanto, el entorno operativo debe
estar claramente definido.
1.8 Definición del desempeño en el contexto de RCM
En el contexto de RCM, hay dos características relacionadas con el rendimiento del equipo
que los custodios responsables deben examinar cuidadosamente: la capacidad de diseño y
el rendimiento requerido.
Los propietarios de activos realizan RCM para determinar qué acciones se deben tomar
para garantizar que el equipo cumpla con los requisitos de la misión. Una misión podría ser
remolcar una pieza de equipo al sitio de construcción, lanzar un avión desde un
portaaviones o garantizar que haya suficiente aire en la planta para el proceso de
fabricación posterior. Pero cuando se trata de definir el rendimiento, los custodios de
equipos deben ser específicos sobre lo que pueden hacer sus activos (capacidad de diseño)
y lo que necesitan que hagan (rendimiento requerido). La siguiente discusión ilustra este
punto.
Tomemos, por ejemplo, una caldera de vapor acuotubular. Como se ilustra en la Figura
1.13, la capacidad de diseño es una presión de trabajo máxima permitida (MAWP) de 500
psi. Sin embargo, el rendimiento requerido es de 650 psi. ¿Es aceptable este escenario?
Absolutamente no, porque lo que requiere la organización (650 psi) excede la capacidad
de diseño de la caldera (500 psi).
La Figura 1.14 ilustra otro ejemplo. Aquí, la capacidad de diseño es una MAWP de 650 psi y
el rendimiento requerido es de 500 psi. ¿Es aceptable este escenario? Sí, porque lo que
requiere la organización (500 psi) se ajusta a la capacidad de diseño del activo.
Esto puede parecer un concepto increíblemente simple, tan básico y fundamental que ni
siquiera merece ser mencionado.
Parece de esa manera. Sin embargo, este concepto es un tema muy serio. Si una
organización se equivoca, puede volverse mortal. De hecho, se ha vuelto mortal.
Tres accidentes de aviones cisterna
La Junta Nacional de Seguridad en el Transporte (NTSB) investigó tres accidentes de
aviones cisterna. La siguiente información se informó en la recomendación de seguridad de
la NTSB con fecha del 23 de abril de 2004.
El 13 de agosto de 1994, un Lockheed C-130A Hercules experimentó una separación en
vuelo del ala derecha cerca de Pearblossom, California, mientras respondía a un incendio
forestal cerca de las montañas Tahachapi. Los tres miembros de la tripulación murieron y
el avión quedó completamente destruido. (En la Figura 1.15 se puede ver un avión similar
al C-130A).
El 17 de junio de 2002, otro Lockheed C-130A Hercules experimentó una ruptura en vuelo
que se inició con la separación del ala derecha, seguida de la separación del ala izquierda,
mientras ejecutaba una caída de retardante de fuego sobre un incendio forestal cerca de
Walker, California. . Ambas alas se separaron del fuselaje en sus respectivas ubicaciones de
unión entre la caja del ala central y el fuselaje. Los tres miembros de la tripulación de vuelo
murieron y el avión quedó completamente destruido. La figura 1.16 muestra el lugar del
accidente de junio de 2002.
El 18 de julio de 2002, un Consolidated Vultee P4Y Privateer experimentó una separación
en vuelo del ala izquierda mientras maniobraba para entregar retardante de fuego sobre
un incendio forestal cerca de Estes Park, Colorado. Ambos tripulantes murieron y el avión
quedó destruido. (En la figura 1.17 se muestra un avión similar.
El 17 de junio de 2002, otro Lockheed C-130A Hércules experimentó una ruptura en vuelo
que se inició con la separación del ala derecha, seguida de la separación del ala izquierda,
mientras ejecutaba una caída de retardante de fuego sobre un incendio forestal cerca de
Walker, California. Ambas alas se separaron del fuselaje en sus respectivas ubicaciones de
unión entre la caja del ala central y el fuselaje. Los tres miembros de la tripulación de vuelo
 murieron y el avión quedó completamente destruido. La figura 1.16 muestra el lugar del
accidente de junio de 2002.
El 18 de julio de 2002, un Consolidated Vultee P4Y Privateer experimentó una separación
en vuelo del ala izquierda mientras maniobraba para entregar retardante de fuego sobre
un incendio forestal cerca de Estes Park, Colorado. Ambos tripulantes murieron y el avión
quedó destruido. (En la figura 1.17 se muestra un avión similar.)
Los tres aviones fueron alquilados por el Servicio Forestal del Departamento de Agricultura
de EE. UU. para vuelos públicos de extinción de incendios. Sin embargo, la aeronave
detallada anteriormente se diseñó originalmente para transportar carga para el ejército de
los EE. UU., no para combatir incendios forestales.
Choques de aviones cisterna: capacidad de diseño versus rendimiento requerido
El entorno operativo y las cargas que experimenta una aeronave que transporta carga son
muy diferentes de los que experimenta una aeronave que lucha contra incendios
forestales. El informe de la NTSB explica que durante una misión de extinción de incendios,
una aeronave experimenta "maniobras de bajo nivel frecuentes y agresivas con altas
cargas de aceleración y altos niveles de turbulencia atmosférica". El informe de la NTSB
detalla además que los programas de mantenimiento utilizados para la aeronave fueron
los mismos que se derivaron de la aeronave cuando su misión era transportar carga para el
ejército. El informe establece que la aeronave probablemente estaba "operando fuera de
la intención del diseño original de los fabricantes".
En el contexto de RCM, el rendimiento requerido de la organización que utiliza los aviones
cisterna superó con creces la capacidad de diseño de la aeronave. La vida útil estructural
de la aeronave se acortó debido al duro entorno operativo y las cargas mucho más
agresivas aplicadas a la aeronave durante la extinción de incendios en comparación con el
transporte de carga. El aumento de carga aceleró el inicio de grietas por fatiga y aceleró el
tiempo de propagación de grietas. Por lo tanto, las inspecciones estructurales que se
realizaron no se realizaron con la frecuencia suficiente para identificar la grieta antes de
que causara una falla catastrófica. El simple concepto de garantizar que un activo sea
capaz de hacer lo que requiere la organización se pasó por alto por completo.
1.9 Introducción al Proceso RCM
La aplicación de RCM verdadero consiste en preparar un Contexto Operativo y llevar a
cabo los 7 pasos de RCM. La figura 1.19 describe el proceso de RCM.
Los capítulos 2 a 8 detallan el contexto operativo y los siete pasos del proceso RCM. La
siguiente discusión introduce brevemente cada concepto.
 Figura 1.19 El proceso RCM
Contexto operativo
Un contexto operativo es un documento que incluye información técnica relevante, como
el alcance del análisis, la teoría de funcionamiento, la descripción del equipo y las notas de
análisis de RCM. En esencia, es una identificación de libro de cuentos del sistema a
analizar. El contexto operativo también documenta notas y suposiciones con respecto a las
decisiones de análisis. Es una importante fuente de referencia para los miembros del
grupo de trabajo y del equipo de validación.
En aras del tiempo, el facilitador suele redactar el contexto operativo antes de que
comience el análisis y luego se revisa con el grupo de trabajo antes de que se complete el
primer paso en el proceso RCM (identificación de funciones). Durante este tiempo, el
grupo de trabajo revisa y revisa el Contexto Operativo, según sea necesario. El Contexto
Operativo se considera un documento vivo; se edita a medida que se aprende más sobre el
equipo y surgen problemas adicionales durante el análisis.
Paso 1: Funciones
La intención de RCM es determinar qué soluciones se deben implementar para garantizar
que un activo cumpla con los requisitos de la organización. Los accidentes del avión
cisterna y el desastre de Aloha Airlines detallados anteriormente ilustran cuán crítico es
comprender lo que se requiere de un activo para poder determinar si el activo es capaz de
cumplir con esos requisitos. Por esta razón, el primer paso en el proceso de RCM es
identificar Funciones.
Las funciones y los estándares de desempeño asociados siempre se escriben para reflejar
lo que la organización requiere del activo.
en lugar de lo que el sistema está diseñado para proporcionar. Durante el desarrollo de
funciones, a menudo se observa que las expectativas de la organización sobre el equipo
superan las capacidades reales del activo. Como se muestra en la Figura 1.20, se registran
la Función Primaria (el propósito principal del sistema) y las Funciones Secundarias (otras
Funciones del activo).
Paso 2: fallas funcionales
El paso 2 en el proceso de RCM es identificar fallas funcionales para cada función. Nowlan
y Heap definen la falla funcional como una condición insatisfactoria. Como se muestra en
la Figura 1.21, tanto las fallas funcionales totales como las parciales se registran para cada
función. Una falla total significa que no se puede realizar ninguna parte de esa función. La
falla parcial describe cómo la función aún es posible pero se realiza a un nivel
insatisfactorio.
Paso 3: Modos de falla
Un modo de falla es lo que causa una falla funcional. Durante el Paso 3 del proceso RCM,
se identifican los modos de falla que causan cada falla funcional. A menudo se cree
erróneamente que todos los modos de falla asociados con el sistema que se analiza deben
registrarse. Por el contrario, RCM proporciona pautas específicas para determinar qué
modos de falla incluir en un análisis. Solo se deben incluir los modos de falla que tienen
una probabilidad razonable de ocurrir en el contexto operativo. Si la respuesta a una o más
de las siguientes preguntas es "sí", el modo de falla debe incluirse en el análisis:
• ¿Ha ocurrido antes el modo de falla?
• Si el Modo de Falla no ha ocurrido, ¿es una posibilidad real?
• ¿Es poco probable que ocurra el modo de falla, pero las consecuencias son graves?
• ¿Se gestiona actualmente el modo de falla a través de un mantenimiento proactivo?
Los Modos de falla incluidos en la mayoría de los análisis consisten en causas típicas como
las debidas al desgaste, la erosión, la corrosión, etc. Sin embargo, es muy importante
incluir Modos de falla que cubran cuestiones como errores humanos, manuales técnicos
incorrectos, diseño inadecuado de equipos y falta de procedimientos de emergencia.
Dichos modos de falla permiten que los problemas se analicen como parte del proceso
RCM para que se puedan desarrollar soluciones además del mantenimiento proactivo.

Paso 4: Efectos de falla

Durante el paso 4, se escribe un efecto de falla para cada modo de falla. Un efecto de falla
es una breve descripción de lo que sucedería si no se hiciera nada para predecir o prevenir
el modo de falla. Los efectos de falla deben escribirse con suficiente detalle para que se
pueda identificar el siguiente paso en el proceso de RCM, las consecuencias de falla. Los
efectos de falla deben incluir:
• Descripción del proceso de falla desde la ocurrencia del Modo de Falla hasta la Falla
Funcional
• Evidencia física de que se ha producido la falla
• Cómo la ocurrencia del Modo de falla afecta adversamente la seguridad y/o el medio
ambiente
• Cómo afecta la ocurrencia del modo de falla a la capacidad/misión operativa
• Restricciones operativas específicas como resultado del Modo de Falla
• Daño secundario
• Qué reparación se requiere y cuánto tiempo se espera que tome
Hoja de trabajo de información
Los pasos 1 a 4 del proceso RCM se registran en la Hoja de trabajo de información, como
se muestra en la Figura 1.22. La hoja de trabajo de información incluye funciones, fallas
funcionales, modos de falla y efectos de falla.

Paso 5: Consecuencias de la falla

Un Efecto de Falla correctamente escrito permite evaluar la Consecuencia de Falla. Una
Consecuencia de Falla describe cómo importa la pérdida de función causada por el Modo
de Falla. Hay cuatro categorías de Consecuencias de fallas:
• La seguridad
• Ambiental
• Operacional
• No operativa
Paso 6: Mantenimiento Proactivo e Intervalos Asociados
Después de evaluar las consecuencias, el siguiente paso en el proceso de RCM es
considerar el mantenimiento proactivo como una estrategia de gestión de fallas. En el
contexto de RCM, las tareas de mantenimiento proactivo que pueden identificarse
incluyen:
Restauración programada Una tarea de restauración programada se realiza en un
intervalo específico para restaurar la resistencia a fallas de un elemento a un nivel
aceptable, sin considerar la condición del elemento en el momento de la tarea. Un ejemplo
de una tarea de restauración programada es recauchutar una llanta a las 60,000 millas.
Reemplazo programado Una tarea de reemplazo programado se realiza en un intervalo
específico para reemplazar un artículo sin tener en cuenta la condición del artículo en el
momento de la tarea. Un ejemplo es un reemplazo programado de un disco compresor de
un motor de turbina a las 10.000 horas.
Las restauraciones programadas y las tareas de reemplazo programadas se realizan a
intervalos específicos, independientemente de la condición del artículo.
Tarea en condición Se realiza una tarea en condición para detectar evidencia de que una
falla es inminente. En el contexto de RCM, la evidencia se denomina condición de falla
potencial y puede incluir mayor vibración, mayor calor, ruido excesivo, desgaste, etc.
Las posibles condiciones de falla se pueden detectar utilizando técnicas relativamente
simples, como el monitoreo de indicadores o la medición de los revestimientos de los
frenos. Además, las posibles condiciones de falla se pueden detectar mediante el empleo
de técnicas más involucradas técnicamente, como termografía o corrientes de Foucault, o
mediante el uso de monitoreo continuo con dispositivos como galgas extensométricas y
acelerómetros instalados directamente en la maquinaria. El punto de las tareas On-
Condition es que el mantenimiento se realiza solo cuando hay evidencia de necesidad.
En el contexto de RCM, todas las tareas de mantenimiento proactivo deben ser
técnicamente apropiadas y vale la pena realizarlas. El Capítulo 9 detalla cómo determinar
si una tarea proactiva es técnicamente apropiada y vale la pena realizarla.
Paso 7: Estrategias predeterminadas
Como se mencionó anteriormente, RCM no se trata solo de mantenimiento.
Hay una gran cantidad de soluciones distintas al mantenimiento proactivo que se pueden
derivar utilizando el proceso RCM. Los ejemplos incluyen: tareas de detección de fallas,
verificaciones de procedimientos, mantenimiento no programado y otras
recomendaciones, como modificaciones a los procedimientos operativos, actualizaciones
de publicaciones técnicas y rediseños de equipos. En el contexto de RCM, estas
recomendaciones se conocen como estrategias predeterminadas. Las estrategias
predeterminadas se analizan en detalle en el Capítulo 10.
1.10 Análisis de Modos de Falla y Efectos (FMEA) y Análisis de Modos de Falla, Efectos y
Criticidad (FMECA)
A menudo se cree erróneamente que FMEA y FMECA son análisis que se realizan
independientemente o en lugar de RCM. Por el contrario, los primeros cuatro pasos del
proceso RCM producen un FMEA. Los pasos para lograr un FMEA se muestran en la Figura
1.23.
Figura 1.23 Los primeros cuatro pasos del proceso RCM producen un FMEA

Figura 1.24 Los primeros cinco pasos del proceso RCM producen un FMECA
Resumen
RCM es un proceso emocionante que produce resultados abrumadoramente positivos
cuando el proceso se aplica correctamente con las personas adecuadas. RCM no es un
proceso nuevo. La aplicación de sus principios abarca varias décadas y se ha aplicado (y se
aplica) en casi todas las industrias del mundo. RCM se puede llevar a cabo de manera
rápida y eficiente cuando se ejecuta correctamente. Además, los principios de RCM son
tan diversos que se pueden aplicar a cualquier activo, como un avión, una planta de
energía nuclear, una planta de fabricación o una plataforma petrolera en alta mar. Los
principios de RCM se pueden aplicar ampliamente a un activo completo o se pueden
aplicar de manera más estrecha a equipos seleccionados.
Después de redactado el contexto operativo, se llevan a cabo los siete pasos del proceso
RCM: 1) Funciones; 2) Fallas Funcionales; 3) Modos de falla; 4) Efectos de falla; 5)
Consecuencias de la falla; 6) Mantenimiento Proactivo e Intervalos; y 7) Estrategias por
defecto. Uno de los principales productos de un análisis RCM es el desarrollo de un
programa de mantenimiento programado. Sin embargo, RCM se puede utilizar para
formular decenas de soluciones que van mucho más allá del mantenimiento.
 CAPITULO 2: UN ENFOQUE DE GRUPO DE TRABAJO
FACILITADO PARA RCM
Cuando se le preguntó a Thomas Edison por qué tenía un equipo de veintiún asistentes, dijo:
“Si pudiera resolver todos los problemas yo mismo, lo haría”.
Es muy emocionante ver los abrumadores resultados positivos que se cosechan cuando los
expertos en equipos, aquellos que están familiarizados con el activo y el entorno operativo,
están facultados para tomar decisiones sobre los activos físicos. De hecho, es un concepto tan
poderoso que es desconcertante por qué las organizaciones no emplean equipos de manera
más proactiva cuando se trata de la gestión de activos.
Aun así, la mayoría de las organizaciones hoy en día utilizan un enfoque de analista único para
RCM. Es decir, un ingeniero de RCM o, en algunos casos, un contratista externo, recopila
manuales técnicos, dibujos, etc., y completa el análisis de forma independiente.
Sin embargo, esta perspectiva limitada suele disminuir la calidad y el poder de los resultados.
En otros casos, las organizaciones reclaman el uso de un enfoque de grupo de trabajo al
realizar entrevistas con expertos en equipos para llenar los vacíos en el análisis de un solo
analista. Estos enfoques, que a veces pueden volverse contraproducentes, palidecen en
comparación con las notables soluciones que puede formular un equipo.
2.1 El enfoque de equipo para lograr los objetivos
Echemos un vistazo al enfoque de equipo porque es esencial para el éxito de tantos
esfuerzos. Los equipos están a nuestro alrededor.
Por ejemplo, un jugador no gana una Serie Mundial para un equipo de béisbol: nueve
miembros son esenciales para cada entrada jugada, y esos nueve son parte de un equipo
aún más grande. Cualquiera que se haya operado sabe de primera mano que nunca hay
solo un cirujano en un quirófano. Se requieren muchos otros profesionales para garantizar
un procedimiento exitoso: el anestesiólogo, el circulador, el técnico de lavado y el primer
asistente entre ellos.
¿Qué tal volar? ¿Es solo un piloto que lleva a los pasajeros de manera segura a un destino?
Por supuesto que no. Muchas personas, incluidos el copiloto, los asistentes de vuelo, el
personal de mantenimiento, el personal de tierra y los controladores de tránsito aéreo,
son esenciales para el vuelo. En todos estos ejemplos, las personas que trabajan juntas
alcanzan un propósito definido.
Cuando hay un accidente aéreo en los Estados Unidos, la Junta Nacional de Transporte y
Seguridad (NTSB) envía inmediatamente un "Vamos Equipo". Este equipo puede constar
de varias personas hasta docenas de personas que representan una variedad de disciplinas
que incluyen operaciones, estructuras, plantas de energía, sistemas, meteorología y
control del tráfico aéreo. ¿Por qué hay tanta gente involucrada en la investigación de un
accidente? Porque se necesita más de una experiencia para identificar la causa de un
accidente aéreo. Entonces, ¿por qué, cuando se trata de RCM, un proceso utilizado para
tomar decisiones vitales sobre los activos, una organización elegiría emplear un enfoque
de analista único?
Trabajo en equipo y preparación
Tuve el privilegio de escuchar al capitán Al Haynes, piloto del vuelo 232 de United Airlines,
hablar en la Conferencia sobre aeronaves envejecidas en Missouri en mayo de 2009. El
vuelo 232 de United Airlines, un DC10, se estrelló en Sioux City, Iowa, el 19 de julio de
1989. En ese vuelo, el motor n. ° 2 ubicado en la cola de la aeronave sufrió una falla
interna del motor debido a un defecto de fabricación no detectado en el conjunto del
rotor del ventilador de la etapa uno. La metralla de la falla cortó las líneas en los tres
sistemas hidráulicos completamente redundantes, dejándolos completamente
inoperables. Esto paralizó casi por completo el avión. Todo lo que quedaba para controlar
la aeronave era el uso de los aceleradores en los motores #1 y #3. La tripulación logró
poner la aeronave en tierra. Trágicamente, de las 296 personas a bordo, 112 murieron,
pero 184 personas sobrevivieron. El Capitán Haynes dijo que fue un equipo de personas las
que permitieron que tantos vivieran: las autoridades del aeropuerto que prepararon el
aeropuerto y la pista para aceptarlos, la tripulación de cabina que preparó a los pasajeros
para un aterrizaje de emergencia, los controladores de tránsito aéreo que controlaron con
calma la aeronave. a la pista, la tripulación de cabina que tan hábilmente logró poner la
aeronave en tierra y el personal de emergencia que atendió a los pasajeros heridos.
¡Trabajo en equipo!
Otra razón, dijo el Capitán Haynes, de que viviera tanta gente era la preparación. Estaban
preparados para manejar una emergencia. Cerró su presentación instando a la audiencia a
considerar las cosas que probablemente nunca sucederán y prepararse para ellas. Sus
palabras fueron: “Prepárate lo más que puedas”. “Prepárate lo más que puedas”. Estas son
palabras poderosas cuando se trata de la gestión de activos, especialmente cuando se
consideran los tipos de activos de los que son responsables los custodios y las
comunidades a las que sirven. Las organizaciones deben estar preparadas para cumplir con
los requisitos de la misión, los compromisos de producción, las restricciones de
programación, los objetivos de seguridad, las reglamentaciones ambientales, los recortes
de todo tipo, los objetivos de calidad y los compromisos de costos. Por lo tanto, los activos
deben funcionar según lo requerido.
 Si una organización busca estar lo más preparada posible, ¿quién está en la mejor posición
para identificar y lograr lo que eso requiere? ¿Es un contratista externo? ¿El fabricante del
equipo? ¿El ingeniero de sistemas? ¿El operador? ¿El mantenedor?
¿Qué persona lo sabe todo? En la mayoría de los casos, no hay uno sola persona,
especialmente cuando se consideran todos los elementos que influyen en un sistema.
2.2 Elementos que influyen en un sistema
Como se discutió en el Capítulo 1 y se muestra en la Figura 1.1, hay muchos elementos que
influyen en un sistema, incluidos: mantenimiento proactivo, procedimientos operativos,
publicaciones técnicas, programas de capacitación, diseño de equipos, problemas de
suministro, ritmo y entorno operativo y procedimientos de emergencia. La variedad de
problemas que afectan directamente el funcionamiento del equipo hace que sea casi
imposible que una persona sepa todo sobre un activo y lo que se requiere para cumplir
con los requisitos.
No importa lo que se analice: un avión, una planta de energía nuclear, un camión, un
tanque, un barco, una plataforma petrolera en alta mar, una unidad móvil de aire
acondicionado, un tractor de remolque, un motor a reacción o una sola bomba. Cualquiera
que sea el activo, la custodia responsable significa identificar y desarrollar estrategias
integrales de gestión de fallas.
2.3 Estrategias de gestión de fallas
Al formular estrategias de gestión de fallas para mantener los activos, las organizaciones
generalmente se enfocan en el desarrollo de un programa de mantenimiento proactivo.
Sin embargo, existen muchas otras estrategias de gestión de fallas que casi siempre se
requieren para garantizar que un activo cumpla con los requisitos. Ejemplos de estos se
muestran en la Figura 1.4; incluyen nuevos procedimientos operativos, actualizaciones de
publicaciones técnicas, modificaciones a los programas de capacitación, rediseños de
equipos, cambios en el proceso de suministro, procedimientos mejorados de solución de
problemas y procedimientos de emergencia actualizados. ¿Dónde, entonces, se puede
obtener la información requerida para formular estas soluciones?
2.4 Datos históricos y el proceso RCM
Un lugar al que recurrir son los datos históricos. Los datos históricos son importantes y
pueden ser increíblemente útiles. Pero sin excepción, el tipo de datos que generalmente se
recopilan no es suficiente para responder todas las preguntas en el proceso de RCM y, por
lo tanto, formular soluciones específicas. En muchos casos, el tipo de datos recopilados
para los activos puede compararse con las estadísticas de béisbol. La figura 2.1 presenta
las estadísticas de bateo de una temporada para el bateador Smith.
 Figura 2.1 Estadísticas de bateo de una temporada para el jugador Smith
El promedio de bateo del jugador Smith es 0.204, lo que significa que el bateador obtiene
un hit aproximadamente dos veces de cada diez turnos al bate. Tiene 21 carreras
impulsadas (RBI) y seis jonrones. Al revisar los datos, el entrenador de bateo puede
concluir que el bateador Smith necesita mejorar. Esta es información valiosa porque ahora
el entrenador de bateo sabe dónde se deben designar los recursos, lo que ayuda a mejorar
el rendimiento del bateador Smith. Sin embargo, lo que el entrenador de bateo no puede
deducir de la revisión de los datos es qué está causando que el bateador Smith se
desempeñe mal, por lo que el entrenador no puede formular soluciones específicas para
ayudar al bateador a mejorar. Por ejemplo, ¿debería el bateador comenzar a hacer swing
un poco antes? ¿O tal vez un poco más tarde? O tal vez el bateador necesita cambiar su
postura. Las soluciones no se pueden determinar simplemente evaluando los datos. Los
datos históricos de los activos suelen ser del mismo tipo. Por ejemplo, una revisión de los
datos de los rodamientos puede revelar que el año pasado se reemplazaron 50
rodamientos, frente a los 20 del año pasado. A partir de esta revisión, el custodio del
equipo puede concluir que existe un problema con el rodamiento. Sin embargo, no se
puede identificar qué causó específicamente las 50 fallas de los rodamientos simplemente
revisando los datos. Por ejemplo, ¿se engrasaron incorrectamente los cojinetes?
¿No estaban engrasados en absoluto? ¿Se utilizó la grasa incorrecta? ¿Hubo un defecto de
fabricación? ¿Se colocaron los rodamientos incorrectamente? Hay muchos problemas que
podrían causar específicamente las fallas de los rodamientos. Entonces, si bien los datos
son valiosos porque permiten que un custodio del equipo se concentre en las áreas
problemáticas y, por lo tanto, asigne recursos donde puedan ser de mayor beneficio, los
datos no revelan exactamente qué está causando el problema de los rodamientos.
El uso de datos históricos en un análisis RCM
Cuando los datos históricos están disponibles, deben emplearse en el proceso de RCM. Por
ejemplo, los datos históricos suelen ser muy útiles para determinar elementos con altas
tasas de fallas y consumidores de horas-hombre de alto mantenimiento. Los datos
permiten que una organización se concentre en las áreas problemáticas y ayuda a priorizar
 los sistemas que estarán sujetos al análisis de RCM. De esta manera, los recursos se
asignan donde serían más beneficiosos.
Donde los datos históricos a menudo se quedan cortos
Los datos históricos pueden estar incompletos porque normalmente:
• Informa solo lo que falló
• Describe lo que se hizo para reparar la falla en lugar de lo que la causó
• No describe fallas que se están previniendo actualmente o fallas plausibles que no han
ocurrido
• Describe fallas que pueden ser el efecto de alguna otra falla
• Ofrece información inadecuada para determinar los intervalos de tareas En condición,
Restauración y Reemplazo.
El uso de datos históricos en un análisis RCM juega un papel muy importante en la
aplicación de RCM, pero los datos a menudo están incompletos y requieren una
explicación más detallada. Entonces, si los datos históricos a menudo están incompletos
para realizar un análisis de RCM, ¿dónde puede acudir una organización para obtener la
información?
2.5 Grupos de trabajo efectivos
Ninguno de nosotros es tan inteligente como todos nosotros. Ken Blanchard
Las organizaciones pueden capturar una enorme cantidad de información preguntando a
las personas adecuadas; esta herramienta es una de las más valiosas en cualquier análisis
RCM. Cuando se reúne un grupo de trabajo, normalmente hay más de 100 años de
experiencia acumulada a disposición de una organización. Debido a la vasta y variada
experiencia y perspectivas representadas, el grupo comparte una oportunidad única para
formular soluciones que pueden marcar una diferencia notable para la organización. Al
recurrir a personas que saben dónde están las oportunidades de mejora, los facilitadores
calificados pueden usar los principios de RCM para consolidar su conocimiento y dirigir a
los expertos en la formulación de soluciones que pueden tener un impacto poderoso en la
organización.
Para que un grupo de trabajo sea efectivo, se requieren los individuos más informados y
experimentados. Los mejores miembros del grupo de trabajo tienen una experiencia
significativa y comprenden el equipo, el entorno operativo, el ritmo operativo y los
requisitos del equipo. Supongamos que se le pide a una persona que participe en un
análisis y la administración informa que no puede permitirse el lujo de tener a esa persona
fuera durante una semana o dos; esa es la confirmación de que se ha identificado a la
 persona adecuada. De hecho, la organización no puede darse el lujo de no contar con el
experto en el análisis.

2.6 Beneficios de un enfoque de grupo de trabajo facilitado

Mantenimiento proactivo más seguro, rentable y técnicamente defendible
Las preguntas que plantea RCM requieren respuestas específicas y detalladas. Por
ejemplo, al tratar de determinar una tarea en condición para monitorear el desgaste de
una correa trapezoidal, un facilitador puede hacerle a un equipo la siguiente pregunta:
¿Cuánto tiempo tomará desde el punto en que aparece la evidencia visual de desgaste en
la correa trapezoidal? es detectable hasta el momento que se rompe la correa? Este lapso
de tiempo se conoce como el intervalo P-F y se analiza en profundidad en el Capítulo 9. Las
respuestas a preguntas como esta rara vez se encuentran en los datos históricos porque
este tipo de datos generalmente no se capturan ni se rastrean. Sin embargo, los expertos
en equipos, personas que trabajan con el equipo todos los días, están preparados para
responder las preguntas de RCM la mayor parte del tiempo. En este caso, el operador de
una máquina generalmente puede identificar, por ejemplo, que la correa tardará seis
meses en romperse una vez que se detecten grietas y deshilachados. Este es un ejemplo
sencillo, pero muchos problemas de RCM pueden ser muy complejos, lo que hace que sea
aún más importante que los expertos puedan responder las preguntas. Esto garantiza que
se formule el plan de mantenimiento proactivo más seguro, rentable y técnicamente
defendible, es decir, se realiza el mantenimiento adecuado en el momento adecuado.
Los resultados van mucho más allá del mantenimiento del equipo
Debido a que trabajan con el equipo día a día y comprenden las complejidades del equipo
y el entorno operativo, los miembros del grupo de trabajo comprenden las
vulnerabilidades del equipo y los procesos asociados que conducen a la falla del equipo.
Esta comprensión les permite saber dónde están las oportunidades de mejora. Cuando se
les hacen las preguntas correctas, los miembros del grupo de trabajo pueden formular
estrategias de gestión de fallas que van mucho más allá del mantenimiento proactivo
(como cambios en los procedimientos operativos y actualizaciones de publicaciones
técnicas), lo que permite abordar otros problemas además del mantenimiento proactivo.
Los miembros del grupo de trabajo aprenden unos de otros
Como se dijo antes, es casi imposible que una persona sepa todo lo que hay que saber
sobre un activo. Debido a que el conocimiento acumulativo de un grupo de trabajo es tan
amplio y variado, los miembros del equipo aprenden unos de otros durante un análisis. Su
familiaridad, conocimiento y comprensión del equipo y la organización crecen, lo que
permite que su contribución a la organización sea aún más valiosa. Muy a menudo,
durante un análisis de RCM, el facilitador recibe retroalimentación de un miembro del
grupo de trabajo como “guau, he estado trabajando en este equipo durante 20 años y no
lo sabía”. Incluso el experto más experimentado aprende.
RCM identifica lo que una organización no sabe
Debido a que el proceso RCM requiere respuestas a preguntas detalladas, una de sus
mayores fortalezas es que identifica naturalmente lo que una organización no sabe. Las
lagunas en la información se documentan para que se pueda obtener la información. Los
miembros del grupo de trabajo a menudo usan la experiencia y el juicio para dar
respuestas, pero no hacen conjeturas. Los facilitadores están capacitados para reconocer
cuándo un grupo de trabajo no sabe y, como resultado, se toman las medidas adecuadas.
Por ejemplo, se puede recomendar un programa de exploración de edad como resultado
del análisis RCM o se puede emitir un elemento de acción para obtener más información.
Durante un análisis, los problemas que requieren información adicional se estacionan
hasta que se puedan encontrar las respuestas. Al igual que en la vida, es peligroso cuando
no sabes lo que no sabes. Pero hay una gran fortaleza en la identificación de lo que no
sabe: luego se puede obtener información mientras los problemas se tratan
adecuadamente mientras tanto. Debido a que se hicieron las preguntas correctas a las
personas adecuadas, algunos de los análisis de RCM más exitosos descubren los problemas
que han causado falta de confiabilidad crónica.
Reduce el error humano
El error humano es un problema generalizado en todo el mundo. La historia está plagada
de desastres fatales causados por ella. El equipo suele ser tan complejo que siempre habrá
vulnerabilidades presentes que pueden conducir a desastres si no se identifican y eliminan.
En la superficie, puede parecer que un técnico tiene la culpa, pero una inspección más
detallada puede revelar la causa real. Por ejemplo, si un componente se instala al revés, la
reacción típica es culpar al técnico que lo instaló. Pero la instalación al revés en realidad
puede ser el efecto de un problema más profundo: el manual de mantenimiento describe
incorrectamente la posición del componente. En este caso, el técnico hizo bien el trabajo.
El problema es que al técnico se le asignó el trabajo equivocado.
Considere los siguientes desastres causados por “errores humanos”.
Mars Climate Orbiter de la NASA perdido el 23 de septiembre de 1999
El orbitador de Marte de $ 125 millones iba a ser una parte clave en la exploración del
planeta. Dos equipos de ingeniería que trabajaban en el proyecto usaban diferentes
unidades de medida: unidades inglesas y métricas.
Como resultado, el 23 de septiembre de 1999, la nave espacial entró en una órbita mucho
más baja de lo previsto y la nave espacial se perdió.
Edward Weiler, Administrador Asociado de Ciencias Espaciales de la NASA, dijo en su
declaración escrita: “El problema aquí no fue el error. Fue la falla de la ingeniería de
sistemas de la NASA y los controles y equilibrio en nuestros procesos para detectar el
error”.
Helios Airways, Vuelo 522
El vuelo 522 de Helios Airways era un Boeing 737-300 que se estrelló en una zona
montañosa a 25 millas al norte de Atenas el 14 de agosto de 2005. La aeronave se sometió
a mantenimiento la noche anterior al accidente. El personal de tierra dejó una
configuración de presurización de la cabina en el modo "manual" en lugar del modo
"automático". Como resultado, la cabina no se presurizaría después del despegue. La
tripulación ignoró la bocina de advertencia de altitud de la cabina, el indicador de
despliegue de la máscara de oxígeno del pasajero y el interruptor principal de precaución,
y la aeronave continuó ascendiendo. Luego, la tripulación sufrió hipoxia o falta de oxígeno.
El avión se estrelló cuando se quedó sin combustible. Las 121 personas a bordo murieron.
Una causa directa citada en el informe final del accidente del Hellenic
La Junta de Investigación de Accidentes Aéreos y Seguridad Aérea (AAIASB) incluye que la
tripulación no reconoció que el selector de presurización estaba en modo manual durante
el prevuelo y el desempeño de las listas de verificación "antes del inicio" y "después del
despegue". También se citaron causas latentes, incluidas las deficiencias en la organización
del operador, la gestión de la calidad y la cultura de la seguridad, la ejecución inadecuada
de la supervisión de la seguridad por parte de la autoridad reguladora y los principios de
gestión de recursos de la tripulación que no se aplicaron adecuadamente.
Desde el accidente, la AAAASB y la FAA emitieron varias correcciones de seguridad. Se
emitió una directiva de aeronavegabilidad que requiere una revisión de los manuales de
vuelo de las aeronaves 737 para reflejar procedimientos mejorados para establecer la
presurización de la cabina y la respuesta de la tripulación a las advertencias de altitud de la
cabina.
Los custodios responsables deben identificar dónde existen este tipo de vulnerabilidades,
también conocidas como condiciones latentes, para que se puedan tomar medidas para
eliminarlas. Una vez más, son los expertos en equipos los que están en mejor posición para
saber dónde se encuentran este tipo de problemas. Los expertos en equipos saben qué:
• áreas de manuales técnicos que están mal
• la formación es inadecuada
• las listas de verificación son inexactas
• las válvulas son difíciles de operar debido a la mala iluminación
• los controles no son accesibles
• los esquemas eléctricos tienen errores
• faltan procedimientos de emergencia
Estos problemas, y otros similares, pueden causar fallas con la misma facilidad con la que
un cojinete desgastado puede provocar una falla en el cojinete. Por lo tanto, las fallas
latentes deben ser consideradas en un análisis RCM.
Las investigaciones de accidentes reconstruyen lo que condujo a un desastre. Son
reactivos. La consideración de las posibles causas de accidentes en un análisis RCM se
enfoca proactivamente en la identificación de fallas latentes para que se puedan formular
soluciones para eliminarlas. Este análisis puede hacer del mundo un lugar mucho más
seguro.
Fomenta las relaciones entre el personal
Es mágico ver lo que sucede cuando los expertos en equipos de diferentes orígenes se
reúnen y participan en el proceso de RCM para tomar decisiones sobre los activos de los
que son responsables. A menudo es la primera vez, por ejemplo, que el operador y el
ingeniero unen fuerzas y se involucran en un proceso formal y estructurado para formular
en colaboración soluciones sobre lo que tienen en común: el activo. La interacción de
diversas disciplinas fomenta un ambiente de equipo.
Construye la propiedad de los resultados finales
Debido a que los representantes de la mayoría de las disciplinas dentro de la organización
realizaron el análisis, es mucho más probable que se adopten los resultados. Cualquier
cambio que ocurra como resultado de RCM se comprende más fácilmente. Cada área de la
organización tiene una inversión en los resultados finales.
Resumen
La variedad de problemas que afectan directamente el funcionamiento del equipo hace
que sea casi imposible que una persona sepa todo sobre un activo, incluido lo que se
requiere para que el activo cumpla con los requisitos. Las organizaciones pueden capturar
una enorme cantidad de información preguntando a las personas adecuadas. Esta
herramienta es una de las más valiosas en cualquier análisis RCM. Al recurrir a personas
que saben dónde están las oportunidades de mejora, un facilitador capacitado puede
utilizar los principios de RCM para consolidar el conocimiento de un equipo y guiar a los
expertos en la formulación de soluciones que pueden tener un impacto poderoso en la
organización.
 El contexto operativo de RCM
Las respuestas a las preguntas planteadas durante un análisis de RCM dependen de una
miríada de factores, como qué es el sistema, cómo necesita la organización que funcione y
en qué entorno se espera que opere. Estos y otros factores deben estar claramente
definidos en el Contexto Operativo antes de iniciar un análisis.
Este capítulo explora:
• Qué es un contexto operativo
• Cuándo se debe redactar un Contexto Operativo
• Qué se incluye en un contexto operativo
• El contexto operativo como documento vivo
3.1 ¿Qué es un contexto operativo?
Un contexto operativo es un documento que incluye información técnica relevante para el
análisis RCM. En esencia, es una identificación del libro de cuentos del sistema a analizar.
Debido al nivel de detalle incluido, a menudo actúa como una herramienta central para
orientar a los miembros del grupo de trabajo cuando comienza un análisis. El contexto
operativo también ayuda en la lluvia de ideas. A medida que se definen los detalles del
sistema, surgen problemas que se identifican para su inclusión en el análisis RCM. El
contexto operativo también sirve como fuente de información para los validadores.
3.2 ¿Cuándo se debe redactar un contexto operativo?
Mucha de la información registrada en el Contexto Operativo debe buscarse en varios
documentos técnicos y puede requerir algo de investigación. En aras del tiempo, el
contexto operativo generalmente lo redacta el facilitador antes de que comience el
análisis. Sin embargo, el documento es simplemente un borrador. Debe revisarse con el
grupo de trabajo antes de que se completen los siete pasos del proceso RCM. Durante el
análisis de RCM, el grupo de trabajo puede revisar y editar el contexto operativo, según
sea necesario.
 Figura 3.1 Secciones incluidas en un Contexto Operativo RCM
3.3 ¿Qué se incluye en un contexto operativo?
Se muestran las secciones incluidas en un Contexto Operativo en la figura 3.1.
Información General, Propósito y Uso
Esta sección incluye una descripción del equipo a analizar. Los temas que se pueden incluir
son:
• Una descripción amplia de la organización y el sistema a analizar
• Una explicación de la función del sistema dentro de la organización (p. ej., se requiere un
sistema de secador de aire para secar el aire comprimido y evitar la oxidación, las
picaduras, los bloqueos y los congelamientos de los equipos aguas abajo).
• Número de unidades en inventario
• Cuánto tiempo ha estado en funcionamiento el sistema o si el equipo es nuevo
• En qué circunstancias se operará el sistema (p. ej., independiente, uno de los cuatro
sistemas se ejecuta a la vez pero se rota todos los meses)
• Descripción del entorno operativo (p. ej., equipo ubicado al aire libre y expuesto a la
intemperie, ubicado en un entorno controlado donde la temperatura varía solo entre 65 y
80 °C).
Fahrenheit, uso a bordo)
• Describir el ritmo operativo (p. ej., operación de 24 horas, funciona solo 6 horas cada día)
• Cómo afecta la falla del sistema a la organización, si es que afecta (por ejemplo, las
operaciones cesan y cada hora de tiempo de inactividad le cuesta a la organización
$10,000 en producción perdida)
• Redundancia (p. ej., si el sistema o cualquiera de sus componentes funcionan en
presencia de una copia de seguridad)
El siguiente ejemplo proviene de un contexto operativo de un generador diésel móvil. El
sistema sujeto al análisis RCM es el sistema de combustible.
Se ha encargado a Porter Consolidated Corporation que construya una nueva instalación
de generación de energía. El sitio albergará una unidad de energía a carbón de 300 MW. La
planificación inicial estima que la instalación estará operativa en tres años. La excavación y
la preparación del sitio están completas.
“Porter Consolidated Corporation ha comprado 30 generadores diésel móviles para
suministrar energía para las actividades de construcción.
Cada generador de un solo cojinete incluye un circuito de control que proporciona varias
indicaciones, advertencias y protección contra fallas. Cada generador suministra energía
ininterrumpida a su respectiva área de construcción las 24 horas. Si falla un generador, la
construcción en el área respectiva se detiene a un costo de $5,000 por hora.
El entorno operativo actual tiene estándares bajos y altas temperaturas de -10º F y 100º F,
respectivamente. Los generadores son mantenidos por el equipo de mantenimiento del
equipo del sitio.”
Alcance del análisis
El alcance del análisis define los límites del análisis. Detalla lo que se incluye en el análisis.
El alcance debe estar claramente definido durante la etapa de planificación del análisis. El
siguiente ejemplo es del sistema de combustible del generador diesel móvil.
El alcance del análisis incluye el sistema de combustible diésel desde el conjunto del
tanque de combustible hasta los seis inyectores de combustible. También incluye el
indicador de nivel de combustible y el sistema de alarma de combustible bajo.
teoría de operación
La Teoría de funcionamiento incluye una descripción detallada de cómo funciona el
sistema, incluidos parámetros específicos como presiones y temperaturas de
funcionamiento. Los parámetros deben reflejar lo que la organización requiere del activo,
no las especificaciones de diseño. El siguiente ejemplo es del sistema de combustible del
generador diesel móvil.