Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo estructurar un proyecto tercerizado de TI

De forma menos riesgosa y con más potencia

[02/07/2015] En el 2015, los grandes contratos monolíticos de outsourcing son considerados proyectos empresariales de TI tanto negativos como enormes. Son vistos como largos, costosos y prácticamente condenados al fracaso. A medida que las organizaciones de TI han dividido sus tareas grandes en entregables más discretos, también han disuelto sus mega contratos de outsourcing con múltiples proveedores. Hoy, las perspectivas de tercerizar un proyecto importante de tecnología a un solo proveedor podría parecer una idea anticuada. Y los riesgos en un enfoque como ese abundan.

"Hay varias razones por las que un proveedor puede que no sea la mejor decisión para un proyecto de largo plazo, señala Andrew Alpert, director de optimización de negocios y consultoría de tercerización en Pace Harmon. "Primero, puede que haya aspectos de los proyectos que requieren el dominio de un expertise específico y de un conocimiento funcional, técnico o de cambio organizacional o específico a una industria, que no esté disponible por parte de un solo proveedor. En segundo lugar, los proveedores que tienen requerimientos fuertes de negocios y experiencia en diseño, puede que no sean la organización más efectiva y eficiente en desarrollo y prueba; o el mejor proveedor de desarrollo y pruebas puede que tenga equipos de equipos de gestión de cambio comparativamente débiles.

Además, quedarse con solo un proveedor de servicios de TI puede limitar la capacidad de un cliente para minimizar costos, asegurar una auditoría comercial y de rendimiento y mantener la calidad en los recursos.

Pero... a veces tener un solo proveedor es la única opción

Sin embargo, las organizaciones de TI aún deben asumir programas transformativos para la empresa. Y encargar ese trabajo fuera, a una variedad de proveedores de TI, no siempre es factible. Puede que cierto expertise en algún software especializado resida solo en cierto proveedor, por ejemplo. "De hecho, este es el caso especialmente cuando se implementan soluciones de software especializado en las que el expertise del mercado tiende a residir solo en el proveedor del software, anota Alpert.

Cierto tipo de proyectos empresariales puede que se presten naturalmente a un enfoque de un solo proveedor. "Esto entra en juego cuando se implementa una plataforma de software como servicio, indica Alpert. "En estas implementaciones, típicamente hay un ciclo de vida de desarrollo y de evaluación mucho más pequeño y efocado en una configuración y evaluación ágil.

Puede que a una organización de TI le guste la claridad que acompaña el trabajo con un solo proveedor. Lamentablemente, los beneficios percibidos de la rendición de cuentas de 'un solo cuello que apretar' son típicamente irrealizables debido a una pobre estructura comercial y a la falta de voluntad del proveedor de aceptar el riesgo real, explica Alpert. "Con un solo proveedor, las futuras fases del trabajo con frecuencia tienen un sobrecosto debido a la carencia de un potenciamiento competitivo, y el alcance del proyecto no está bien definido para determinar el calendario exacto, los entregables, los requerimientos y la línea de tiempo para mantener al proveedor auditable.

Mitigar el riesgo cuando se estructura un proyecto de tercerización de TI de gran escala

Sin embargo, hay formas de estructurar proyectos de TI de gran escala tercerizados que mitiguen el riesgo del proyecto y mantengan el apalancamiento de TI de la organización con un solo proveedor. Y esas bases deben sentarse durante la fase de negociación y contratación. Específicamente, cuando se aborda un programa importante con un solo proveedor, las organizaciones de TI deberían comprometerse contractualmente solo con el trabajo que puede ser especificado, alcanzado y planeado en el corto plazo.

"Recomendamos que los compradores limiten el alcance del trabajo a lo que puede ser definido con actividades específicas y entregables que estén dentro del control del proveedor, señala Aplert. "Con esto, el proveedor puede comprometerse a una tarifa fija por una cantidad establecida de trabajo que esté dentro de su control. A cambio, los compradores recibirán la comodidad de saber lo que obtendrán en forma de entregables y el presupuesto. Pueden usar la tradicional fase de diseño del proyecto para identificar especificaciones funcionales detalladas.

Esos entregables "permiten al cliente alcanzar y potencialmente completar la siguiente fase del trabajo (por ejemplo, diseño técnico y build) vs. [crear] un nivel más alto de diseño con promesas de proveedores para 'capturar el detalle de diseño adicional durante la siguiente fase de trabajo', anota Alpert. De esta forma, los compradores se asegurarán de que los hitos del proyecto estén estructurados para mantener la capacidad de completar fases futuras de trabajo en caso de que el proveedor no "esté muy hambriento, explica Alpert.

La meta es aprovechar al máximo el enfoque de un solo proveedor mientras se gestionan los inconvenientes inevitables de enlazarse a una sola fuente. "El enfoque óptimo es potenciar la escala potencial del proyecto para crear una estructura completa que ofrezca tarifas comprometidas, descuentos, estructura de gobierno, requerimientos de recursos y personal, términos comerciales, y estructura de rendimiento, finaliza Alpert.