Gestión de Problemas: tus clientes se merecen una explicación (razonable)

Leo en The Opposite of Luck una entrada sobre un informe de análisis forense realizado para determinar la causa raíz de un incidente producido en el Complejo Tecnológico Fisher Plaza de Seattle y que dejó KO las webs de varios clientes alojadas allí.

El informe completo (en inglés) puede leerse aquí.

Como los chicos de The Opposite of Luck, aplaudo la transparencia con la que Fisher Plaza ha manejado este incidente, sobretodo como deferencia a sus clientes, que realmente merecen una explicación; al fin y al cabo, Fisher Plaza provee servicios de housing y hosting, ese es su negocio: el cliente tiene derecho a saber por qué ese servicio ha fallado de forma tan catastrófica.

De igual forma, tus usuarios tambien se merecen una explicación cuando un servicio IT de los que prestas se cae; no tienes que redactar un informe de 12 páginas para cada problema que analices, pero lo que es inaceptable es encogerse de hombros y decirle: “estas cosas pasan…”. 

Gestión de problemas: el terror del registro de problemas en blanco

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.

RCA: incomprendida, mal valorada, pero sobretodo desconocida.

Llevo unos 8 años trabajando en el sector informático, siempre en equipos de soporte (menos una temporada en que el equipo de soporte era sólo yo). En los últimos 2 años, más allá de la explosión del hype de ITIL como receta dorada para convertir los departamentos de sistemas en máquinas perfectas (como si eso bastara), una de las expresiones más utilizadas para vender y comprar servicios de soporte IT es “mejora contínua”.

Seguir leyendo…

En enero de 2008 me incorporé en un equipo de soporte IT formado por 5 personas, donde desempeñé el rol de administrador de sistemas; el cliente era un grupo empresarial privado al que mi empresa vendió un servicio de soporte gestionado y la implantación de algunos procesos ITIL: gestión de incidentes, gestión de problemas y gestión de cambios.
Yo nunca conocí nada parecido, en el mundo de la administración de sistemas, a la gestión de problemas, cuya misión es encontrar la causa raíz que subyace bajo los incidentes graves o recurrentes, y una vez encontrada, proponer un cambio (en la infrastructura, en los procedimientos de operación, en la documentación o donde haga falta) para erradicar esa causa y, por tanto, erradicar la recurrencia de esos incidentes.
Estos procesos son comunes en cadenas de producción industrial, descritos desde hace años en estándares como Six Sigma y otras tambien basadas en el ciclo de Deming, pero descubrí que en el entorno IT resulta muy complejo implantarlos con éxito; pensé que sería debido a la idiosincrasia particular de la empresa en la que intentábamos implantarla, pero tras varias charlas con colegas y algunas búsquedas en Google descubrí que el mayor obstáculo es que clientes, proveedores y técnicos no comprenden adecuadamente el análisis de causa raíz (RCA en adelante, siglas en inglés de la expresión Root Cause Análisis).
Entienden, en la mayoría de casos, la importancia que puede tener para la mejora de la infrastructura, del servicio ofrecido por el departamento IT, incluso alguno es capaz de medir esa importancia con conceptos avanzados como TCO y ROI (y la ventaja que el uso de esos datos frente a la Dirección aporta), pero en pocos casos se entrevé un conocimiento profundo del RCA, de la visión necesaria para afrontarla, de qué información relevante debe desprenderse de un RCA, qué output esperar y cómo usar esa información.
Esto provoca que una implantación de ITIL en una organización sea incapaz de completar los 4 pasos del ciclo de Deming, convirtiendo el ciclo “Plan, Do, Check, Act” en “Plan, Do, Stop”.
Algunos de los obstáculos principales que se pueden encontrar en una organización (y más que obstáculos, frecuentemente, es resistencia del propio departamento IT), incluyen excusas como:

• No hay tiempo: los técnicos no disponen de tiempo para efectuar RCA, porque casi todo su tiempo lo invierten en apagar fuegos; no implementar la gestión de problemas o cualquier otro método de RCA, y obviamente ejecutar los cambios que se extraigan como solución para extirpar la causa raíz de dichos incidentes, alimenta esos fuegos y las tareas de extinción consumen cada vez más tiempo, más recursos… y consumen tambien la imagen de profesionalidad que pueda quedarle al equipo IT en la organización.

• No hay dinero: un cambio, casi siempre, requiere una inversión; si de un RCA se espera como salida una propuesta de cambio, se debe contar con la necesidad de realizar un gasto (gasto, por otro lado, justificable simplemente con el contenido del RCA, si es correcto, profundo y bien documentado). La realidad es: pueden los jefes de unidades IT conseguir ese dinero? Están dispuestos a partidas ya asignadas, por ejemplo, a la renovación de la electrónica de red, solicitada, sin embargo, con muchos menos argumentos que la petición de cambio extraída de un RCA? Tienen estos responsables una visión clara y realista del coste que tienen, para su departamento y para toda la organización, los incidentes IT (el descenso en la productividad de los usuarios afectados o las horas invertidas por el personal IT en solventar esos incidentes?)

• No se sabe a ciencia cierta de qué incidentes se trata: los técnicos de un Service Desk están más preocupados por resolver las incidencias que reciben que por recoger todo tipo de detalles relativos a las circunstancias en que se ha producido el incidente; asimismo, suele ser frecuente el desinterés a la hora de relatar las acciones seguidas para solventarlo, si resuelven el incidente. Por último, los service desks suelen contar con un sistema manual de clasificación y calificación de incidentes; esto hace que la relación de incidentes atribuibles a una causa raíz común sea generalmente incompleta, parcial y pobre, y dificulta cuantizar tanto el impacto que tendría sobre la organización no erradicar el problema que se está analizando como el beneficio de implementar el cambio propuesto para erradicarlo.

Todo lo anteriormente expuesto, cristaliza, en el mundo real, en una pregunta que directivos, responsables IT y técnicos lanzan al que defiende la imperiosa necesidad de implantar la gestión de problemas y los RCA: “¿para qué?”.

Y eso demuestra que no sólo no comprenden la importancia de conocer la causa raíz que detona los incidentes graves en su organización, sino que tampoco tienen una visión clara del impacto que incidentes graves o menos graves tienen sobre la productividad de su organización y, aún peor: de su departamento.

Sobre esto último tengo que hablar largo y tendido, porque otra de las actitudes que más detesto en el mundo de la informática es la incentivar el comportamiento de bombero entre los técnicos, el considerar héroes a los resolutores veloces de incidencias graves y fomentar la actitud cowboy de cabalgar a lo loco sobre la administración de sistemas. Este es el rollo en el equipo donde trabajo ahora, y la verdad es que se tiene que acabar, es demasiado 90’s…