6 Mejores Prácticas de SLA para el éxito en la gestión de servicios

Según ITIL 4, un acuerdo de nivel de servicio (SLA) es "Un acuerdo documentado entre un proveedor de servicios y un cliente que identifica tanto los servicios requeridos como el nivel de servicio esperado." En pocas palabras, un SLA define qué deben esperar el proveedor de servicios de TI y el cliente al contratar un servicio. En el ciclo de vida del servicio ITIL, los SLA son definen y modifican en dos áreas principales:

• Diseño de servicios
• Mejora continua del servicio

Esto significa que los SLA para servicios de TI deben crearse junto con cualquier especificación para servicios nuevos y actualizados. Siempre que un servicio de TI se están diseñado o modificado, también debe revisarse y modificarse su SLA correspondiente para Haz de que están justos, exigibles y realistas. Dado esto, aquí son seis mejores prácticas para crear y cumplir SLAs de servicios de TI en un entorno de gestión de servicios de TI (ITSM).

1. Crea SLA separados para cada servicio de TI que te necesites medir

Los SLA son un conjunto de promesas que el proveedor de servicios hace al cliente. Evita crear un único SLA para todo tu catálogo de servicios. En lugar de definir que todas las solicitudes de servicio de TI se cumplirán en cinco horas, por ejemplo, Crea SLA separados para cada servicio de TI te quieras seguir. Procura ser específico. Algunos ejemplos podrían incluir:

• Se creará un nuevo usuario en el plazo de un día desde recibir un formulario de solicitud aprobado.
• Las terminaciones de usuarios se procesarán al final del último día del usuario para salidas amistosas o inmediatamente para salidas no amigables.
• Se pedirán y entregarán nuevos teléfonos dentro de una semana desde la solicitud.

Cada servicio de TI tiene su propio plazo de entrega y programa de aprobación, que debe completarse en consecuencia.

2. No Crees SLA que cubran todas las divisiones de tu organización

Si te prestas soporte a una organización con muchas ubicaciones o divisiones diferentes, ten cuidado al crear SLAs que cubran varias ubicaciones. Diferentes unidades operativas pueden tener diferentes requisitos de soporte, por lo que un SLA paraguas puede no dar soporte adecuado a cada ubicación. Por ejemplo, si te proporciona soporte para impresoras, el cliente puede solicitar un tiempo de respuesta de cuatro horas entre las 8 de la mañana y las 17 de la tarde entre semana. Esto puede ser fácil de satisfacer en una área metropolitana, donde son muchos técnicos. Puede ser más difícil mantener esa respuesta de 4 horas en zonas rurales, donde son hay menos técnicos viviendo más separados. Esta y situaciones similares pueden requerir más detalles sobre los servicios por región o SLA separados para cada región.

3. Alinear los SLA con el resultado deseado por el cliente

Los SLA deben crearse para los resultados deseados por el cliente. Ten en cuenta el "efecto sandía", donde el proveedor de servicios está cumpliendo con las métricas del SLA (por ejemplo, el tiempo de actividad del servicio), mientras no apoya los objetivos reales de tu cliente.

Un SLA tradicional utiliza métricas operativas de TI como que las líneas de telecomunicaciones deben estar activas el 99,1% del tiempo. Estos SLA gestiona los números, pero carecen de contexto para los resultados deseados por el cliente. En su lugar, utiliza mediciones y métricas verídicas en tus SLAs, reflejando los resultados reales deseados por el cliente. Por ejemplo, tu SLA puede garantizar un 99,9% de tiempo de actividad para las líneas de telecomunicaciones. Tus pruebas muestran que te cumples esa métrica, pero el 0,1% de inactividad ocurre en el momento más ocupado del cliente, cuando el tráfico de telecomunicaciones se dispara, como durante el torneo de la NCAA o en Amazon Prime Day. El servicio cae durante esas caídas del 0,1% y el cliente están descontento. Como una sandía, el proveedor de servicios ve un SLA verde cumplido en el exterior—99,9% de tiempo de actividad en telecomunicaciones—mientras que el cliente ve un SLA rojo fallando en el interior—sus usuarios son pierden conectividad cuando la línea están saturada. Siempre que sea posible, descubre el resultado deseado por el cliente para el SLA y escribe el SLA para ese resultado. Un SLA basado en resultados de reemplazo podría ser. Los servicios de telecomunicaciones redundantes permitirán acceso ininterrumpido entre las 6:00 AM y la medianoche EST. Los SLA basados en resultados gestiona al resultado deseado por el cliente en lugar de llegar a un número. Los SLA basados en resultados también influirán en cómo te, como proveedor de servicios de TI, gestiona el servicio al cliente. Esta importante buena práctica depende de implicar y escuchar a tu cliente mientras creas y modificas sus SLAs. Deja que formen parte del proceso para que puedan entender tus niveles de servicio y te puedan redactar tus SLA según sus necesidades.

4. Haz que los SLA sean medibles

Tu mesa de servicio debe ser capaz de recopilar y presentar las métricas necesarias para determinar si se ha cumplido un SLA. Los SLA deben representar objetivos SMART: específicos, medibles, alcanzables, relevantes y oportunos. Cada SLA individual debe poseer las siguientes características:

• Esespecífico. Un SLA debe ser lo suficientemente específico y detallado como para Define expectativas en la prestación de servicios.
• Maccesible. Debe haber una forma de hacer un seguimiento del rendimiento real frente al SLA prometido. Muchas plataformas de gestión de servicios cuentan con capacidades para comparar las promesas de SLA con el tiempo real u otra medición de servicio registrada para ese elemento. Es difícil acumular y demostrar el rendimiento del SLA si tus herramientas básicas de gestión no incluyen los objetivos de SLA y las mediciones utilizadas al entregar los elementos del catálogo de servicio.
• Unobjeto de suerte. El SLA debe ser realista y poder cumplirse. Objetivos poco realistas pueden desmotivar a tu equipo de prestación de servicios.
• Relevant. El SLA debe estar directamente relacionado con el servicio de TI que se presta y debe ser relevante para evaluar el rendimiento en función de ese objetivo.
• Imely. El SLA debe contener un plazo dentro del cual se prestará el servicio.

Un proveedor de servicios de TI debe ser capaz de recopilar datos sobre el rendimiento de los SLA e informar sobre ese rendimiento. Haz que tu software de gestión de servicios están a la altura para ambas tareas.

5. Revisar y ajustar los SLA periódicamente

Como parte del área central de Mejora Continua del Servicio de ITIL, un SLA debe revisarse y actualizarse siempre que son cambios propuestos o prometidos para ese servicio. Ajusta cualquier cambio que afecte a los objetivos deseados del cliente, como horas de servicio, disponibilidad, tiempo de funcionamiento, finalización o tiempo de respuesta. Las empresas que no revisen ni ajusten sus SLA en momentos de mejora del servicio TI pueden dejar de cumplir sus objetivos de nivel de servicio, y el resultado podría ser la pérdida de un cliente o sanciones por incumplimiento del SLA.

6. Asegurar que los SLA tengan en cuenta las excepciones habituales e inusuales

Es igual de importante Define dónde no se aplica un SLA como dónde sí se aplica. Tu SLA debería Define cualquier situación habitual e inusual que dificulte o impida el procesamiento de servicios de TI. Algunas excepciones a SLA pueden incluir:

• Todos los pedidos se liberarán en un plazo de una hora desde su recepción, excepto los domingos entre la 1:00 y las 4:00 AM, cuando se realiza el mantenimiento del sistema.
• Los nuevos ordenadores se configurarán y entregarán en un plazo de cinco días laborables. Se necesitarán días adicionales cuando un festivo esté dentro del periodo de entrega.
• Los nuevos usuarios se añadirán al sistema en el plazo de un día tras recibir un formulario de usuario nuevo completado, siempre que la dirección haya aprobado la incorporación del usuario. No se considerará un fallo en el nivel de servicio si se ha recibido una solicitud de nuevo usuario, pero la dirección está lenta en aprobar al nuevo usuario.
• Los objetivos de SLA serán temporalmente eximidos en caso de un desastre local o regional que afecte al servicio, incluyendo, pero no limitado a, incendios, inundaciones, terremotos, pandemias, cortes prolongados de electricidad o de red, etc.

Recursos adicionales

Para saber más sobre la gestión de niveles de servicio, consulta el blog de gestión de servicios de BMC y consulta estos artículos:

• Ejemplos y plantilla de Acuerdos de Nivel de Servicio (SLA)
• Procesos de diseño de servicios ITIL
• Mejora Continua del Servicio ITIL

Mira hacia el futuro brillante en el horizonte del service desk de BMC Software

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.