Migraciones, Fusiones y Adquisiciones (Tercera entrega)

Hola de nuevo,
Para poner fin a este serie de artículos sobre los procesos de migración (M&A), vamos a centrarnos en la metodología y la forma de plantear estos proyectos.
En primer lugar debemos definir una metodología y unos procedimientos claros que deberemos ejecutar y cumplir para la realización de nuestro proyecto de migración. Normalmente un proyecto de este tipo se suele ejecutar con una metodología en cascada similar a la que os muestro en el siguiente gráfico.






Esta metodología es la que yo denomino “La Trampa de la migración”, es un metodología que presupone toda una serie de datos y conocimiento que en muchas ocasiones desconocemos. Recardar lo que comentábamos en el capítulo 2 de este mismo artículo http://integracionycalidad.blogspot.com/2008/04/migraciones-fusiones-y-adquisiciones_10.html , donde ya avanzabamos que no podemos presuponer nada en este tipo de proyecto.
Si analizamos con un poco más de detalle esta metodología veremos que el primer paso consiste en realizar un análisis previo, para más tarde realizar un diseño de procesos, desarrollar los procesos y por último realizar el test, una vez realizado el test ya podemos dar por finalizada la migración. Sencillo, ¿verdad?, la realidad nos muestra que normalmente cuando llegamos a la fase de test suelen aparecer errores y tenemos que realizar un proceso de análisis inverso es decir:
1- Detectamos un error en fase de test (Test)
2- Comprobamos que el error no se produce por los propios procedimientos de test, si es así corregimos el error y volvemos a lanzar el test (Test).
3- Si el error no está en fase de test, comprobamos la fase de desarrollo (build), sí el error esta aquí lo corregimos y volvemos a lanzar el test (Test).
4- Si el error no está en fase de desarrollo (build), comprobamos si es un error de diseño (design), sí es así lo corregimos, entonces modificamos la parte de desarrollo correspondiente (build) y por último volvemos a fase de test (Test).
5- Por último, si el error no era de diseño (design), comprobamos sí el error es de análisis (analyze), lo corregimos, actualizamos el diseño con esa información (design), volvemos a generar los desarrollos o procedimientos necesarios (build) y volvemos a ejecutar la fase de Test (Test).
Bueno, creo que el proceso es fácil y sencillo, ¿verdad?. Ahora un par de preguntas, ¿Cuántos errores pueden aparecer en fase de test para cada procedimiento de migración?, ¿Cuántos de esos errores suelen ser motivados por un mal análisis?.
Respuesta: He aquí vuestra metodología:


Una bonita espiral que será tan grande como complejo y ambicioso sea vuestro proyecto. Ahora os dejo algunos datos de esos que tanto nos gustan:

• Algunas suposiciones sobre los datos son erróneas - 25% del tiempo de proyecto estimado se pierde en análisis
• El rediseño requiere de un análisis detallado - 25% de la estimación inicial se pierde en diseño
• Problemas de proceso inesperados requieren de un re-diseño. - 50% de la estimación inicial se pierde en creación de nuevos procesos
• Escenarios de datos inesperados rompen los desarrollos - 50% de la estimación inicial se pierde en procesos de test
  

Como conclusión tenemos que la gran mayoría de proyectos de migración o fusión acaban ejecutándose sobre un 150% de la estimación inicial, esto supone que la empresa ha de asumir un incremento del 50 en tiempo o en coste.

Ahora otra par de preguntas, ¿cuantos de vosotros habéis visto, oído o vivido proyectos de migración donde a mitad de proyecto se acepta por parte de la empresa un retraso en tiempo o un aumento de costes de proyecto?.

Bueno, os dejo reflexionar un poco con estos temas y enseguida continuamos.