Cómo plantear un proyecto de conversión con garantías

Ahora que esta de moda trabajar por proyectos permitidme hacer una reflexión sobre una especialidad que algunos de nosotros llevamos años haciendo desde los departamentos de migración de muchas empresas TIC. Empecemos por conocer qué hacemos. No se trata de una migración como las que a menudo vemos en documentales de naturaleza. La palabra proyecto deriva del verbo latino prociere donde pro significa hacia adelante, y iacere, lanzar. Esto es lanzar, enfocarse hacia adelante. Y si algo necesita enfoque es un proyecto de migración de una solución de gestión empresarial a otra.

Algunos diréis ¿Migrar clientes y facturas a otra aplicación? ¿Ese es el PRO-YEC-TO de qué me hablas? ¿Es ese el PRO-YEC-TO de conversión en el que concurren tantas personas y en al que dedicáis tantas horas?

Bien, una traslación de un sistema a otro también es un proyecto. Pero yo en este artículo me refiero al Boeing de los proyectos. A algo que te pueda encargar un cliente de gran envergadura. Aquí no solo se trata de migrar una serie de datos con un cierto volumen. Hablamos de tener en cuenta, muchos otros factores que describiremos después. Pero así, en volumen, pensemos en una tarea que puede contar con:

5.242.000.000 líneas de registros migrados (2 hitos de migración)
22.500 líneas de código desarrolladas para efectuar la extracción, conversión y carga;
La definición, ejecución y análisis, de aproximadamente 600 informes e indicadores volumétricos, de calidad y coherencia;
2.926 peticiones de usuario y tareas incorporadas en los desarrollos de conversión efectuados;
186 tareas de depuración gestionadas con sistemas origen o depuradas por regla de conversión
514 tareas definidas y ejecutadas en el plan de corte de la compañía (cliente), en la que han intervenido 181 responsables de 18 sistemas/entornos diferentes y de 9 proveedores desiguales;
46 actividades de reingeniería de procesos con el objetivo de optimizar y reducir los tiempos en máquina para ejecutar toda la conversión y migración de datos…
Y 33 consultores, además de tres jefes de proyecto asignados en alguna o todas su fases.

Ya tenemos el cómo, ahora nos falta el por qué. ¿Qué hace a la dirección interna de un departamento de IT poner patas arriba a todo su sistema de información y confiar en una serie de proveedores externos para ayudarle en su reorganización? ¿Dónde se van las horas y horas de trabajo del equipo de conversión?

Mejorar sus procesos, sin duda. Ser más competitivo, por supuesto. Mejorar su información, por descontado…pero siempre hay un motivo tangible, una situación concreta que les obliga a cambiar, los factores que antes citaba.

Por ejemplo que en el porfolio de sistemas internos del cliente se considere unificar las diferentes líneas de negocio de la compañía en una misma aplicación y entorno. Unas líneas que actualmente se mantienen en diferentes aplicaciones o sistemas.
O, tal vez, para mejorar la calidad del dato del cliente. Algo que no se ha mantenido en años. Pese a los numerosos proveedores que han ido rotando y manipulando los datos transaccionales continuamente en el tiempo. Con la consecuente pérdida de robustez y coherencia.
A lo mejor recurren a un proveedor externo para adaptar campo a campo y estructura a estructura el modelo de datos y las validaciones funcionales implementadas entre sistemas origen y destino. Que son parecidas pero no iguales.
Sin obviar que, tal vez, en su alcance y por estrategia global, el proyecto de migración debe analizar, planificar, desarrollar y probar los desarrollos, prácticamente en paralelo. Y hacerlo cuando otros equipos y proveedores todavía están definiendo y desarrollando cada una de las funcionalidades.
Para rematarlo ya, nos encontramos con que la nueva aplicación donde se migrarán los datos (así como la del sistema origen), no son estáticas y pueden evolucionar en el tiempo. Y esto conlleva la entrada de nuevos desarrollos, realizados por una multitud de equipos y proveedores ajenos a ekon y donde el equipo de conversión es el vagón de cola en las diversas responsabilidades del proyecto global.

Y todo esto no es más que el planteamiento, la definición del alcance del proyecto. El desarrollo de los proyectos de conversión de esta magnitud también tiene dificultades añadidas que hay que afrontar como os descubro en una entrada posterior sobre cómo afrontar con garantías un proyecto de conversión.