En la primera parte de este artículo enumerábamos los distinto perfiles y áreas que van a a intervenir en un proceso de fusión o adquisición de empresas y el proyecto de integración que de esa situación se deriva. A continuación me gustaría comentar que retos y consideraciones hemos de contemplar desde un punto de vista más técnico y práctico a la hora de abordar el proyecto.
Lo primero que deberemos analizar son las necesidades que se nos plantean a la hora de abordar este tipo de proyectos, para realizar este análisis hemos de tener presentes algunas de las preguntas que aparecían en la primera parte del artículo:
- Experiencia en proyectos similares
Lo primero que podemos plantearnos es sí tenemos alguna experiencia previa en este tipo de proyectos. Esta experiencia puede ser de gran utilidad para no empezar de cero ya que podemos recopilar la información sobre como ejecutamos esos proyectos y utilizarla como plantilla para elaborar el nuevo proyecto, aprovechando aquellos puntos que funcionaron como se esperaban y corrigiendo los errores de planteamiento y ejecución que se pudieran haber producido.
Por desgracia, la gran mayoría de empresas no sufren procesos de fusión cada año, posiblemente no dispongamos de información de proyectos anteriores porque no se han efectuado o bien el último proyecto de fusión se ejecuto hace bastante tiempo y gran parte de esa información ya no nos sirva, ya sea porque nuestros sistemas han cambiado o bien porque la forma de abordar ese proyecto ya no tenga vigencia a día de hoy.
- Conocimiento de los sistemas a migrar
Este suele ser el primer punto técnico del proyecto que nos planteamos, ¿conocemos los sistemas que vamos a migrar o integrar sobre nuestra plataforma?, este pregunta suele tener una respuesta negativa o bien podemos tener un conocimiento bastante limitado de esos sistemas, por lo tanto la primera necesidad que se nos planteará será recopilar la mayor información posible sobre esos sistemas.
- Definición de tiempos de ejecución y dependencias
Otro de los puntos clave será definir los tiempos de ejecución del proyecto. En esta primera definición no se trata de definir cuanto tardaremos en ejecutar la migración, ya que aún no tenemos toda la información necesaria para poder estimar un esfuerzo, sino que en esta fase deberemos analizar las dependencias de cada una de las fases del proyecto y crear un mapa de dependencias, tanto a nivel de procesos y aplicaciones como a nivel de datos. Esto nos servirá para tener un primera aproximación de cómo deberemos ejecutar nuestro proyecto a nivel lógico y a partir de ahí evaluar los requisitos técnicos de cada fase y por último estimar los esfuerzos necesarios.
- Disponibilidad de recursos
Por último, otra de las típicas preguntas que nos realizaremos será si disponemos de los recursos necesarios para abordar un proyecto de este tipo o bien si necesitaremos de recursos externos. Esta pregunta ya os la respondo yo, necesitaréis de recursos externos, sino es así os podéis considerar afortunados, son pocas las empresas que a día de hoy aún disponen de departamentos de IT lo suficientemente amplios como para abordar un proyecto de estas características sin necesidad de ayuda externa.
Estas son sólo algunas de las preguntas que nos planteamos antes de abordar el proyecto, una vez que nos ponemos manos a la obra se nos presentarán diversos retos que deberemos ir asumiendo:
Como comentábamos anteriormente, este reto responde a una de las preguntas que nos planteábamos, como consecuencia, deberemos ser capaces de superar las limitaciones de recursos que existan en nuestra organización, la falta de procesos de migración anteriores que nos doten de metodologías, métricas y buenas prácticas para plantear la migración, y por último, tendremos que intentar coordinarnos con otras áreas de la organización que participen de forma directa o indirecta en el proceso de migración.
El segundo reto se centra en la identificación de los datos a migrar. Tenemos que comprobar la existencia de los datos a migrar, es decir tenemos que disponer de hechos, no supuestos, que nos permitan asegurar que los datos que deseamos migrar tienen las características y se corresponden con lo que esperamos encontrar.
Tendremos también que verificar la procedencia de los datos, es decir las fuentes que deberemos manejar para extraer esos datos. Otro de los factores que tendremos que vencer es el conocimiento de las reglas o contexto del negocio donde se utilizan esos datos, así como las relaciones que existen entre ellos, por escenificar un poco este punto diremos que deberemos conocer en cuantas aplicaciones y soluciones de negocio se utilizan esos datos ya que si no nos podemos encontrar con la sorpresa de que al eliminar o migrar una base de datos, dejen de funcionar aplicaciones o áreas de negocio que no teníamos contempladas.
Los últimos tres puntos no son menos importantes, ya que necesitaremos establecer una temporización de migración en base a los accesos a los datos, los diferentes orígenes y las dependencias a nivel de aplicaciones, está claro que cuando migremos un silo de datos deberemos tener contemplada la migración de todas las aplicaciones y procesos que utilizan esos datos, o establecer unos periodos de sincronización entre origen y destino, si se produjera el caso de no poder migrar todas las aplicaciones y procesos dependientes del dato.
Por último, ¿Qué son los datos huérfanos?, son todos aquellos datos que presentan algún tipo de excepción o casuística que nos impide asociarlos dentro del proceso normal de migración, ya sea porque no responden a unos estándares o porque no contienen una integridad referencial o simplemente porque se encuentran descontextualizados. En este caso deberemos trabajar con tablas de excepciones para tratar cada una de las casuísticas que nos encontremos.
Este punto lo veremos un poco más en detalle más tarde.
Por desgracia, los procesos de migración o fusión entre empresas no se pueden ejecutar en un fin de semana, y suelen ser proyectos que se alargan durante meses hasta que se definen todos los escenarios y se ejecutan todos los procesos de migración, así que será muy importante responder a los retos que supone asimilar los cambios sobre los requerimientos iniciales, los modelos de datos o los interfaces, quien suponga que puede decirle a su organización que “pare máquinas” hasta que se ejecute la migración peca de inocencia, así que deberemos contemplar todos nuestros diseños de procesos teniendo en cuenta las capacidades de adaptación al cambio de los mismos.
Por suerte, podemos decir que, a día de hoy, este punto es mucho más fácil de administrar de lo que pueda parecer a priori.
A la hora de realizar una validación de los datos que migramos no basta con comprobar que se han pasado el número de registros y tablas que había en el origen, una validación implica comprobar que en el destino se han grabado los datos que nuestras reglas de negocio y aplicaciones esperaban, comprobando su integridad, su formato y la idoneidad de los mismos. En este punto necesitaremos realizar no sólo validaciones de calidad a nivel de estandarización, conformidad o formato del dato, si no que deberemos realizar validaciones sintácticas, semánticas y de integridad. ¿de qué me servirá migrar un dato si en el destino se espera que el dato aparezca tratado en un formato específico?.
Por último una migración no acaba cuando se mueven los datos y las aplicaciones, sino que después deberemos realizar una revisión de todos los sistemas, procedimientos, aplicaciones y datos para comprobar que todo “ha ido bien”. En este punto nos pueden surgir varias necesidades para las que hemos de estar preparados, y responder de una forma rápida sí por ejemplo nos encontramos con problemáticas de datos, con problemas de integridad, de funcionamiento de las aplicaciones, etc.
Para solucionar estos problemas será muy importante disponer de trazabilidad de los datos, análisis de impacto sobre los cambios realizados y de procesos de sincronización entre entornos para asegurar capacidades de convivencia de entornos o bien de procesos de roll-back.
Hasta aquí hemos enunciado los retos que debemos tener en cuenta a la hora de plantear un proyecto de migración, o lo que es lo mismo, hemos definido algunas de los puntos sobre los que debemos estar alerta. Espero no haber generado muchos miedos, pero como veis un proyecto de migración no es sólo mover datos de un sitio a otro, sino que hay muchas cosas que controlar y contemplar.
En el siguiente artículo de esta “saga” pasaremos a definir la metodología para abordar estos procesos y hablaremos de algunas de las herramientas y funcionalidades que os pueden ayudar a realizar una migración sin morir en el intento.
No hay comentarios:
Publicar un comentario