Errores en un SLA de Incidencias

0

Hoy os traigo un recopilatorio de los errores más comunes al definir un SLA sobre el proceso de gestión de incidencias. Este tipo de SLA es el más común, conjuntamente con los de disponibilidad de servicios o activos. No pretendo hacer una guía de cómo diseñar un SLA correcto, sino enumerar lo que considero errores sistemáticos en la redacción de los SLA’s.

No permitir ni un fallo

Es un error común en SLA’s el determinar sólo el objetivo de servicio y no el acuerdo sobre el nivel de servicio. Vamos por partes:

  • Objetivo de servicio: Es el objetivo que se propone cumplir el proveedor en cada ejecución del proceso. Por ejemplo, “resolveremos las incidencias críticas en menos de 3 horas”
  • Nivel de servicio: Es el grado de cumplimiento de los objetivos de servicio. Como por ejemplo, si hemos tenido 10 incidencias críticas, y en 9 hemos tardado menos de 3 horas, hemos logrado un 90 % de cumplimiento.
  • Acuerdo de Nivel de Servicio (SLA): Es el grado de cumplimiento al que nos comprometemos.

Así, no se puede definir un SLA diciendo que se resolverán las incidencia en menos de tantas horas y nada más. Es cuestión de tiempo que alguna incidencia tarde más. ¿Por una vez que incumplas das mal servicio?

Además, como ya traté en otro artículo, hay que diferenciar la forma de aplicar las penalizaciones a un hecho concreto (multa con un importe fijo) a un incumplimiento del acuerdo (normalmente asociado a un variable).

Resumiendo: Debemos diferenciar entre objetivo de servicio y acuerdo de nivel de servicio.

Asociar tiempos a complejidad y no a necesidad

Los acuerdos muchas veces los diseña el equipo de TI, y los tiempos de resolución suelen ponerlos en base a lo que les cuesta solucionar el fallo. Hay dos puntos que intervienen en el tiempo de resolución:

  • El tiempo que lleva arreglarlo o resolver la incidencia.
  • El tiempo que la incidencia está en cola esperando a ser atendida.

El primer tiempo es el que es. El equipo puede mejorar sus capacidades, pero poco puede hacer. Un objetivo de un SLA es el de alinear objetivos entre el proveedor y el cliente. Así que un SLA debe servir para la priorización. Por ello, los tiempos debería ir acordes a la necesidad del cliente y no a la comodidad del proveedor.

Un ejemplo de mala definición sería:

Si la resolución de la incidencia requiere a los equipos de tercer nivel, 2 días. Si no el tiempo de resolución será de 1 día.

Os doy mi palabra que he visto en un SLA la frase anterior. Y otra similar en la que dependiendo del equipo que tenía que resolverla, el horario sobre el que se mide cambiaba. ¿Pero qué tendrá que ver el nivel de resolución en el tiempo de respuesta? Al cliente del servicio le da igual si han tenido que intervenir técnicos expertos o si están en cancún. Lo que le importa es el impacto que tienen en su negocio.

Mi recomendación es mapear las prioridades a las necesidades reales de negocio, tal y como ya lo decía en este artículo. Y luego ligar los SLA a estas prioridades. El equipo que presta el servicio deberá adaptarse para conseguir los mejores tiempo. A lo mejor la adaptación es aumentar la resolución en segundo nivel.

Resumiendo: Los tiempos de respuesta deben ir alineados con la necesidad de negocio, no con la complejidad de la incidencia.

Olvidarse del horario

El horario debe quedar claro. ¿Los tiempos se miden en 24×7? Si es así, todo es cristalino. Pero normalmente muchos SLA’s se definen en un horario laboral. Si proveedor y cliente son de la misma empresa, puede parecer una trivialidad. Pero a la que haya más de una sede, o que cliente y proveedor sean de dos empresas, el concepto de horario laboral es diferente. En el acuerdo de nivel de servicio debe quedar claro el horario. De hecho es un concepto que debería estar definido en la propia definición del servicio.

Un horario no sólo se define por las horas y días a los que aplica, sino que hay que dejar claro el calendario de festivos, sobretodo si hay más de una localidad entre cliente y proveedor. Yo ahora estoy en una empresa española con clientes en todo el mundo. ¿Entienden los clientes de Caribe el nivel de servicio con 6 horas de diferencia? Pues es algo que hemos tenido que trabajar, y en los SLA con ellos debe quedar reflejado. Además incluso internamente afecta. Contamos con oficina en Madrid y Palma de Mallorca, y todo TI está prácticamente en Palma de Mallorca. La oficina de Madrid debe entender que el nivel de servicio recibido cuando es festivo local en Palma de Mallorca es diferente del resto de días. Y si eso no fuese aceptable, el equipo de Palma tendría que saberlo para poder disponer de los equipos de guardia adecuados.

No sólo es un pliego de descargo para hacer entender al cliente el horario que tiene el proveedor. También es la demanda del cliente y la necesidad que debe cubrir el proveedor.

Resumiendo: El horario de aplicación, con especial atención a festivos locales, debe quedar reflejado en el SLA.

Asumir que el cliente sabe lo que es una incidencia

Tal vez tú, lector, sabes perfectamente lo que es una incidencia. Es posible que tengas un perfil ITIL o que vengas del mundo de los servicios TI. Así que no hay por qué hacer una definición. Pero un cliente, sobretodo si tienen un perfil más del lado de negocio, puede no entenderlo. Sobretodo les costará mucho entender la diferencia entre incidencia y problema. Y cuando surja una disputa, es cuando parecerá que te escudas en tecnicismos para incumplir el acuerdo.

Por ejemplo, os pongo el siguiente caso real:

Un cliente abre un ticket de incidencia porque una factura al aprobarla le da un error. El técnico la mira, y comprueba que tiene los permisos adecuados, pero que efectivamente le da un error. Así que hace dos cosas: a) aprueba la factura con su perfil (que si le deja) indicando que lo hace en nombre del usuario y cierra la incidencia b) crea un ticket de defecto de software para pasarlo a desarrollo (tipo de problema).

El usuario llama quejándose al responsable de soporte diciéndole que la incidencia no está resuelta, que si vuelve a intentar aprobar otra factura, le sigue fallando. El responsable le indica que si necesita aprobar más, que contacten con el servicio y que mientras arreglan el software y sube a producción, ese paso se lo harán ellos.

El caso anterior es un ejemplo de libro de incidencias, asociadas a un problema, del que se genera un error conocido. Pero el cliente no lo entiende, el error tarda una semana en subir a producción y hay una queja por el SLA, diciendo que la incidencia se ha tardado en resolver 7 días. Cuando una incidencia que bloquea la facturación es grave.

Conviene dejar claro lo que es una incidencia y evitarse así problemas más graves.  Así recomiendo dejar claro, a ser posible con ejemplos, qué es una incidencia y qué no lo es. Con especial atención a los errores de software.

Resumiendo: Hay que definir claramente lo que aplica al SLA y lo que no.

Indicar que los tiempos que no son responsabilidad del proveedor no cuentan

Esto es muy común, y está bien indicarlo, pero… ¿Qué significa que son responsabilidad del proveedor?. Si se deja así y nada más, no tardaremos en discutir sobre de quien es la responsabilidad en tal o cual caso. Los motivos por los que el reloj del SLA se para deben quedar claros.

Ejemplos de esto son:

  • Cuando la resolución requiera aprobación del cliente.
  • Cuando un tercero, que no es responsabilidad del proveedor esté involucrado.
  • Cuando se solicite más información al cliente y se esté esperando.

Conviene enumerarlos en el acuerdo.

Resumiendo: Definir los supuestos en los que el tiempo de resolución no se tiene en cuenta.

SLA’s por tipo o por prioridad

En mi carrera me he encontrado muchas veces (por no decir casi todas) con acuerdos como el siguiente:

SLA incidencias críticas: El 99% resueltas en menos de 4 horas.

SLA incidencias altas: El 97% resueltas en menos de 1 día.

Es decir, por cada tipo de incidencia, un SLA diferente, cada uno con su penalización. Mala idea. Primero porque tratamos como servicios diferentes la resolución de críticas de la de altas o de otras prioridades. El nivel de servicio es uno. Por lo tanto el SLA debe ser común. Pero debe estar ponderado para reflejar que una incidencia crítica es mucho más importante cumplirla que una de prioridad baja. Un ejemplo de acuerdo bien definido sería:

El nivel de servicio se medirá como el peso de las incidencias resueltas en tiempo dividido entre el peso total de incidencias. Contando las incidencias críticas como de peso 20. Las altas de peso 8. Las medias de peso 3 y las bajas de peso 1.

El acuerdo de antes nos da un único indicador del nivel de servicio y combina la importancia de cada tipo de incidencia. El acuerdo final, será que ese nivel sea superior a un determinado valor. Además os recomiendo, en el caso de hacer una penalización, que sea progresiva, tal y como definí en este artículo.

Resumiendo: Combina el SLA en un único indicador.

SLA’s por tiempo de respuesta

Sinceramente es un tipo de SLA que tiene muchos problemas. El tiempo de respuesta se suele llamar al tiempo que tarda el equipo en ponerse en ello. O dicho de otra manera el tiempo que lleva en cola. Normalmente se suele cumplir mandando un mail avisando de que se está en ello.

Mi opinión es que este SLA carece de valor por los siguientes motivos:

  • No aporta valor a negocio en el sentido de que no arregla el servicio.
  • Es el SLA más fácil de pervertir.

Resumiendo: No incluyas acuerdos sobre el tiempo de respuesta.

SLA’s abruptos

Recordando lo que ya indiqué en el artículo sobre cómo diseñar el pago variable de un SLA, las penalizaciones no deberían ser abruptas. Es decir, no debería existir una frontera que implique de no pagar nada a pagar un importe considerable. Y no debería existir un punto en el que da igual si lo haces peor, la penalización no sube.

De hecho siempre he considerado que el SLA ideal para incidencias (y que ninguna aplicación del mercado te deja medir) sería el siguiente:

  • Para cada prioridad definimos un tiempo de resolución como objetivo.
  • Se calcula el factor de incumplimiento de cada incidencia como el tiempo que se ha pasado del tiempo de resolución pactado, dividido entre el tiempo de resolución que había. Así, una incidencia de prioridad media que tiene 20 horas de tiempo y tarda 30 en resolverse, tiene un factor de 0,5. Una incidencia crítica que tarda 12 horas y el tiempo de resolución era de 3, tiene un factor de incumplimiento de 3.
  • Se asigna un peso a cada prioridad, en base a la importancia que otorga negocio. Así por ejemplo, una crítica tiene un peso de 20. Una alta de 10, una media de 4 y una baja de 1 (estos valores son arbitrarios en este ejemplo).
  • Multiplicamos para cada incidencia su factor de incumplimiento por el peso de la prioridad, obteniendo el factor ponderado. En el ejemplo anterior la incidencia media con un factor 0,5 tiene un factor ponderado de 2 (al multiplicarla por 4). La crítica tiene un factor ponderado de 60.
  • Sumamos el factor de incumplimiento ponderado de todas las incidencias, lo dividimos por la suma de los pesos de todas las incidencias, y restamos a uno se resultado. Este es el nivel de servicio prestado. Por ejemplo, imaginemos que se han resuelto 100 incidencias bajas (100 de peso), 40 medias (160 de peso), 5 altas (50 de peso) y 3 críticas (60 de peso), dan un peso total de 270. El incumplimiento de las de antes era de 64. 64/270 = 23,7%, y uno menos lo anterior: 76,3 %. Ese es el nivel que ha tenido ese servicio.
  • Definimos un nivel de acuerdo, si es menor, se resta y se multiplica por el importe de penalización. Por ejemplo, se pacta un nivel del 95%, y 100 € por cada 1%. El caso anterior implicaría una penalización de casi 2.000 €.

Este método permite muchas cosas:

  • Da la importancia a cada incidencia. En el ejemplo una crítica ha tardado muchísimo en resolverse y sólo ese caso ha tirado el nivel de servicio a un valor pésimo. Pero es que una crítica que tarde 12 horas hace muchísimo daño a negocio.
  • Una incidencia una vez roto el acuerdo sigue penalizando, cada segundo. No se produce el efecto de ir a por otra, total esa ya está rota.
  • En ningún momento hay un caso en el que por tardar un segundo más se aplique un importe elevado. Sólo penaliza cada segundo que se pasa del tiempo y un mismo valor.

Pero lo dicho, todavía no he visto herramienta que soporte de serie el modelo anterior.

Resumiendo: Diseña un pago variable progresivo y sin límite.

Diseñar algo sin saber como medirlo

Típico error de novatos: diseñar un SLA sin saber cómo se va a medir. Y peor todavía, sin intención de medirlo. Todas las recomendaciones anteriores pierden valor cuando la herramienta ITSM que tenemos no puede medirlo.

Hay que estudiar qué puede medir nuestro ITSM, e intentar aplicar las mejores prácticas dentro de nuestras opciones.

He visto casos en los que un cliente solicitaba un SLA a un proveedor, y éste se lo daba sin saber como medirlo. Luego tiene un problema grave, de medirlo y de pelearse porque la medición se hace a mano, sin objetividad. también he visto casos en la administración pública en la que un pliego exigía un tipo de SLA para un contrato de un servicio. La administración también pedía utilizar su ITSM. Pero luego su ITSM no podía medir el SLA, por lo que el SLA dejaba de poder ser aplicado.

Resumiendo: Diseña el SLA teniendo en mente la herramienta y cómo piensas medirlo.

Definir un SLA sin haberlo medido

Y el último error, en el que he visto bofetadas de impresión, es el de colocar los niveles del SLA al vuelo, sin haber medido el servicio que se puede dar.

Hay ocasiones en las que un servicio que solicita un cliente es único. En esos casos, hay poca medición que podamos haber hecho. Pero en muchas ocasiones el servicio que pide el cliente es estándar y el proveedor ya lleva años proporcionándolo a otros clientes. en estos casos el proveedor debería tener información de los tiempos de resolución que maneja y por lo tanto debería saber qué SLA es capaz de cumplir y cual no. En estos casos debería ser norma de oro primero medir, y luego definir acuerdos. Si no, la bofetada puede ser importante, sobretodo si hay penalizaciones.

Conozco el caso de una empresa que entró a dar un servicio con un SLA muy agresivo, pero que no valoró adecuadamente. Yo estaba en ese momento encargado en el proyecto de implantación del ITSM que se usaría para medir. Una de las características de la penalización, es que podía llegar a superar el 100% del valor del servicio, con lo que se acumularía la penalización a meses siguientes, sin pagar nada. Hablamos de un servicio de muchísimo dinero al mes. Pues el primer mes de servicio la penalización resultante superó con creces el 200%. Como os podéis imaginar, el impacto fue muy, muy grave.

Resumiendo: Debes saber lo que puedes cumplir antes de comprometerte a cumplir un SLA.

Conclusiones

Bueno, un SLA de incidencias parece algo que cualquiera puede diseñar en un momento, pero encierra detrás unas buenas prácticas que no muchas gente sigue. Y luego vienen las lágrimas o las peleas entre cliente y proveedor. Y un contrato en el que hay peleas, no suele acabar bien.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...