Llegamos a ustedes gracias a:



Reportajes y análisis

Outsourcing: Cómo crear una hoja de ruta de la transformación

[03/08/2009] La mayoría de los líderes de las tecnologías de la información ingresan a las relaciones de outsourcing con un entendimiento razonable sobre donde les gustaría que sus proveedores de servicios TI los lleven, algún punto en el futuro en donde el estado de las TI haya ido mejorando, ahorrando dinero, incrementando la eficiencia o implementando nuevos sistemas empresariales.

Pero ¿tienen una idea clara de cómo realmente llegar ahí? No mucha.
El problema con esa estrategia es que es igual a salir de viaje a un gran destino sin un mapa o direcciones, señala Shawn Fields, consultor de la firma de consultaría en outsourcing Alsbridge. Y probablemente lo deje a uno con esa sensación de pérdida y frustración.
Los clientes de outsourcing necesitan especificar no solo a dónde van -queremos una reducción de costos de 20% en cinco años, por ejemplo- sino también cómo van a llegar ahí. Una forma de hacerlo es crear una hoja de ruta de transformación: un plan definitivo que especifique la forma en que el proveedor proporcionará esas contractualmente obligadas mejoras.
Es fácil para un proveedor decir que van a reducir el gasto en contratos en 20% en cinco años, pero todo se hace real cuando el cliente pregunta ¿cómo?, sostiene Fields. Ese due dilligence extra (el 'cómo') proporciona el mecanismo para que el cliente verifique que las mejoras comprometidas en el costo son o no son logrables.
Una hoja de ruta de transformación debería consistir en un conjunto de proyectos a los que se ha priorizado en base a su importancia así como por la pertinencia de su implementación, aconseja Fields.
Cada proyecto transicional del total de la transformación debería incluir un conjunto específico de informaciones. Por ejemplo, si la hoja de ruta de la transformación total requiere la mejora de la mesa de ayuda de una organización, un proyecto transicional podría ser cambiar el proceso de reestablecimiento de contraseñas, lo cual podría verse algo así:
Descripción/Objetivo: Una breve descripción del proyecto (La introducción de una herramienta automatizada de reestablecimiento de contraseñas)
Alcance: El alcance esperado del proyecto (Una mesa de ayuda TI)
Inversión: Un estimado no vinculante de lo que podría ser la inversión esperada y quién es el responsable de realizar la inversión (Los costos de implementación proyectados del sistema de reestablecimiento de contraseñas son de 300 mil dólares. Los costos se compartirán entre el proveedor y el cliente.)
Beneficios/Ahorros: Los beneficios esperados de implementar el proyecto: generalmente expresados en términos de ROI o productividad (la implementación de la herramienta de reestablecimiento de contraseñas reducirá las llamadas por este concepto a la Mesa de Ayuda en un 50% anual. Con 50 mil llamadas para reestablecimiento de contraseñas al año y a 20 dólares por llamada, los ahorros esperados en costos anuales son de 625 mil dólares. El ROI se logra aproximadamente en seis meses.)
Impacto en el usuario: El impacto esperado en la comunidad de usuarios finales (el tiempo promedio actual en la Mesa de Ayuda es de 45 segundos. Los usuarios se beneficiarán por poder reestablecer sus contraseñas de acuerdo a su conveniencia sin tener que esperar para ello, lo cual implica un correspondiente incremento en la satisfacción del consumidor).
Dependencias: Cualquier dependencia que podría afectar el proyecto (para que el cliente logre un ROI más alto, el cliente debe aceptar la plataforma actual de contraseñas del proveedor. La seguridad corporativa del cliente también debe aprobar la plataforma de reestablecimiento de contraseñas, las políticas y procedimientos del vendor).
Tiempo/Enfoque: El tiempo de implementación proyectado, y cualquier detalle específico relacionado al enfoque del proyecto (el proyecto tomará 90 días y comenzará en el primer trimestre del 2010. Se seguirá la metodología de proyecto estándar del proveedor).
Luego, cada proyecto puede ser categorizado en uno de los tres tipos de proyecto:
Categoría A: El cliente/proveedor tiene suficiente información para comenzar el proyecto, crear el plan del proyecto, definir los requerimientos de inversión y estimar los ahorros.
Categoría B: El cliente y el proveedor creen que el proyecto podría tener un efecto positivo pero carecen de la suficiente información para crear el plan del proyecto, los requerimientos de inversión o los estimados de ahorro.
Categoría C: Se espera que la idea, visión o innovación van a ser beneficiosas pero deberán ser evaluadas en forma conjunta en el largo plazo.
Aunque algunos proyectos, particularmente aquellos que caen dentro de la última categoría, podrían no estar completamente definidos, la información incluida como parte de la hoja de ruta de la transformación, debería ser lo suficientemente descriptiva como para permitir a los clientes y miembros del equipo de proveedores evaluarlos y priorizarlos de forma efectiva en base a las necesidades del negocio y el presupuesto disponible.
El primer año de una hoja de ruta de transformación podría incluso ser incorporado en el contrato inicial, señala Fields, junto con un lenguaje que comprometa a ambas partes a una revisión anual de la hoja de ruta y de los mecanismos de financiamiento para revisarla. Si no se dispone de la suficiente información para incluir un plan para el primer año en los papeles firmados, los clientes de outsourcing deberían incluir un lenguaje que estipule una metodología para, y la obligación de crear, una hoja de ruta de la transformación en el primer año del contrato.
La hoja de ruta es de beneficio mutuo, señala Fields. Toma la vaga noción de mejoras continuas y las coloca en términos concretos. Adicionalmente, ayuda a establecer las expectativas en ambos lados sobre los cambios que se vienen y cuándo se espera que ocurran.
El único peligro es profundizar mucho en los detalles en las etapas tempranas de cada proyecto.
Si eso sucede, tanto el cliente como el proveedor pierden valioso tiempo discutiendo sobre las personas, procesos y herramientas de cada uno de los proyectos, más que en el beneficio de ese proyecto para el total de la estrategia de negocios de la empresa, señala Fields. Ambas partes tienen que aprender a caminar sobre la fina línea que divide el detalle excesivo en cada proyecto de la ausencia del mismo, siendo la cantidad correcta la que permite que cada parte tome una decisión estratégica basada en los méritos del proyecto individual, y su beneficio para el negocio.
Stephanie Overby, CIO