Durante una implementación de ISO 20000, surgió una duda acerca de cómo alinear los objetivos de nivel de servicio de los suministradores con los que fueron acordados con el proveedor y el cliente.
Es una pregunta que frecuentemente escucho, así que busque un correo electrónico –de hace algún tiempo– en donde acerco un pequeño razonamiento para este punto:
Acerca de los proveedores de tercer nivel (suministradores). Telefónica, Cisco, y demás que componen los servicios TI:
Hoy vamos a hablar de otro dogma parece venir de ITIL y de la ITSM: “Los objetivos de nivel de servicio de los contratos de apoyo (UC) deben alinearse con los objetivos de nivel de servicio de nuestro SLA”
(Tomen en cuenta que hablamos de SLA: un SLA tiene muchos SLT, no hablamos de la totalidad de SLAs. Cada contrato tiene un SLA, el SLA tiene uno o varios SLT)
El motivo que me impulsó a escribir este correo fue una consulta específica:
“Puede alguien decirme cómo se puede definir un
acuerdo de nivel de servicio con el cliente cuando el
acuerdo de nivel de servicio que tengo con el suministrador dice que para las solicitudes críticas y urgentes:
trataremos de resolver en el plazo de dos días, si el problema no se puede resolver dentro de ese plazo, serán empleados mayores esfuerzos y le informaremos la fecha prevista para la resolución… ¿se pueden imaginar cuanto tiempo de atención tienen las llamadas de menor prioridad?”
De manera ortodoxa se dice que no puedes escribir un SLA con tus clientes que tenga SLTs más estrictas (más difíciles de conseguir, más ajustadas) que las que tienes con tus proveedores.
Pero hay una idea de la que ITIL no habla directamente: “Haz los SLTs para los proveedores de la manera que quieras, documenta el riesgo de escalar determinados incidentes con los proveedores y escala ese riesgo al negocio. Mantén –siempre– un rastro documentado. Esto no debería suceder muy a menudo. Para todo lo que el proveedor tiene que realizar, tenga en cuenta que ellos no tendrán el mismo grado de compromiso que usted. Considerando estos puntos, los incumplimientos de los SLTs serán raros.”
Si existe un incumplimiento podemos:
a) Tratar al incidente como un incidente que no cumplió con el SLT. (por eso hablamos a menudo de que el 95% de incidentes tendrán cumplirán tal o cual SLT)
b) Tratar al incidente como una excepción debido a que el riesgo está documentado.
Es decir, en términos prácticos, para la mayoría de situaciones esto no será un problema mayor para todo lo que hacemos en ITSM. El costo de incrementar (o ajustar) los SLTs a los proveedores no está justificado si la empresa acepta el riesgo. Es una decisión de la empresa el aceptar o no aceptar el riesgo, nuestro papel es asegurarnos de que toman una decisión informada.
Por ello no es correcta la expresión: “ si el proveedor no tiene un SLT igual o menor, entonces no podremos cumplir nuestros SLT”
Una respuesta interesante a la pregunta fue:
“Voy a ir en una dirección algo diferente a lo que planteas. Yo empezaría con la conversación con el proveedor… quizá, solo quizá, el proveedor de servicios está bien. Vale la pena comprobar si existe alguna tecnología, fallo, restricción o configuración que no va a poder resolverse en dos días. O, quizá el negocio simplemente no quiere pagar por el costo adicional que supone reducir o mitigar el riesgo que no se contempló cuando se negoció el contrato.”
…O quizá son más realistas!
Cuando una incidencia escala al tercer nivel, la idea de predecir cuánto tiempo va a tomar resolverla es simplemente absurda. En primer lugar, las comunicaciones son más lentas o largas. En segundo lugar, la relación entre las partes es ahora contractual, no interna. Cada uno tratará de cubrirse. En tercer lugar, y más importante todavía, casi todos los casos de tercer nivel no son estándar. Estos casos son impredecibles.
Finalmente, esto sirve como argumento para aceptar que nuestros contratos de soporte nunca estarán perfectamente alineados con nuestro SLA para el negocio. Esto no es un gran problema, como solemos decir en TI, porque ocurre raras veces. Si hemos identificado el impacto y la probabilidad del riesgo, y además está bien entendido, es lógico que el riesgo se acepte, a fin de no pagar el monto que implicaría un mayor nivel de servicio.
Que tengan buen día!
Vocabulario:
Objetivos de nivel de servicio: (SLT – Service Level Targets) Son los componentes de los SLA con el cliente.
Contratos de apoyo: (UC – Underpinning contract)
Roles objetivo:
Gestor y coordinador de suministradores
Gestor y coordinador de capacidad
Gestor y coordinador de niveles de servicio
Fuente: www.itskeptic.org
