Blog

He decidido escribir un pequeño post acerca de nuestro querido Acuerdo del Nivel del Servicio o SLA para los amigos, gracias a que llevo varios días leyendo referencias acerca del mismo y del impacto que tiene lanzarlo en una organización.

El SLA ha de ser el documento donde se recojan las condiciones que gobiernen la relación entre cliente y proveedor de servicios tecnológicos. Este documento ha de estar vivo y debe estar sujeto a cambios a lo largo de su ciclo de vida, bien porque el cliente solicita mejores condiciones para cumplir con los objetivos de negocio o bien porque la organización de TI ve que no es capaz de llegar a las condiciones pactadas con los recursos de los que dispone (el caso de que el proveedor de TI proponga endurecer las condiciones no se suele dar con mucha frecuencia). Una vez pactado sirve de referencia contra lo que medirse y contra lo que poder determinar si el servicio es o no de buena calidad. El SLA debe incluir condiciones como el horario de servicio, el del soporte, el nivel de disponibilidad que se garantiza, los canales de acceso al soporte y a las extensiones del servicio, los horarios de las ventanas del servicio, carga esperada del servicio, tiempos de respuesta y de resolución en base a las prioridades.

El problema es que lanzarlo de esta forma no es tan fácil, a veces existen impedimentos como por ejemplo: el cliente no es capaz de cumplir su rol en la relación entre proveedor y cliente que gobierna el SLA, la falta de tiempo o de entendimiento, las herramientas de gestión con las que se cuenta no “œsacan” el % de disponibilidad global del servicio X, no es fácil definir la carga esperada del servicio que se puede soportar.

Según mi experiencia con departamentos de informática, únicamente con empezar a medir los tiempos de respuesta y de resolución en base a prioridades se logra un gran cambio de mentalidad. Los técnicos, gracias a la presión del cronómetro y del cumplimiento, se centran en solucionar aquellas incidencias o solicitudes que mayor impacto tienen en la actividad de la empresa y no dedicarse a aquellas que una vez resueltas alimentan el ego y pensamos por dentro “oye! Soy un hacha”¦” y esto es la bomba para los departamentos de informática porque se empiezan a concentrar en lo que verdaderamente importa, no en lo que a los técnicos más les gusta. Y ya, si una vez medidos, se cumplen, al resto de la organización le parecen correctos, y los publicamos, es un auténtico lujo! Luego solo nos queda mejorarlos continuamente, casi nada ;P

¿Alguien más quiere colaborar con su visión acerca del tema?

Nerea Molinero

La OGC (Oficina de Comercio del Gobierno Británico)ha revisado el contenido de los 5 libros de ITIL v3,5 publicados en 2007. Los motivos principales de la revisión de esta nueva edición 2011 (así le han llamado) han sido:

1. Eliminar inconsistencias que se dan entre los diferentes libros
2. Hacer inteligible el contenido del libro Estrategia del Servicio
3. Asegurar que el contenido es coherente con el glosario
4. Asegurar que todos los procesos se definen bajo la misma estructura de metas, objetivos, roles
5. Facilitar el entendimiento de las 5 publicaciones en general

Me parece perfecto, además era algo que, por lo visto la comunidad venía pidiendo.
Anda que no he pasado tiempo para entender Estrategia del Servicio a fondo, volviéndome loca viendo que los libros decían cosas diferentes acerca del mismo tema, intentando buscar el sentido de porqué el portfolio de servicios (Estrategia) se diseña en la fase de Diseño (así suena muy lógico pero cuando te sumerges en el mundo teórico de ITIL y lees esto, algunos planteamientos de base se desintegran y tienes que hacer más café). Según los resultados de una encuesta que ha realizado la OGC el 100% de los encuestados creen que los libros se entienden mejor. ALELUYA!

Lo que no me parece tan bien es que saquen esta nueva edición (que sale exclusivamente debido a fallos de la anterior) al mismo precio que los libros de 2007 para todo el mundo. Es decir, que como buenos ITILeros tenemos que comprar los 5 libros a un precio de 450€, nos los estudiamos con cierta dificultad y en 2011 tenemos que pagar otros 450€ para tener una versión que no tenga errores y sea más fácil de entender, ya está bien”¦

Por cierto, comentar también que esta nueva edición ha engordado un poquillo, lo cuenta estupendamente mi colega Joaquín Báñez en su interesantísimo blog ITIL-es del que soy fan “ITIL engorda“

¡Saludos a todos!

¿Empezamos a ciegas los proyectos de consultoría? Yo creo que sí y explico por qué. Tomamos muchos datos al inicio para situar el escenario: datos de organización, de roles, datos técnicos, de operaciones”¦ Estos datos, por supuesto son necesarios, nos plantean el input del proyecto de forma objetiva, sabemos todo lo que hay que saber para empezar a trabajar en el proyecto de transformación”¦ espera ¿todo?

¿Sabemos lo que piensa el personal acerca de este proyecto? ¿Sabemos quiénes lo ven como una oportunidad y quiénes como una amenaza? ¿Conocemos los miedos de las personas con respecto al cambio que se va a articular? ¿Conoce todo el personal los motivos del lanzamiento del proyecto?

Las personas pueden, tranquilamente y con una sonrisa en los labios, hacer que un proyecto de transformación se desvíe, desvirtúe o incluso hacer que fracase. Por mucho que nos empeñemos, si no tenemos a aquel agente del service desk borde de nuestra parte por poner un ejemplo, con toda seguridad nos dificultará la implantación, pondrá millones de pegas, nos mirará con desdén”¦ y al final, si tenemos suerte, puede que se dé por vencido y lo pase. Todo esto con la pérdida de tiempo o desviación correspondiente porque además, esta persona se ha encargado de poner mala fama al proyecto desde dentro: en el comedor, en la máquina de café y lamentablemente ha conseguido un pequeño ejército de máquinas de impedir que empiezan a renegar del proyecto guiados por su líder”¦ Claramente estoy exagerando, soy de Bilbao… pero seguro que a más de uno le suena familiar todo esto que estoy contando.

Todo es mucho más fácil, si al inicio del proyecto nos preocupamos por conocer las opiniones del personal para con el proyecto. Saber con qué aliados contamos y a quiénes nos tenemos que ganar. Conocer cuáles son los puntos fuertes y cuáles son los débiles, las fortalezas y las oportunidades. Comunicar debidamente el porqué del proyecto para hacer que todo el mundo se involucre”¦
Entiendo que muchos puedan pensar que es ciencia ficción pero realmente se puede hacer, doy fe, y además facilita una barbaridad el trabajo de implantación. ¿Alguien más se anima?