El análisis de causa raíz (RCA) es una actividad intuitiva y nos sentimos naturalmente inclinados a hacerlo en nuestra vida cotidiana; disponemos de las técnicas y los métodos para realizar análisis profundos y precisos de nuestros eventos diarios, desde la enumeración de factores causales hasta la generación de recomendaciones y la implementación de cambios para eliminar la causa subyacente.
¿Por qué resulta entonces tan difícil trasladar esa habilidad al entorno laboral?
A nivel de gerencia IT, existe una cierta conciencia sobre la necesidad de integrar la gestión de problemas dentro de los procesos de gestión IT, pero con muchas reticencias a la hora de implementarla efectivamente, basándose en un puñado de motivos poco fundamentados. Es de esperar que si la dirección es resistente a la adopción de la gestión de problemas, más lo serán los técnicos implicados en ejecutarlo, por partida doble:
- El primer efecto percibido es un aumento en su carga de trabajo: cualquier organización mediana o pequeña evitará la dedicación exclusiva de ningún recurso al análisis de causa raíz porque es caro; de manera inmediata, sin entrar en cálculos de ROIs o VOIs y otros indicadores aún más etéreos, es cierto que supone un desembolso desde el inicio. Los técnicos han de compaginar en su jornada la prestación rutinaria del servicio y, además, investigar incidencias graves o recurrentes, y una vez hallada la causa raíz, proponer los cambios y mejoras necesarios para erradicarla.
- El administrador de sistemas medio no sabe por dónde empezar… pero tampoco dónde acabar.
Ese fue mi caso cuando me vi por primera vez en el brete de hacer un RCA y gestionar un problema: “¿cómo hago un análisis de causa raíz?”
Después del salto, intento arrojar algo de luz sobre esto…
El terror del registro de problema en blanco
Imaginemos: el ServiceDesk recibe un aluvión de llamadas de usuarios reportando que no les funciona el correo electrónico; se inicia el proceso de Incidente Grave, se desencadena el plan de acción, llega a Sistemas y un administrador lo resuelve; actualiza el registro de incidencia con la información de la resolución y se comunica a los usuarios el restablecimiento del servicio.
En una organización que haya iniciado la adopción de ITIL, un incidente grave requiere la apertura de una investigación de problema; y ante la extensión inmaculada del registro de problema recién abierto se encuentra el administrador de sistemas encargado de completarlo. ¿Por dónde empezar?
Lo primero: identificar el servicio y sus componentes afectados por el incidente, algo que ya no es trivial en un departamento que no haya adoptado la Gestión de la Configuración y que tenga un catálogo de servicios incompleto, con poca sustancia, en resumen: más bien flojo. Tener que hacer el ejercicio de determinar los componentes de un servicio afectados por un incidente durante la investigación de problema tiene una ventaja: puede convertir esa información generada en input para la Gestión del Catálogo de Servicios para enriquecerlo y así hacerlo más preciso y útil.
Lo siguiente es saber cómo documentar un registro de problema; requiere que contenga una descripción fiel y detallada del desarrollo de los acontecimientos desde la primera notificación del incidente hasta su resolución. La forma más clara: contarlo como si fuera una crónica periodística, en la que se establece primero el marco del suceso (fecha, hora y lugar) y después se detalla la secuencia cronológica de eventos. Una vez realizada esta crónica, comienza el análisis; para realizar esa parte, es conveniente disponer de un cuerpo de preguntas que:
- vertebre la investigación
- prevenga el dejar cabos sueltos o áreas de responsabilidad vacías
- nos ayude a identificar y formalizar las mejoras que conformarán la solución permanente al problema, y que es, en definitiva, el producto principal que debe extraerse de la gestión de problemas.
Exponiendo los hechos: la verdad, toda la verdad y nada más que la verdad
Un registro típico de problema podría empezar con algo como:
“A las 10:15 am, el usuario Joaquín Báñez contactó al Service Desk por teléfono y reportó que al abrir MS Outlook para acceder al correo se producía el siguiente mensaje de error…”
El primer paso en la investigación es, por tanto, recopilar todos los registros de incidencias relacionados con el problema que tratamos; el primero de ellos, se convertirá en el cabo del ovillo del que iremos tirando para responder a una colección de preguntas similar a:
- cuándo fue detectado el incidente?
- cómo se detectó?
- ¿qué se hizo para resolverlo?
- ¿qué impacto causó a los usuarios?
- ¿ha pasado antes? ¿es un problema recurrente?
- ¿se pudo de alguna manera detectar antes este problema?
- ¿se pudo de alguna manera resolver antes este problema?
- ¿existía documentación sobre esta incidencia en la base de datos de conocimiento? En tal caso, la instrucción de trabajo era adecuada para la resolución?
- ¿Debe algún otro equipo o proveedor estar involucrado en la investigación del problema?
En siguientes entradas, daré más detalles sobre cómo documentar, argumentar y contestar, de manera metódica y estructurada (y, sobretodo, documentada), todas estas preguntas.