{"id":91837,"date":"2018-07-11T12:19:33","date_gmt":"2018-07-11T10:19:33","guid":{"rendered":"http:\/\/www.agendaempresa.com\/?p=91837"},"modified":"2018-07-11T12:49:32","modified_gmt":"2018-07-11T10:49:32","slug":"articulo-opinion-michael-lamoureux-synertrade-estan-sus-datos-orquestados-poder-combinarlos-formar-bonita-melodia","status":"publish","type":"post","link":"https:\/\/www.agendaempresa.com\/91837\/articulo-opinion-michael-lamoureux-synertrade-estan-sus-datos-orquestados-poder-combinarlos-formar-bonita-melodia\/","title":{"rendered":"\u00bfEst\u00e1n sus datos orquestados para poder combinarlos y formar una \u201cbonita melod\u00eda\u201d?"},"content":{"rendered":"

Seguramente, tras la lectura del t\u00edtulo de este art\u00edculo, se encuentre completamente confundido, es normal que haya sucedido algo as\u00ed. Podr\u00eda haberlo titulado \u201cArmonizaci\u00f3n de datos\u201d, pero estoy convencido que de igual forma resultar\u00eda dif\u00edcil de entender lo que aqu\u00ed vamos a tratar.<\/p>\n

\n

T\u00e9cnicamente, nos referimos al esfuerzo por combinar datos, procedentes de diferentes fuentes, <\/strong>para permitir una visi\u00f3n consistente del conjunto de informaciones y, as\u00ed, proporcionar a los usuarios una herramienta de an\u00e1lisis m\u00e1s comprensible.<\/p>\n

Empecemos por definir el concepto \u201ccombinar\u201d. El concepto es sencillo pero su ejecuci\u00f3n no lo es tanto, depende mucho de la estructuraci\u00f3n de los datos. Se consideran estructurados cuando existe una relaci\u00f3n bien definida entre los mismos, semiestructurados cuando las relaciones se realizan con campos de metadatos o de notas y adem\u00e1s se combinan con alg\u00fan dato no estructurado, mientras que los completamente desestructurados son los datos procedentes de textos, archivos de audio, v\u00eddeo, etc. Por lo tanto, si una fuente est\u00e1 desestructurada y otra no, se ha de saber contestar a la t\u00edpica pregunta: \u00bfc\u00f3mo se combinan?<\/strong><\/p>\n

Por otro lado, los datos pueden estar almacenados en diferentes formatos: archivos planos o Excel con macros, bases de datos orientadas a columnas, sistemas de bases de datos relacionales tradicionales, nuevas bases de datos orientadas a objetos o bases de datos NoSQL modernas.<\/p>\n

Siempre se ha de tener en mente que cada base de datos puede almacenarse con un conjunto de caracteres diferentes <\/strong>(ANSI, ISO, Unicode, etc.) y utilizar diferentes formatos para sus n\u00fameros enteros y reales<\/strong> (incluso puede haber diferentes n\u00fameros de bits y diferentes usos para el bit inicial o final, por ejemplo el que representa el signo de un n\u00famero).<\/p>\n

Si puede discriminar entre los datos estructurados, semiestructurados y no estructurados y transformarlos a filas, columnas, en definitiva, relacionarlos, y ponerlos en un almac\u00e9n de datos masivo (virtual), relacion\u00e1ndolos, entonces tan solo estar\u00e1 en la fase inicial de armonizaci\u00f3n de datos.<\/p>\n

El hecho de que pueda unificar los datos no significa que pueda hacer algo \u00fatil con ellos. \u00bfPor qu\u00e9? <\/strong>cuando tiene datos en diferentes sistemas, tiende a tener datos duplicados y hasta que no se depure la informaci\u00f3n para eliminar dichos duplicados, cualquier informe que ejecute ser\u00e1 incorrecto e in\u00fatil.<\/p>\n

\u00bfPor qu\u00e9 se llega a tener tantas \u201ccopias\u201d? Ello sucede cuando se manejan datos de proveedor para tareas de planificaci\u00f3n de necesidades (un sistema MRP), pero tambi\u00e9n se recogen datos de detalle de productos o de ubicaciones en stock (un sistema ERP), o los datos relativos a pagos (en sistemas de Cuentas a Pagar), o las informaciones espec\u00edficas de productos terminados (en Cat\u00e1logos), o relativas a negociaciones con proveedores (aplicaci\u00f3n eSourcing), o concernientes a los rendimientos de las relaciones con nuestros proveedores (un SRM), o las incidencias acontecidas con productos comprados, o el repositorio de contratos de compras, o la gesti\u00f3n de riesgos de proveedores (donde se recopilan m\u00e9tricas internas y datos de terceros ) o sus facturas, etc, en definitiva, un caos, \u00bfverdad?<\/p>\n

\u00bfNo ser\u00eda m\u00e1s sencillo tener identificados a los proveedores b\u00e1sicos, con su identificador, su denominaci\u00f3n, contacto, etc? Estamos hablando de cambiar el trabajar con muchas copias de una misma informaci\u00f3n en funci\u00f3n del \u00e1rea de aplicaci\u00f3n, a trabajar con un \u00fanico registro, unificado y sin duplicidades. \u00bfPor qu\u00e9 no se ha planteado la unificaci\u00f3n? Quiz\u00e1s por la laboriosidad que supone el unificar dichas informaciones. Necesitar\u00e1 identificar las informaciones duplicadas, verificar cu\u00e1les son correctas o incorrectas, y reemplazarlas por una \u00fanica informaci\u00f3n actualizada, y todo ello para cada registro, encontr\u00e1ndonos normalmente con miles de registros (proveedores, producto\u2026). \u00a1No es tarea f\u00e1cil!<\/p>\n

Pero incluso si logra hacer esto, encontrar\u00e1 que todav\u00eda existen vac\u00edos de informaci\u00f3n que requerir\u00e1 de un enriquecimiento de la misma a partir de fuentes externas de informaci\u00f3n. Posteriormente, habr\u00e1 que considerar todos los problemas derivados de la sintonizaci\u00f3n de los datos unificados frente a los capturados desde fuentes adicionales (v\u00eda EDI\u2026). Es decir, se asumir\u00e1 siempre que faltar\u00e1n datos. Por lo tanto, el enriquecimiento y la actualizaci\u00f3n tambi\u00e9n llegan a considerarse un desaf\u00edo. <\/strong><\/p>\n

Sin embargo, incluso cuando consigue:<\/p>\n