Si usted esta a cargo de algún departamento informático en su empresa, o si tiene alguna responsabilidad en la operación y desarrollo del área tecnológica de su organización, tal vez uno de los hitos que fácilmente recuerde en su mente, sea la ocasión en que tuvo que migrar por distintas razones alguno de sus sistemas principales. Y con toda seguridad en la medida que el sistema migrado era de mayor criticidad para su organización, mas se acuerde de aquel hito de su carrera profesional.

En este post quiero hacer un breve análisis de lo que significa migrar sistemas informáticos, compartir con ustedes mi experiencia en el tema, y dar algunas recomendaciones básicas al respecto. Comentare también algunas buenas practicas y donde deberá hacer énfasis para minimizar los riesgos de proyectos de este tipo. Obviamente una buena metodología o recomendaciones no aseguran que todo salga bien, solo aseguran que usted realizo o se preocupo de todos los ítems que debería haber considerado.

Veamos entonces donde hacer el énfasis si usted es el responsable de una migración de sistemas informáticos. Lo primero será…

Considerar que este articulo se enfoca principalmente para aquellos proyectos de migración de sistemas core o principales, donde ya existen versiones y data de sistemas antiguos que desean ser remplazados.

Como una imagen vale mas que mil palabras considere la siguiente figura como aproximación general de una metodología de transición de sistemas informáticos empresariales (Puede hacer click para ampliar la imagen):

Como puede observar en la figura superior, el patrón de transición de sistemas deberá orientarse en general a la descontinuación y reemplazo de módulos, servicios o subsistemas por aquellos que en su totalidad considera el nuevo modelo. En este punto es correcta la afirmación de que una migración de sistemas puede ser evolutiva o incremental, en particular para sistemas complejos y mutí relacionados, como por ejemplo ERPs. Sin embargo existe una diferencia sobre a que nivel estamos hablando al considerar el tamaño mínimo de las piezas y partes que incrementalmente serán migradas.

Idealmente es aconsejable migrar evolutivamente primero servicios y luego aplicaciones o módulos. Sin embargo en situaciones donde los sistemas legacy no soportan interfaces del tipo webservice o similares esto es mas dificultoso. Pero siempre es aconsejable en este punto que los tamaños de cada pieza a migrar sean lo mas pequeño posible, sin entrar en riesgo operativo al realizar dicho reemplazo.

El por que es correcta la afirmación del párrafo anterior, radica en el riesgo potencial de mas líneas de código presentes en un modulo en comparación con aquellas presentes en un servicio. Sin embargo es imprescindible considerar en el escenario de migración de servicios o partes pequeñas, que dichos servicios o piezas pueden impactar en varios módulos al mismo tiempo. Por ejemplo el pack de servicios relacionados a cuentas corrientes, este pegara tanto en los sistemas de venta como en los sistemas de créditos de una solución empresarial.

Así pues deberá primeramente realizarse un estudio completo de todas las partes de los sistemas actuales, llegando a validar dichos impactos haciendo estudios de observación de los propios códigos y flujos de módulos y sub-partes de la solución.

En este punto quiero tocar un tema altamente significativo en el éxito de un proyecto de migración de sistemas empresariales. Este punto tiene relación en cuanto al governance de este tipo de proyectos. Es poco probable que un proyecto de estas características llega a tener éxito si no considera su empresa al menos una clasificación que separe la operación tecnológica de las soluciones informáticas de la gerencia de desarrollo de nuevos proyectos.

• Gerencia de operaciones tecnológicas: Departamento encargado de darle continuidad operativo a todos los sistemas vigentes o legacys de la empresa, esta gerencia solo se preocupa del "hoy", del soporte y del "ahora" de los sistemas computacionales, no del mañana o de los nuevos proyectos en general.
• Gerencia de desarrollo tecnológico: Departamento con personal independiente focalizado en el desarrollo de las nuevas soluciones tecnológicas. Esta gerencia no trabaja sin consultas a la gerencia de operaciones, pero en general evita quitarles tiempo al personal operativo de soluciones tecnológicas al interior de la empresa.Tiene una carpeta de proyectos o sub proyectos y el control de los mismos y sus costos asociados. La priorización de ellos esta definida a nivel estratégico de la empresa

Así pues considere la siguiente figura en relación a los actores y la cantidad de ellos, su importancia y su impacto en proyectos de migración de sistemas (Puede hacer click en la imagen para aumentar su tamaño):

Puede ver en la figura que actores e ítems debe considerar al momento de la planificación de la migración, énfasis en los componentes fundacionales de su sistema antiguo y aquellos actores que los soportan o utilizan, alternativas de negocio para estos cambios manteniendo los objetivos de negocios y en concordancia con la futura visión de negocio de la empresa.

Pero el punto mas importante a la hora de migrar su sistema informático a otro, será sin lugar a dudas en el ámbito operativo, la migración de datos. Este debería ser casi un capítulo aparte y llevar una planificación adicional dentro de la totalidad de la migración de sistemas.

En algunos casos de nada servirá migrar sistemas si no se pueden reutilizar parte o la totalidad de los datos antiguos, en otros casos esto no será de mayor importancia para empezar pero deberá sin duda planificar una migración incremental de la data histórica. De otra forma comparaciones a nivel de informes, cálculos en base a proyección de varios años de data, o otros temas relacionados con la data antigua no serán viables.

En general estas recomendaciones son de sentido común y de experiencia real. Pero existe otro set de recomendaciones o ítems a considerar poco vistas en las practicas de migración. Le comento aquí algunas de mis preferidas:

• Si usted esta migrando de sistemas informáticos del tipo cliente servidor de primera generación, esto es de sistemas cuyos clientes corre desde archivos ejecutables (*.exe) con bases de datos tipo SQL en un repositorio central. Hacia un modelo WebEnabled donde su cliente corre en un browser y la ejecución de procesos de interfaz se ejecuta en un servidor Web, que tiene por detrás otro servidor donde permanece una base de datos SQL como repositorio, considera las siguientes puntos:
  • El modelo de cliente servidor .exe puede realizar operación con conexiones abiertas entre pantalla y pantalla, es decir el tipo de conectividad a su repositorio esta mas cercano a un modelo sincrónico. Por el contrario un modelo WebEnabled debe ser un sistemas mas cercano a algo asíncrono en el sentido que cada pantalla se conecta al repositorio extrae datos y se desconecta. Por lo tanto en el intervalo posterior puden surgir situaciones que en el modelo antiguo no se contemplaban, como por ejemplo validaciones para asegurar que los registros a actualizar, sigan existiendo al iniciar el proceso de escritura.
  • En el modelo cliente servidor .exe, al mantener entre pantallas la conexión abierta usted no administra el concepto de sesión, en web enabled cada pantalla se conecta y desconecta, permaneciendo la mayor parte del tiempo desconectada de su repositorio, por lo que deberá implementar o utilizar un alguna estructura de manejo de sesiones vía GUID u otra similar para distinguir a ese cliente como el mismo que se desconecto anteriormente y darle continuidad a su sesión.
  • Es recomendable que si puede reutilizar su repositorio original mas algunas mejoras, lo haga versus la alternativa de un repositorio y cliente nuevo, esto le permitiría migrar en 2 fases, primero la capa 1 o pantallas, y luego el repositorio, si al definir su capa 1 se abstrae usando un modelo de servicios entre la capa 1 y su repositorio, la segunda fase. Esto es, la de migrar su repositorio a un repositorio nuevo, distinto o mejorado, será mas fácil ya que sus servicios le darán una mejor medición del impacto de los cambios, deberá por supuesto ajustar su capa 1 y servicios, pero ya los tendrá reconocidos y podrá con las mejoras en su repositorio mejorar también el rendimiento y funcionalidades de sus servicios o generar funcionalidades plus por sobre las originales de sus servicios, de manera de suavizar mas aun la migración.
• Pero si por el contrario su migración es mas dura, y planea cambiar de un modelo de .exe a otro totalmente distinto tipo ERP WebEnabled, entonces considere algunos tips como estos:
  • Planifiqué el governance del proyecto con 2 tareas fundamentales: migración de aplicaciones, módulos y funcionalidades. Y migración de datos.
  • Según el modelo de su ERP existen módulos que pueden ser implementados primero que otros y de menor impacto. No es lo mismo migrar el modulo de RRHH que el modulo de Inventario. El primero no se relaciona con la venta de productos, pero el segundo deberá tener implementados los módulos de Contabilidad, y otros similares que en un ERP son base para otros módulos.
  • Planifiqué la fecha de migración con el periodo de menores ventas: Vacaciones u otros donde el nivel de clientes o transacciones sea el mínimo. Ni se le ocurra planificar una migración en meses cercanos a navidad o fin de año. Recuerde que para muchos rubros ese periodo puede significar el hasta el 30% de las ventas del año, y sin sistemas eso es casi un crimen.
  • Administre las expectativas reales con sus clientes, que funcionara, que no y los problemas que tendrán. Muestre o haga ensayos donde se concientise el tipo de problemas que pueden surgir y cual será el Plan B, en esos casos.
  • Priorise los puntos de Ventas, Vendedores e Inventarios o Productivos, por sobre otros de menor importancia de continuidad operativa de ventas si va contra el tiempo.
  • Si el tiempo le acompaña y su planificación fue bien hecha, debería considerar un plan piloto, es decir pruebas en paralelo al sistema actual, pero solo para efectos de validación de comportamiento de sus nuevos sistemas.
  • Genere un ambiente de pruebas para sus usuarios, de manera de capactitarlos con un set de datos distintos al real.

Considere hacer énfasis en su migración en otros temas relevantes o mas genéricos como los que se detallan en el siguiente cuadro, si puede generar equipos coordinados que desarrollen estos temas doblemente mejor.

Cada uno de ellos es un mundo a parte y tiene importancia directa y relacionada con los demás, Por ejemplo su maestro de productos, su nuevo plan de cuentas contables, su plan de pruebas, las nuevas características de usabilidad que dispondrán en el nuevo sistemas, etc.

Finalmente considere que existen migraciones y migraciones, algunas pueden ser muy simples y otras como renovaciones de arquitecturas y sistemas totales muy complejas. Sepa bien en que nivel de migración esta parado. Y cuales son las características propias del nivel que enfrentara y sus riesgos. En el siguiente diagrama puede ver algunas relaciones al respecto. Puede hacer click para ampliarlo:

Finalmente mi mejor recomendación para una buena migración de sistemas, es la planificación detallada de cada fase, etapa, modulo, pantalla y funcionalidad que migre, invierta hasta el 50% del tiempo de su proyecto en esto si lo requiere, no será tiempo perdido. Trabaje con herramientas orientadas al usuario final, por ejemplo realice sesiones de storyboard usando herramientas como Axure o similares. Planifiqué, planifiqué, planifiqué!. No planifiqué en días, planifiqué en horas (como detalle máximo), use el Project como visión general y en detalle de su proyecto de migración, pero use mucho mas el Excel para el control del dia a dia de los trabajos (pero en Horas a Horas consumidas y por consumir) .

Ahora, finalmente considere que políticamente un plan de migración en general pude tener costos políticos para los responsables técnicos de llevarla a cabo, asegúrese entonces con contar con el apoyo necesario en esos niveles (estratégicos). No bastan palabras.

Me gustaría saber algo de su experiencia personal en el tema de migración de sistemas, ayudeme a ver si agregamos ítems a este pequeño resumen de donde hacer énfasis y que temas considerar a la hora de migrar sistemas empresariales, cual a sido su experiencia personal en migración de sistemas empresariales?.

Buena suerte! en su migración de sistemas
(Pero mas Planificación!).

Javier Urrutia

(3 votos, promedio: 3.67 de 5)

 Loading ...