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”…

Cómo sobreponerse a la aplastante inercia de la realidad en 4 pasos: paso 2

jbanez — Wed, 02 Sep 2009 09:58:00 +0000

El paso 1 trataba sobre crear el contexto para el cambio, prepararse para que el cambio ocurra definiendo qué debe cambiar y por qué. El paso 2 trata de determinar a quién le importa realmente (o debería importarle) el cambio y por qué. En muchas conversaciones con compañeros en varias empresas en las que he trabajado, existe un “ellos” difuso y étereo involucrado (a veces incluso un “ellos” explicito y concreto): los procesos no pueden cambiarse porque “ellos” no nos dejarán, o porque alguien que ocupa un puesto determinado de mando no permitirá que el cambio se ejecute. En el paso 2 hace falta establecer un enlace entre el comportamiento (“qué”), la razón por la que debe cambiar (“por qué”) y quién necesita entender que el cambio es necesario. Así de simple… aunque si realmente fuera tan simple, no habría ninguna inercia a la que sobreponerse, ¿no?

Los mecanismos alrededor de esa cuestión incluye hacer llegar la información correcta la persona indicada en el momento preciso, que es lo que determinamos que debía cambiarse en el paso 1 y las razones por las que debe cambiar. Sin contexto, sin razones sólidas y concretas, nadie sensato querrá cambiar nada, porque apoyandolo en justificaciones débiles esos deseos de cambio pueden ser considerados un capricho. Por eso mismo, con contexto, nadie sensato se opondrá a cambiar. En casi todas las empresas en las que he trabajado, mis compañeros culpabande la inercia corporativa a la poca voluntad de cambio de la Dirección, cuando el problema a menudo era que no se había tenido en cuenta a la persona adecuada para crear el contexto, o que la información precisa no se había entregado a la persona que la necesitaba. Y además, no sólo se trata de hacer llegar esa información a la gente adecauda, sino asegurarse de que esa gente tiene intención (o se les puede convencer de que lo hagan) de usarla. En un artículo de Gartner (Use a ‘Friendly’ Approach to Organizational Change and Application Process Improvement”), sugieren trabajar primero con los amigos porque eso ayudará a que el consumidor de la información se incline a usarla, así que conviene no desperdiciar la oportunidad de predicar al respecto si una conversación frente a la máquina del café deriva en el rollo de “necesitamos un cambio…”.

Crear diagramas del contexto y hacer análisis RACI (Responsible, Accountable, Consulted and Informed) son puntos clave, y algunos pasos podrían ser:

Primero: considerar el proceso en cuestión
después, considerar al consumidor del proceso y cómo evaluará los resultados
finalmente, considerar al proveedor del proceso y cómo evaluará los resultados; aquí se puede incluir a los consumidores directos y a los proveedores (y sus jefes)

Esto es básico: es crucial llegar a la mayor parte de altos directivos (aunque en otros casos el objetivo del cambio serán los cargos intermedios). A veces ocurre que las personas que ejecutan un proceso y sus jefes reconocen el contexto para el cambio, pero la necesidad de cambio no se ha mostrado de manera explícita a los que pueden (y deben) dirigir el cambio. En cualquier caso, en este punto sólo hablamos de la persona que debe aprobar o dirigir el cambio, sea cual sea su cargo.

En el paso 3, si se ha conseguido la atención de los que deben dirigir el cambio (y como es muy mala idea escalar un problema sin acompañarlo de una solución), se debería definir de manera precisa qué hay que cambiar (y no vale decir simplemente “los procesos”…).

ITIL-es » cambio

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

Cómo sobreponerse a la aplastante inercia de la realidad en 4 pasos: paso 2