Calidad de Datos vs Resolución de Identidades

El tema de la Calidad de datos es algo que ha dejado de ser un tema restringido a los departamentos de Marketing y a tener unas buenas direcciones para realizar campañas, envíos, etc. Cada día más las empresas ven la importancia de poseer datos de calidad para asegurar que los procesos de negocio no tengan errores, que los informes de BI sean fiables y que los departamentos de ventas, call center o soporte puedan tener la información correcta de los clientes con los que tratan.


Así a día de hoy han aparecido infinidad de proyectos donde se demuestra que la calidad del dato es importante para asegurar el éxito del proyecto. De todos es conocido que uno de los principales motivos del fracaso de algunos proyectos de Business Intelligence es la mala calidad de los datos que residen en el Data Warehouse y que en muchas ocasiones provocan que la informes no sean del todo fiables, esto hace que los principales consumidores de estos informes acaben perdiendo la confianza en los mismos y recurran a la tan socorrida Hoja de Cálculo, donde se aseguran que los datos que aparecen son fiables y que los cálculos han sido hechos según sus criterios.


Otro de los aspectos que cada día cobran más importancia es la capacidad de detectar duplicados o identificar de forma correcta nuestros clientes, para ellos es necesario disponer de procesos que sean capaces de realizar desduplicaciones y matching de nuestros clientes de forma eficiente, a estos requerimientos se unen que en la situación actual, en un mundo globalizado los nombres, la direcciones y los contactos han dejado de ser exclusivos de un idioma y necesitamos ser capaces de extender estas capacidades de búsqueda y desduplicación a diferentes idiomas, con diferentes formatos de nombre y diferentes patrones de fecha, direcciones, etc. Para resolver estas problemáticas podemos recurrir a las aplicaciones de Identity Resolution que se encargan de identificar a nuestro cliente de forma univoca independientemente de que los registros se encuentren estandarizados, limpios o que sean de diferentes idiomas.


En este artículo intentaré explicar las diferencias, ventajas e inconvenientes de utilizar procesos de Calidad o de Identity Resolution en nuestros procesos de tratamiento de datos.

Calidad de datos versus Identity Resolution, ¿Qué hacen?

Lo primero de todo es tener claro que nos puede ofrecer cada una de estas soluciones.
La calidad de datos es un concepto muy amplio, así que para aclarar las cosas utilizaremos los 4 pilares que definía Gartner en junio de 2005 como pilares imprescindibles de una suite corporativa de calidad de datos.


Por eficacia del contacto entendemos la capacidad de limpiar y estandarizar los datos personales como nombres, direcciones y teléfonos. En este apartado es donde tenemos la gran mayoría de herramientas conocidas como normalizadores.

La identificación de relaciones consiste en la capacidad de localizar relaciones entre registros para realizar desduplicaciones (matching), relación de dos o más tablas, detección de unidades familiares o corporativas (householding), etc.

La calidad de datos general nos habla de que la calidad no debe ser implementada sólo a nivel de eficacia del contacto, sino que hemos de ser capaces de limpiar y estandarizar, nombres de producto, cuentas bancarias, tarjetas, o cualquier otro dato de negocio que sea susceptible de errores de calidad. Algunos ejemplos los encontramos en los sectores de distribución, retail y manufacturing, donde la calidad de datos puede ser utilizada para el control de stock, producción o compra de productos, es muy típico encontrar referencias de producto duplicadas por errores de calidad que pueden generar alertas de roturas de stock, sobrecostes de producción o errores en la gestión de compras.

Por último una suite corporativa de calidad ha de poseer herramientas de análisis de la calidad de los datos que nos permitan conocer en todo momento el estado de la calidad de nuestros datos, realizar informes de calidad, monitorizar las fluctuaciones, etc. Esto nos puede ser útil, por ejemplo, en las campañas de marketing, ya que en muchas ocasiones nos encontramos que una campaña puede ser lanzada por diversas vías (telefónica, mailing postal, e-mail, etc) y saber el estado de la calidad de esos campos nos puede ayudar a escoger el mejor medio para realizar nuestra campaña, imaginaros lo útil que puede ser para un director de marketing saber que el campo e-mail sólo es fiable en un 30% o que el campo dirección sólo es correcto en un 50%, de esta manera podemos elegir la vía que obtenga un mayor nivel de impactos correctos y de la misma forma no enviar la campaña a aquellos contactos que sabemos que sus datos no son correctos o no están estandarizados, ahorrando así todos los costes asociados por impactos fallidos.

Todos estos puntos son los que deberemos considerar cuando hablamos de herramientas de Calidad de Datos Empresarial.

...continuará, en breve.

Magic Quadrant for Data Integration tools, 2008

El pasado 22 de septiembre Gartner publicó un nuevo cuadrante de integración de datos. En esta nueva entrega se han producido algunos cambios, como podríes comprobar en la comparativa entre el 2007 y el 2008, algunos fabricantes como Syncsort y Hummingbird han desaparecido del cuadrante y otros como Business Objects y Cognos ahora aparecen junto a SAP y IBM, respectivamente, después de que estos adquierieran estas marcas durante el 2007.




















En el apartado de leaders ha habido poca modificación, tanto IBM como Informatica con sus herramientas IBM Information Server y Informatica PowerCenter, marcan la línea a seguir en este sector. Ambos han añadido nuevas funcionalidades a sus plataformas, una gran parte de ellas fruto de la compra de otros fabricantes, y ofrecen una amplia variedad de funcionalidades que no se limitan simplemente a las funciones típicas de una ETL. Cada día más se habla de la necesidad de integración de datos como un factor clave dentro de las compañias para cualquier tipo de solución, MDM, CRM, ERP, DW/BI, etc. El termino acuñado por Informatica hace ya un par de años como EDI (Enterprise Data Integration), herramientas de integración empresarial define claramente la visión que estos fabricantes tiene del mercado.

En este apartado de leaders cabe destacar también la irrupción de SAP gracias a la compra de Business Objects y la suma de sus herramientas SAP XI y BODI (Business Objects Data Integrator). Desde mi modesto punto de vista, no queda demasiado claro cual va a ser la línea que adquiera SAP, actualmente en el mercado están hablando de SAP Netweaver como la capa de integración de las aplicaciones SAP y entiendo que SAP XI como la capa de integración de datos, no se bien donde se ubicará BODI o bien se este sustituirá a XI.

Como detalles curiosos me gustaría destacar que tanto Oracle como Microsoft se han quedado en el cuadrante de challengers, practicamente en la misma posición que en el 2007 y parecen no haber apostado por el mercado de la integración, todo y que Microsoft lanzó su nueva versión de los DTS, el MS-SSIS y había leído algún buen comentario sobre la nueva versión.

En el apartado de visionaries, tanto SAS como iWay software, división de Information Builders, continuan incluyendo nuevas funcionalidades en sus productos como calidad de datos, data federation, metadata managemnt, etc. Pero en ambos casos aún no son reconocidos como vendedores de integración y sus productos siguen siendo complementos de herramientas como WebFocus o SAS BI, siendo difícil su presencia en entornos como herramientas de integración corporativas.

Os dejo un enlace de Informatica Corporation donde podríes descargar el informe de gartner al completo. http://www.informatica.com/di_mq/default.htm

Informatica Corporation adquiere las operaciones de PowerData Iberia

Hola a todos,

El pasado 2 de septiembre, se anuncio en varios medios de comunicación la noticia de la adquisición por parte de Informatica Corporation (http://www.informatica.com/) de la parte de operaciones de PowerData Ibérica (http://www.powerdataib.com/). De esta forma la firma americana especializada en soluciones de integración y calidad de datos pasará a tener oficinas propias en Madrid, Barcelona y Lisboa.

La compra ha sido limitada, ya que sólo adquieren la parte de operaciones (comercial, marketing, etc), mientras que la parte de servicios pasa a denominarse PowerData Solutions.

PowerData Solutions seguirá siendo partner de Informatica en España, con la ventaja de que poseen un amplio conocimiento de las soluciones, que los coloca en clara ventaja sobre el resto de partners para ofrecer los servicios de los productos de la compañía Informatica.

La división de Informatica Iberia la dirigirá Juan Oñate, hasta ahora Director General de PowerData, mientras que PowerData Solutions será dirigida por Alberto Collado hasta ahora director de la división de PowerData America.

Independientemente de los detalles de la compra, la división, etc, considero que es una buena noticia para los posibles clientes de Informatica Corporation en España, ya que ahora dispondrán de un canal de comunicación directo con el fabricante y no a través de un partner como se operaba hasta ahora.

Por otra parte creo que demuestra que el mercado español de la integración de datos es cada vez más maduro y las empresas españolas, cada vez más, consideran la integración como un elemento clave en su estrategia de negocio, de ahí que la firma americana haya decidido implantarse en la península Ibérica.

http://www.powerdataib.com/index.asp?idedicao=51&idseccao=512&id=300&action=noticia

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”.

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.

Parón obligado

Hola a todos,

Durante el mes de junio me he visto obligado a descansar mi actividad en el blog, ya que una inoportuna rotura de menisco me ha tenido postrado en casa.


Durante este tiempo he podido leer mucho y muy variado sobre la actividad del mercado de la integración y calidad de datos, como detalles significativos destacar que ya tenemos publicado el nuevo Magic Quadrant for Data Quality Tools de Gartner.

Como curiosidades de este nuevo informe, si comparamos con el último cuadrante, publicado en junio de 2007, en el apartado de Leaders siguen apareciendo los mismos 5 fabricantes (Business Objects, DataFlux, IBM, Informatica y Trillium), entre ellos sólo trillium e Informatica han variado notablemente sus posiciones, mientras Trillium ha bajado en facilidad de ejecución, Informatica ha subido notablemente, presentandose muy pocas diferencias entre los 5 fabricantes en este cuadrante.

En el resto de apartados no ha habido mucho movimiento y practicamente todos los que aparecian en el 2007 conservan sus posiciones en 2008, sólo destacar la desaparición de Fuzzy! Informatik que fue adquirida por Business Objects a finales del 2007 y por lo tanto deja de existir como fabricante independiente.

Os dejo unos enlaces donde podéis consultar el informe completo

http://www.informatica.com/news_events/press_releases/Pages/06102008_dq_mq.aspx

http://www.sap.com/about/press/press.epx?PressID=9607

http://www.dataflux.com/Resources/resource.asp?rid=232


Como podréis comprobar la información que ofrecen los fabricantes se asemeja mucho a las que ofrecen los partidos políticos después de las elecciones, todos dicen que han mejorado y son leaders significativos en su sector.

Entrando un poco más en detalle sobre la información que nos facilita Gartner de cada fabricante, destacar que:

Business Objetcs

Desde la compra por parte de SAP, el objetivo esta siendo incrementar su cuota de mercado mediante operaciones de cross-selling en clientes SAP. La complentariedad de las aplicaciones de calidad de datos con los entornos de SAP como MDM es uno de sus puntos fuertes. Otra de las ventajas es la posibilidad de integrar la solución de calidad de datos dentro de su herramienta de integración. El producto se divide basicamente en Data Insight XI que ofre funcionalidades de profiling y Data Quality XI que ofrece las operaciones de limpieza y estandarización de datos.

DataFlux

Es uno de los fabricantes consolidados como leader del marcado de calidad. Los clientes destacan su facilidad de uso, incluso para usuarios no técnicos y ofreces buenos resultados en cuanto a performance, profiling y matching. Entre las capacidades que ofrece destacan profiling, matching, cleansing y monitoring.

IBM

La plataforma Information Server es la base para todas las funcionalidades de calidad de datos, exitiendo dos productos principales que ofrecen estas funcionalidades, IBM Information Analyzer que ofrece funciones de discovery, profiling y analysis, y IBM QualityStage que ofrece parsing, standardization y matching. Actualmente IBM esta integrando las capacidades de calidad de datos dentro de la plataforma Cognos para poder crear Data Quality Dashboards.

Informatica

Informatica Corporation ha sufrido un notable avance con su herramienta Informatica Data Quality, gran parte de este nuevo posicionamiento en el cuadrante es debido a iniciativas de cross-selling con su herramienta de integración Informatica PowerCenter, actualmente Informatica tiene una base instalada estimada de 400 clientes en calidad de datos entre sus productos Informatica Data Quality y Informatica Data Explorer (herramienta de perfildado de datos).

Trillium
Harte-Hanks Trillium ofrece un potfolio de productos formado por una herramienta de perfilado de datos (TS Discovery), Calidad de Datos (TS Quality) y una herramienta de creación de cuadros de mando de calidad (TS Insight). Actualmente disponen de una base instalada de casí 700 clientes, la mayor parte en Norte América. Actualmente tienen un acuerdo de partnership con Oracle quien ofrece funcionalidades de calidad dentro de la suite Oracle Data Integration.

Elegir una herramienta de integración de datos

Hola de nuevo,
Me quiero permitir un paréntesis en la serie de artículos que estaba escribiendo sobre los procesos de migración y fusión para hacer una reflexión sobre los típicos errores, prejuicios y omisiones que se dan a la hora de realizar la elección de una herramienta de integración de datos empresarial.
Cuando hablo de integración de datos empresarial es muy importante remarcar la palabra empresarial como una cualidad indispensable en este tipo de soluciones. La razón es muy sencilla, las necesidades de integración son necesidades que no se encuentran vinculadas a un solo proyecto, sino que son comunes a muchas tipologías de proyecto como pueden ser los proyectos de BI, en la parte de carga del Data Warehouse, los proyectos de M&A, los proyectos de BPM, B2B, ERP, CRM, Visión única de cliente, de producto, etc, por lo tanto es muy importante que este tipo de herramientas se plantean como una solución corporativa para las necesidades de integración de la empresa y no como una solución puntual para cubrir las necesidades de un proyecto específico.
Partiendo de esta aclaración o premisa me gustaría enumerar los 4 errores típicos o los 4 argumentos de resistencia que me he encontrado en el mercado a la hora de plantear soluciones basadas en productos de integración de datos.
La idea es plantearos el requerimiento o la necesidad que deberíamos considerar a la hora de elegir la herramienta y a continuación os explico los errores típicos, situaciones y consecuencias que se planean de una aproximación errónea.

Caso 1:
La herramienta ha de cubrir los requerimientos actuales y asegurar capacidades de crecimiento y adaptación a nuevos requerimientos.

• Error 1: Adquirimos la herramienta que se ajusta a las necesidades actuales sin valorar el crecimiento futuro.
• Posible situación: A los 10 meses aparece un nuevo requerimiento y no podemos hacer frente con la herramienta que escogimos.
• Argumento utilizado por IT: Era la más barata, su coste era reducido, de fácil implantación, etc.
• Punto de vista de dirección: Mala decisión por parte de IT ya que esta herramienta nos saldrá muy cara porque ahora debemos adquirir una nueva para cubrir las necesidades actuales y perdemos la inversión hecha en esa herramienta, el tiempo de implantación, la formación a los administradores y tenemos que volver a pasar por todas esas fases.

Caso 2:

La herramienta ha de tener capacidades de reutilización de procesos.

• Error 2: La herramienta que elegimos NO permite diseñar los procesos de ETL como módulos reutilizables entre los diferentes procesos de carga.
• Posible situación: Nos encontramos que muchos de los procesos de tratamiento de datos son repetitivos y tenemos que volver a generar cada uno de esos procesos.
• Argumento utilizado por IT: Es muy fácil volver a generar el proceso, al final es hacer un copy/paste entre diferentes procesos.
• Punto de vista de dirección: Mala decisión por parte de IT ya que sí mañana cambio la lógica de tratamiento de los datos he de volver a revisar todos los procesos donde se utiliza esa lógica y no dispongo de un punto centralizado donde realizar el cambio.

Caso 3:
La herramienta ha de poder realizar análisis de impacto y dependencia entre orígenes y destinos.

• Error 3: No consideramos esta funcionalidad como algo primordial ya que actualmente sólo tengo una base de datos con unas cuantas tablas y un solo destino.
• Posible situación: Después de varios meses de uso necesitamos cambiar un campo en una tabla, añadir un campo nuevo o cambiar la base de datos de SQL a Oracle ya que nuestro director ha firmado un acuerdo corporativo con Oracle.
• Argumento utilizado por IT: Esta situación era difícil de prever ya que llevamos años utilizando la misma tecnología de DDBB. No contemplamos el cambio en la orientación del negocio o los datos.
• Punto de vista de dirección: Falta de previsión por parte de IT, nuestro negocio es dinámico y siempre se pueden producir cambios en la metodología o lógica que aplicamos, así que las herramientas han de ser capaces de adaptarse a esos cambios.

Caso 4:
Para reducir los costes de integración y anticiparse a los errores de calidad del dato o formato debemos tener capacidades de perfilado.

• Error 4: El perfilado no es necesario ya que conocemos muy bien el modelo de datos de nuestras bases de datos.
• Posible situación: Empiezan a aparecer errores de datos motivados por formatos no esperados o campos con contenido no esperado (Nulls, diferentes formatos de fecha, números no validos, etc).
• Argumento utilizado por IT: El problema reside en el Data Entry ya que las chicas que entran los datos en el Call Center no hacen caso de la normativa de entrada de datos.
• Punto de vista de dirección: Falta de previsión por parte de IT, el personal del call center es subcontratado y rota con mucha frecuencia, no podemos asegurar su formación para entrar los datos perfectos, cada persona escribe las fechas o los teléfonos de forma distinta, algunas no entienden el uso que podemos llegar a hacer de cada dato,…

Otras consideraciones:

• Necesidades de conocimientos de lenguajes de programación específicos (script, java, pl/sql,…)
• Falta de capacidades de autodocumentación de procesos
• Entornos de desarrollo y producción sin capacidades de despliegue guiado, versionado, roll-back, etc.
• Limitadas capacidades de crecimiento vertical, horizontal y optimización del rendimiento (grid computing, alta disponibilidad, particionado, pushdown, etc)
• Imposibilidad de extender el uso de la herramienta a entornos Saas y B2B. (EDI, SEPA, Swift, …)
• Imposibilidad de incorporar datos de formatos no estructurados (excel, pdf, word, etc)

Como resumen de todas estas experiencias que me he ido encontrando a lo largo de todos estos años, me gustaría hacer hincapié en que a la hora de analizar una herramienta de integración de datos no es quedéis sólo en el precio, el fabricante o las capacidades de conexión, porque a la larga pueden aparecer escenarios como los que hemos planteado donde quede claro que la elección no ha sido muy afortunada y en ese momento tendréis un problema sobre la mesa muy difícil de gestionar, creerme que no es grato averiguar al cabo de unos meses que te has equivocado con la elección de la herramienta y que el único argumento que puedes esgrimir ante tus jefes es que “era más barata” o que “para ese proyecto servía”, porque lo único que van a ver tus jefes es que tienes una gran falta de visión global del negocio, de previsión y por lo tanto de gestión de tus presupuestos o proyectos.

Migraciones, Fusiones y Adquisiciones (Segunda parte)

Hola de nuevo,

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.

El reto de la validación de los datos es un reto que nos encamina directamente hacía lo que conocemos como Calidad de Datos.
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.

Migraciones, Fusiones y Adquisiciones (Primera parte)

Hola de nuevo,
La situación económica actual y los movimientos empresariales están produciendo que cada día un mayor número de empresas planteen compras, fusiones, adquisiciones o escisiones de empresas. En la prensa y en Internet se suceden las noticias empresariales sobre los movimientos de compra y venta de empresas. Todos estos procesos son analizados desde la vertiente económica y nos reflejan las posibilidades de crecimiento, expansión, etc., de cada una de las empresas, en este artículo intentaremos desmarcarnos de esa visión y centrarnos en los procesos de migración, escisión o fusión de datos que se producen en las empresas como consecuencia de estos movimientos financieros.
El primer punto que debemos tener claro cuando nos encontramos en un proceso de migración o fusión (el acrónimo inglés utilizado es M&A), es que visión tiene cada uno de los estamentos de la empresa a la hora de afrontar este tipo de procesos, esta visión nos servirá para encontrar el interlocutor adecuado para cada situación e identificar porque se toman algunas decisiones y que espera cada departamento de nosotros.
Desde la dirección los procesos de compra o fusión se plantean siempre desde el punto de vista económico y en términos de oportunidad de negocio, crecimiento, posicionamiento, etc.

Lo que va a valorar Dirección siempre va a ser la ventaja competitiva que supone la compra de otra empresa, ya sea en términos de cartera de clientes, productos, posicionamiento en el mercado, imagen de marca, oportunidad de expansión a otros mercados u otras áreas de negocio, diversificación de la inversión, etc.
Una vez que se plantea la migración o la fusión desde Dirección, ¿Cómo se ven afectados los otros departamentos de la organización?. Desde el resto de la organización se plantean básicamente los impactos que se van a producir en la forma de trabajar, en la organización y en los procesos a partir de ese momento. Desde estos departamento la visión suele ser algo más catastrofista que desde Dirección, se suelen ver los inconvenientes en cuanto a cambios organizativos, problemáticas de aplicación y adaptación a la nueva estructura, los procesos y recursos necesarios para asumir todas las tareas necesarias para llevar a cabo el proceso de migración y un largo número de inconvenientes asociados a los trabajos que se derivarán de este proceso iniciado por dirección.
Por último cabe destacar que existen otros condicionantes que nos van a afectar a la hora de platear un proyecto de integración. Estos condicionantes son los que se producen motivo de la desconfianza que genera un proceso de este tipo dentro de los profesionales que comprenden nuestra organización. En estas situaciones siempre hay una resistencia al cambio, ya que es normal que se genero un miedo sobre los nuevos procesos y como estos van a afectar a la operativa diaria de cada persona, también es típico que se genere una ola de pesimismo sobre el futuro de la compañía y sus puestos de trabajo, que conlleva asociado un ocultismo de información como herramienta para conservar su puesto de trabajo y un cierto inmovilismo para no favorecer los cambios que puedan afectar a esas personas de forma directa o indirecta.

Todas esta premisas respecto a la dirección, a la organización y a las personas son las que deberemos tener en cuenta a la hora de plantear cualquier paso, reunión o decisión respecto del proyecto de integración. Por lo tanto, ¿que debemos hacer con cada interlocutor?.
Cuando hablemos con Dirección para exponer una problemática o sugerir ciertas acciones hemos de tener presente que su objetivo es mejorar los beneficios de la empresa y que para ellos lo más importante es que el proceso de fusión se haga de la forma más rápida y menos costosa posible. Así las preguntas que se plantean desde dirección son:

• ¿Cuánto tiempo tardaremos en tener operativos los datos y procesos migrados?
• ¿Cuánto nos va a costar?

Teniendo en cuenta esas preguntas nuestros argumentos siempre han de estar dirigidos a resolver esas preguntas, por lo tanto deberemos utilizar argumentos del tipo:

• Para reducir los costes de migración deberíamos….
• Para reducir el tiempo de migración necesitamos disponer de…

Si nos centramos en esas dos variables Dirección siempre va a ser más receptiva y va a entender perfectamente la problemática o necesidades que estamos exponiendo.
Por otra parte, si queremos hablar con otros departamentos o dentro de nuestro propio departamento de IT con otras áreas, deberemos realizar el mismo ejercicio y ver que problemáticas o preguntas se plantean en esta área, así nos surgirán cosas como:

• ¿Poseo documentación de los sistemas origen?
• ¿Conozco como están organizados los datos?
• ¿Conozco las dependencias entre datos y aplicaciones?
• ¿Existen técnicos en mi organización que dominen todas las aplicaciones que he de integrar y los lenguajes y protocolos necesarios (Cobol, PL/SQL, XML, Java, EDI, Swift, etc ?

Están son algunas de las preguntas que deberemos responder dentro de nuestro departamento para poder plantear los pasos y procesos que demos realizar en la fusión.
Por último, no debemos olvidarnos que cuando hablemos con cualquier persona de nuestra organización podemos encontrar reticencias a colaborar o facilitar información que pueda ser sensible a su trabajo. La forma más eficaz para evitar esas barreras es informar a esa persona del porqué necesitamos esa información, que vamos a hacer con la información y demostrar en todo momento que no estamos intentando recoger información para eliminar o degradar a esa persona dentro de la organización. Es muy importante que todos se sientan una parte importante del proceso de migración o fusión y que su colaboración es necesaria y que de ella depende la marcha de la compañía y en parte su futuro en ella.
Bueno, en esta primera parte hemos sentado las bases para saber donde nos vamos a mover y como debemos plantear nuestras conversaciones en base de nuestro interlocutor. En la segunda parte de este artículo nos centraremos en la parte más práctica de la migración, donde veremos los procesos de integración de datos, que pasos son importantes, requisitos previos, etc.

¿Qué es la integración de datos?

Hola a todos,
Considero que el primer artículo que he de escribir en este blog ha de estar dedicado a clarificar que entendemos por integración de datos o como mínimo que entiendo yo por integración de datos.
Para entender este concepto es necesario hacer un poco de historia. En los años 90 los departamentos de IT consideran que cualquier problemática que la empresa les plantea obtiene su solución a través del diseño, creación o adquisición de una nueva aplicación, son muchos los ejemplos donde vemos como van proliferando soluciones a medida o empaquetadas que resuelven problemas o necesidades específicas de unas áreas concretas del negocio, así surgen aplicaciones para la gestión de la producción, de la logística, del ciclo de vida del producto, aplicaciones de marketing, financieras, comerciales, etc. Ha nacido la era del Application-Oriented.
Cada una de estas aplicaciones llevan asociados sus propios datos que son almacenados en repositorios propios o bases de datos genéricas, creciendo así el número de repositorios donde existen datos almacenados en nuestra empresa, es lo que conocemos como silos de datos.
Pronto las necesidades del negocio nos obligan a compartir información entre estas aplicaciones y es necesario que nuestra aplicación financiera disponga de información de compras o logística, o que la aplicación comercial pueda ver cuando se emite una factura desde nuestro ERP, etc. Esta necesidad acabamos resolviéndola mediante la creación de procesos de intercambio de datos entre las aplicaciones, lo que en el sector conocemos como interfaces de integración o procesos de ETL.

Este modelo es utilizado por la gran mayoría de empresas y es muy rápido y efectivo si el número de aplicaciones de nuestra empresa es muy pequeño o bien no requieren intercambiar grandes cantidades de información.
Pero ¿Qué sucede cuando el número de aplicaciones o el número de datos crece?, la situación en esas circunstancias empieza a complicarse, lo que antes eran unos cuantos interfaces empiezan a crecer de forma exponencial y en muchas ocasiones nos encontramos con lenguajes de integración diferentes y necesidades de programación muy específicas. Os pongo algunos ejemplos muy típicos:
Empresas que necesitan extraer datos de su Mainframe o transaccional y pasarlo sobre sistemas medios o operacionales, en estos casos suele ser necesario disponer de programadores Cobol que permitan extraer la información del Mainframe y de programadores PL/SQL para poder volcar luego esa información sobre nuestras bases de datos operaciones, por ejemplo Oracle o SQL.
Procesos de comunicación mediante estándares tipo Swift, EDI, Sepa, etc. En estos casos es necesario disponer de un equipo de desarrolladores que extraigan la información de las cadenas swift o EDI y las conviertan a XML u otro estándar para luego ser descompuestas y enviadas a nuestras aplicaciones.
Y por último, el ejemplo que ha revolucionado el mundo de la integración de datos, la creación de un Data Warehouse para BI. En este caso es necesario recopilar información de varias aplicaciones o silos de datos, tratarla, transformarla y volcarla por un último en un repositorio donde luego será analizada por nuestra aplicación de Business Intelligence. Este proceso ha de ser automatizado y repetido periódicamente para refrescar los datos que luego serán analizados.
El tratamiento de todos estos procesos de integración ha motivado que las empresas tengan un número muy elevado de scripts o procesos de integración, en empresas medianas o grandes podemos hablar de más de 1000 o 1500 scripts, que a su vez conllevan un mantenimiento elevado y una falta de flexibilidad o agilidad a la hora de introducir cambios. Imaginemos un típico escenario donde nuestro repositorio de Data Warehouse se encuentra sobre una base de datos SQL, ¿Qué pasaría si la dirección decide reemplazar esta DDBB por Oracle o Teradata por motivos de coste, rendimiento, escalabilidad, etc?. Como os podéis imaginar deberemos cambiar todos los scripts para que ahora apunten a esta nueva base de datos y ¿que sucede sí cambiamos una tabla?, deberemos analizar todos los scripts que se ven afectados, ¿y si nuestra dirección nos pide un nuevo informe o modifica un informe de BI existente?, ¿podremos analizar el impacto sobre nuestros procesos de integración?.
Todas esta problemáticas son las que han hecho aparecer en el mercado lo que conocemos como herramientas de ETL (Extract, Tranform and Load), en su inicio y que a día de hoy han pasado a ser herramientas muy potentes pensadas para entender la integración como un concepto estratégico para la empresa y como una vía para mejorar nuestra agilidad, flexibilidad ante el cambio y la innovación y una forma de reducir costes de integración, desarrollo y mantenimiento.
Pues sobre estos temas y muchos otros relacionados con la integración como la calidad de datos iremos centrándonos en este blog.

Un saludo.

Bienvenida

Hola a todos,

Viernes, 14 de marzo de 2008. Después de 20 años en el sector hoy me he decidido a crear este blog donde me gustaría compartir con todos vosotros las experiencias, consejos, información y comentarios que he ido recopilando durante los últimos años en los que me he dedicado a la consultoría y asesoría tecnológica, orientada principalmente a procesos de integración y calidad de datos.
En este primer artículo de bienvenida quiero explicaros un poco la orientación que me gustaría darle al blog, así como que os podéis esperar de él.
Lo primero de todo es destacar que este blog no pretende ser de un alto contenido técnico, todo y que por los temas que se tratan, deberemos recurrir en algunas ocasiones a cuestiones técnicas.
El tipo de artículos que os iré escribiendo se enfocan más a la consultoría o asesoría sobre soluciones de negocio y políticas de arquitectura y gestión de proyectos. Pretende ser una ayuda para que os podáis plantear nuevas soluciones tecnológicas, nuevos enfoques de negocio o bien simplemente como apoyo para justificar inversiones de proyecto o metodologías delante de vuestra dirección o superiores.
El objetivo es ambicioso, así que espero no fracasar en el intento. Aunque esto sólo el tiempo y vuestras visitas podrán responder a ese temor.
En cuanto a mi experiencia en el sector, os relataré brevemente. Llevo dedicándome a esto que genéricamente llamamos informática desde el 1989 y he pasado por integradores y distribuidores como Sermicro, Microblanc, Morse o PowerData, por algunos fabricantes como WordPerfect (que tiempos) y Informatica Corporation, he trabajado también como profesor en el ICT (Institut Català de Tecnología) y AulaDat, también estuve un tiempo ganándome el sustento como consultor autónomo.
En todo este tiempo he ido ejerciendo diversas tareas y especializándome en diversos ámbitos hasta llegar a la integración de datos, como os podéis imaginar he pasado por técnico de campo, de hardware, de sistemas, product manager y consultor y he pasado por las siguiente etapas CNE de Novell, MCSE de Microsoft, especialista certificado de IBM en xSeries, pSeries y soluciones SAN, especialista ATI-Router de Allied Telesyn, VMware, y alguna otra cosilla que seguro que me dejo en el tintero porque no debe tener gran importancia.
Bueno, para este mensaje de bienvenida creo que ya me he extendido demasiado, así que os dejo y espero que os guste el blog.
Un saludo.
David.