Por Carlos J. Pernett | Director ThinkReliability Latin America

Este artículo fue publicado inicialmente en LinkedIn, pero al ver la amplia aceptación que tuvo decidimos también publicarlo en nuestra página web.

Hoy día existen varias herramientas para análisis y solución de problemas: la primera que conocí fue el Espina de Pescado (o Diagrama Ishikawa), luego los famosos 5 Por qué y luego la metodología conocida como RCFA* –posteriormente conocí otras más hasta finalmente llegar a Cause Mapping, pero eso es historia para otro artículo.

Importante: En esta publicación el término RCFA (Root Cause Failure Analysis, o Análisis Causa Raíz de Fallas) hace referencia a la metodología descrita a continuación, la cual se enfoca principalmente en fallas de equipos, para diferenciarlo del término abreviado RCA (Root Cause Analysis, o Análisis Causa Raíz) que hoy día agrupa varias metodologías para analizar cualquier tipo de problema (con falla de un equipo, o no).

Cuando conocí el RCFA me pareció interesante pues usaba un modo estructurado y lógico para analizar la falla de un equipo mediante la aplicación de los siguientes pasos (ver diagrama más abajo):

  • Identificar el problema (el nombre del caso)
  • Identificar el modo de falla que se presentó
  • Para este modo de falla, identificar sus posibles causas preguntando ¿Por qué?
  • Usando evidencia, descartar o confirmar dichas causas
  • Para estas causas, identificar sus posibles causas preguntando ¿Por qué?
  • Usando evidencia, descartar o confirmar las nuevas causas
  • Repetir este proceso hasta llegar a la llamada Causa Raíz Física (fenómeno físico que dio origen a la falla)
  • Luego a la llamada Causa Raíz Humana (acción humana que dio origen a la Causa Raíz Física)
  • Y por último a la llamada Causa Raíz Latente (falencia organizacional que dio origen a la Causa Raíz Humana) y que se supone es la Causa Raíz de todo el problema.

Pero, y entonces, ¿qué tiene de malo el RCFA?

Dicho de forma extremadamente resumida, una letra: la F (de Failure, o Falla).

Algunos dirán “Pero si estamos analizando una falla, ¿qué tiene de malo usar la F de Falla en la herramienta que usamos para entender dicha falla?” En realidad el problema no está en la letra en sí, sino en el hecho de que al enfocarnos únicamente en la Falla dejamos de ver el problema como un todo.

Para explicarlo mejor, usaremos una historia de la vida real.

La falla de un “insignificante” transmisor de nivel

En el año 2005 me encontraba trabajando como Ingeniero de Confiabilidad en una planta química y un día cualquiera se presentó la falla de un transmisor de nivel en el reactor principal.

Al principio parecería una falla más de transmisores, de esos que se dañan sin dar razones aparentes, de esos que según RCM fallan de forma aleatoria. Sin embargo, a medida que pasaban las horas el problema seguía y seguía hasta el punto en que la planta duró detenida un poco más de 2 días.

Escuchó bien, 2 días por un transmisor de nivel. Le pregunto, ¿cuánto cree que debería demorar en reestablecer el proceso en su planta si se dañara un transmisor de nivel? Pues bien, cuando ya se normalizó el proceso y finalmente la planta pudo arrancar, el Gerente de la compañía dijo:

“No quiero que me digan por qué se dañó el transmisor, quiero saber por qué la planta duró detenida más de 2 días por un insignificante transmisor”.

Es decir, el Gerente no quería hacer un Análisis Causa Raíz de la Falla (RCFA), sino que prácticamente quería hacer un Análisis Causa Raíz del Impacto de la Falla (algo así como RCFIA, Root Cause Failure Impact Analysis… o como diría el Chapulín Colorado: “La idea es ésa”). En conclusión, al Gerente no le preocupaba la falla del transmisor, sino el tiempo de detención por la falla del transmisor.

Y como vamos a ver, era allí donde había muchas oportunidades de aprendizaje porque si no se entendía qué había pasado, en caso de que cualquier otro transmisor fallara (y había varios por toda la planta), el proceso podría detenerse nuevamente por más de 2 días.

De acuerdo con esto, ¿cómo habría hecho Usted si el RCFA por definición se enfoca en la Falla del Equipo y eso no es lo que quiere saber la Gerencia de la planta en la que Usted es responsable como Ingeniero de Confiabilidad?

Enfóquese en el impacto a las metas –y de todas formas tendrá que analizar la falla

La buena noticia para mí es que en ese entonces ya conocía otra herramienta que no se enfocaba sólo en la falla de los equipos, sino en los impactos de dichas fallas. Y una buena noticia adicional, es que podría responder las preguntas del Gerente y a la vez podría entender por qué había fallado el transmisor (de todas maneras no me iba a quedar con esa duda).

Para ponerlos en contexto, cuando el reactor falló se generaron una serie de eventos que a la final terminaron sumando los más de 2 días de detención y que podríamos ordenar de la siguiente manera:

  • Se detiene el reactor (y por tanto el proceso) por un problema de nivel,
  • Como el evento ocurrió de noche, hubo que esperar a que llegara el instrumentista pues no había personal de Instrumentación durante el turno nocturno (lo cual tomó unas horas),
  • Para que el instrumentista pudiera hacer el diagnóstico completo, debía esperarse a que el reactor se enfriara y tenerlo en condiciones seguras (lo cual tomó más horas),
  • Cuando el instrumentista logró detectar que el transmisor estaba dañado fue a buscar el repuesto en bodega y lo instaló, pero luego de hacer las pruebas el problema persistía, y al revisar en detalle se encontró que el transmisor instalado estaba defectuoso pues tenía una membrana con fuga, al parecer por un transporte o almacenamiento inapropiado (y esto siguió sumando horas de detención)
  • No se encontró más repuestos equivalentes pues el último había sido usado unas semanas atrás, por lo que se recurrió a otra planta similar que por suerte estaba en una ciudad cercana (sin embargo, esto tomaría otras horas para que un instrumentista de la otra planta trajera el repuesto),
  • Al llegar el nuevo instrumentista con el repuesto, lo instalaron y el problema persistía, por lo que sospecharon que el nuevo transmisor estuviera desajustado, sin embargo, la herramienta para probar el transmisor no funcionaba (y el reloj seguía corriendo),
  • Luego de que encontraron la manera de arreglar la herramienta para ajustar el transmisor e instalarlo ya ajustado, iniciaron las pruebas y el problema finalmente había sido solucionado, por lo que se reinició el proceso desde cero hasta llevarlo a operación normal (lo cual tomó otras horas más).

Como se puede ver, las más de 48 horas de detención del proceso no habían sido causadas simplemente por la falla del transmisor en sí.

El tiempo esperando a que el instrumentista llegara a la planta, el tiempo de enfriamiento del reactor, el tiempo instalando el transmisor dañado, el tiempo esperando a que llegara el repuesto desde la otra ciudad, el tiempo instalando el transmisor desajustado, el tiempo arreglando la herramienta para ajustarlo, el tiempo ajustándolo, el tiempo instalándolo y el tiempo reiniciando el proceso, todo esto ofrecía más puntos vulnerables dentro de la organización que el daño del transmisor en sí.

No sólo hubo falla en el transmisor, hubo falla en el almacenamiento del transmisor, hubo falla en el proceso de instalación del primer transmisor (pues no se detectó que estaba dañado antes de instalarlo), hubo falla en la reposición pronta de repuestos, hubo falla en el mantenimiento de las herramientas de ajuste, entre otras fallas.

Todo esto podría explicarse de forma gráfica (que es más fácil de entender) como se muestra en el Mapa de Causas abajo. Para ampliar el Mapa de Causas haga clic en la imagen.

En resumen, ¿qué tiene de malo el RCFA?

Más que decir “¿qué tiene de malo el RCFA?” preferiría decir “¿qué le hace falta al RCFA?”.

Cuando ocurre la falla de un equipo que afecta la operación de su planta (ya sea deteniendo el proceso o restringiéndolo para operar por debajo de su máxima capacidad) y Usted se enfoca única y exclusivamente en entender las causas de la falla, hay mucha información que quedará por fuera de su análisis.

Y es muy probable que no identifique problemas relacionados con la no detección temprana de la falla (antes de que ocurra), con el tardío o impreciso diagnóstico de la falla (cuando ya ocurrió), con el inapropiado almacenamiento de los repuestos (al momento de atender la falla), con la posible puesta en servicio de redundancias (para cubrir la falla de un equipo), etc.

Y lo curioso, es que estos problemas (de detección, diagnóstico, almacenamiento, etc.) le van a afectar con esta falla y con cualquier otra falla similar, por lo que al corregirlos no sólo tomará medidas para una falla en particular sino que extenderá los beneficios del análisis a otros problemas en su planta.

En resumen, el RCFA le mostrará sólo una parte del problema (la asociada con la falla del equipo en cuestión), pero no le ayudará a identificar todas las falencias que existen en los procesos de su organización y que se muestran expuestas al momento de la falla.

Recuerde que el objetivo fundamental de cualquier análisis que su compañía le solicite no es simplemente entender la falla del equipo, sino prevenir que las metas de su compañía sean impactadas por una falla igual o similar.

Advertencia Importante

Sé que algunas personas dirán: “Pero si evitamos la falla del transmisor nada de esto habría ocurrido”. Eso es cierto para este caso. Sin embargo, nótese que si no volviera a fallar este transmisor sino otro transmisor, u otro instrumento, u otro equipo, en otra sección de la planta, varias de las deficiencias que salieron a flote en este caso también se presentarían y nuevamente podrían tener un impacto prolongado a las metas de Producción en su organización.

Por si acaso, no estamos diciendo que no deban identificarse las causas de la falla del equipo (que en este caso también se hizo), sino que deben identificarse todas las deficiencias que generaron el impacto en las metas de la organización (incluyendo, pero no limitándose, a la falla del equipo).

¿Y Usted qué opina?

Cuando falla un equipo en su planta, ¿en su organización se enfocan única y exclusivamente en encontrar las causas de la falla del equipo o en las causas de los impactos a las metas de su organización (que resultaron como consecuencia de la falla)?

Déjenos saber su opinión en los comentarios y comparta con sus amigos para ver qué piensan ellos al respecto.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s