ARTÍCULOS POR NUESTROS CONFERENCISTAS

9
Ago

Análisis causa raíz: ¿cuál es el punto?

RCA: estado actual

El personal de mantenimiento y confiabilidad repara los equipos defectuosos con regularidad y, cuando el impacto de esta falla es sustancial, a menudo se requiere un análisis de causa raíz (RCA). ¿Pero cuál es el punto? Una vez que hayamos solucionado el problema, ¿no deberíamos dejarlo en paz y seguir con nuestras vidas? Ya tenemos suficiente. ¿Por qué necesitamos sacar a varias personas de sus trabajos para pasar varias horas analizando algo que está en el pasado? 

Un análisis de causa raíz (o cualquier análisis) requiere una inversión de nuestro recurso más escaso: el tiempo. ¿Por qué debería pasar nuestro precioso tiempo completando un RCA? La respuesta a esta pregunta puede parecer obvia, pero siempre vale la pena preguntar. 

Invertimos en RCA porque, como con cualquier inversión, creemos que generarán rendimientos positivos. Pero esa no es siempre la mentalidad de quienes realizan estos análisis. Muchas veces, hacemos un RCA porque es un mandato del liderazgo. Los que investigan no creen que valga la pena el tiempo, pero hay que hacerlo porque, ya sabes, esas son las reglas. Entonces, el estándar se convierte en el “producto mínimo viable” que hace que el jefe firme que se completó el RCA. 

 Esta no es la forma de ejecutar un programa RCA eficaz. RCA hecho de esta manera logra muy pocos resultados y puede hacer más daño que bien. Se convierte en un impuesto al tiempo, resultando en poco valor agregado y una cantidad considerable de sentimientos negativos. Pero no tiene por qué ser así. Es necesario contar con un proceso confiable y un conjunto de herramientas para desarrollar un proceso RCA exitoso. Pero primero, debemos establecer por qué alguien querría o necesitaría invertir su tiempo y dinero en RCA. 

Hablemos un minuto de nuestra realidad actual. En este momento, estamos en un ascensor de progreso tecnológico, acelerando exponencialmente hacia arriba. Tome el progreso de la rueda, por ejemplo; la rueda se inventó por primera vez alrededor del año 5200 a. C. y probablemente se usó para la cerámica, no para los carros. Se necesitaron casi mil años para que la rueda se usara para el transporte, y no fue hasta el siglo XIX que comenzamos a ver vehículos motorizados. Ahora, a medida que nos acercamos al final del primer cuarto del siglo XXI, descubrimos que los automóviles casi pueden conducirse solos. 

La mayoría de los avances en tecnología ocurrieron en los últimos 150 años más o menos. Si los 7.000 años transcurridos desde la primera rueda equivalieran a una hora, casi todo el progreso serio se habría producido en el último minuto. Y ese progreso sigue acelerándose. 

¿Entonces que significa eso? Problemas, y muchos de ellos. Nuestro impulso por hacer avanzar la tecnología está generando más problemas de mayor complejidad que requieren soluciones en un período de tiempo más corto. Por supuesto, las personas de diferentes industrias experimentarán este fenómeno en diferentes grados; no es lo mismo para todos. Pero está ocurriendo universalmente, y si no encontramos una manera de volvernos buenos en la resolución de estos problemas rápidamente, puede llegar un momento en nuestro futuro no muy lejano en el que estos problemas nos abrumen. 

Entonces, ¿cuál es el punto detrás del análisis de causa raíz? Los procesos y herramientas de RCA nos permiten resolver problemas difíciles o “retorcidos” mejor y más rápido. Estos problemas son a menudo más grandes que cualquier persona. Ninguno de nosotros tiene el monopolio del conocimiento. Necesitamos traer a otros a la mezcla para superar las brechas en lo que creemos que sabemos. En el mejor de los casos, RCA permite que grupos de diversos expertos aprendan rápidamente unos de otros para explicar cómo ocurrió el problema y qué se debe hacer para prevenir futuros incidentes. 

Necesitamos desarrollar culturas que aprendan más rápido de lo que fallan las máquinas. Para hacer esto, necesitamos un análisis de la causa raíz que tenga el tamaño correcto (escalable) para el problema en cuestión, uno que funcione, que brinde un valor constante dado el tiempo invertido. Cuando se hace correctamente, quienes realizan RCA pueden reconocer el valor en el proceso y no realizarlo simplemente porque el jefe lo solicitó. 

Análisis de causa raíz: cinco pasos

Hay varias variaciones del análisis de causa raíz y, por lo general, todas involucran una combinación de los siguientes cinco pasos: 

  • Reúna evidencia y datos que se utilizarán para sacar y respaldar conclusiones.
  • Documente la información importante del problema, como cuál es el problema específico, cuándo sucedió, dónde sucedió y cuál es el impacto del problema.
  • Identificar las causas del problema. ¿Qué sucedió que condujo al problema?
  • Determinar qué se hará para resolver el problema.
  • Comparte lo aprendido con los demás.
  • Recopilación de pruebas y datos

Imagina que estás cocinando la cena para un grupo grande y quieres que sea excelente. Todo chef sabe que comprar los mejores ingredientes es el primer paso para una gran comida. La evidencia y los datos son los “ingredientes” de un RCA. Por lo general, cuando ocurre una falla, toda la energía se dirige a que el activo vuelva a estar en línea. En la prisa por recuperar, los datos y las pruebas pueden acabar siendo descartados o destruidos. Esto siempre es un error. Necesitamos recopilar piezas y equipos rotos, muestras de fluidos, datos del sistema, documentación y declaraciones de testigos o expertos lo antes posible para facilitar el aprendizaje futuro.

Puede encontrar evidencia de una variedad de fuentes diferentes:

  • Personas: Testigos, operadores, técnicos de mantenimiento, ingenieros de diseño, ingenieros de seguridad, representantes de OEM y expertos externos, todos son excelentes fuentes de información. Recuerde, ninguna fuente única sabe todo sobre el problema, por lo que es crucial diversificarse.
  • Procedimientos y Documentación: Busque evidencia documentada. Esto incluye:
  • Registros de tareas de mantenimiento preventivo y predictivo
  • Manuales de mantenimiento, operación e instalación.
  • Informes de operaciones y mantenimiento
  • Diagramas de diseño
  • Tuberías, instrumentación y esquemas eléctricos
  • Documentación de fallas pasadas.
  • Fotos, video, audio: muchas instalaciones están bajo vigilancia por video las 24 horas. Si está disponible, intente obtener estos videos o fotos, o recorra la escena y tome fotos y videos usted mismo, asegurándose de cumplir con todas las pautas de la organización. Si existen archivos de audio, como los de una comunicación de radio bidireccional, también pueden ser buenas fuentes de información. Si bien los videos en línea pueden ser recursos útiles, no se vuelva dependiente de ellos y siempre asegúrese de que provengan de una fuente confiable.
  • Hardware, software, sistemas: diferentes sistemas pueden ofrecer información única. Para descubrir la información, haga preguntas de descubrimiento como:
  1. ¿Qué equipo falló? ¿Fue un componente específico o múltiple?
  2. ¿Cuál fue la intención del diseño?
  3. ¿Cómo encaja cada componente en el sistema general?
  4. ¿Cómo estaba siendo operado en comparación con cómo fue diseñado para operar?
  5. Medio ambiente: Las causas ambientales también son consideraciones importantes. Pregúntese:
  6. ¿Hacía calor o frío? ¿Húmedo o seco?
  7. ¿Estaba adentro o afuera?
  8. ¿Cuál era el ambiente de negocios en ese momento? ¿Fue estacionalmente ocupado o lento?

Recopilar evidencia de diversas fuentes lo antes posible después del evento es una de las partes más importantes de un RCA de alta calidad.

Plantear el problema

El problema debe establecerse con precisión y la información clave debe documentarse. Al desarrollar una declaración de problema para un problema de confiabilidad, es útil usar la siguiente fórmula:

“Activo ABC no disponible + XX horas para recuperar”

Al analizar las causas, escribir la declaración del problema con esta fórmula nos permite incluir la historia de por qué y cómo el activo experimentó un tiempo de inactividad, así como cuánto tiempo se necesitó para que el activo volviera a estar en línea.

También necesitamos documentar la hora y la fecha, dónde ocurrió el problema y los impactos reales y potenciales del problema. Es particularmente importante documentar los impactos reales y potenciales porque los líderes necesitan saber qué tan grave fue el problema y qué tan grave podría haber sido. Finalmente, es útil incluir con qué frecuencia ha ocurrido este tipo de problema en el pasado.

Analizar las Causas

Hay varias formas de analizar las causas. Pero, ¿cuál es la forma “correcta”? La verdad es que no existe una manera correcta, solo la que funciona mejor para usted. “Todos los modelos están equivocados, pero algunos son útiles” es un dicho atribuido a George Box, y es apropiado aquí. Pregúntese si su modelo analítico de causa y efecto:

¿Te ayuda a administrar los aportes del grupo?

¿Te ayuda a contar la historia completa del evento?

¿Lograr estas cosas de una manera que no aumente la carga del análisis?

Si es así, entonces su modelo es útil.

En Sologic, nos gusta crear un modelo comenzando con el problema y luego retrocediendo en el tiempo, identificando las relaciones de causa y efecto que llevaron al problema. Es como reproducir una película al revés, cuadro por cuadro. Cuando analiza las causas de esta manera, el grupo puede ver claramente cómo resultaron en el problema.

Las plantillas modelo pueden ser extremadamente útiles. Por ejemplo, la siguiente plantilla funciona para la mayoría de los problemas de confiabilidad.

Esta plantilla comienza con la fórmula descrita en la sección “Declarar el problema”, que es Activo no disponible + XX horas para recuperar. Luego, la rama superior le indica al equipo de investigación que descubra la historia de la falla y qué provocó la caída del activo. La rama inferior les pide que cuenten las horas necesarias para lograr la recuperación. Parte de ese tiempo se utilizó para hacer que el sistema fuera seguro, parte se debió al diagnóstico y el resto se utilizó para reparar el problema. Esta plantilla se puede escalar para adaptarse a la complejidad y la gravedad del problema para ayudar a garantizar que no perdamos el tiempo investigando demasiado.

Tenga en cuenta que un método como este no llevará al equipo a una sola causa raíz. De hecho, cuanto más retrocedas en el tiempo, más divergirán las ramas entre sí. Es importante recordar que no existe una única causa raíz para un evento determinado. Por lo tanto, buscar uno es inútil. Lo que es más importante es comprender cómo funcionan las causas en conjunto para dar como resultado el problema.

Resolver el problema

Las soluciones controlan las causas. Cuando usa un modelo causal como el anterior, puede identificar fácilmente soluciones que controlan las causas individuales. Ya se ha mencionado que no hay causas raíz únicas para ningún evento. Este hecho es liberador porque libera al equipo para identificar cualquier cantidad de soluciones que controlen las causas identificadas en el modelo. En última instancia, se desea una “canasta” diversificada de soluciones.

Hallazgos del informe

Una vez que el equipo ha reunido evidencia, definido minuciosamente el problema, analizado sus causas e identificado soluciones, el paso final es compartir lo aprendido. El equipo de investigación sabe más sobre el problema que nadie. Por lo tanto, están en la mejor posición para ayudar a enseñar al resto de la organización. La mejor manera de hacer esto es creando un informe de incidente completo y reflexivo. Un informe de incidente no necesita ser largo, solo necesita contar la historia de una manera que ayude a otros a aprender.

Poniéndolo todo junto

Los avances tecnológicos están generando un número cada vez mayor de problemas complejos. El éxito en un mundo así requiere que empleemos técnicas de aprendizaje organizacional, incluido el análisis de causa raíz, de manera que nos ayuden a aprovechar los diversos conocimientos y la capacidad intelectual a nuestra disposición. En última instancia, el éxito da como resultado una organización que aprende más rápido de lo que falla.

Leave a Reply