ITIL-es » herramientas

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

jbanez — Wed, 20 Jan 2010 08:41:52 +0000

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.

El CFIA permite:

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:

1. Seleccionar un servicio TI, obtener la lista de CIs que lo conforman; si tenemos la suerte de tener Gestión de la Configuración, lo obtendremos de ahí, si no… toca recopilar la documentación que tenga el departamento de sistemas y sonsacarle lo que podamos a los administradores: tirar de inventarios, de documentos, de manuales de explotación y de lo que se tenga a mano. O sea, lo de siempre.

2. En una hoja de Excel (o en un folio, o en cualquier papel), listar en la primera fila los servicios que estemos considerando y en una columna los CI que los componen; después, para cada CI bajo cada servicio:

Marca una “X” si un fallo del CI provoca una parada de servicio
Marca una “A” si el CI tiene backup inmediato (el backup entra en acción inmediatamente tras un fallo del CI)
Marca una “B” si el CI tiene backup intermedio (requiere una intervención para activar el backup y supone un corte en el servicio, aunque sea breve).

Con esto, se consigue una matriz básica de CFIA. Cada “X” y cada “B” representa una vulnerabilidad potencial, y el último paso, será generar una petición de cambio (RfC) para erradicarlas:

3. Evaluamos las “X” y las “B” de la matriz; las podemos analizar con preguntas del tipo

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.

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

jbanez — Tue, 12 Jan 2010 14:47:45 +0000

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…

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.

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

jbanez — Mon, 21 Dec 2009 08:44:00 +0000

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…

De estos seminarios salen con 2 ideas muy claras:

Necesitamos una herramienta para “gestionar ITIL”: y esto se vuelve una obsesión y alcanza una prioridad tan alta elegir esa herramienta que acaba convirtiendose en el foco del proyecto de implantación de ITIL, desplazando el objetivo principal que es… pues empezar a gestionar las TI según las mejores prácticas de ITIL.
Lo de ITIL es muy bonito, si el mundo fuera perfecto, pero tendremos que cambiar algunos procesos porque no se adaptan a lo que nosotros hacemos: hay que tener valor para decir que ITIL, aceptado mundialmente como conjunto de mejores prácticas, no es bueno para nosotros. Vaya, que mejor cambiar ITIL que cambiar cómo funcionan las cosas en nuestra empresa.

Hoy, trataremos la primera perversión que arruina cualquier proyecto de implantación de ITIL.

1. Elegir qué software comprarán para gestionar las incidencias, los cambios y los problemas constituye una obsesión: se estudian soluciones variopintas que incluyen el desarollo ad hoc y otras locuras. La herramienta se convierte en el factor restrictivo del alcance de la implantación. La ambición de generar el cambio en el modelo de gestión TI de la organización es tan grande… como la herramienta permita, según ellos.

Casi todas las empresas tienen una aplicación para la gestión de incidencias, y seguramente esa ya vale. Para el resto de procesos, según el tamaño de la organización y los procesos que desplieguen, quizás no requieran nada aparte de aplicaciones ofimáticas. En cualquier caso, hay que resaltar que ITIL no contaba con un esquema de software hasta el 1 de diciembre de 2009, y lo lanzó como piloto. Es posible que en breve haya un aluvión de herramientas certificadas ITIL Process Compliant; para elegir una, en tal caso, habrá que olvidar si sirve para “gestionar ITIL”, la OGC certifica que sirve. Habrá que seguir los preceptos que se seguirían para cualquier otra compra: precio, flexibilidad, facilidad de uso y administración, robustez, integración con otras herramientas, opciones de entrega de la aplicación…

Pero es más: justo en una etapa de crisis económica, ¿por qué no ahorrar unos dineros en la implantación de ITIL recortando en la elección de las herramientas? Puestos a ser frugales, y suponiendo el caso más habitual (la empresa cuenta con una herramienta de gestión de incidencias y un sistema PIM o una intranet), el set de software necesario para implantar ITIL consistiría en:

Esa herramienta de que ya disponen para gestionar incidencias. De forma ideal, debería poder modificarse para adaptar las clasificaciones al Catálogo de Servicios
Una intranet o un sistema PIM con calendario y mensajería: para informar a los integrantes de la organización sobre los cambios planificados, impacto sobre servicios, paradas programadas, etc. Google Calendar es ideal. Hasta envía SMS gratis para avisar de los eventos planificados.
Google Docs: tiene un procesador de textos que admite plantillas: suficiente para redactar las peticiones de cambio. Una vez redactadas, se envían al CAB para revisión y aprobación. Tambien sirve para la gestión de problemas, que se beneficia de las hojas de cálculo de Google Docs, por ejemplo, para hacer mapas de causa raíz . Desde luego, para gestionar el Catálogo de Servicios, es suficiente una hoja de cálculo.

Habría más ejemplos de empleo de herramientas gratis, seguras y confiables que resolverían esa fase de elección de software. En cualquier caso, es algo inconsciente confiar la implantación de procesos de ITIL, que introducen cambios en la forma de actuar de personas y la forma de comunicarse entre ellas, a un producto software. No es de recibo que una implantación de ITIL fracase porque no hay consenso sobre qué herramienta comprar o, aún peor, porque la compra descalabra el presupuesto asignado a un proyecto mucho más ambicioso que la implantación de una herramienta software: el cambio organizacional que ITIL introduce.

Mañana hablaremos de la soberbia o, dicho de otro modo, de lo de “tendremos que cambiar algunos procesos porque no se adaptan a la forma en que nosotros hacemos las cosas”…