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 “yes! 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