Integración de datos B2B

Hola a todos,

Cuando hablamos de integración de datos, una gran mayoría de personas no pueden evitar pensar en aprovisionamiento de datos para entornos Data Warehouse, una de las misiones que persigo con este blog es conseguir ampliar esa visión e intentar hacer reflexionar sobre las necesidades de movimiento de datos (integración) a lo largo de nuestra organización y dar a conocer que otras soluciones o proyectos pueden ser gestionados o abordados con una herramienta de integración.

En esta nueva entrada quiero analizar lo que conocemos como Integración B2B o como B2B Data Gateway o B2B Data Integration.

En esencia el concepto es muy sencillo, partimos de la idea que toda empresa necesita poder compartir datos o mover datos entre los diferentes departamentos que componen esa empresa, esos movimientos de datos son lo que conocemos como integración empresarial (Enterprise Data Integration), pero las necesidades de comunicación no terminan dentro de los muros de la empresa, cada día más estas necesidades se extienden fuera de la empresa motivadas por la necesidad de intercambiar información con proveedores, distribuidores, organismos reguladores, organismos gubernamentales, etc. Este tipo de comunicación que efectuamos con terceros es lo que conocemos como comunicación de empresa a empresa (Business to Business o B2B) y cuando nos centramos en los intercambios de información entre todas las partes es lo que llamamos B2B Data Integration.

Me gusta empezar con esta pequeña aclaración sobre el concepto de B2B Data Integration porque en muchas ocasiones se confunde el intercambio de datos entre distintas entidades con la gestión de cadenas de mensajería o la encriptación de canales de comunicación. No es lo mismo un TiBCO, un WebMethods o un IBM MQ que una herramienta de integración de datos, todo y que en algunas ocasiones los gestores de cadenas de mensajería y los EAI puedan ofrecer funcionalidades básicas de integración de datos.

El origen del problema.

El B2B no es un invento de hoy, desde que existen las empresas ha sido necesario intercambiar información entre ellas, esta comunicación ha ido variando a lo largo del tiempo y hemos pasado del correo postal al teléfono, luego al fax, al correo electrónico, a la mensajería electrónica, a la web, etc. En resumen el intercambio de información ha existido y existirá siempre que intervengan dos o más empresas a la hora de establecer un negocio.

El problema nace cuando nos encontramos que nuestra empresa necesita intercambiar información con múltiples empresas para realizar pedidos de material, realizar trámites bancarios, gestionar movimientos de mercancías, realizar pagos de impuestos, etc.

Nos encontramos con la problemática de que cada uno de estos intermediarios solicita la información en un medio diferente, ya sea por fax, por correo electrónico, por teléfono, por carta, con una hoja Excel, con un PDF, etc., y nosotros necesitamos gestionar nuestra información para adecuarla al canal de comunicación que nuestro colaborador nos solicita. Estos procesos de intercambio de información son muy costosos para la empresa y en muchas ocasiones ocasionan perdidas de efectividad, competitividad, negocio, etc.


La solución es sencilla y como siempre en estos casos la solución es bien simple, nos servimos de las nuevas tecnologías, de las posibilidades de comunicación que nos ofrecen las nuevas redes y…

¡Creamos un estándar de comunicación ¡

De tan simple que es la solución, supongo que decidimos que era demasiado buena idea y nos creamos nuestro estándar de comunicación propio en base al mercado, nuestras exigencias de seguridad, nuestras exigencias de información, ideología, país, etc. Así que a día de hoy la situación es que dependiendo de con quien nos hemos de comunicar podemos utilizar diferentes “estándares”, ya sea si queremos intercambiar información con nuestros proveedores, distribuidores, bancos, gobierno, etc., nos podemos encontrar con la necesidad de utilizar:

• HL7, SWIFT, AL3, HIPAA, EDI–X12, EDI-Fact, FIX, MVR, ASTM, Cargo IMP, VSM, ACORD XML, LegalXML, IFX, cXML, ebXML, HL7 V3.0, SEPA…

Un caso muy curioso de la aplicación de estándares es el de EDI, EDI es utilizado para comunicación con proveedores en las industrias de Retail, pues ellos han rizado el rizo ya que incluso utilizan una versión diferente o personalizada de EDI dependiendo de la empresa que lo implementa y te puedes encontrar, por ejemplo, que sí tú eres un fabricante de yogures, recibes un pedido EDI formateado de forma diferente dependiendo de si viene del supermercado 1, del hipermercado 2 o de la gran superficie 3. Lo mismo sucede a la inversa, cuando envías los datos de facturación del pedido a tu distribuidor, etc.

Estas mismas discrepancias dentro del estándar te las puedes encontrar con XML, SEPA, Swift, etc.

Y si nos salimos de los estándares el panorama no es mucho mejor ya que a día de hoy te puedes encontrar con necesidades de intercambio de datos con entidades gubernamentales, con empresas de venta de datos de todo tipo, con analistas de mercado, con servicios públicos, etc.

Por poner unos cuantos ejemplos, las grandes farmacéuticas recopilan datos de venta de fármacos a través de IMS, la información les puede llegar como fichero plano, como hoja Excel, como Cubo OLAP, etc. Los bancos y cajas intercambian información de listas de terrorismo (OFAC), de listas de personas expuestas políticamente (PEP), información de morosidad (RAI, ASNEF), cotización, normativa, etc. Las empresas de servicios intercambian información con la administración pública para información sobre estado de los embalses, calidad del agua suministrada, etc. Las aerolíneas y otras entidades de transporte intercambian información con los servicios meteorológicos para poder trazar rutas de vuelo, calculo de consumos de combustibles, etc.

Como podéis imaginar la cantidad de información que intercambiamos con el exterior es muy grande y cada día más utilizamos nuevos canales de información y necesitamos de nuevos estándares de comunicación. La pregunta que supongo o espero que muchos de vosotros os estéis haciendo ahora es ¿Cómo damos respuesta a esas necesidades de intercambio de información?, ¿Cómo se hace a día de hoy?.

A día de hoy las empresas gastan un gran porcentaje de su presupuesto de IT en el mantenimiento de equipos de desarrollo para mantener todos estos canales de comunicación, para programar procesos que permitan automatizar estos canales y para adecuar estos a los cambios constantes del negocio y del mercado.

Una forma de dar respuesta a estas necesidades y reducir los costes de desarrollo para la comunicación entre empresas es la utilización de herramientas de integración B2B. Pero una vez introducido el problema, el detalle de que beneficios nos ofrecen estas herramientas lo voy a dejar para el siguiente artículo, mientras lo termino me gustaría recibir comentarios al respecto de esta problemática, ¿os encontráis frecuentemente en esta situación?, ¿es un problema para vuestra empresa la comunicación B2B?, ¿Cómo lo solucionáis?...

Pregunta de Juan Vidal

Hola a todos,

He recibido un comentarío de Juan vidal donde me hace la siguiente pregunta:

"Quería hacerte una consulta referente a herramientas de integración de datos. He trabajado con las herramientas de Data Integration comerciales como SAS y Oracle. Estamos empezando a evaluar herramientas open source, lo que es un mundo totalmente desconocido para mí. La herramienta en cuestión es Pentaho y estamos viendo su solución de data integration que se llama Kettle. Quería preguntarte si conoces esta herramienta y tienes referencias."

Os pongo aquí la respuesta ya que creo que puede ser interesante para todos comentar este tema con mayor profundidad.

Respecto de la pregunta que me formulas, es la pregunta del millón, yo no he trabajado directamente con Kettle, pero sí que he investigado un poco y he cruzado bastantes comentarios con diferentes integradores y fabricantes de software acerca de las herramientas de integración OpenSource ya sean de Pentaho o de Talend que son las más conocidas.

Normalmente los fabricantes te dicen que el OpenSource y en concreto las herramientas de Pentaho no son tan baratas como parecen y que ofrecen muchos inconvenientes en cuanto a funcionalidades y soporte.

Por otra parte los integradores no confían demasiado, ya que normalmente argumentan que suelen ser poco estables, que el desarrollo suele ser bastante complejo y que es difícil disponer de técnicos en el mercado que conozcan estas herramientas.

Por último los analistas como Gartner o Forrester recomiendan utilizar estas herramientas sólo para operaciones básicas de ETL y que cuando se desea una herramienta que ofrezca una visión empresarial y unas capacidades de integración que no se limiten a mover datos entre las principales bases de datos recurramos a herramientas más consolidadas como Informatica PowerCenter, IBM Integration Server (antes DataStage), SAS, Oracle Data Integrator, etc.

Mi experiencia me dice que normalmente los clientes que recurren a estas herramientas lo hacen basándose principalmente en el precio y luego disponen de recursos propios para dedicar al aprendizaje y al desarrollo con las mismas.

En este caso yo lo que te aconsejaría es que evaluarás que funcionalidades requieres para el proyecto que estáis evaluando y luego hagas una valoración un poco más a medio plazo viendo que otros proyectos se pueden beneficiar de tener una ETL y que funcionalidades puedes requerir en un futuro, ya sea a nivel de conectividad (conectores de aplicación, web services, intercambio de ficheros, colas de mensajería, etc) o a nivel de funcionalidades como Calidad de Datos, Alta Disponibilidad, gestión de metadatos, trazabilidad, etc. Cuando tengas esa lista confeccionada comprueba si las herramientas de OpenSouerce cumplen con los requerimientos que tenéis para el proyecto actual y con los que podáis tener a medio plazo.

Sobretodo no os ceguéis con el precio o con el ROI, evalúa primero muy bien las funcionalidades que necesitas y que necesitarás, ya que una vez que adquieras la herramienta la inversión la tendréis que amortizar a 3 ó 5 años y luego te será muy difícil justificar el reemplazo de la herramienta que hayáis elegido si aparecen nuevos proyectos y no puedes abordarlos con la ETL que elegisteis.

Te pongo un ejemplo que viví yo en un cliente, bastante grande por cierto. El responsable de BI de este cliente eligió una herramienta de ETL en su día para aprovisionar su DataWarehouse, al cabo de 1 año aproximadamente desde dirección solicitaron poder realizar informes operacionales y cuadros de mando que reflejarán la situación de las ventas a tiempo real. Eso significa disponer de una ETL que pudiera trabajar en Real Time, con capacidades de captura de cambios y que pudiera acceder a recuperar datos del portal online de venta (a través de web services). Se planteó la compra de una nueva herramienta que ofreciera esas funcionalidades y en una de las reuniones de evaluación de la herramienta el CIO preguntó al director de BI ¿Por qué había que cambiar la herramienta de ETL?, la persona de BI le explico que necesitaba esas nuevas funcionalidades, a lo que el CIO le volvió a preguntar ¿Por qué no se compró una herramienta con esas funcionalidades hace 1 año? Y el responsable de BI le dijo que compraron esa herramienta porque era más barata.

No te puedes imaginar la bronca que recibió por parte del CIO, entré las cosas que le dijo hizo una reflexión que considero muy interesante fue algo del tipo “como puedes decir que era más barata si a lo que nos costo la herramienta en su día has de añadir el coste de formación en esa herramienta, más los costes de desarrollo, más el coste de la herramienta que hemos de comprar ahora, más el coste de formación de la nueva herramienta, más el coste de cambio de todos los procesos a la nueva herramienta…” y concluyó diciendo que no había tenido en cuenta la evolución del negocio, las necesidades a futuro y los costes de cambio.

Cómo conclusión te diría que busques aquella ETL que te ofrezca todo lo que necesitas (ahora y a medio plazo), que no os centres sólo en el coste de adquisición, mira también desarrollo, soporte, disponibilidad de integradores o Partners con experiencia en el uso de la herramienta, referencias, etc. Sí todo lo que necesitas se cumple lo de menos es sí es OpenSource o no.

Por último os recomiendo un documento de Gartner títulado "Open Source in Data Integration Tools" que ilustra lo que os comentaba. También os dejo un enlace que habla del mismo tema.

"http://searchdatamanagement.techtarget.com/news/article/0,289142,sid91_gci1353613,00.html"

Un saludo.

¡ Sí funciona, mejor no tocarlo!. Un error grave.

Desde que estoy trabajando en el sector he escuchado esta frase en un sinfín de ocasiones, siempre es utilizada como justificación, sobretodo por aquella gente más veterana en el sector, y siempre he tenido la misma impresión, ¡ Que grave error!.

Creo que esa frase evidencia la tendencia de los últimos tiempos de muchos profesionales y departamentos de IT ya que considero que esta máxima es la escenificación del inmovilismo y de la falta de inquietudes de nuestro sector.

Siempre hemos de preguntarnos el porqué de cada cosa y cuando las cosas funcionan, la pregunta que deberíamos formularnos es ¿podemos hacerlo mejor? o ¿sí lo cambiamos funcionará más rápido, de forma más eficiente, con menos recursos, etc?

Aquellos profesionales con más éxito, aquellos departamentos de IT más representativos, ejemplares y que ofrecen una mayor utilidad a la empresa son aquellos que son capaces de cuestionarlo todo, de buscar alternativas para mejorar, de invertir en hacer cosas que permitan mejorar los procesos, ahorrar costes o facilitar el trabajo en la organización, todos ellos ofrecen un valor añadido a su empresa y permiten mejorar el funcionamiento del negocio que siempre acaba redundando en un beneficio, monetario, operativo u organizativo al negocio.

Por eso desde hoy he decidido revelarme cada vez que escuche esa famosa frase y cuestionar en cada caso si merece o no la pena tocarlo todo y que hasta ahora haya funcionado.

Ejemplificando sobre el tema de este blog diríamos que porque no hemos de plantearnos cambiar todos los procesos que realizamos hoy en día de forma manual y buscar como hacerlos de una forma más eficiente, ya sea a través de una herramienta de integración (ETL) o bien con procesos automatizados de limpieza, estandarización o desduplicación de datos (Data Quality).

De esta forma igual podemos conseguir eliminar esos cientos o miles de programas PL/SQL, Cobol, Java, XML, etc que se encargan de mover datos dentro de nuestra organización (interfaces ETL) y sustituirlos por un software que permita administrarlos de forma centralizada, auditarlos, editarlos, documentarlos, reutilizarlos, analizarlos, etc, en busca de una mayor eficiencia y coherencia en nuestros procesos y sí de paso con ello nos ahorramos problemas de codificación, de reutilización, de necesidad de especialistas en diferentes lenguajes, problemas de perdida de conocimiento por fugas de desarrolladores o problemas de incompatibilidad que en algunos casos nos impiden avanzar o implantar nuevos proyectos, quizás sólo en ese momento nos habremos dado cuanta que el cambio merecía la pena todo y que como se hacía hasta ese momento funcionaba.

¡ Sí funciona, pensemos como funcionaría mejor!

Sequía o crisis

Hola a todos,

Después de un tiempo sin postear ninguna entrada nueva, me he decidido, por fin, volver al trabajo.
Han sido unos meses que podríamos considerar de sequía creativa o bien de crisis de ideas, pero lo cierto es que las razones han sido muy diferentes. El trabajo y sobretodo los estudios me han forzado a permanecer en silencio durante un largo tiempo, así que sin más prolegómenos y justificaciones vamos a ponernos manos a la obra.

Hasta ahora sólo hemos hablado de integración de datos y de calidad, así como conceptos relacionados con ambos temas, a partir de ahora me gustaría poder ahondar un poco más no sólo en estas temáticas sino en otras que se encuentran muy relacionadas con este tipo de proyectos, como pudieran ser la utilización de los datos en las empresas y los diferentes sectores, las problemáticas que envuelven a algunas soluciones sectoriales, así como otros considerantes que nos hacen inclinarnos por soluciones de integración o de calidad de datos.

Estoy pensando en temas como gestión de riesgos, blanqueo de dinero, prevención del fraude, etc para entidades bancarias o bien en temas como gestión de la cadena de suministros, RFID, Scada, BAM, etc en el sector retail.

Naturalmente habrán más temas, así que os sugiero que aquellos lectores que consideran que este blog puede ser interesante, así como los contenidos que ahora quiero abordar, os animéis a postear comentarios sobre estos temas, así como sugerencias de nuevos temas.

Espero vuestras sugerencias.

Un saludo.

Calidad de Datos vs Resolución de Identidades II

Las soluciones de resolución de identidades (identity resolution) se están conviertiendo cada día más en un componente clave de cualquier solución de calidad de datos, más si cabe en un mundo cada día más globalizado, donde los procesos de identifiación de lcientes, calidad, etc ya no están supeditados a un solo idioma.

El concepto de Identity resolution es muy sencillo, el objetivo es poder identificar a un contacto de forma correcta. Pero bajo este concepto aparecen diversas problemáticas que hemos de ser capaces de solucionar. Estas problemáticas pueden ser causadas por diversos motivos, por ejemplo errores de entrada en los datos, diferencias entre idiomas, errores de secuencia, concatenación de nombres, etc.

Entre las problemáticas más comunes tenemos:
Sequence errors. Son los errores producidos por una alteración en el orden en que los datos son entrados, por ejemplo podemos tener una entrada donde el nombre del contacto aparezca como Stephen Smith o como Smith Stephen.
Concatenated names. Es muy típico encontrarnos con nombre que pueden escribirse de forma separada o no, produciendo así errores de concatenación como Ana María o Anamaría.
Nicknames and aliases. Los apodos, alias o diminutivos son otro de los componentes que pueden causar errores, un ejemplo muy típico en España puede ser José, Josep, Pepe, Pep, etc o en el caso de nombre ingleses también podemos encontrarnos con Chris, Christine, Christoher, Tina, etc.
Abbreviations, cuando se introducen datos desde el Data Entry cada persona tiene su forma particular de introducir abreviaciones o expresiones así nos podemos encontrar ejemplos como Mª/María, Mkg/Mkt/Marketing, Dpt/Dpto/Departamento, Tel./Tlfno./Tlfo/, etc.
Unpredictibe use of initials, el uso de iniciales en la entrada de nombres, caso como J. M. Garcia puede ser interpretado como José Manuel, Juan Manuel, José María, etc.
Phonetic errors or Foreign sourced data, los datos de personas de otros idiomas pueden ser malinterpretados ya sean por errores fonéticos o simplemente por traducciones del nombre en el idioma original, en este punto me gusta exponer siempre el ejemplo del nombre ucraniano Шевченко que puede ser escrito en Inglés como Shevchenko, en francés como Chevtchenko y en polaco como Szewczenko. Hay un ejemplo que la gente de España tiene muy presente y que todos recordaran como insistía el político Carod Rovira en refirmar que su nombre es Josep Lluís y no José Luís.
Estos son sólo algunos de los errores típicos que nos podemos encontrar a la hora de trabajar con identidades, existen muchos otros como errores de escritura, prefijos, Missing tokens, transposed characters, etc.

El gran problema que nos encontramos es que las herramientas de calidad de datos operan sólo con aquellos datos que pueden estandarizar y limpiar y muchos de estos casos no son fácilmente estandarizables, de esta forma todos aquellos datos que se consideran no estandarizables o incorrectos no son utilizados a la hora de realizar una desduplicación o un matching, motivando errores a la hora de detectar duplicados o identificar un contacto.

Otra de las grandes problemáticas es la imposibilidad de realizar comparaciones entre módulos de diferentes idiomas, de esta forma se hace imposible cruzar un listado de clientes inglés con un listado español para encontrar duplicados, ya que los diccionarios utilizados para matching suelen ser diferentes y no permiten ese tipo de desduplicación.

Las soluciones de Identity resolution solucionan esta problemática permitiendo detectar todo estos errores, para ello utilizan todos los datos, estén o no estandarizados y diferentes técnicas de detección y comparación de datos.

Las herramientas de calidad de datos suelen utilizar técnicas de lógica difusa (fuzzy logic) para realizar el matching de registros, en el caso de las herramientas de Identity resolution se utiliza una combinación de técnicas y algoritmos.

Este tipo de soluciones puede ser muy útil en diferentes sectores y diversos tipos de proyectos. Los proyectos más comunes que pueden necesitar de soluciones de resolución de identidades son:
• Customer Inquiry
• “Customer” Identification
• Account Number Confirmation
• Data Warehouse & Account Consolidation
• Marketing Database
• Mail Campaigns
• Certified Global Address Standardization
• Call Center
• Duplicate Discovery & External File Matching
• Address Searches
• Directory Inquiries
• Human Resources
• New Customer / Account Screening
• Credit Card / Loan Application Screening
• Fraud Investigation
• Welfare Eligibility & Tracking
• Healthcare & Community Services
• Police, Court & Intelligence Systems
• Tax Systems
• Customs & Immigration
• Company & Business Registers
• Patent & Trade Mark Registers
• License & Vehicle Registers
• Data Warehouse & Data Consolidation
• Fraud Investigation & Debt Recovery
• Criminal Justice Information Systems & Criminal History Systems
• Persons of Interest
• Intelligence & Case Management Systems
• Missing and Runaway Persons
• Stolen Property
• Border Control
• Data Consolidation or Linking across Jurisdictions
• Patient Inquiry
• Provider Inquiry
• Disease & Pathology Tracking Registries
• Pharmaceutical or Poison’s Databases
• Immunization Database
• ID Confirmation
• Fraud Discovery & Investigation

Como podéis comprobar la lista es bastante extensa, todo y que a priori pudiéramos considerar que la resolución de identidades no es importante, son muchos los procesos que pueden verse beneficiados del uso de esta tecnología.

Me gustaría acabar este artículo explicándoos una anécdota que me ha sucedido este pasado Enero. Como os comento en enero tuve que realizar un viaje a Estados Unidos para una convención de empresa, al llegar al aeropuerto de Nueva York (JFK) me retuvieron en el control de pasaportes y me llevaron a una sala anexa. Cuando pregunte que es lo que sucedía me indicaron que debían hacer una comprobación rutinaria, media hora más tarde una amable policía me devolvió mi pasaporte y me explico que el problema había sido que tengo un nombre “demasiado común” y que habían tenido que cotejar la lista de personas sospechosas que aparecían con mi nombre con todos mis datos para asegurarse que no era ninguno de ellos, os podéis imaginar lo primero que me vino a la cabeza “necesitan un sistema de identity resolution”.