M015S4 CONSECUENCIAS DE LA FALLA

Este captulo trata de al quinta pregunta del proceso RCM: de qu manera importa cada falla?

4.1 Tcnicamente Factible y Merecer la pena

Cada vez que ocurre una falla, sta de alguna manera afecta a la organizacin que utiliza el activoFsico. Algunas fallas afectan la produccin, la calidad del producto o la atencin al cliente. OtrasRepresentan un riesgo para la seguridad o el medio ambiente. Algunas incrementan los costos Operativos, por ejemplo al incrementar el consumo de energa, mientras que algunas tienen impacto en cuatro, cinco, o las seis reas. Algunas otras aparentemente no tienen efecto alguno si ocurren por s solas, pero ponen en riesgo a la organizacin exponindola a falla mucho ms serias.Si cualquiera de estas fallas no es prevenida, el tiempo y el esfuerzo que se necesitan para repararlosTambin afecta a la organizacin, porque la reparacin de fallas consume recursos que podran ser utilizados para otras tareas ms rentables. La naturaleza y la gravedad de estos efectos definen la manera en que la falla es vista por la organizacin. El impacto de cada caso, es decir la manera en que es importante cada falla, dependeDel contexto operacional del activo fsico, los parmetros de funcionamiento que se aplican a cadaFuncin, y los efectos fsicos de cada modo de falla.Esta combinacin de contexto , parmetros, y efectos, significa que cada falla tiene un conjunto deConsecuencias especficas asociadas a ella. Si las consecuencias son serias, entonces se harn Esfuerzo considerables por prevenir la falla, o al menos para anticiparla a tiempo como para reduciro eliminar las consecuencias. Sobre todo si la falla podra causar heridas o la muerte a una persona, oEfectos serios sobre el medio ambiente. Pero tambin si las fallas interfieren con la produccin o las operaciones, o si pueden causar daos secundarios significativos.Por otro lado, si la falla slo tiene consecuencias menores, es posible que no se tome ninguna accin Proactiva, y que la falla simplemente sea reparada cada vez que ocurra. Esto sugiere que las consecuencias de las fallas son ms importantes que sus caractersticas tcnicas.Tambin sugiere la idea del mantenimiento proactivo no es tanto acerca de prevenir fallas sino de evitar o reducir las consecuencias.

El mantenimiento proactivo tiene Que ver mucho ms con evitar o reducir Las consecuencias de la falla que conPrevenir la falla misma.

Si aceptamos esto, entonces se entiende que cualquier tarea proactiva solo merezca la pena si resuelveAdecuadamente las consecuencias de la falla que se pretende evitar.

Merece la pena realizar unaTarea proactiva si resuelveAdecuadamente las consecuencias De la falla que se pretende evitar.

Esto ciertamente presupone que es posible anticipar o prevenir la falla. Si una tarea proactiva es Tcnicamente factible o no, depende de las caractersticas tcnicas de la tarea y de la falla que pretende evitar. Los criterios que gobiernan la factibilidad tcnica se examinan en detalle en Los captulos 6 y 7.Si no es posible encontrar una tarea proactiva adecuada, la naturaleza de las consecuencias de falla tambin indican qu accin a falta de deben ser tomada. Las tareas a falta de vuelven a verse en los captulos 8 y 9.El resto de Este captulo considera los criterios utilizados para evaluar las consecuencias de al fallaY as decidir si merece la pena realizar algn tipo de tarea proactiva. Estas consecuencias se dividen en dos etapas y en cuatro categoras. La primera etapa separa las funciones ocultas de las funcionesEvidentes.

4.2 Funciones Ocultas y EvidentesHemos visto que casi todo elemento de una planta tiene ms de una, y a veces docenas de funciones.La mayora de estas funciones, cuando fallan, inevitablemente ponen en evidencia que ha ocurrido Una falla.Por ejemplo, algunas fallas hacen funcionar alarmas audiovisuales. Otras hacen que se paren las mquinasO que se interrumpa alguna parte del proceso. Otras dan lugar a problemas da calidad del producto, o a Un incremento en el consumo de energa, y an otros van acompaados de efectos obvios tales como ruidos fuertes, escapes de vapor, olores extraos o manchas de lquido en el suelo.Por ejemplo, en el captulo 2 aparecen tres bombas que se ven nuevamente en la figura 4.1 a continuacinSi se agarrota un rodamiento de al bomba A, se pierde la capacidad de bombeo. Esta falla por s sola se Manifestara inevitablemente a los operadores o bien tan pronto como se produce, o bien al interrumpirse Alguna operacin situada ms adelante en el proceso. (posiblemente los operadores no se darn cuenta Inmediatamente de que el problema tiene origen en el rodamiento, pero inevitablemente se dara cuentaEn que algo anormal ha sucedido) . Se califican de evidentes las fallas de este tipo porque alguien se dar cuenta cuando se producen por s Solas. Esto lleva a la siguiente definicin de una funcin evidente: Una funcin evidente es aquella cuya Falla finalmente e inevitablemente Ser evidente por s sola a los operadoresEn circunstancias normales

No obstante, algunas fallas ocurren de tal forma que nadie sabe que el elemento se ha averiado A menos que se produzca alguna otra falla.Por ejemplo, si fallase la bomba C de la figura 4.1, nadie se dara cuenta de que ha fallado porque en circunstancias normales la bomba B seguira funcionando. Es decir, la falla de la bomba C por s sola no tendra ninguna repercusin directa a menos que fallase la bomba B (lo cual sera unaCircunstancia anormal) .

ABCBomba nica En servicio Reserva Figura 4.1: tres bombas La bomba C exhibe una de las caractersticas ms import5antes de una funcin oculta, que es la Falla de al bomba por s sola no es evidente a los operarios bajo circunstancias normales. Esto Conduce a la siguiente definicin de una funcin oculta:

Una funcin oculta es aquella cuya falla no Se har evidente a los operarios bajo circunstancias Normales , si se produce por s sola.

El primer paso en el proceso de RCM es separar las funciones ocultas de las evidentes porqueLas funciones ocultas de las evidentes porque las ocultas necesitan de un manejo especial. Se Detallan en la parte 6 de este captulo. Veremos luego que estas funciones estn asociadas a dispositivos de seguridad sin seguridad inherente.Dado que suman hasta la mitad de los modos de falla que podran afectar equipamientos Modernos y complejos, las funciones ocultas bien podran convertirse en el tema dominante del mantenimiento en los prximos diez aos. Sin embargo para situar a las funciones ocultas en perspectivas, primero debemos considerar las fallas evidentes.

Categoras de fallas evidentes Las fallas evidentes se clasifican en tres categoras de importancia decreciente de la siguiente manera: consecuencias para la seguridad y el medio ambiente. Una falla tiene consecuencias para la seguridad si puede lesionar o matar a alguien. Tiene consecuencias para el medio ambiente si puede lesionar o matar a alguien. Tiene consecuencias para el medio ambiente si puede infringir Alguna normativa municipal, regional o nacional relativa al medio ambiente. consecuencias operacionales. Una falla tiene consecuencias operacionales si afecta a la produccin o a las operaciones ( volumen de produccin, calidad de producto, servicio al cliente o costo operacional, adems del costo directo de la reparacin ) .

consecuencias no operacionales. Las fallas evidentes que caen dentro de sta categora no afectan ni a la seguridad ni a la produccin, de modo que slo involucran el costo directo de la reparacin.con sta jerarquizacin de las fallas evidentes, RCM garantiza que se consideren las repercusiones a La seguridad y el medio ambiente en todo modo de falla evidente. Mediante este enfoque RCM inequvocamente coloca a las personas antes que a la produccin. Tambin significa que se evalan en un solo ejercicio las consecuencias a la seguridad, el medio Ambiente y las economas, lo cual es mucho ms eficaz que considerarlas por separado. Las prximas cuatro secciones de este captulo consideran a cada una de estas categoras detalladamente, Comenzando por las categoras evidentes y pasando a los temas ms complejos que hacen a las funciones ocultas.

4.3 Consecuencias y el Medio Ambiental para la Seguridad

Primero la seguridadComo hemos visto, el primer paso en el proceso de evaluacin de las consecuencias es identificar funciones ocultas para que stas puedas ser tratadas apropiadamente. Todos los modos de fallaRestantes -en otras palabras las fallas que no se clasifican como ocultas- deben ser evidentes por definicin. El proceso RCM considera primero las implicancias y el Medio Ambiente para la seguridad de cada modo de falla evidente. Lo hace preguntndose si alguien pudiera ser lastimado o morir tantoComo resultado directo del modo de falla mismo o por cualquier otro dao que pueda ser causadoPor la falla. Un modelo de falla tiene consecuenciasPara la seguridad si causa una prdida de funcin u otros daos que pudieran Lesionar o matar a alguien.

En otro nivel, la seguridad se refiere a la integridad o bienestar de la sociedad en general. Hoy en daLas fallas que afectan a la sociedad tienden a calificarse como problemas ambientales. Las Expectativas de la sociedad se expresan en la forma de normativas ambientales municipales, regionalesY nacionales. Algunas organizaciones tienen, adems, sus propios reglamentos corporativos an ms Rigurosos. Se dice que un modo de falla tiene consecuencias ambientales si pudiera conducir a la infraccin de cualquiera de estas normativas.

Un modo de falla tiene consecuencias ambientales si causa una prdida deFuncin u otros daos que pudieranConducir a la infraccin de cualquier Normativa o reglamento ambiental conocido.

Notemos que al considerar si una falla tiene consecuencias o para la seguridad o el medio ambiente, Estamos considerando si un modo de falla por s solo podra tener esas consecuencias. Esto es diferenteA la parte 6 de ste captulo, en la que consideramos la falla de los dos elementos de un sistema protegido.

La cuestin del Riesgo.Aunque la mayora de las personas quisieran vivir en un medio en el que no exista posibilidad alguna de muerte o dao fsico, generalmente se acepta que hay un elemento de riesgo en todo lo que hacemos. En otras palabras, el cero absoluto es inalcanzable, aunque sea un mejor objetivo por el que vale la pena seguir luchando. Esto inmediatamente nos lleva a preguntarnos qu es alcanzable.Para responder a esta pregunta, ante todo debemos considerar la cuestin de riesgo en mayor detalleLa evaluacin del riesgo consta de tres elementos. El primero pregunta qu puede pasar si ocurre el evento en cuestin. El segundo se pregunta cun probable es que ocurra el evento. La combinacin de estos dos elementos nos provee de una medida del grado de riesgo. El tercero, y con frecuencia el Elemento ms polmico, se pregunta si el riesgo es tolerable.Por ejemplo, consideramos un modo de falla que podra resultar en la muerte o dao fsico de diez personas (lo que puede ocurrir) las posibilidades de que ocurra este modo de falla es de una en mil en un ao cualquiera (la probabilidad de que ocurra). Basndose en stos datos, el riesgo asociados conEsta falla es:10 x (1 en 1000) = 1 muerte cada 100 aosAhora consideramos un segundo modo de falla que podra causar 1000 muertes, pero la probabilidadDe que ocurra ste modo de falla es de 1 en 100000 en un ao cualquiera. El riesgo asociado consta fallas es: 1000 x (1 en 100000) = 1 muerte cada 100 aosEn estos ejemplos, el riesgo es el mismo aunque los datos en que se basa son bastante diferentes. Notemos tambin que estos ejemplos no indican si el riesgo es tolerable o no, es una pregunta aparte y Ms complicada, la cual ser tratada ms adelante.Notemos que a lo largo de sta exposicin, los trminos probabilidad ( 1 en 10 de una falla en unPerodo) y tasa de falla (1 en 10 perodos promedio, correspondiente a una medida de tiempo entre fallas de 10 perodos) son utilizados como si fuesen intercambiables cuando se aplican a fallas Al azar. En un sentido estricto, esto no es verdad. Sin embargo si el tiempo medio entre fallas ( TMEF o MTBF- Mean Time Between Failures-) es mayor que 4 perodos, la diferencia es tan pequea que usualmente puede ser ignorada.Los prrafos siguientes consideran cada uno de estos tres elementos de riesgo en mayor detalle.qu puede pasar si ocurre la falta? Dos temas deben ser tenidos en cuenta al considerar lo que puede pasar si ocurre un falla. stosSon , qu sucede realmente , y si es probable que alguien resulte lastimado o muerto como Consecuencia. Lo que sucede realmente si ocurre cualquier modo de falla debe ser registrado en la hoja de InformacinRCM como efectos de falla, como se explica claramente en la parte 3. En la parte 3 tambin hayUna lista de efectos tpicos que representan una amenaza para la seguridad o para el medio ambiente.El hecho de que estos efectos podran matar o herir a alguien no significa necesariamente que lo harn cada vez que ocurran. Algunos hasta podran ocurrir con frecuencia sin hacerlo. Sin embargo, elTema no es si dichas consecuencias son inevitables o no, si son posibles.

Por ejemplo, si fallase el gancho de un puente gra utilizada para cargar bobinas de acero, la carga que Cae podra matar o herir a cualquier persona que se encontrase parada cerca o debajo de ella en ese momento. Si nadie estuviera cerca, entonces nadie saldra herido. Sin embargo, la posibilidad de que Alguien pudiera resultar herido significa de este modo de falla debera ser tratado como un riesgo Para la seguridad y analizando de manera acorde.Este ejemplo demuestra que el proceso RCM evala las consecuencias para la seguridad al nivel msConservador. Si es razonable asumir que cualquier modo de falla podra afectar la seguridad o el Medio ambiente, asumimos que puede hacerlo, en cuyo caso debe ser sometido a un anlisis posterior( luego vemos que las posibilidades de que alguien resulte herido son tomadas en consideracin alEvaluar la tolerabilidad del riesgo).

cun probable es que ocurra la falla?En el capitulo 3 se menciona que solo los modos de falla que tienen posibilidades razonables de ocurrir en el contexto en cuestin deben ser registrados en la hoja de informacin RCM. En consecuencia, si la hoja de informacin ha sido preparada sobre una base realista, el mero hecho De que el modo de falla haya sido registrado sugiere que hay alguna posibilidad de que pudiera Ocurrir, y por lo tanto que debe ser sometido a un anlisis posterior.

es tolerable el riesgo? Uno de los aspectos ms difciles de la administracin de seguridad es la medida en que varan las expectativas de qu es tolerable, de individuo a individuo y de grupo a grupo. Muchos factores influyen sobre esas creencias: el ms dominante es el grado de control que un individuo cree tenerSobre la situacin. Las personas casi siempre toleran un mayor nivel de riesgo cuando creen que Tienen control personal sobre la situacin que cuando creen que la situacin est fuera de control.El segundo factor clave se relaciona con el beneficio que las personas creen que derivar de Exponerse a este riesgo. En trmino generales, esta combinacin de control percibido y eleccin puede variar para un individuo en particular como lo muestra la fig.4.2Las figuras dadas en este ejemplo no pretenden ser prescriptivas y no necesariamente reflejan el criterio del autor meramente ilustrado que un individuo en el transcurso de su trabajo diario. Este puntoDe vista debe luego ser traducido al grado de riesgo para toda la poblacin ( todos los trabajadoresDel lugar, todos los ciudadanos de un pueblo, o hasta la poblacin entera de un pas).En otras palabras, si tolero una probabilidad de 1 en 100000 (10^-5) de morir en el trabajo en un ao y tengo 1000 compaeros de trabajo que comparten la misma opinin, entonces todos toleramos que como promedio 1 persona por ao morir en nuestro lugar de trabajo cada 100 aos- y que esa persona podra ser yo, y podra suceder este ao.

10^-710^-610^-510^-4Probabilidad que tolero de resultarMuerto en un ao cualquieraCreo tenerControl total(manejandoMi auto o en elTaller de miCasa)Creo tenerAlgo de control Y de eleccin aExponerme (en el lugar De trabajo)Creo no tener Control alguno,Pero no tengo que exponerme (en una Aeronave dePasajeros)No tengo controlNi eleccin sobreMi exposicin ni/oLa de mi familia(exposicin a Accidentes Industriales fueraDel lugar de Trabajo)Figura 4.2 ; tolerabilidad de riesgo fatal Debemos tener en cuenta que cualquier cuantificacin de riesgo hecha de esta manera slo puede ser una aproximacin general. En otras palabras, si yo digo que tolero una probabilidad de 10^-5, nuncaEs ms que un nmero indicativo. Indica que estoy preparado a aceptar un probabilidad de morir en El trabajo que es aproximadamente 10 veces ms baja que la que acepto al transitar por las rutas (alrededor de 10^-4) Siempre he tenido en cuenta que estamos tratando con aproximaciones, el prximo paso es traducir la probabilidad que yo y mis compaeros de trabajo estamos preparados a aceptar que cualquiera de nosotros podra morir a causa de cualquier evento en el trabajo , a una probabilidad aceptable para Cada evento (modo de falla o falla mltiple) que podra matar a alguien.Por ejemplo, continuando con la lgica del ejemplo anterior, la probabilidad de que uno de mis 1000Compaeros de trabajo muera en un ao es 1 en 100 (asumiendo que todas las personas en el lugarDe trabajo afrontan aproximadamente los mismos riesgos). Adems, si las actividades llevadas a caboEn el lugar de trabajo incluyen, digamos, 10000 eventos que podran matar a alguien, entonces la Probabilidad promedio de cada evento puede matar a una persona debe ser reducida a 10^-6 en unAo. Esto significa que la probabilidad de un evento que es capaz de matar a una persona debe ser reducido a 10^-7 mientras que la probabilidad de un evento que tiene 1 chance en 10 de matar a una Persona debe ser reducido a 10^ -5.Las tcnicas por las cuales uno mueve en forma ascendente las jerarquas de probabilidad de esta manera se conocen como evaluaciones de riesgo cuantitativas o probabilsticas. Los puntos clave a tener en cuentaEn este tema son que:

la decisin de qu es tolerable debe comenzar con la probable victimas . La manera de involucras a dicha probables vctimas en esta decisin en el contexto industrial, es tratada ms adelante en Este captulo

Es posible vincular lo que una persona tolera directamente y cuantitativamente a una Probabilidad tolerable de modos de falla individualesAunque la percepcin del grado de control generalmente domina las decisiones acerca de la Tolerabilidad del riesgo, de ningn modo es el nico principio. Otros factores que nos ayudan a decidir lo que es tolerable incluyen los siguientes: valores individuales valores de industria: si bien hoy en da toda industria reconoce la necesidad de operar con la mxima seguridad, no podemos eludir la realidad de que algunas son intrnsecamente ms peligrosas que otras. el efecto sobre las generaciones futuras : la seguridad de los nios especialmente de los que an no han nacido tiene un efecto especialmente poderoso en las opiniones de la gente acerca de lo que es tolerable. conocimiento: las percepciones de riesgo son influencias en gran modo por cunto las personas conocen acerca del activo fsico, el proceso del que forma parte, y los mecanismos de falla asociadosCon cada modo de falla. Muchos otros factores tambin influencian las proporciones de riesgo , talesComo el valor depositado en la vida humana en diferentes grupos culturales, valores religiosos, y hasta factores como la edad del individuo y su estado civil.Todos estos factores significan que es imposible especificar un estndar de tolerabilidad que sea absoluto y objetivo para cualquier riesgo. Esto sugiere que la tolerabilidad de cualquier riesgoSlo puede ser evaluada partiendo de la base de que es al mismo tiempo subjetiva y objetiva-relativa en el sentido que el riesgo es comprando con otros riesgos con los que hay un consenso relativamente claro, y subjetivamente porque toda esta cuestin es en su esencia una cuestin de discernimiento o juicio. Pero el juicio de quin?

Quin debe evaluar los riesgos?La diversidad misma de los factores tratados anteriormente significa que es simplemente imposible para cualquier persona o hasta para una organizacin- evaluar los riesgos de tal manera que sean universalmente tolerable. Si el evaluador es demasiado conservador puede que la gente ignore o ridiculice la evaluacin. Si es demasiado relajado, puede terminar acusado de jugar con la vida de personas (si no de realmente matarlas)Esto sugiere que una evaluacin de riesgo satisfactoria slo puede ser realizada por un grupo. En La medida de lo posible, el grupo debe representar a las personas que probablemente tengan un claro entendimiento del mecanismo de falla, los efectos de falla (especialmente la naturaleza de cualquierRiesgo), la probabilidad de que las fallas ocurran, y qu posibles medidas pueden ser tomadas para anticiparla o prevenirla. El grupo tambin debe incluir a las personas que tengan un punto de vista legtimo de la tolerabilidad o en todo caso de los riesgos. Esto significa representantes de las probables vctimas (generalmente operadores o personal de mantenimiento en el caso de riesgos directos para la seguridad) y la gerencia (que son hechos responsables cuando alguien resulta herido o si se infringeUna normativa ambiental) .Si se aplica de esta naturaleza generalmente pueden llegar a un consenso rpido cuando tratan con riesgos directos para la seguridad, porque ellos mismos estn incluidos entre las personas en riesgo.Los riesgos ambientales no son tan simples, porque es la sociedad en general la posible victimaY muchos de los temas incluidos son poco conocidos. Entonces cualquier grupo del que se espera que considere si una falla podra infringir una normativa o regulacin ambiental, debe primero averiguar

Cules de esas normativas y regulaciones cubren el proceso que se est revisando.

Seguridad y Mantenimiento ProactivoSi una falla pudiese afectar la seguridad o el medio ambiente, el proceso de RCM estipula que Debemos intentar prevenirla. La discusin anterior sugiere que: Para modos de falla que tienenConsecuencias para la seguridad o el medioAmbiente, slo merece la pena realizar unaTarea proactiva si reduce la probabilidad de La falla a un nivel tolerablemente bajoSi no puede hallarse un tarea proactiva que logre este objetivo satisfaciendo al grupo que est Realizando el anlisis, estamos enfrentando un riesgo ambiental o para la seguridad que no Puede ser adecuadamente anticipado o prevenido. Esto significa que algo debe ser cambiado para hacer que el sistema sea seguro. Este algo puede ser el activo fsico mismo, en proceso, o un Procedimiento operacional. Notemos que al tratar con temas ambientales y de seguridad, RCM no introduce el tema econmico.Si no es seguro, tenemos la obligacin de o bien prevenir que falle o hacerlo seguro. Esto sugiere Que el proceso de decisin para modos de falla que tienen consecuencias para la seguridad o el medio Ambiente, puede ser resumido como lo muestra la figura 4.3:

produce este modo de fallaUna prdida de funcin uOtros daos que pudieranLesionar o matar a alguien? produce este modo de falla una prdida de funcin u Otros daos que Pudieran infringir cualquierNormativa o reglamentoAmbiental conocido? Merece la pena realizar mantenimientoProactivo si reduce el riesgo de Falla a un nivel tolerablemente bajoDe no hallarse una tarea proactiva que reduzcaEl riesgo de la falla a un nivel tolerablementeBajo, el rediseo es obligatorio.NoSisiNoVer los puntos 4 y 5 De este captuloFigura 4.3 : identificacin y desarrollo de una estrategia de mantenimiento para una falla que afecta la seguridad o el medio ambiente.

RCM y la Legislacin de Seguridad

Frecuentemente surge la pregunta de cmo se vincula RCM con la legislacin de la seguridad( la legislacin ambiental es tratada directamente) Hoy en da, la mayora de las leyes que gobiernan la seguridad meramente demandan que los usuariosSean capaces de demostrar que estn haciendo todo lo que sea prudente para asegurar que sus activosFsicos sean seguros. Esto ha llevado a un veloz incremento del nfasis en le concepto de traza de Auditora, que bsicamente requiere que los usuarios de los activos fsicos sean capaces de producir evidencia documentada de que hay una base racional y defendible para sus programas de mantenimiento. En la gran mayora de los casos, RCM satisface completamente este tipo de requerimientos. Sin embargo algunos reglamentos demandan la realizacin de tareas especficas en tipos de equipo especficos a intervalos especficos. Si el proceso RCM sugiere una tarea diferente y/o un intervaloDiferente, es aconsejable continuar haciendo la tarea especificada por el reglamento y discutir elCambio sugerido con la autoridad reguladora apropiada.

4.4 Consecuencias Operacionales

Como las fallas afectan a las operacionalesLa funcin primaria de la mayora de los equipos en la industria est vinculada de algn modo conLa necesidad de industria est vinculada de algn modo con la necesidad de producir ingresos o deApoyar alguna actividad econmica.Por ejemplo la funcin primaria de la mayora de los equipos utilizados en la fabricacin es la deaadir valor a los materiales. En cambio los clientes pagan directamente para acceder a equipos de transporte y comunicacin (autobuses, camiones, trenes o aviones).Las fallas que afectan las funciones primarias de estos activos fsicos afectan la capacidad generadora de ingresos de la compaa . La magnitud de estos efectos depende de cunto se haya cargado el equipo y de la disponibilidad de alternativas. Sin embargo en al mayora de los casos los efectosSon mayores frecuentemente mucho mayores- que el costo de reparar las fallas. Esto tambin se Aplica a los equipos de las industrias de servicio, tales como entretenimiento, comercio y hasta la industria bancaria.Por ejemplo, si fallan las luces en un estadio durante un partido, los espectadores pretenden que se les devuelva el dinero. Lo mismo ocurre si falla el proyector en un cine. Si falla el aire acondicionadoEn un restaurante o un negocio, los clientes se van (y generalmente no vuelven). Los bancos pierdenSus negocios si fallan los cajeros automticos. En general, las fallas afectan las operaciones de cuatro maneras: afectan al volumen de produccin total. afectan la calidad del producto. afectan el servicio al cliente. incrementan el costo operacional sumando este costo adicional al costo directo de la reparacin.Si una falla evidente no supone una amenaza a la seguridad o el medio ambiente, el proceso RCM enfoca a continuacin las consecuencias operacionales de la falla.Una falla tiene consecuencias Operacionales si tiene un efecto adverso Directo sobre la capacidad operacional.

Como hemos visto, estas consecuencias tienden a ser econmicas por naturaleza, por lo que Normalmente son evaluadas en trminos econmicos. Sin embargo, en ciertos casos ms extremos (como perder una guerra), el costo puede tener que ser evaluado a partir de una base ms cualitativa.

Evitando Consecuencias OperacionalesEl efecto econmico global de cualquier modo de falla que tiene consecuencias operacionales depende de dos factores: cuanto cuesta la falla cada vez que ocurre, en trminos de su efecto sobre la capacidad operacional, ms el costo de la reparacin. con que frecuencia ocurre.En al parte anterior de este captulo no prestamos demasiada atencin a la frecuencia probable de las fallas . (los porcentajes de falla no influyen mucho en las fallas relacionadas con la seguridad, porqueEl objetivo en estos casos es evitar cualquier fallas condicionada a un porcentaje) . Sin embargo, si Las consecuencias de las fallas son econmicas, el costo total es afectado por la probable frecuencia de las consecuencia, es decir, para evaluar la trascendencia econmica de estas fallas, debemos evaluar cunto pueden costar a lo largo de un perodo de tiempo. Entonces si una falla trae consecuencias operacionales, el criterio para decidir si merece la pena econmica realizar una tarea proactiva es el siguiente:Para modos de falla con consecuenciasOperacionales, vale la pena realizar una Tarea proactiva si, a lo largo de un perodo De tiempo, cuesta menos que el costo de las Consecuencias operacionales ms el costo de repara la falla que pretende evitar .Si no se pude encontrar una tarea proactiva que sea costo- eficaz, entonces no merece la pena realizar ningn mantenimiento proactivo para tratar de anticipar o prevenir el modo de falla en cuestin.En algunos casos, la opcin ms costo-eficaz a esta altura podra simplemente ser la de decidir convivir con la falla.

ejerce el modo de falla un Efecto adverso directo sobre La capacidad operacional?Vale la pena realizar un mantenimientoProactivo si el costo a lo largo de un perodoDe tiempo es menor que el costo de las Consecuencias operacionales ms el costoDe reparar la falla que pretende prevenirSi no se puede encontrar una tarea proactivaQue sea costo-eficacia, la decisin a falta deEs no realizar ningn mantenimiento Proactivo ........ Pero puede merecer la pena redisearEl activo fsico o cambiar el procesoPara reducir los costos totales SiNoVer los puntos4 y 5 de estecaptuloFigura 4.4 : identificacin y desarrollo de unaestrategia de manetnimiento para una falla Que tiene consecuencias operacionalesSin embargo, si o puede hallarse una tarea proactiva y las consecuencias de la falla todava son Inaceptables, puede ser deseable cambiar el diseo del activo fsico ( o cambiar el proceso) paraReducir los costos totales: reduciendo la frecuencia ( y por ende el costo total) de la falla reduciendo o eliminando las consecuencias de la falla modificando una tarea preactiva para hacerla costo-eficaz.A la luz de estos comentarios, el proceso de decisin para fallas con consecuencias operacionales Puede ser resumido como lo muestra la figura 4.4

4.5 Consecuencias No Operacionales

Las consecuencias de una falla evidente que no ejerce un efecto adverso directo sobre la seguridad, el medio ambiente, o la capacidad operacional, son clasificados como no operacionales. Las nicas Consecuencias asociadas con estas fallas son los costos directos de reparacin. Entonces estas Consecuencias son tambin econmicas.Esto sugiere que slo vale la pena tratar de prevenir una falla que tiene consecuencias no operacionales Si , a lo largo de un perodo de tiempo, el costo de la tarea proactiva es menor al costo de repara la Falla cuando ocurre. Si no lo es, entonces no merece la pena realizar mantenimiento programado.Para modos de falla con consecuencias no operacionales, vale la pena realizar tareasProactivas si, a lo largo de un perodo de Tiempo, cuesta menos que el costo de reparar Las fallas que pretende prevenir.Si no vale la pena realizar una tarea proactiva, entonces en algunos casos poco comunes podra justificarse un rediseo por razones similares a las que se aplican a falla con consecuenciasOperacionales.

4.6 Consecuencias de Fallas Ocultas

Fallas ocultas y dispositivos de seguridadLa parte 2 menciona que los dispositivos de seguridad o de proteccin funcionan en una de cinco maneras: alertar a los operadores ante condiciones anormales parar el equipo en caso de falla eliminar o aliviar las condiciones anormales originadas por una falla y que de otra manera podran causar daos ms serios asumir control de una funcin que ha fallado prevenir que surjan situaciones peligrosas.La funcin esencial de estos dispositivos es de garantizar que las consecuencias de la falla de la funcin protegida sean mucho menos graves de lo que seran si no hubiera proteccin. Entonces Cualquier dispositivo de seguridad es de hecho parte de un sistema con al menos dos componentes: la funcin protectora (el dispositivo de seguridad) la funcin protegidaLa existencia de tales sistemas crea dos tipos de posibilidades de falla, dependiendo de si el dispositivo de seguridad tiene seguridad inherente o no. Consideremos las implicancias de cada tipo en los prrafossiguientes, comenzando por los dispositivos que tienen seguridad inherente.

Dispositivos de proteccin con seguridad inherenteEn ste contexto, seguridad inherente significa que la falla del dispositivo por s sola se har evidente para el grupo de operarios bajo circunstancias normales. Esto significa que, en un sistema que incluye un dispositivo de seguridad inherente, hay tres posibilidades de falla en cualquier perodo :La primera posibilidad es que no falla ninguno de los dispositivos. En este caso todo se desarrollaNormalmente.

La segunda posibilidad es que la funcin protegida falla antes que el dispositivo de seguridad. En Este caso el dispositivo de seguridad cumple con su funcin asignada y, dependiendo de la naturalezaDe la proteccin, las consecuencias de falla de la funcin protegida son reducidas o eliminadas.La tercera posibilidad es que el dispositivo de seguridad falla antes que la funcin protegida. Esto Sera evidente porque de no serlo el dispositivo no contara con seguridad inherente en el sentido en queSe defini anteriormente. Si se hacen las cosas en forma correcta, la posibilidad de que el dispositivoProtegido falle mientras el dispositivo de seguridad se encuentra averiado puede ser casi eliminada,O bien deteniendo la funcin protegida o aportando una proteccin alternativa mientras el dispositivo de seguridad fallado es reparado.Por ejemplo, podra pedrsele a un operador que vigile un medidor de presin, y que est alerta para en caso necesario- presionar el botn de parada, mientras se est reemplazando un switch de presin.Esto significa que las consecuencias de la falla de un dispositivo de seguridad con seguridad inherenteGeneralmente caen en las categoras de operacional o no operacional. La secuencia de stos Eventos se resume en la figura 4.5.

2: la funcin protegida es detenida o se provee otra proteccin mientras el dispositivo de seguridad se est reparandoEsto reduce las probabilidades de falla Mltiple prcticamente a cero. 4: si la funcin protegidaFalla aqu, el dispositivoDe proteccin acta paraReducir o eliminar las Consecuencias.3: se reinstala el Dispositivo de seguridad: la situacinVuelve a la normalidad. 1: La falla deUn dispositivoDe seguridadcon seguridadInherente es InmediatamenteEvidente.La funcin protegidaEs asegurada Mientras el dispositivoDe seguridad est Bajo reparacinTiempo FuncinprotegidaDispositivoDe seguridadFigura 4.5 : falla de un dispositivo de seguridad con seguridad inherente

Dispositivos de seguridad que no cuentan con seguridad Inherente

En un sistema que contiene un dispositivo de seguridad que no cuenta con seguridad inherente, el Hecho de que el dispositivo sea incapaz de cumplir su funcin no es evidente bajo circunstancias Normales. Esto crea cuatro posibilidades de falla en cualquier perodo dado, dos de los cuales son losMismos que ocurren en los dispositivos con seguridad inherente. La primera es cuando ninguno de Los dispositivos falla, en cuyo caso todo se desarrolla normalmente como antes.La segunda es que falle la funcin protegida en un momento en que el dispositivo de proteccin todava est funcionando. Como en este caso el dispositivo de proteccin tambin cumple con suFuncin, las consecuencias de la falla de la funcin protegida son nuevamente reducidas o eliminadas completamente.Por ejemplo, consideremos una vlvula de alivio (dispositivo de proteccin o de seguridad), que estMontada en una caldera (la funcin protegida). Si la presin asciende mas all de los lmites Aceptables, la vlvula abre (alivia) y al hacerlo reduce o elimina las consecuencias de la presin Excesiva. De manera similar, si al bomba B en al figura 4.1 falla , la bomba C toma su funcin.La tercera posibilidad es que falle el dispositivo de seguridad mientras la funcin protegida sigue funcionando.en este caso, al falla no tiene consecuencias directas. De hecho nadie sabe que el Dispositivo de seguridad se encuentra en estado de falla.Por ejemplo, si la vlvula de alivio hubiera quedado en posicin cerrada, nadie sera consciente deEste hecho mientras la presin en la caldera permaneciera dentro de los lmites operacionales normales. de manera similar, si la bomba C fallase de alguna manera mientras la bomba B est Trabajando, nadie sabra de este hecho a menos que fallara tambin la bomba B.La discusin anterior sugiere que las funciones ocultas pueden ser identificadas al hacerse la siguiente pregunta: Ser evidente para el equipo de Operaciones la prdida de funcinOriginada por este modo de falla porS solo bajo circunstancias normales? Si la respuesta a esta pregunta es no, entonces se trata de un modo de falla oculto. Si la respuestaEs s, es evidente. Notemos que en este contexto, por s solo2 significa que nada ms ha fallado.Notemos tambin que asumimos en este punto del anlisis, que no se est haciendo nada paraChequear si la funcin oculta sigue funcionando. Esto es porque tales chequeos son una forma deMantenimiento programado, y el propsito del anlisis es precisamente ver si tal mantenimiento es necesario. La cuarta posibilidad durante un ciclo cualquiera es que el dispositivo de seguridad falla, y luego la Funcin protegida falla mientras el dispositivo de seguridad est en su estado de falla. La situacin es conocida como falla mltiple (esta es una posibilidad real simplemente porque la falla del dispositivo de seguridad est en su estado de falla. La situacin es conocida como falla mltiple(esta es una posibilidad real simplemente porque la falla del dispositivo de seguridad no es evidente, por eso nadie sabra de la necesidad de tomar una accin correctiva o alternativa- para evitar la Falla mltiple).

Slo ocurre una falla mltiple si una funcin protegida falla mientras el dispositivo de proteccin se encuentra en estado de falla La secuencia de eventos que lleva a una falla mltiple se resume en la figura 4.6 2: no se toma ninguna accin para detener la funcin protegidaO proveer otra proteccin3: si la FuncinProtegidaFalla aqu El resultadoEs una fallamltiple1: la falla de un Dispositivo de proteccin sinSeguridad Inherente noEs evidente aLos operariosLa funcin Protegida operaSin proteccinPorque nadieSabe que el Dispositivo protectorHa falladoTiempoDispositivoDe seguridadFuncinprotegidaFigura 4.6 : falla de un dispositivo de proteccin cuya funcin es oculta

En el caso de una vlvula de alivio, si la presin en el recipiente asciende excesivamente mientras la vlvula se encuentra atascada, el recipiente probablemente explotar ( a menosQue alguien acte con rapidez o a menos que haya proteccin en el sistema). Si la bomba B falla mientras la bomba C se encuentra fallada, el resultado ser una prdida total del bombeo.Dado que la prevencin de fallas principalmente persigue evitar las consecuencias de la falla,Este ejemplo tambin sugiere que cuando desarrollamos programas de mantenimiento para Funciones ocultas, nuestro objetivo de hecho es prevenir o al menos reducir- lasprobabilidades de la falla mltiple asociada.El objetivo de un programa de Mantenimiento para un funcin ocultaEs prevenir o al menos reducir- lasProbabilidades de la falla mltiple asociada

Cunto nos esforzamos en tratar de prevenir la falla oculta depende de las consecuencias de la fallaMltiple. Si la consecuencias de la falla mltiple son realmente serias, haramos grandes esfuerzosPara preservar la integridad de la funcin oculta. Si las consecuencias de la falla mltiple son puramente econmicas, entonces el cunto cuesta influenciara el cunto nos esforzamos en Tratar de prevenir la falla oculta.

La Disponibilidad que Requieren las Funciones OcultasHasta aqu, esta parte del captulo ha definido fallas ocultas y descrito la relacin entre dispositivosDe seguridad y funciones ocultas. La siguiente pregunta lleva a analizar de ms cerca el Funcionamiento que requerimos de las funciones ocultas. Una de las conclusiones ms importantes a la que se ha llegado hasta ahora es que la nica consecuencia directa de una falla ahora es la nica consecuencia directa de una falla ahora es que la nica consecuencias directa de una falla oculta es un incremento en la exposicin al riesgo de una Falla mltiple. Y ya que en esta ltima la que ms deseamos evitar, un elemento clave del desempeo requerido de una funcin oculta debe estar vinculado con la falla mltiple asociada.Hemos visto que cuando un sistema est protegido por un dispositivo sin seguridad inherente, sloOcurre una falla mltiple si el dispositivo protegido falla mientras el dispositivo de seguridad seEncuentra fallado, como lo ilustra la figura 4.6Entonces la probabilidad de una falla mltiple en cualquier perodo debe estar dada por la probabilidad de que la funcin protegida falle cuando el dispositivo de seguridad se encuentra Fallado durante el mismo perodo. La figura 4.7 muestra que esto puede calcularse de al siguiente Manera: Probabilidad probabilidad de indisponibilidadDe falla falla de la X promedio delMltiple funcin protegida dispositivo de seguridad

La probabilidad tolerable de la falla mltiple es determinada por los usuarios del sistema, como se trata en la siguiente parte de este captulo. Generalmente la probabilidad de falla de la funcin protegida es un dato dado. Por lo tanto si se conocen estas dos variables, la no disponibilidad Permitida puede ser expresada de la siguiente manera:Indisponibilidad promedioDel dispositivo = probabilidad de falla mltiple _____________ De seguridad probabilidad de falla de la funcin protegida

Entonces un elemento crucial del funcionamiento requerido de cualquier funcin oculta es laDisponibilidad requerida para reducir la probabilidad de la falla mltiple asociada a un nivel Aceptable. La discusin anterior sugiere que esta disponibilidad puede determinarse en las tres Etapas siguientes: primero establecer qu probabilidad de falla mltiple est preparada a tolerar la organizacin luego determinar la probabilidad de que falle la funcin protegida en el perodo en cuestin (esto tambin se conoce como ndice de demanda) finalmente, determinar qu disponibilidad debe lograr la funcin oculta para reducir la probabilidad De la falla mltiple al nivel requerido.Notar que generalmente es posible variar tanto la probabilidad de falla de la funcin protegidaComo ( y especialmente) la indisponibilidad del dispositivo protector adoptando las polticas Apropiadas de mantenimiento y de operaciones. Como resultado, tambin es posible reducir la La probabilidad de la falla mltiple a casi cualquier nivel deseado que sea razonable, adoptando

Dichas polticas. (cero por supuesto es un ideal inalcanzable) En al practica, la probabilidad que se considera tolerable para cualquier falla mltiple depende de sus consecuencias. En la mayora de los casos la evaluacin debe ser realizada por los usuarios del activo fsico. Estas consecuencias varan enormemente de un sistema a otro, por lo que lo que se estima Tolerable vara con la misma amplitud. Para ilustrar este punto, la fugura 4.8 sugiere cuatro evaluaciones posibles para cuatro sistema diferente: Como mencionamos anteriormente, estos niveles de tolerabilidad no pretenden ser taxativos y no Necesariamente reflejan el punto de vista del autor. Pretenden demostrar que en cualquier sistema protegido, alguien debe decidir qu es tolerable antes de que sea posible decidir el nivel de proteccin Necesaria, y que esta evaluacin ser diferente para sistemas diferentes.

Mantenimiento de Rutina y Funciones OcultasEn un sistema que incorpora un dispositivo de seguridad con seguridad inherente, la probabilidad De una falla mltiple puede ser reducida de la siguiente manera: reducir la frecuencia de falla de la funcin protegida - haciendo algn tipo de mantenimiento proactivo - cambiando la manera en que se opera la funcin protegida - cambiando el diseo de la funcin protegida incrementar la disponibilidad del dispositivo de proteccin - haciendo algn tipo de mantenimiento proactivo - verificando peridicamente si el dispositivo de proteccin ha fallado - modificando el dispositivo de proteccin

Prevenir la falla de la funcin protegida Para prevenir un falla mltiple , debemos tratar de asegurar que la funcin oculta no se encuentre en estado de falla si y cuando falla la funcin protegida. Si pudiera encontrase una tarea proactiva que fuera lo suficientemente buena como asegurar un 100% de disponibilidad del dispositivo protector , Entonces una falla mltiple es tericamente imposible. En la prctica, es poco probable que alguna tarea proactiva pudiera lograr que una funcin alcanzara una disponibilidad de 100% indefinidamenteLo que debe hacer, sin embargo, es dar la disponibilidad necesaria para reducir la probabilidad de una Falla mltiple a un nivel tolerable. Entonces: Para fallas ocultas, vale la pena realizarUna tarea proactiva si asegura la disponibilidadNecesaria para reducir la probabilidad de una Falla mltiple a un nivel tolerable.Si no podemos encontrar una manera de prevenir una falla oculta, debemos encontrar alguna otra manera de mejorar la disponibilidad de la funcin oculta.

Detectar la Falla Si no podemos encontrar una manera adecuada de prevenir una falla oculta, todava es posible reducir elRiesgo de una falla mltiple revisando la funcin oculta peridicamente para saber si sigue funcionando.Si sta revisin (llamada tarea de bsqueda de falla) es llevada a cabo a intervalos adecuados y si la funcin es restaurada en cuanto se descubre que est defectuosa, todava es posible asegurar altos Niveles de disponibilidad .

Figura 4.7 : Clculo de la probabilidad* de una fallaLa probabilidad * de que falle una funcin protegida en cualquier perodo es la inversa de su tiempoMedio entre fallas, como ilustra la figura 4.7 a:

Figura 4.7 a :ProbabilidadY funcionesProtegidas Funcin Protegida Dispositivo Protector Falla Falla Periodo de Medicin Si el tiempo medio (MTBF o TMEF) entre fallas no anticipadasDe la funcin protegida es de 4 aos y el perodo de medicinEs de un ao, entonces la probabilidad de que la funcinProtegida falle en este perodo es de 1 en 4.La probabilidad de que el dispositivo de proteccin est fallado en un momento cualquiera est dado Por el porcentaje de tiempo que est en estado de falla. Esto es ciertamente medido por su indisponibilidad (tambin conocido como tiempo de parada de mquina) , como lo muestra la figura 4.7 b abajo: Figura 4.7 c:Probabilidad De una fallamltiple Falla FalladoFuncin Protegida Dispositivo Protector Si la no disponibilidad promedio del dispositivo protector es de 33%, entonces la probabilidades que est en estadode falla en cualquier momento es de 1 en 3La probabilidad de la falla mltiple es calculada multiplicando la probabilidad de falla de la funcin protegida por la indisponibilidad promedio del dispositivo protector. Para el caso descrito en la figura 4.7(a) y (b) anteriores, la probabilidad de una falla mltiple ser la que indica la siguiente figura 4.7 ( c ) : Figura 4.7 b:Probabilidad yDispositivos deseguridad Falla Fallado Un aoFuncin Protegida Dispositivo Protector Probabilidad de falla en un aoCualquiera = 1 en 4Disponibilidad 67% indisponibilidad 33%La probabilidad de una falla en un ao cualquiera: 1 en 4x1 en 3 = 1 en 12

Falla de laFuncin protegida

Error de ortografa en Un memo o e-mailInterno entreOficinas

El motor de 10 KW De la bomba BSobrecargado

Falla la bombaDe servicio B

Exceso de presinEn la calderaEstado de fallaDel dispositivoDe proteccin

Corrector deOrtografa de un Programa de Procesador deTextos,Incapaz deDetectar errores

Disyuntor atascado En posicin Cerrada

Bomba de Reserva CFallada

Vlvulas de Alivio atascadasEn posicin cerradaFallaMltiple

Error de Ortografa noDetectado

El motor se quema: 800Dlares paraRebobinar

Prdida total de la capacidadDe bombeo: 18000 dlares deProduccinPerdidas

Explota la caldera:Mueren 10personasFrecuencia tolerableDe falla mltiple

10 por mes?

1 en 50 aos?

1 en 1000 aos?

1 en 10000000 aos?

Figura 4.8 : frecuencia de falla mltiples Modificar los equipos (rediseo) En un pequeo nmero de casos, es o bien imposible en contar alguna clase de tarea de rutina que asegure el nivel de disponibilidad deseado, o es poco prctico hacerlo con la frecuencia requerida .Sin embargo, an debe hacerse algo para reducir el riesgo de la falla mltiple a un nivel tolerablePor eso, en estos casos, generalmente es necesario volver a considerar el diseo. Si la falla mltiple pudiera afectar la seguridad o el medio ambiente, es obligatorio redisear. Si la falla mltiple slo tiene consecuencias econmicas, la necesidad de redisear es evaluar en trminos econmicos.

Funciones Ocultas : el Proceso de DecisinTodo lo que hemos dicho acerca del desarrollo de una estrategia de mantenimiento para funciones ocultas puede ser resumido como lo muestra la figura 4.9:

Merece la pena realizar mantenimiento Proactivo si asegura la disponibilidadNecesaria para reducir la probabilidadDe una falla mltiple a un nivel tolerableSi no puede encontrarse una tarea proactiva adecuadaRevisar peridicamente si la funcin oculta est Funcionando (realizar tareas programadas de bsqueda de falla)Si no puede encontrase una tarea de bsquedaDe falla apropiada: el rediseo es obligatorio si la falla mltiple pudieraAfectar la seguridad o el medio ambiente si al falla mltiple no afecta la seguridad ni el medioAmbiente, el rediseo debe ser justificado en Trminos econmicos. ser evidente a los operarios la Prdida de funcin causada por esteModo de falla actuando por s soloEn circunstancias normales? No Si La falla es Evidente. VerPuntos 3 a 5 de Este captuloFigura 4.9: identificacin y desarrolloDe una estrategia de mantenimientoPara una funcin oculta4.7 Conclusin Este captulo ha demostrado cmo el proceso RCM provee un marco estratgico de trabajo completo para manejar las fallas. Como lo resume la figura 4.10, este marco de trabajo: clasifica todas las fallas basndose en sus consecuencias. Al hacerlo as, separa las fallas ocultas de las fallas evidentes, y luego ordena las consecuencias de las fallas evidentes en un orden de importancia decreciente provee una base para decidir caso por caso, si merece la pena realizar mantenimiento proactivo sugiere qu accin debe tomarse si no puede encontrarse un tarea proactiva adecuada.Los diferentes tipos de tareas proactivas y acciones a falta de, son abordados en los prximos cuatro captulos, junto con un enfoque integrado de la evaluacin de consecuencias y seleccin de tareas.

ser evidente a los Operarios La prdida de funcin causadaPor este modo de falla Actuando por s solo en Circunstancias normales?ejerce steModo de falla Un efecto Adverso directoSobre la CapacidadOperacional?produce este modoDe falla una prdida De funcin u otrosDaos secundariosQue pudieran lesionarO matar a alguien,O llegar a infringir Alguna normativa Del medio ambienteConocida?Merece la pena Realizar mantenimientoProactivo si reduce lasProbabilidades de una Falla mltiple a un Nivel tolerable Merece la pena Realizar mantenimientoProactivo si reduceLas probabilidades deLa falla a un nivel tolerableMerece la pena Realizar mantenimientoProactivo si, duranteUn perodo de tiempoCuesta menos que el Costo de las Consecuencias Operacionales ms el costoDe reparar la fallaMerece la penaRealizar mantenimiento proactivo si, duranteUn perodo de Tiempo cuesta menosQue el costo deReparar la falla N S N S N S Si no...Si no...Si no...Si no...Realizar una tareaProgramada deBsqueda de fallaEl rediseoEs obligatorioNingn mantenimientoprogramadoNingn mantenimientoprogramadoEl rediseo puedeSer obligatorioEl rediseo puedeSer deseableEl rediseo puedeSer deseableFigura 4.10 : la evaluacin de las consecuencias de la falla

M020S5TAREAS PROACTIVAS