Un departamento de sistemas puede tener un equipo dedicado a la investigación y resolución de problemas (¡bienaventurados aquellos con el presupuesto para tenerlo!), y no es exigible al resto de empleados la resolución de los problemas. Pero la detección sí: cabe esperar de cualquier técnico o usuario que vea un posible problema, un agujero, un fallo, lo que sea, que de inmediato aviso de tal fallo.

Un “no es mi trabajo” no es aceptable: los que saben arreglar cosas, deben arreglarlas; los que no saben, deben avisar a alguien que sepa. Y después hacer un seguimiento formal mediante Gestión de Problemas de cada uno de estos problemas para que ninguno se pierda.

Finalmente, concluí la diapositiva con un sucinto “Todos los implicados con los servicios TI deben involucrarse en la detección de problemas proactivamente y debe premiarse el esfuerzo en la detección y la resolución de problemas”.

Sobre el cuándo debe abrirse un problema, fui incluso más sucinto, y sólo incluí: “siempre que sea necesario, útil y que aporte valor”.

El caso es que aún no sé si la presentación fue del gusto del cliente o no. Quizás debería ser menos idealista y ceñirme al estándar español de generar problemas sólo cuando ITIL dice que es imprescindible…

Compartimos peldaño con Barbados, por ejemplo. Y nos adelanta Chipre. ¿Qué hacemos mal?

En el artículo original de Blogcafé dan algunas explicaciones muy consistentes…

España vuelve a suspender en implantación de nuevas tecnologías

El detonador es aquello que ha provocado que se desencadene el problema, lo que hace que aflore; tener una colección de detonadores bien tipificados y que elegir un detonador sea obligatorio en cada registro de problema gestionado, ayuda a:

• Identificar cuál es el factor que más frecuentemente desencadena problemas
• Tener una visión numérica de los factores de riesgo que amenazan nuestros servicios
• Detectar las malas prácticas que pueden ocasionar problemas
• Y hacer algo útil con todo esa información después…

“Detonador” no tiene nada que ver con causa raíz; el detonador va a hacer explotar un problema , va a hacer que se manifieste y que aflore; la causa raíz es el error o circunstancia que hace que, al darse ese detonador, el problema se dispare. Es decir, al final, la meta ha de ser erradicar la causa raíz: es lo que realmente evitará la recurrencia del problema; pero el control de los detonadores es importante y como parte del plan de acción que se diseña para solucionar un problema se deben incluir acciones encaminadas al control de los detonadores.

Ejemplos de detonadores que se me ocurren: uso válido. Es el más frecuente y, en realidad, el que más nos debe preocupar si aparece demasiado a menudo. Un ejemplo: que se te llene el disco de sistema porque una aplicación ha agotado el espacio disponible con los logs generados no es un fallo de aplicación, sino que es su comportamiento normal.

El problema que te ha generado es que se ha agotado el espacio en disco; posiblemente esa aplicación se ha detenido, y tambien es probable que todo el sistema que aloja dicha aplicación se detenga. Te has quedado sin servicio.

La causa raíz no es “los logs de la aplicación han agotado todo el espacio en disco”; la aplicación genera logs cuando funciona normalmente. Fue diseñada así. Es correcto. Y ese funcionamiento correcto según la norma ha sido el detonador. ¿Cuál sería la causa raíz? Que ese funcionamiento normal no se tuvo en cuenta en la fase de diseño; no se consideraron adecuadamente los requerimientos del servicio, en este caso de espacio en disco para logs, o no se aplicó una política de rotación de logs correcta o la que se aplicó se dimensionó incorrectamente. La raíz de causapodría caer en una categoría como  ”Diseño / fallo de capacidad”, si el problema fue que el volumen de datos de registros fue inesperado, o en el caso de que la política de rotación de logs fuera inadecuada o no se aplicara, algo como “Política inadecuada”, en el sentido de que las políticas para la adopción de servicios quizás no estén correctamente definidas para entregar al negocio servicios resistentes a los detonadores (pero esto,  las clasificaciones de causa raíz, lo hablamos otro día).

Otros posibles detonadores que podrían incluirse:

• Fallo de un componente: fácil, el servidor se rompió, el switch se quedó lelo… un componente del servicio, simplemente, falló.
• Fallo de infrastructura: como podrían ser problemas de alimentación eléctrica en el CPD (o que se te inunde, o que se incendie…)
• Error humano: este es otro que aparece frecuentemente; un error de operación te la puede liar, y gorda.
• Terceros (y aquí cabrían muchas subclasificaciones): bugs de software desarrollado por otros, fallos en comunicaciones, tu ISP…
• Acto deliberado: que un empleado cabreado te rompa algo es algo que puede pasar… y un atentado terrorista tambien

Cuando ya los tengo clasificados… ¿qué hago?

Cuando tras un periodo gestionando problemas tienes una muestra significativa de problemas analizados y resueltos, estudia la distribución porcentual de detonadores y elabora planes de acción para acotar su impacto actual y futuro; la gestión de problemas no sólo sirve para reducir el número de incidencias sino también el número de fallos de la plataforma tecnológica, y aquí incluyo todo lo que tenga que ver con el departamento TI: hardware, software y gente. A saber:

• Si tu detonador principal es “Uso válido”: revisa a fondo tus procesos de diseño y cambio, porque se están entregando al negocio servicios poco fiables, mal diseñados, mal dimensionados…
• Si es fallo de componente: revisa la disponibilidad de tus servicios y la capacidad de tu plataforma;  si tus componentes críticos no están redundados, sientate con la dirección y analiza si el negocio lo necesita; puedes usar esto para empezar el análisis
• Si el error humano encabeza la lista: forma al personal, mejora tus procedimientos  e instrucciones de trabajo, introduce el uso de checklists para las tareas rutinarias, e idealmente, automatizalas.

Y así con todos; y tambien sería importante delegar en los procesos de Mejora Contínua el perfilar esta lista de detonadores hasta ajustarla a las necesidades del servicio prestado. Cada organización va a necesitar considerar una colección de detonadores que represente de forma fidedigna qué hace estallar un problema en su negocio; por ejemplo, para un proveedor ISP móvil puede ser interesante incluir “Meteorología” como detonador mientras que a un proveedor web no le sirve de nada incluir tal categoría.

Pero así es todo; al fin y al cabo, ITIL no es un modelo pret-a-porter, sino una guía de estilo; no te vende el traje hecho, pero sí te deja bien claro que no combines nunca negro con azul.

Pero, ¿por qué no soy el único en mi grupo de amigos que tiene un jefe incapaz de decidir algo? ¿por qué abundan? No todos somos rápidos y determinados a la hora de tomar decisiones, y ni siquiera hay que serlo siempre para ser un buen jefe; pero cuando alguien es incapaz de tomar decisiones, ¿por qué se mete a jefe?

Todo el mundo da por sentado que el camino natural es aceptar los ascensos laborales según se presenten, pero tener talento para desempeñar tu trabajo no implica que lo tengas tambien para hacer el de tu jefe, y mucho menos que te atraiga su puesto. Estas dos consideraciones deberían tenerse muy en cuenta a la hora de elegir quién ocupará un puesto de responsabilidad, tanto por el candidato como por la persona que lo designará.

Si el criterio para asignar el cargo es, como era en aquel Departament, el orden en la línea de sucesión, es decir, el subalterno inmediato a la plaza vacante, el fracaso está garantizado; ese tipo de elecciones no funciona y suele ser el más frecuente en las empresas. La persona que accede al puesto o bien opta por el continuismo más acomodado o por la ruptura brusca con la gestión anterior, y ambas suelen ser opciones equivocadas, porque no siempre están enfocadas a mejorar el funcionamiento del equipo, sino que es por disfrutar de las comodidades de una actitud conservadora, la primera, o por ánimo revanchista contra la opresión vivida en el peldaño inferior que hasta ahora ocupaban la segunda.

Por otro lado, la conclusión más clara que extraigo de estos jefes es que en realidad no quieren serlo; quieren el ascenso y el aumento de sueldo (y eso que no siempre van juntos), pero nada de actuar como jefes y trabajar como jefes; si uno sufre esa minusvalía que le impide asumir la responsabilidad de un posible error al tomar una decisión (pese a que no decidir suele demostrarse más perjudicial que elegir mal) , ¿por qué acepta el puesto? ¿Qué va a aportar desde su nuevo cargo?

No peco de ingenuo al reivindicar la honestidad como principal virtud en el mundo laboral: creo que facilita el funcionamiento de un equipo y de una organización, y ningún cambio que se haga para optimizar el rendimiento, ya sea en el organigrama o implantando ITIL o cualquier metodología, servirá de nada si no se basa en la honestidad de la organización y de los individuos que la integran.

• Identificar items de configuración (CI) que pueden provocar un corte de servicio
• Localizar CIs que no están redundados o que por lo menos no tienen un backup
• Evaluar el riesgo de fallo de cada CI
• Justificar la demanda de inversiones
• Colabora en la creación y mantenimiento de la CMDB.

Los 3 pasos clave para realizar el CFIA con éxito serían:

• Es este CI un punto único de fallo?
• Qué impacto tiene para el cliente/para el negocio el fallo de este CI? A cuántos usuarios afectará? Cuál será el coste para el negocio?
• Cuál es la probabilidad de fallo? Qué puede cambiarse para evitar ese impacto?
• Podría prevenirse ese impacto realizando algún cambio de diseño? Sería conveniente dotar ese CI de redundancia o hacerlo más robusto? Y en tal caso, cuánto costaría?

Realmente, es un método sencillo y muy resultón para empujar al departamento de TI a meter el pie en Gestión de la Disponibilidad, que no es uno de los procesos más populares ahora mismo; de paso, lo que me pregunto es si podría expandirse la matriz para incluir los procedimientos o instrucciones de trabajo de recuperación de fallo de esos CI, quizás añadiendolo como una fila en la parte inferior de la matriz CFIA, aunque esto requiere primero que el departamento de TI sea lo suficientemente maduro como para tener todo eso por escrito (voy a dar por hecho que sí; en caso contrario, no tiene ningún sentido plantearse ni CFIA ni disponibilidades sin tener lo más básico listo: algo de documentación).

Añadir la documentación a la matriz CFIA podría usarse para evaluar tanto la organización como la infrastructura, analizandolo con preguntas tipo:

• Cómo se responde cuando ese CI falla?
• Qué procedimientos se siguen? ¿Están documentados esos procedimientos?
• ¿Se pueden mejorar esos procedimientos? ¿Se pueden automatizar?
• ¿Se podrían mejorar los procedimientos formando al personal o usando nuevas técnicas o herramientas?
• ¿Se podría haber evitado el problema efectuando mantenimientos preventivos?

Si se logara la ejecución metódica y exhaustiva de análisis de impacto de fallo de componentes a todos los niveles (a nivel de infrastructura y de la organización), se generarán RfCs que aporten mejoras reales al negocio pero sin requerir un elevado nivel de madurez en los procesos ni derrochar en software de soporte. Tambien aporta beneficios al departamento TI, porque además de poner un primer pie en Gestión de la Disponibilidad tambien significa meter la cabeza en Gestión de la Continuidad; los datos obtenidos en la preparación de la matriz CFIA sirve como input para Gestión de la Configuración, sobretodo si se añade la documentación de recuperación, que puede aprovechar ese conocimiento para la CMDB. Y por supuesto, Gestión de Incidencias, que usará esos procedimientos de recuperación, y Gestión de Problemas, que recibirá como input el resultado de los análisis efectuados.

Pero para que todo esto sea verdad, es necesario que esa herramienta sea realmente adecuada para apoyar la gestión de servicios basada en ITIL…

Para comprobarlo, Pink Elephant, auténticos apóstoles de ITIL y sin duda de las empresas más reconocidas por su conocimiento y experiencia en ITIL, creó el sistema Pink VERIFY. Recoge una serie de requisitos de cumplimiento obligatorio y otros de integración que ha de cumplir una herramienta software para considerarla apta para apoyar la gestión por procesos ITIL. Y está disponible de forma gratuita.

Si teneis que valorar alguna herramienta de soporte, es recomendable imprescindible contar con estos formularios.

Y si teneis que elegir una, Pink VERIFY cuenta con una lista extensa de herramientas ya validadas y aptas.

Por cierto: una herramienta sólo es válida si cumple el 100 % de los criterios obligatorios. No vale menos.