Los SLA, NSA o traducido al castellano, acuerdos a nivel de servicio son un documento cotidiano entre proveedores tecnológicos y clientes. Un contrato que si bien puede parecer una mera formalidad, se convierte en algo crucial a la hora de gestionar, informar, estructurar o negociar una propuesta tecnológica.
La importancia de un SLA es clave cuando hablamos de un proyecto que migra información delicada a la nube o una propuesta en la que se va a pasar a gestionar datos confidenciales de clientes, por poner algún ejemplo concreto. Situaciones frecuentes donde tanto proveedores como clientes finales deben estar alineados en lo que quieren, los plazo en los que se ejecutara y el cómo. Precisamente eso es todo lo debe recoger un documento de estas características pero ¿lo hace en las condiciones adecuadas?
Para evitar tener un documento que suponga papel mojado vamos a detallar algunos errores típicos en los SLA que debemos evitar. Así, conseguiremos que este tipo de documentos sean algo más que un mero trámite burocrático que no sirva para nada.
Acuerdo unilateral
Puede sonar un poquito fuerte, pero la realidad es que en muchas ocasiones este tipo de documento no son un acuerdo sino una imposición de una de las partes. Un craso error si lo que queremos es que buscamos es que las dos partes obtengan beneficios.
Olvidarse de la concepción de acuerdo para establecer una reglas unilateralmente son el primer fallo que debemos evitar. Ya sea por parte del cliente o del proveedor tecnológico, lo importante es comenzar a dialogar para llegar a unos términos en común, reflejados en el SLA.
Marabunta de SLAs
Comenzar con un servicio, después añadir uno nuevo y quitar ciertos aspectos del anterior es el día a día en la relación cliente-proveedor TI. Unos cambios donde es común que se creen diferentes SLA para reglar todo.
Sin embargo, tiene mucho más sentido aprovechar un único eje central desde el que variar los términos que sean necesarios. De esta forma, será mucho más sencillo volver sobre esa documentación para revisar o recuperar ciertos puntos.
No comprender al proveedor
Los clientes son exigentes y así debe ser para que el proveedor TI pueda dar el máximo. Sin embargo, en muchas ocasiones esas exisgencias no son realistas y se llegan a firmar SLA en los que de base se sabe que no se podrán cumplir por diferentes motivos: plazos, nivel de servicio exigido…
Firmando este tipo de acuerdos, como proveedor, conseguimos quedarnos muy lejos de las expectativas creadas por el cliente y por ende, ofrer una imagen negativa de nuestro servicio.
SLA aislado
A medida que las propuestas tecnológicas son más integrales, también lo deberían de ser los SLA. Sin embargo, en muchas ocasiones nos encontramos con documentos donde solo se atiende a un servicio prestado sin poner en contexto con el entorno en el que trabaja la empresa.
Así, lo más útil tanto para el proveedor como el cliente es evaluar la compañía en su conjunto, tecnológicamente hablando. Estableceremos así unos parámetros que permitan no crear un SLA ajeno a su contexto.
Cláusulas poco claras
De poco sirve un documento donde no se establezcan los requisitos concretos para la ejecución de un servicio. Plazos, formato, equipo involucrado y todo lo que haga falta para que tanto el cliente como el proveedor sepan cómo se va a desarrollar ese servicio.
Tiempos mal calculados
Una cosa es lo que quiere el cliente que tardemos en ofrecer un servicio y otra muy diferente, lo que tardaremos en realidad. Y es justo en este punto donde no debemos dejarnos llevar por lo debería ser sino por lo que es. Todo ello debe quedar bien reflejado en el documento contractual.
Marcar plazos reales sabiendo hasta dónde podemos llegar, nos podrá traer algún disgusto perdiendo algún cliente, pero a la larga será nuestra mejor estrategia de marketing.
Métricas mal formuladas
No siempre es fácil establecer ciertas métricas en los SLA. Ya sea porque no tenemos los datos adecuados, no están claros los objetivos o directamente no sabemos cómo medirlo, errar a la hora de establecer el ciclo del servicio, la calidad o el proceso es de lo más habitual.
Así, debemos comenzar por establecer los métricas adecuadas para cada tipo de servicio. Un análisis que nos permitirá dotar a los acuerdos de mayor fiabilidad y confianza.
En cloud no importa las SLA
Pensar que en el cloud todo está claro o es más sencillo y que no es necesario un SLA es una circunstancia muy habitual.
Sin embargo, lejos de ser verdad, es justamente lo contrario. Una vez que nos introducimos en un servicio cloud es necesario dejar claros muchos términos para evitar males mayores; quién será el propietario de los datos, qué pasará si no se llegan a los términos contratados o cómo resolveremos ciertas incidencias de servicio.
Obviar la seguridad
Aunque no sea el foco central del acuerdo, lo cierto es que a día de hoy la seguridad debe ser un área transversal en cualquier propuesta tecnológica. Es por ello que no debemos olvidar establecer un proceso de protección de la aplicación o desarrollo que estemos acordando, así como una vía de mitigación ante cualquier imprevisto o amenaza.
SLA, el mediador de conflictos
Recurrir a este tipo de acuerdos para clarificar algún término del contrato es una práctica habitual y muy sana, pero no puede ser el argumento definitivo para todo tipo de problemas.
Ciertos conflictos requieren de más «mano izquierda» en la que tenemos que ser empáticos y contextualizar para tomar una decisión. Y es que hay muchas situaciones que se escapan de los SLA y pueden ser perfectamente viables para que la relación con el cliente siga siendo exitosa.
Enfocarnos en las multas
Unido al punto anterior, debemos tener en cuenta que las multas establecidas en los SLA deben ser tomadas en situaciones muy extremas, cuando el resto de vías han fracasado.
Imagen | Romain Dancre
