Extendiendo el CDI

Como ya dije en la entrada «Nuestro cliente, centro del negocio» toda empresa que disponga de sistemas heterogéneos para la gestión de sus clientes, deberían pensar en implementar una estrategia  MDM (Master Data Management) y más concretamente CDI (Customer Data Integration)

No voy a repetirme en lo que ya escribí en la anterior entrada, ahora voy a hablar de lo que bajo mi humilde opinión debe aportar un proyecto de este tipo y más concretamente la herramienta CDC que elijamos.

– Mapeo de orígenes visual: esto que puede parecer algo obvio, no es siempre así. Algunas aplicaciones realizan esta operación de mapeo de campos orígenes por medio de scripts o ficheros de parámetros. Quizás para entornos cerrados donde no sean desplegados muchos cambios en las estructuras de orígenes, el impacto sobre el proyecto no sea alto. Pero si hablamos de entornos en los que se puedan dar cambios en estas estructuras, conocer de una manera rápida y visual el impacto de dicho cambio en nuestro modelo y sobre todo, poder realizar su modificación de forma rápida, ahorrará quebraderos de cabeza.

– Integración con las fuentes (nivel de integración): muchas compañías que se lancen a conseguir un modelo CDI, pueden tener ya herramientas de integración desplegadas para el soporte de otros proyectos. Sin embargo, si puede ser interesante que la herramienta elegida cuente con capacidades de integración, pudiendo ser estas internas o externas con la adaptación de módulos (aplicaciones externas que aporten esta funcionalidad). Si eligiésemos utilizar esta funcionalidad de la herramienta, podría ayudarnos al aislamiento de nuestro proyecto, haciendo así que todo esté desarrollado en un mismo entorno y evitando dependencias externas o complicados sincronismos de carga con otras aplicaciones.
Como es lógico esta capa de integracion ha de favorecer o solucionar el crítico apartado de la sincronización con los orígenes de datos y los destinos (si optamos por una estrategia activa de MDM), debiendo permitir su inclusión en un planificador de tareas (en ocasiones puede ser una aplicación corporativa) en caso de no aportar uno.

– Estandarización y calidad de datos: otra de las cosas a tener en cuenta cuando elijamos nuestra aplicación, es si cuenta con algún módulo que cubra la calidad de los datos. Es importante en un proceso de carga del MDM saber si en los orígenes de datos ya se aplican reglas de calidad y estandarización de los datos o si por el contrario, esto no ocurre. Si no se aplica (en la mayoría de los casos), nuestro entorno de MDM se estaría enfrentando a un problema de calidad a la hora de obtener el registro maestro. Por ello, algo que siempre se propone en este tipo de proyectos, es la aplicación de reglas de calidad de datos que permitan cruzar con diccionarios (de direcciones, tipos de empresa, etc.) y evaluar el contenido (perfilado de datos) de los campos utilizados con el fin de marcarles unos valores  de datos estándar. Un caso típico, son los campos con valores vacíos, a NULL o «ceros».

– Multi Dominio: esto significa que podremos crear más de un entorno MDM, es decir, no sólo centrándonos en los clientes, también podríamos crear una visión unificada de todos aquellos productos y/o servicios distribuidos a en los sistemas de inventario (esto suele darse mucho en las industrias farmaceúticas o retail). Si nuestro caso es un entorno CDI puro, no siempre es necesario disponer de una herramienta multi dominio, pues esta característica suele encarecer la misma. Ahora bien, si pese a pretender obtener la vista 360º de los clientes, queremos tener silos aislados en distintas áreas de la compañía, esta característica, nos permitiría dicho aislamiento.

– Entorno de usuario de negocio Web: una vez que se quiera desplegar la herramienta MDM, el HUB, será puesto a disposición inicialmente de un conjunto de personas de negocio muy específico. Por ello siempre que sea posible, evitaremos que el entorno de usuario de negocio deba ser «instalado», permitiendo acceder al mismo por medio de una Web.

– Administración de usuarios con perfiles y permisos: como es lógico, ha de existir la posibilidad de crear distintos roles de aplicación, pues tendremos usuarios de visualización y otros que con permisos «mayores» puedan realizar cambios en los datos del modelo.

– API para integración con aplicaciones: que la herramienta elegida cuente con una API (Application Programming Interface) que permita, bien con el desarrollo de módulos, bien, por disponer ya de un conjunto de desarrollos propios la integración o reutilización de parte de la misma. Muchas aplicaciones disponen de un una serie de objetos de programación creados para poder ser reutilizados en aplicaciones externas. Así mismo, tiene ejemplos o incluso código fuente pre-desarrollado que con pequeñas modificaciones puede ser utilizado. Un ejemplo de esto, sería la posibilidad de incorporar pantallas de visualización unificada del cliente (en algunas aplicaciones esto se muestra de manera gráfica con posibilidad de «navegar» entre los datos), embebidas en nuestros CRMs y  ERPs en la compañía, de tal manera que los usuarios de éstas aplicaciones dispongan, sin moverse de su entorno de trabajo, de la vista 360º del cliente.

– Web Services para comunicación con aplicaciones:  al igual que comentábamos la posibilidad de contar con una API para su integración con las aplicaciones, también es más que recomendable que disponga de la capacidad de integración vía Web Services. Esto por ejemplo, permitiría a los distintos orígenes de datos, enviar las actualizaciones de datos por medio de estos interfaces, ahorrando así un desarrollo en un entorno más complejo. Del mismo modo, estos Web Services, permitirían esa sincronización con los orígenes cuando (en un entorno MDM activo) algún dato fuese modificado en el HUB de clientes.

– Escalabilidad y alta disponibilidad: finalmente si el entorno MDM es desplegado en toda la compañía y comienza a ser utilizado de forma «extendida» en las aplicaciones CRMs, ERPs, gestores de campaña, entornos de BI etc. terminará por ser un elemento estratégico para negocio. Esto unido a posibles adquisiciones de datos o incorporación de nuevos orígenes, terminará por ubicar al entorno de software / hardware que dé soporte al MDM en los considerados servicios críticos. Por este motivo es muy importante, que la aplicación que elijamos, tenga la capacidad de configurarse como un entorno de alta disponibilidad, si es necesario, distribuyendo tanto la base de datos como la aplicación en diferentes entornos de hardware.

Como es lógico podríamos extender mucho más esta entrada hablando más detalladamente de cada una de las capacidades. Pero, no pretendo más, que dar unos pequeños indicios de lo que bajo mi punto de vista, podemos exigirle a una herramienta MDM.