ITIL V3 2011 Update: predicar con el ejemplo

Llegando el verano, ITIL anuncia que hay actualizaciones. Todos los libros, dicen, han pasado por el CSI y han incorporado muchos de los cambios y sugerencias que han recibido, incluyendo nuevos procesos, roles, flujos de proceso, inputs, outputs… vaya, que se han aplicado el cuento del Continual Service Improvement. Eso es guay.

La única información oficial disponible por ahora sobre esta actualización es un lacónico FAQ, del que se extrae, como primera conclusión, que se ha intentado hacer un esfuerzo en clarificar conceptos y añadir ejemplos prácticos (espero que hayan hecho énfasis en esto último!). Algo que será muy práctico, al menos para mí, si lo aplican a fondo en la fase de Service Strategy y si consiguen aclarar el movidón del CSM y el SKSM, que sonaba bonito pero no hay quien lo entienda ni sepa cómo aplicarlo de forma beneficiosa…
Lee un resumen de los cambios…

La detección de problemas es asunto de todos

Hace unas semanas preparaba la presentación del proyecto de adopción de la Gestión de Problemas para nuestro cliente; una de las diapositivas hacía referencia a quién podía registrar un problema y cuándo debía hacerse; inicialmente, pensaba incluir los típicos actores, los técnicos del SAU, los de Sistemas, los técnicos de cualquier equipo, desarrolladores… luego pensé que era más conveniente ampliar la lista e incluir a los usuarios. Hasta que al final pensé que no era adecuado hacer una lista de autorizados para la detección de problemas, sino transmitir la necesidad de que cada persona relacionada con la organización debe implicarse en la detección de problemas. 

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…

CFIA o de cómo meter el pie en Gestión del a Disponibilidad y la Continuidad sin despeinarse

A primera vista, es fácil ver que el Análisis de Impacto de Fallo de Componente (sus siglas en inglés son CFIA: Component Failure Impact Analysis) está relacionada de algún modo con los procesos de Gestión de Problemas y de Disponibilidad, pero sigue siendo un concepto algo difuso para la mayoría. Aunque CFIA suena guay y suena grande, es simplemente una forma de evaluar (y predecir) el impacto de fallos y caídas, y tambien ayuda a la localización de puntos únicos de fallo. Y todo lo que hace falta para hacer ese análisis es una hoja de Excel (o algo aún mejor…). Nada de sumar al pack de herramientas de gestión otra aplicación carísima.

• 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.

Y ahora, cómo propongo hacerlo…

Hay que elegir una herramienta de gestión para implantar ITIL.

Pese a que puede parecerlo, nunca he dicho que no sea conveniente usar una herramienta de gestión a la hora de implantar ITIL. Es conveniente, útil y contribuye a la gestión del servicio, de la mejora contínua, agiliza las tareas de todos los agentes implicados en la prestación de servicios y tambien de los usuarios. Permite obtener información consistente y útil sobre desempeño, uso, disponibilidad, etc. Muchas cosas. Mola.

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…
Seguir leyendo…

Implantar ITIL va de implantar procesos, no de implantar (más) herramientas de gestión

Contratar una consultoría de assesment e implantación de ITIL cuesta un dineral, pero es un producto que, en esta época de crisis, se vende bien. Muchas empresas se han tenido que subir a la movida de ITIL porque algunos directivos creen ver la posibilidad de suturar, al menos parcialmente, la sangrante herida que el departamento de informática supone a la organización. Otros, como algunas administraciones públicas, se han tenido que subir al carro por motivos legales y de convergencia con la Unión Europea.

Si no existe cierto entusiasmo por abrazar ITIL, todo son pegas: los directores de Informática leen la mini-guía de introducción a ITIL y quizás asistan a un par de seminarios donde obtienen una visión general de la gestión por procesos, de cómo los define ITIL y a qué están orientados, y algunos casos de éxito de implantación de ITIL en organizaciones…
Y qué pasa después?