SLAs orientados a requerimientos de negocio. Parte 1. Perspectiva del cliente.

Un Service Level Agreement (SLA), o Acuerdo de Nivel de Servicio, es la formalización contractual de un requerimiento de servicio entre dos partes (un solicitante y un proveedor). Su principal ocurrencia se da en contextos de tercerización de procesos, o business process outsourcing (BPO).

Sin embargo, los SLA no sólo se dan en escenarios de outsourcing. Sucede que también son una manera efectiva de formalizar la relación y responsabilidades entre áreas internas de una organización. Desde el punto de vista de los procesos de negocio, todos somos clientes y proveedores de distintas áreas, personas y stakeholders dentro de nuestra organización.

En este artículo, delinearemos de manera general la estrategia de definición y la pauta de negociación para el establecimiento de SLAs desde la perspectiva del cliente, sin importar si hablamos de escenarios BPO o de negociación interna, puesto que al final la premisa es la misma, minimizar el costo, al tiempo que maximizamos el retorno de la inversión.

El SLA como Contrato
Los SLA han existido desde siempre, y su representación más común es el contrato legal, en el cual se especifican derechos y obligaciones para dos o más partes que se comprometen mutuamente para conseguir un objetivo común. En nuestro caso estamos hablando de un contrato civil. Este contrato generalmente es definido por un área legal, que conoce la legislación en el contexto del contrato civil, así como la regulación interna de la compañía, pero que puede —y muchas veces es el caso— ignorar totalmente los requerimientos de negocio y tecnológicos que dan origen al acuerdo. Lo ideal para nosotros clientes, sería el contar con abogados que además de dominar la legislación pertinente, conocieran a fondo nuestro negocio y su estrategia, así como las necesidades específicas que dan pie al servicio contratado.

Otra representación un poco menos común en las empresas mexicanas, pero no menos importante, es el acuerdo administrativo de servicios, mismo que no tiene implicaciones legales ni coercibilidad por parte de las autoridades gubernamentales, y restringe su jurisdicción al interior de la compañía. Este acuerdo administrativo generalmente es concertado entre diferentes ejecutivos de una misma empresa o grupo empresarial que detectan un área de oportunidad para minimizar costos o aumentar la productividad, al delegar actividades a otros con una mayor capacidad técnica, económica o política para solventar los requerimientos de negocio dentro de la misma empresa. Los acuerdos formales de este tipo no son aún muy comunes en México debido a que son pocas las empresas con el tamaño, así como la madurez necesaria para darse cuenta de que cada área tiene oportunidades y ventajas especiales para la realización de ciertas actividades que inicialmente eran llevadas a cabo en otras partes de la empresa.

Identificar el Servicio
En general, los servicios que subcontratamos con terceros no deben ser parte de nuestro negocio central, o core business. Esto es, nuestro negocio puede depender del servicio requerido, sin embargo, no constituye el producto o servicio final que nosotros ofrecemos a nuestros propios clientes.

La regla de dedo es la siguiente: toda actividad que no figure en la misión de nuestra organización o área productiva dentro de la misma, es un servicio que podemos delegar a otros. Sin embargo, regirnos por esta única regla es simplificar de más las cosas, dado que no todas las organizaciones o áreas internas cuentan con una misión totalmente definida. La mejor forma de complementar esta regla es preguntarse: ¿forma el proceso de negocio X parte de la estrategia central de mi organización? Si la respuesta es un rotundo NO, significa que podemos tercerizar el proceso. Si la respuesta es un NO a medias, debemos de analizarlo con mayor profundidad antes de embarcarnos en una iniciativa de tercerización. Si la respuesta es un SÍ, entonces mejor convendrá el rascarnos con nuestras propias uñas, pues no queremos que el proveedor se convierta en nuestro competidor, o arriesgarnos a perder el control sobre lo que ofrecemos a nuestros clientes como producto o servicio final.

Definir Métricas Orientadas al Negocio
Una vez que hemos identificado el servicio que requerimos, así como a los proveedores que se especializan en él, procedemos a identificar las variables de negocio que se ven afectadas por este servicio; dígase costos, productividad, time to market, calidad, ventaja tecnológica, etcétera. Estas variables deberán ser cuantificadas y ponderadas para diversos escenarios de nivel de servicio dentro del contexto del proceso. Obviamente, para definir los diferentes escenarios, debemos conocer las medidas cuantitativas y cualitativas del proceso, así como las entradas y las salidas del mismo. Es de especial importancia este paso dado que, como expuse en un artículo anterior, “lo que no se puede medir, no se puede controlar” (véase “BPM Aplicado al Desarrollo de Software”, SG Año 1 No. 4).

En las diferentes disciplinas de TI, generalmente nos encontramos con muchas métricas que pertenecen a un estricto contexto técnico y que no nos dicen nada acerca del costo real o del impacto productivo de las actividades respecto al todo que constituye el negocio. Siempre que sea posible (y siempre lo es), nuestro objetivo será obtener métricas y variables que nos digan algo acerca del valor para el negocio que tienen nuestros procesos. Si somos parte del área de TI de una compañía de servicios y queremos tercerizar el soporte técnico, midamos el impacto en horas muertas resultante de una infraestructura improductiva, sin preocuparnos demasiado por medir el número de estaciones de trabajo o nodos de red. Si somos parte del equipo de desarrollo de aplicaciones de una institución financiera, midamos el time to market de algún producto financiero respecto al desarrollo de las aplicaciones de software que habilitan su operación, así como el impacto en este tiempo, resultante de una fuerte rotación de personal o la capacidad de staffing de algún proveedor, en vez de simplemente estimar el número de horas necesarias para desarrollar. Una vez que hemos obtenido estas variables, traduzcámoslas siempre a dinero, puesto que al final, es el dinero el que define el retorno de inversión. Ya que hemos identificado las variables de negocio, para cada una debemos definir niveles de servicio óptimos, mínimos y deficientes. Estos niveles serán cuantificados en métricas que nos darán el detalle necesario para saber en qué momento los niveles de servicio son inaceptables.

Empatando las métricas técnicas con las variables de negocio y su impacto en dinero, tendremos todo lo que necesitamos para definir un buen SLA que nos dé un amplio margen de maniobra en la negociación para obtener los resultados que esperamos, mitigando el riesgo de que el proveedor maneje ventajosamente su propuesta.

La clave para la definición de SLAs orientados a requerimientos de negocio consiste en saber cómo integrar los impactos al negocio, los dineros, y las métricas técnicas del proceso. Hacer esto, por muy difícil que parezca, es muy simple si lo visualizamos de esta manera:
• Las variables de negocio son el requerimiento para el proveedor.
• El dinero es la línea base para determinar las penalizaciones por incumplimiento.
• Las métricas técnicas son nuestra manera interna (y secreta por cierto), de evaluar a nuestro proveedor en su propuesta y, posteriormente, en la prestación concreta del servicio.

Evaluar Proveedores
Una vez identificadas las métricas y alineadas a los requerimientos de negocio, podemos acercarnos a los proveedores para evaluar de manera concreta sus propuestas. Generalmente, los proveedores buscarán convencernos de manejar métricas técnicas como requerimientos, además de manejar contratos a precio variable. Los proveedores están muy acostumbrados a esto, y es de especial importancia que nos mantengamos firmes en nuestra postura respecto al manejo del acuerdo, aún y cuando el proveedor nos ofrezca algo que parece una verdadera ganga; por ejemplo, con un precio bajísimo por hora-hombre por un número de horas determinado, puesto que lo que realmente intentará hacer el proveedor con todo esto será minimizar su nivel de riesgo, transfiriéndolo a nosotros. Este tipo de esquemas en general no agregan valor a una relación de negocios, dado que no se comparte equitativamente el riesgo entre el cliente y el proveedor.

El contrato que especifica un precio bajísimo por hora-hombre por un número de horas determinado es un caso típico de las tácticas de los proveedores para ganar una venta sin arriesgar demasiado, puesto que aunque financieramente estamos hablando de un precio fijo, realmente hablamos de un precio variable al darnos cuenta de que si el proveedor no tiene la capacidad para cumplir en tiempo, entonces tendremos que pagarle más para que termine su trabajo. Para un proveedor es fácil comprometerse, por ejemplo, a que el desarrollo de un nuevo sistema le llevará seis meses, y después facturarnos sus servicios por hora-hombre. De esta manera, el no terminar en tiempo sólo le puede afectar reportándole más ingresos. Aún en el caso de que exista una cláusula en el contrato que especifique que si tarda más del tiempo convenido, no se le pagará o se le cobrará una penalización, la práctica común de los proveedores suele ser el “estimar para vender”, sin estar seguros de poder cumplir.

Es por esto que definiremos las penalizaciones por incumplimiento a partir del impacto directo que esto tiene sobre nuestro negocio, y no sobre lo que el proveedor considera conveniente de acuerdo al precio del servicio contratado. Si el servicio consiste en proveer un alfiler para sostener los hilos de nuestro negocio cada cinco horas, penalizaremos al proveedor con la pérdida resultante de ser improductivos en nuestro negocio por cinco horas, y no con el costo de un alfiler. Lo que intentamos hacer con esto es minimizar nuestro nivel de riesgo al contratar un seguro contra la falla en el servicio, no llevar a la quiebra al proveedor, y así justamente hay que hacérselo entender a él.

El proveedor que sea capaz de entregar una propuesta coherente al requerimiento de negocio, en la cual se especifique la manera de obtener los resultados que especificamos, en general está hablando el mismo idioma que nosotros. Al comparar su propuesta técnica con nuestras métricas técnicas, podremos darnos cuenta de si su solución es exageradamente optimista respecto al desempeño que nosotros hemos identificado para el proceso, o si realmente está planteando darnos los resultados de negocio que pedimos con un desempeño técnico inferior a lo que nosotros sabemos que es posible. En todo caso, lo que esto nos permite es identificar el nivel de madurez de nuestro proveedor, su conocimiento del negocio, y por tanto, el nivel de riesgo al que nos exponemos al contratar con él.

Negociar y Establecer el Acuerdo
Al final, es poco probable que consigamos todos y cada uno de los puntos de nuestro requerimiento, así como es poco probable conseguir que el proveedor firme con las penalizaciones exactas que hemos definido. Aquí es donde entra la labor de negociación, la cual es tal vez la parte más importante de firma de un SLA, y donde se afinarán esas asperezas que definitivamente serán motivo de conflicto. Recordemos siempre que un SLA es un balance muy delicado entre lo que queremos, lo que podemos conseguir y lo que estamos dispuestos a pagar. Mi mejor consejo respecto a esto es que siempre tengamos en mente una visión Ganar-Ganar, en la que las fuerzas económicas y los riesgos se equilibren de la mejor manera posible entre los participantes. Si nuestro proveedor va a la quiebra por nuestra culpa, o por la suya propia, será difícil conseguir que otro proveedor tome su lugar debido a que se nos identificará como una cuenta de alto riesgo. Es por esto que conviene no exagerar en lo que pedimos, puesto que siempre habrá alguien dispuesto a vendernos el paraíso e ir a la quiebra, desprestigiando nuestra imagen al mismo tiempo. No creo tener que advertirles respecto a los peligros de dejarse arrastrar por cualquier propuesta de un proveedor, puesto que asumo que ustedes saben qué es lo que quieren, cuándo lo quieren y cuánto quieren que les cueste.

Cabe enfatizar que nuestro trabajo como clientes de un servicio de TI, no es delimitar la solución técnica al problema, sino especificar el requerimiento de negocio y evaluar la capacidad de los proveedores. El trabajo del proveedor es cuantificar su propio riesgo y madurez de procesos, ofrecer una solución dentro de los límites de nuestros requerimientos, y asegurarse de que esta solución sea correctamente implementada. Si el proveedor es digno de ser contratado, será únicamente porque es capaz de cumplirnos, y esto gracias a que ha optimizado sus procesos hasta ese punto dulce que nosotros no podremos conseguir, dado que nuestro core business es otro, mientras que el de él... es fácil, es hacer lo que hace mejor que nosotros.

Con esto concluimos la primera parte de este artículo, donde hablamos sobre cómo se debe establecer un SLA desde la perspectiva del cliente. En la próxima ocasión nos enfocaremos en la perspectiva del proveedor, y lo que debe hacer para lograr un acuerdo sano y exitoso.

En este ejemplo podemos ver cómo se especifican tres requerimientos de negocio para la contratación de un servicio de recuperación de datos. Estos requerimientos cumplen con definir la necesidad de negocio, que es mantener a la empresa productiva independientemente de la situación en la que se presente una pérdida de datos. Además, podemos cuantificar directamente el costo de que no se cumpla con el requerimiento: si la pérdida de datos afecta a quince personas y se recupera el servicio en cuatro minutos, se habrá perdido una hora-hombre en producción. Este es un ejemplo concreto y poco común de una buena utilización de las horas-hombre para la definición de requerimientos. Al final, si la empresa consigue que un proveedor acepte cumplir con el requerimiento, y establece penalizaciones de acuerdo al costo en pérdida de negocio que se plasma en el requerimiento, estará asegurando niveles operacionales y de servicio, y no solamente un número de índole técnica que sólo tenga significado para un puñado de trabajadores en la organización.

Acerca del autor
Axel Nissim es Director de entrempresarios.com, un portal y startup de Internet con la meta de desarrollar herramientas colaborativas basadas en el Social Networking. Axel es Licenciado en Sistemas Computacionales Administrativos por la Universidad de las Américas, y ha laborado como consultor en algoritmos para seguridad e inteligencia artificial. Actualmente trabaja de manera estratégica en la definición de metodologías y herramientas de workflow en megaproyectos basadas en redes sociales, planeando sacar al mercado el producto resultante.