15 errores de SLA que los líderes de TI siguen cometiendo

0
10

Ser diligente con los acuerdos de nivel de servicio (SLA, por sus siglas en inglés) siempre ha sido importante para las organizaciones de TI que trabajan con proveedores de nube y de servicios de TI. Pero comprender cómo negociar, estructurar, gestionar, medir e informar sobre estas métricas es más crucial que nunca.

«Dada la transformación digital y los recortes de gastos en TI y las líneas de negocio, es fundamental confirmar por adelantado los resultados esperados en relación con el gasto en TI; de lo contrario, los líderes de TI se desilusionarán y decepcionarán con los resultados”, señala Dave Jordan, vicepresidente y jefe global de consultoría e integración de servicios en Tata Consultancy Services.

La pandemia de COVID-19 también ha aumentado los riesgos de la gestión de los SLA. «Los SLA refuerzan los niveles de desempeño acordados que se necesitan para que los clientes continúen recibiendo los servicios para ejecutar sus operaciones independientemente de la ubicación del cliente o el personal del proveedor, el impacto de la pandemia o la capacidad de los clientes del cliente de comprar y/o interactuar”, anota Clay Calhoun, socio de la compañía de asesoría e investigación tecnológica ISG.

Es más, dado que muchas funciones de TI continúan ejecutándose de manera dispersa, los SLA se han convertido en una medida principal de desempeño. «Esta nueva realidad inducida por el COVID aumenta la dependencia de una organización de datos confiables para identificar qué tan bien (o mal) se están desempeñando las operaciones”, comenta David Borowski, director de la consultora de negocios y tecnología West Monroe.

Muchas veces, los SLA han sido un punto de conflicto -no solo entre proveedores y clientes, sino dentro de las propias organizaciones también. «A menudo se reduce a que los líderes de la TI odian leer los acuerdos legales, mientras que los equipos legales y de adquisiciones se centran en el riesgo comercial y financiero, en lugar de las dependencias de TI o el impacto de las interrupciones del sistema en la prestación de servicios”, explica Joel Martin, vicepresidente de investigación de estrategias de nube en HFS Research. Y a medida que las empresas trasladan más soluciones a la nube, es importante comprender los niveles de servicio acordados para desarrollar relaciones confiables.

Además, el desarrollo y la gestión de los SLA ha evolucionado significativamente en los últimos años, con miras a impulsar el valor empresarial. «Los destinatarios del servicio se han vuelto mucho más sofisticados en la forma en que gestionan los SLA”, asegura Marc Tanowitz, director gerente de West Monroe, y agrega que «buscan resultados de extremo a extremo que impulsen el éxito empresarial y reconozcan que el verdadero valor de los SLA es promover los conocimientos y el rendimiento del negocio -en lugar de reducir el costo del servicio mediante la captación de créditos de desempeño”.

No obstante, siguen existiendo algunos errores comunes de SLA, y potencialmente costosos, que pueden cometer los líderes de TI. A continuación, se describen algunos de los más perjudiciales para la organización de TI y la empresa en general.

No acordar ni establecer los SLA por adelantado
«A menudo, ambas partes asumen que las expectativas son claras y se comparten mutuamente, pero puede que no sea el caso si no se detallan”, señala Robert Castles, director y CTO de PMG, fabricante de software de organización de procesos. «Es muy preferible para ambas partes negociar los términos del SLA antes de que exista un problema”.

Uno de los errores más grandes que puede cometer un líder de TI es ignorar la «A” de «acuerdo” en SLA, agrega Wendy M. Pfeiffer, CIO de Nutanix.

«Un acuerdo no es una declaración unilateral de las capacidades de TI, ni una demanda unilateral de requisitos empresariales”, asegura. «Un acuerdo implica crear un entendimiento compartido de la calidad y la prestación de servicios deseadas, calcular los costos relacionados con las expectativas y luego acordar los resultados de la inversión”.

Demasiados SLA
Una sobreabundancia de SLA puede provocar un incumplimiento del servicio acordado, lo que resulta en un crédito de servicio que prácticamente no tiene sentido, indica Mike Fuller, director de The Hackett Group.

Por ejemplo, si un cliente tiene 65 SLAs y el monto en riesgo es solo el 10% de las tarifas facturadas mensualmente, el incumplimiento de uno da como resultado un crédito de servicio que es 1/65 del 10%. «Definir demasiados SLAs diluye el impacto de cada uno, y dificulta que los proveedores sepan cuáles son los más necesarios para priorizarlos y gestionarlos activamente”, señala Borowski de West Monroe.

No entender el punto de vista del proveedor
«A menudo, un SLA se centra en el tiempo de actividad proporcionado por un tercero; sin embargo, el líder de TI o de negocios puede preocuparse más por el rendimiento de la aplicación o el servicio que se proporciona”, anota Martin de HFS Research.

Cuando se trata de un SLA para copias de seguridad o recuperación ante desastres, por ejemplo, una empresa debe considerar documentar de manera clara el objetivo de punto de recuperación (RPO) / objetivo de tiempo de recuperación (RTO) en su acuerdo. «Lo mismo podría decirse de las torres de TI que se están trasladando hacia un modelo nativo de la nube”, explica Martin. «Estos incluyen mesa de servicio, gestión de servicios, gestión de infraestructura y más”.

SLAs en silos
Los SLAs que se enfocan demasiado en la infraestructura individual y el tiempo de actividad de los componentes de la aplicación son problemáticos, señala Fuller de The Hackett Group, y Jordan de TCS está de acuerdo.

«Cada vez más organizaciones están solicitando el establecimiento de integración de servicios con resultados empresariales cuando se trata de los SLA. Luego, en función de esos resultados, se obtienen métricas de rendimiento de TI relevantes, y queda claro quién está encargado de respaldar cada resultado empresarial en el ecosistema”, señala.

Con un mayor enfoque en los resultados empresariales, los SLA deberían ser más holísticos y consolidados, y abordar categorías generales o resultados más amplios como si un usuario empresarial puede o no completar una transacción. Tanowitz de West Monroe recomienda adoptar una perspectiva de cartera para identificar áreas donde los procesos o el alcance del proveedor se puede optimizar para impulsar mejoras.

No contar con cláusulas de escape
Estas son imprescindibles para tratar un rendimiento deficiente continuo o para los objetivos incumplidos.

«Si no hay puntos claros en el contrato, honestamente, el SLA no vale mucho”, anota Martin de HFS Research. «Estos deben ser umbrales claramente establecidos que definan un número ‘x’ de veces en un período determinado, y deben revisarse con el proveedor regularmente”.

Falta de claridad en los cálculos de un SLA
«He visto casos en los que el cliente recibe el informe del SLA del proveedor y está escrito en el contrato que solo la documentación del SLA del proveedor se considera objetiva y precisa”, comenta Martin. «Trabajar de esa manera debería ser un motivo obvio de preocupación para cualquier líder astuto”.

No tener capacidad para medir
No es raro que las organizaciones de TI establezcan una métrica de desempeño sin contar con los datos adecuados para sustentar el objetivo, sostiene Calhoun de ISG. Pero no tener una forma de calcular realmente los SLAs (herramientas y procesos claros, comprensibles y fáciles de usar) suele resultar en una gestión de los SLAs demasiado ardua o ignorada, añade Fuller de The Hackett Group.

«Un cambio que estamos comenzando a ver es un mayor uso de herramientas de descubrimiento de datos y procesos para medir los SLA”, señala Borowski de West Monroe. «Si bien aún no predominan, estas herramientas representan una oportunidad para identificar las métricas más significativas y medir objetivamente el desempeño (por ejemplo, tiempo de ciclo, calidad, cumplimiento). Cuando son proporcionadas por el cliente, también elimina la dependencia de las herramientas del proveedor como única fuente de la verdad para los datos de rendimiento”.

Falta de representación de TI en acuerdos shadow
Cuando los contratos empresariales para sus propios servicios tecnológicos o líderes de TI permiten que los directores de niveles inferiores firmen acuerdos para un número creciente de servicios, la empresa se ve más expuesta al riesgo solo en términos de SLAs sino también de remediación, indica Martin de HFS Research.

Considerar los SLAs como un ejercicio de una sola vez
«Lograr los resultados empresariales adecuados mediante los SLAs e integración de servicios es como una maratón. Es una parte activa de la competencia central de TI”, comenta Jordan de TCS. «Los líderes de TI deben tener interiorizada la definición de su función y la comprensión del dinero que gastan en relación con los resultados o beneficios empresariales”. Las organizaciones de TI deben establecer competencias en torno a la gestión de los SLAs para la realización del valor.

Suponer que los SLAs no tienen importancia en la nube
No comprender cómo los SLA se entrelazan con los servicios y aplicaciones en la nube es un problema. Los proveedores de servicios de red, por ejemplo, son responsables de la transferencia de datos hasta el momento exacto en que el tráfico se transfiere a un proveedor de nube pública. «Sin embargo, la mayoría de los proveedores no ofrecen ningún SLA de la nube comprometiéndose con un alto nivel de rendimiento”, anota Terry Traina, CTO de Masergy, una red definida por software y una plataforma en la nube. «Cada servicio es una oportunidad para un SLA, y el contrato debe cubrir todo el terreno”.

No abordar la seguridad
Piense en los compromisos continuos que el proveedor asume en torno a la recuperación ante desastres, el cifrado, la respuesta a incidentes o las evaluaciones de vulnerabilidad. «Cuando sea posible, los clientes deben presionar a los proveedores de servicios para que aborden la seguridad en sus SLAs”, aconseja Alain Pannetrat, investigador senior y gerente de producto de Cloud Security Alliance.

Usar los SLAs como herramientas de resolución de conflictos

Confiar en el lenguaje contractual para resolver un problema antes de profundizar es un error. «El primer paso en cualquier conflicto debería ser comprender el impacto y tratar de abordar el daño en lugar de centrarse en quién tuvo la culpa contractualmente y qué sanción debería imponerse”, explica Castles de PMG.

Dustin Hilliard, CTO de eSentire, agrega: «Es más importante priorizar la relación con el cliente y el resultado, que litigar malentendidos técnicos u operativos que puedan haber iniciado el conflicto”.

Centrarse en las sanciones
Considerar los SLA como una fuente de ingresos en lugar de una fuente de información para impulsar la mejora del rendimiento genera controversias en lugar de beneficios empresariales. «Los clientes no deben centrarse en recuperar sus pérdidas”, asegura Traina de Masergy. Después de una caída de la red, el daño suele estar hecho. En cambio, los líderes de TI deberían centrarse en los SLAs que le exigen al proveedor responsabilizarse por los más altos niveles de servicio desde el inicio.

Establecer objetivos de alto rendimiento de manera innecesaria, y a menudo poco realista, aumenta los costos del proveedor sin necesariamente proporcionar un beneficio empresarial, señala Borowski de West Monroe. Además, los proveedores se dan cuenta de que las recuperaciones de ingresos de los SLAs son unilaterales, indica Ali Yasin, director gerente del grupo de tecnología de servicios financieros de Protiviti. «Por lo tanto, si existe una recuperación de ingresos debido a incumplimientos, en los SLAs el rendimiento excesivo también debería proporcionar incentivos de ingresos. Estos SLAs de doble sentido son cada vez más frecuentes”.

No asumir la responsabilidad
Las organizaciones de TI tienen un rol que desempeñar en la prestación de servicios. Y lo reconocen aquellos que construyen las relaciones más productivas con sus socios de servicio. Es un error no «reconocer el rol del destinatario del servicio a la hora de permitir que los proveedores de servicios se desempeñen como se espera”, anota Tanowitz de West Monroe. Los prerrequisitos del SLA pueden establecer que un determinado umbral no se mantendrá si un proveedor no recibe la información necesaria en su totalidad para realizar la función de la organización solicitante.

«Por lo tanto, una organización debe considerar si la madurez de sus procesos internos permite el tipo de SLA que esperan de un proveedor”, explica Yasin. «Es posible que se establezcan los SLAs, pero nunca se activen porque no se cumplen los prerrequisitos del proveedor debido a la inmadurez de la organización”.

SLAs estáticos
Es fundamental incluir en los contratos de servicios de TI la posibilidad de actualizar o aumentar automáticamente los objetivos de un SLA en función de las tendencias históricas, advierte Fuller. Por ejemplo, muchas organizaciones de TI otorgaron alivio de SLA a sus socios al principio de la pandemia. «Así como el entorno operativo remoto se ha estabilizado y se ha convertido en la ‘nueva normalidad’, es importante revisar si dicho alivio sigue siendo necesario y también revisar las métricas y prioridades del SLA para garantizar que se mantengan alineadas con las necesidades empresariales”, señala Tanowitz de West Monroe.

Sriramkumar Kumaresan, jefe de mercados de líneas de servicio en Mindtree, aboga por acuerdos dinámicos de nivel de procesos empresariales (BPLA, por sus siglas en inglés) que puedan seguir el ritmo de la velocidad del cambio en los negocios y la tecnología. «Los BPLAs dinámicos e integrales permiten a las empresas asignar TI a los resultados empresariales”.

Los líderes de TI también deben tener en cuenta el aumento de la eficiencia y la rigidez de los proveedores. «Es importante reducir progresivamente los indicadores de riesgo claves de un SLA a lo largo del tiempo”, señala Yasin. «Esto incentiva a los proveedores a mejorar constantemente y seguir participando en la relación”.

Además, los SLAs integrales deben incluir la revisión continua de la documentación para permitir que la organización de TI acceda a los procesos críticos en caso quiera cambiar de proveedor en el futuro.

Stephanie Overby CIO.com