jueves, 17 de julio de 2008

Migraciones, Fusiones y Adquisiciones (última entrega)


Continuamos,
¿Cómo podemos abordar un proyecto M&A con garantías?. Lo primero que deberemos tener en cuenta son todos los retos y problemáticas que hemos citado hasta ahora y con ellas realizar una metodología de implantación que trate de evitar incurrir en esos errores.
Una de las aproximaciones que a mí más me gusta y que he visto más efectiva en los últimos proyectos donde he participado es aquella que realiza un especial énfasis en la fase de análisis y perfilado de datos.
Normalmente para este tipo de proyectos se utilizaban aproximaciones basándose en desarrollos manuales y grandes equipos de migración encargados de diseñar los procesos y “programar” todas las extracciones y reemplazos de información y sistemas. Hoy en día existen en el mercado muchas herramientas que nos permitirán enfocar estos proyectos de una forma más ágil y segura.
El primer requisito “acceso a los datos de origen y destino”.


Lo más normal al plantearnos una migración o una fusión entre empresas es que todo y que el negocio sea el mismo, la plataforma informática puede diferir notablemente por lo tanto deberemos asegurarnos que somos capaces de acceder a los datos y aplicaciones de la plataforma a migrar. Plantear el acceso de forma manual o mediante programación suele ser bastante complejo ya que en muchos casos será muy difícil disponer en nuestra organización de personas con conocimientos de todas las aplicaciones y lenguajes que necesitamos, los más comunes suelen ser (PL/SQL, Cobol, Natural-Adabas, Java, XML, etc). Para garantizarnos el acceso a todos los orígenes y destinos os recomendamos utilizar una herramienta de integración, lo más importante a la hora de elegir la herramienta es comprobar que realmente posee conectores a todos los repositorios que necesitamos y que es capaz de gestionar o leer los Metadatos de nuestras aplicaciones.
Las herramientas de integración actuales permiten la integración a nivel de metadatos, esto nos será de gran utilidad ya que podremos entender los modelos de datos de las aplicaciones, sus estructuras, sus relaciones, etc, ayudándonos por ejemplo a mantener la integridad referencial y establecer las dependencias entre tablas e instancias a la hora de realizar la migración.

El análisis y el perfilado de los datos. “la Clave”.

¿En que consiste el perfilado de los datos?. Por perfilado de datos se entiende el análisis de los datos de los sistemas para entender su contenido, estructura, calidad y dependencias.
Este paso es vital ya que a la hora de plantear un análisis de los datos de origen nos encontramos en muchas ocasiones que realmente no sabemos que hemos de preguntar, ni donde pueden residir algunos problemas. Esto lo resumo con una frase que me gusta mucho en inglés:
You don’t know what you don’t know (desconocemos lo que no sabemos)
De esta forma el perfilado nos dará un análisis exacto de la estructura y el modelo de datos a tratar, dejando de lado la forma más común de análisis y la que nos lleva a más errores, “basar nuestro análisis en lo que nos cuenta un DBA o un administrador”, estos análisis todo y que pueden ser muy bien intencionados se basan en “suposiciones”, es decir, en promesas más o menos ciertas de lo que nos vamos a encontrar cuando intentemos extraer los datos de esos orígenes. Por eso una herramienta de perfilado nos dará “hechos sobre los que construir nuestro diseño”.
Con una herramienta de este tipo obtendremos informes donde podremos ver, estructura y formato de cada uno de nuestros registros, número de registros para cada tipo de formato, comprobación de integridad referencial, dependencias entre tablas, etc.
Tratamiento de excepciones y errores “el otro pilar”
Una vez identificados los registros y los modelos de datos a través del perfilado, deberemos realizar el tratamiento de excepciones y de errores.
Este punto consiste en analizar los informas del perfilado de datos y detectar todos aquellos formatos, registros nulos, contenidos o errores de integridad referencial que han aparecido y definir, junto con los responsables de los datos, como tratar cada una de las casuísticas que van apareciendo, por ejemplo: ¿Qué hacer con aquellos clientes que tienen el código de cliente con un formato incorrecto?, ¿Qué hacer con los registros nulos?, ¿Qué hacer con los formatos, estandarizarlos?, etc.
Una vez tenemos claro que haremos con cada uno de los errores que sabemos que existen en los datos el siguiente paso es establecer la estrategia para corregir, estandarizar, eliminar o tratar todos esos errores y excepciones.
Manejo de excepciones o errores “cross-reference data”
Uno de los típicos errores de planteamiento que se producen en los procesos de migración es tratar todas estas excepciones y errores como parte de un proceso de migración de una tabla, creando los desarrollos y el código necesario para corregirlos en el momento de transformación, pero obviando que gran parte de esos errores pueden ser estructurales, por causas históricas o comunes a la metodología de trabajo de la compañía y que por lo tanto pueden volver a aparecer en otros procesos de migración que llevemos a cabo en otras tablas o aplicaciones.
Por lo tanto, en estos casos yo recomiendo utilizar el uso de Cross-reference tables o tablas de control de excepciones. Estas tablas son un mecanismo donde centralizar todos los procesos de normalización o estandarización y de esta forma podremos cruzar cualquier información que estemos migrando con estas tablas para asegurar que todos los procesos utilizan los mismos criterios.


Otra de las grandes ventajas de estas tablas es su capacidad de reutilización en todos los procesos que necesitemos estandarizar, normalizar o corregir datos y su capacidad de adaptación a cambios, ya que cualquier cambio que se produzca en los criterios de estandarización o corrección estará centralizado y todos los procesos se cruzaran contra las mismas tablas.


Otros consejos importantes

Algunos puntos que también deberéis tener en cuenta son:


Como veis estos son sólo algunos de los puntos que hay que tener en cuenta a la hora de plantear una migración de datos, como resumen destacar que un enfoque adecuado nos ayudará a disminuir los riesgos de proyecto e incrementar la colaboración, otro de los conceptos importantes es dar la importancia necesaria a la fase de análisis, el análisis de los datos es crítico en un proyecto de migración y por último recordar que es importante disponer de una herramienta que nos proporcione acceso nativo a todos los orígenes y destinos que están involucrados en la migración, capacidad de acceder a metadatos de aplicación, que tenga una potente herramienta de perfilado y análisis que nos permita realizar análisis de impacto, análisis de dependencias y naturalmente, extraer un modelado de datos lo más preciso y fiable posible, no menos importante deben ser las capacidades de reutilización de procesos y como consejo huir de la programación manual o incluso de aquellas herramientas que requieren de programación ya sea en Java o con un lenguaje propio, ya que a la larga crean dependencias con ese lenguaje y suelen ser más costosas de mantener y menos flexibles en su uso.
Recordar siempre “Migration is not just moving the data – It’s making the data work”.