Llegamos a ustedes gracias a:



Reportajes y análisis

Utilizar los acuerdos de nivel de operación en multisourcing

[15/03/2013] Los acuerdos de nivel de operación (OLA, por sus siglas en inglés) no son precisamente nuevos en TI. A diferencia de los acuerdos de nivel de servicio (SLA) entre la organización de TI y su proveedor de servicios, el OLA establece cómo determinadas partes involucradas en el proceso de entrega de servicios de TI, van a interactuar entre sí con el fin de mantener el rendimiento.
"Al establecer OLAs entre estos grupos, la función de TI puede proporcionar el establecimiento de un servicio ininterrumpido a la empresa", señala Edward Hansen, socio de la firma de abogados Baker & McKenzie.
Hasta hace poco, los OLA eran más a menudo internos en una organización de TI o con un único proveedor grande de servicios, asegurando que los grupos dentro de la organización estén trabajando juntos para ofrecer servicios de TI. Pero con el aumento de multisourcing, los OLA están nuevamente en el centro de atención.
"En este contexto, un OLA se convierte en un registro de supuestos compartidos e interdependencias a nivel de procesos compartidos, así como la intersección entre cada una de las múltiples partes involucradas en la prestación de servicios", señala Les Druitt, director fundador de la consultora de outsourcing Sourcing Advisory Services. "Es donde el caucho resuelve la llanta y toca la pista en un outsourcing multi partes".
"Se ha vuelto cada vez más importante para el cliente final saber que las relaciones e interacciones entre las múltiples partes están bien conocidas, documentadas en un lenguaje claro y preciso, y se refleja en los acuerdos vinculantes que pueden ser aplicados -si es necesario-por el cliente", señala Robert Zahler, socio en el grupo de sourcing global de la firma de la ley Pillsbury.
Cómo utilizar OLA en una configuración de múltiples fuentes
El establecimiento de un OLA en un entorno de múltiples fuentes, sin embargo, es intrínsecamente más difícil que instituirlo dentro de una sola organización.
"Hay una comprensión limitada de este nuevo rol, qué nivel de exposición es suficiente, el papel que juegan en la validación de OLA tanto los precios y los supuestos de la solución, y de la facilitación de mejora continua", agrega Druitt. "La creación de un OLA a efectos de documentar y confirmar cómo las soluciones trabajarán en armonía, requiere un proceso de colaboración para llegar a un conjunto de documentos que todas las partes respeten y apoyen".
Aquí hay nueve recomendaciones de qué hacer y qué no hacer para el establecimiento de los OLA en un entorno de múltiples fuentes de TI.
1. Considere baches en el camino. "El establecimiento de un OLA requiere un proveedor de servicios que entienda claramente sus propios procesos, y [esté en] acuerdo armonioso con los proveedores pares sobre el papel que cada uno juega dentro de esos procesos", señala Druit. Los OLA para procesos maduros, como la gestión de incidencias, serán más fáciles de establecer que para otras áreas. "Puede ser una lucha cuando los niveles de madurez de los procesos difieren significativamente entre los proveedores", añade Druitt.
2. No permita que los proveedores de servicios secuestren el proceso. "A menudo, los proveedores de servicios son los más interesados en esos OLA, que son necesarios para soportar el desempeño de su entrega contra el SLA del cliente", señala Druitt.
Un proveedor puede no ser capaz de satisfacer un compromiso del SLA para la gestión de incidencias, a menos que otro proveedor se comprometa a ciertas tareas y lapsos de tiempo. "Los OLA son una herramienta poderosa porque documentan un proceso de gran alcance. Pero ese proceso no está hablando con su proveedor de servicios para ver cómo van a comportarse unos con otros", agrega Hansen.
"El proceso realmente de gran alcance incluye la discusión interna entre los grupos de TI y el negocio para determinar cómo debe proporcionarse el servicio en un esquema agnóstico a la fuente", agrega Hansen.
3. Haga los OLA antes que los RFP. "Los clientes a menudo caen en el proceso ejecutando primero múltiples contratos de outsourcing, y solo entonces reconocen la necesidad de coordinar e integrar las actividades a través de estos diversos contratos de outsourcing", señala Zahler. "El OLA no debe utilizarse después de los hechos para documentar las relaciones que se han desarrollado con el tiempo. Por el contrario, el OLA debe proporcionar la hoja de ruta de cómo esas relaciones deben establecerse en primera instancia".
Un OLA puede ser útil para ayudar a redactar una RPF de servicios, señala Hansen de Baker & McKenzie.
4. No tercerice la responsabilidad. Establecer los OLA entre los proveedores de servicios no lo exime de responsabilidad. "La organización del CIO debe ser responsable del servicio en todos los ámbitos", señala Hansen. "No hacer esto se traduce en acusaciones y en usuarios de negocios que se sienten a merced de los proveedores externos de servicios, independientemente de los OLA".
Es una buena idea establecer OLA internos primero, aconseja Hansen. "Esto no tiene nada que ver con lo difícil o fácil que usted enfrente con sus proveedores. Solo tiene que ver con asegurarse de que la organización de TI y de negocios se dé cuenta e internalice que el outsourcing no quiere decir que estén fuera del gancho".
5. Sea claro y conciso. Puede ser tentador pensar demasiado en el OLA y ensuciarlo con asuntos legales y jerga de TI. Resista. "Normalmente no hay razón para quedar demasiado empantanado en la formalidad", señala Hansen. "Lo más importante acerca de un OLA es que tienen que ser legible y comprensible tanto para los lectores de negocios como para los de tecnología".
6. No acepte OLA de negocios. Un proveedor de servicios puede empujar a un cliente a aceptar un OLA contra el rendimiento del usuario final, como exigir que una unidad de negocio dé los requisitos completos del proyecto al proveedor de servicios dentro de un plazo determinado. No estoy de acuerdo con ellos, informa Druitt.
"Mientras que la dependencia está ciertamente allí, el acuerdo subyacente no está ahí", señala Druitt. "La unidad de negocio es el cliente y no debe ser tratado como un socio en la prestación del servicio".
7. Incluya todas las interacciones fundamentales. "Los clientes a menudo no saben qué incluir en una OLA", señala Zahler. "Como mínimo, el OLA debería identificar los servicios específicos cubiertos por el OLA y especificar cómo serán manejadas las interacciones principales".
Las interacciones más importantes son la planificación del trabajo, la provisión de datos operativos, información y reportes; la integración de las actividades con la mesa de servicio; la coordinación de cambios, el manejo de los servicios multi-funcionales, y la gobernanza y la resolución de controversias.
También es importante que la Oficina de Asuntos Jurídicos expresamente indique que el cliente, y no una parte del OLA, es lo que los abogados llaman un "tercer beneficiario" del acuerdo. "Esto permite, pero no requiere, que el cliente haga cumplir el OLA en su propio nombre, si lo desea", señala Zahler.
8. No gerencie por OLA. Es un error "utilizar estas métricas adicionales que vienen desde el establecimiento del OLA como medio para gestionar la entrega de un modo completamente nuevo", señala Druitt. "Las medidas deben apoyar la prestación del servicio y está para que tengan con qué manejarse con proveedores. Solo intervenga cuando los proveedores fallen en cumplir con el rendimiento.
9. Haga un seguimiento de sus OLA. "Los OLA a menudo pueden ofrecer métricas que proporcionan una base para tomar buenas decisiones, si se les da seguimiento; lo que a menudo no se hace", señala Hansen. Estos indicadores son útiles no solo en la mejora de la prestación de servicios, sino que también pueden proporcionar una base sólida para las futuras decisiones de proveedores.
"Si tiene OLAs que están al día y se les hace seguimiento, y si se toma la decisión de externalizar, entonces documentar los SLA legacy es muy fácil, lo que hace que la discusión en torno a la transición y transformación sea mucho más fácil de hacer".
Stephanie Overby, CIO (EE.UU.)