El costo oculto de los datos maestros

En el diagrama de arquitectura de cualquier proyecto corporativo, la integración entre dos sistemas se dibuja con una flecha limpia. En la vida real, esa flecha es una persona con tres planillas de Excel abiertas al mismo tiempo, café frío a las seis de la tarde y prohibición tácita de enfermarse — porque nadie más sabe traducir los códigos de las cadenas de retail ni habilitar los atributos de los productos nuevos.

Excel sigue siendo, nos guste o no, el bus de integración empresarial más usado de Latinoamérica.

💡 El costo de tener los datos maestros desordenados no se ve en ninguna parte. Está escondido en el trabajo manual de alguien que cubre la diferencia todos los días, hasta que intentas automatizar y la cuenta llega de golpe.

Un dato maestro es simplemente eso: la lista de quiénes son tus clientes y qué son tus productos, con los códigos y nombres que deberían significar lo mismo en todos tus sistemas. El problema es que casi nunca significan lo mismo. Y mientras una persona traduzca esa diferencia a mano, el desorden es invisible: los reportes cuadran, los pedidos entran, nadie levanta la mano.

No es un costo menor. Gartner estima que la mala calidad de datos le cuesta a una organización, en promedio, USD 12,9 millones al año (Gartner). El punto no es la cifra exacta, sino que casi nadie la ve: es un costo que no aparece en ninguna línea del presupuesto.

Hasta que decides automatizar. Ahí el costo oculto sale a la superficie, y suele ser más grande de lo que nadie imaginaba.

El caso en 30 segundos

• El problema: dos procesos críticos: diseño de producto y ventas retail, dependían de la carga manual de datos hacia el ERP, porque los maestros no coincidían entre sistemas.
• El hallazgo: en la primera prueba real del frente de órdenes, el 62% rebotó (174 de 277) por brechas históricas en los datos maestros.
• La solución: homologar los maestros y automatizar el traspaso de extremo a extremo, sin invadir la base de datos del ERP. Pipelines, una API propia y tablas de traducción explícitas.
• El resultado: hoy los dos procesos corren solos, con trazabilidad transaccional y cero carga manual. En su primera puesta al día en producción, el frente de órdenes cargó cerca de 2.000 pedidos en SAP de forma autónoma.

Quién es el cliente

Trabajamos con una empresa chilena de consumo masivo del rubro de alimentos y nutrición, con marca propia y un catálogo amplio: más de 700 artículos activos y más de 300 recetas y formulaciones de producto. Vende por tres vías a la vez: canal directo online, negocio B2B y cerca de diez cadenas de retail (supermercados grandes), y opera su backoffice sobre SAP Business One, con su infraestructura de datos ya montada en la nube.

Es una empresa que creció rápido y en varios frentes al mismo tiempo. Y como suele pasar cuando el negocio crece más rápido que su plomería de datos, terminó con dos procesos críticos sostenidos por trabajo manual, en dos áreas que no tenían nada que ver entre sí, salvo por la misma raíz.

Datos de producto. La empresa diseña sus productos en un sistema PLM (Product Lifecycle Management), pero esa información no llegaba de forma fluida a SAP. Habilitar un artículo, una receta, un proveedor o una cotización dependía de planillas formateadas y cargadas a mano.

Órdenes de venta retail. Cada cadena publica sus órdenes de compra en su portal B2B, en su propio formato, un estándar compartido le habría quitado todo el encanto al asunto. Una persona descargaba los archivos, traducía los códigos de tienda a códigos internos, calculaba factores de conversión de unidades a cajas, y digitaba los pedidos uno por uno.

Dos dominios distintos, un mismo costo oculto: los datos maestros no coincidían entre plataformas, y una persona pagaba la diferencia a mano, todos los días.

Los dos frentes: qué construimos?

A primera vista, integrar una ficha técnica desde un PLM no se parece en nada a procesar el pedido de un supermercado. El primero tiene pocas transacciones y muchos atributos; el segundo es un flujo masivo con precios volátiles, factores de embalaje y fechas de entrega. Pero al abrir el capó, los dos pedían el mismo patrón de solución: ordenar los maestros y después dejar el dato viajando solo.

Frente 1 — Datos de producto (PLM → SAP). Construimos un pipeline diario, sobre una arquitectura de extracción y transformación de datos (Airbyte y Airflow para orquestar, dbt para modelar, BigQuery como base), que extrae la información del PLM, la limpia y la consolida en cuatro entidades de negocio: artículos, recetas, proveedores y cotizaciones. La expusimos en una API propia, con un endpoint por entidad, autenticación y filtros por estado de integración. El partner de implementación de SAP consume esa API y carga la información al ERP, reportando de vuelta qué registros entraron limpios y cuáles quedaron con observaciones.

Frente 2 — Órdenes de venta retail (portales B2B → SAP). El flujo corre cuatro veces al día y hace el recorrido completo solo: captura los archivos desde los portales —incluido el formato propietario de una cadena grande, que desafiaba cualquier estándar—, traduce los códigos del retailer a códigos internos, aplica las reglas comerciales de cada cliente (venta por unidad o por caja, con factores que varían por producto) y envía cada pedido a SAP convertido en orden de venta. Las órdenes que fallan quedan registradas y se reintentan hasta resolverse.

Ordenar los maestros era la mitad del trabajo. La otra mitad era construir el software que los mantiene viajando solos, para que el costo no vuelva a esconderse en el Excel de alguien.

La prueba de la verdad: cuando 174 de 277 órdenes rebotaron contra la realidad

Antes de programar cualquier pipeline elegante, había que responder una pregunta engañosamente simple: ¿cómo sabemos que un producto en el portal del supermercado, o un atributo en el PLM, son exactamente el mismo código registrado en SAP?

Hicimos una primera prueba sobre un lote histórico de 277 órdenes de retail. El resultado fue un baño de realidad: 174 rebotaron en el primer intento. Un 62% de falla. En un examen es reprobar; en un proyecto de datos, es un martes cualquiera haciendo arqueología del software corporativo.

Ahí quedó a la vista el costo oculto. Las causas eran el desorden natural de sistemas que crecieron sin gobierno:

• Códigos de clientes del retail que sencillamente no existían en el maestro interno.
• Un código mal tipeado a la rápida años atrás, que nadie corrigió y que ya tiene antigüedad y derechos adquiridos.
• Productos identificados por código de barras en el archivo del supermercado, pero registrados por SKU interno en el ERP.
• Órdenes con descuentos comerciales que, al dividirse por unidades, entregaban decimales infinitos que hacían colapsar la validación de SAP.

Nadie diseñó ese desorden a propósito. Funcionaba porque la persona a cargo corregía esas inconsistencias de memoria, todos los días, gratis y en silencio. (Tuvimos la mala educación de exigir que las reglas estuvieran escritas).

Descubrir la brecha en la primera etapa fue el mayor acierto del proyecto. Siempre es infinitamente más barato pagar ese costo en una prueba de 277 filas que un viernes de cierre, cuando Finanzas pregunta por qué no cuadra la facturación.

Cómo se veía antes, y cómo se ve ahora

Tres decisiones de arquitectura donde le dijimos que no al camino fácil

En consultoría de datos hay dos formas de hacer las cosas: la rápida, para cerrar el contrato e irse; y la sólida, para que el sistema no explote en seis meses. Elegimos siempre la segunda.

1) Respetar las fronteras de los sistemas: exponer el dato vía API, no invadir el ERP. La tentación de escribir directo en la base de datos de SAP era grande. Nuestro CTO frenó esa idea en una frase: si hay un equipo administrando el ERP, nuestra pega es dejar el dato limpio en la puerta mediante una API, no meter mano en su infraestructura. Cada equipo quedó a cargo de su dominio, y la integración no se volvió una pieza frágil que se rompe con cada actualización de SAP. Cuando hay un partner de ERP de por medio, esta decisión ahorra semanas de conversaciones sobre de quién fue la culpa.

2) Tablas de traducción explícitas, no lógica escondida en el código. La salida fácil era escribir un bloque gigante de condicionales para cada cadena. Resuelve hoy y condena mañana: el conocimiento queda enterrado en el código y nadie del negocio puede auditarlo. Diseñamos tablas maestras explícitas y versionadas que traducen entre el código del cliente y el interno. Si mañana entra una cadena nueva, se agrega una fila — no se contratan horas de desarrollo.

3) Trazabilidad registro por registro, no una caja negra. El atajo clásico es programar el flujo para que ignore lo que no entiende y siga de largo. Los paneles quedan verdes y nadie molesta, hasta que en Finanzas descubren semanas después que faltan pedidos y nadie sabe desde cuándo. Implementamos trazabilidad por transacción: si una orden falla por un decimal mal redondeado, las demás siguen y esa queda marcada con un mensaje legible.

El impacto real en la operación

El éxito de un proyecto de datos no se mide en líneas de código escritas, sino en cómo cambió el día a día del negocio.

Dos procesos operativos sin carga manual. Copiar y pegar información entre sistemas dejó de existir como tarea. El traspaso diario desde el PLM y la ingesta de órdenes retail corren en segundo plano.

Cero error humano en el tramo crítico. La traducción de códigos y la conversión de unidades a cajas, donde un error se transforma directo en un pedido mal facturado, ya no depende del cansancio de nadie al final de la jornada.

Trazabilidad que responde preguntas del negocio. "¿Esta orden entró al ERP?" se contesta mirando un estado, no reconstruyendo la historia a mano.

Autonomía total para el cliente. Todo el código quedó en repositorios de la empresa. La prueba de fuego: el equipo interno incorporó cadenas de retail adicionales por su cuenta, agregando filas a las tablas maestras, sin pedir soporte.

¿Por qué el costo oculto de los datos maestros lo tienen casi todas las empresa?

Casi nunca es un problema de herramientas. Las herramientas suelen estar: un sistema para diseñar productos, otro para vender online, un ERP para facturar, un portal para recibir pedidos del retail. Cada uno se compró en un momento distinto, para resolver el dolor de un área distinta, muchas veces con un proveedor distinto.

Lo que casi nunca tiene dueño es el tramo del medio: el que hace que todos esos sistemas se pongan de acuerdo sobre quién es un cliente y qué es un producto. El equipo de datos entrega su tabla. El del ERP recibe sus archivos. Y el pedazo que conecta los dos mundos no aparece en el organigrama de nadie, así que lo absorbe una persona, con buen criterio y una planilla.

El crecimiento no crea el problema; solo lo apura. Mientras más sistemas y más volumen, más carga ese puente humano, hasta que un día no da abasto (o se toma vacaciones).

Ese es el costo oculto: no una línea en el presupuesto, sino un riesgo silencioso que solo se vuelve visible cuando intentas construir algo encima. Un CRM que hereda clientes duplicados. Una migración de ERP a la que no le calzan los códigos. Un modelo de analítica predictiva que, alimentado con datos traspasados a mano, no entrega respuestas malas de inmediato: las entrega equivocadas y redactadas con una seguridad envidiable.

Si estás pensando en implementar un CRM, migrar tu ERP o sumarle IA a tu operación, el consejo es el mismo: primero ordena tus maestros, y no te quedes en la tabla intermedia. El valor aparece cuando el dato llega operando solo hasta el destino final.

En Datalized nos especializamos en resolver esa franja incómoda del trabajo de datos, donde la teoría se junta con la operación real.
Cuéntanos el dolor operativo, no la especificación técnica, y te ayudamos a resolverlo.

Preguntas Frecuentes

¿Qué es un dato maestro y por qué importa tanto?

Es el registro de referencia de una entidad del negocio —un cliente, un producto, un proveedor— con su código único y sus atributos válidos. Importa porque todos los demás sistemas dependen de él: si el maestro está desordenado o inconsistente entre plataformas, cualquier reporte, integración o automatización que se construya encima hereda ese desorden.

¿Por qué es tan compleja la homologación de datos maestros?

Porque los datos se crean en silos operativos. Un mismo producto puede tener un nombre en el sistema de diseño (PLM), un código en el ERP y otro distinto en el portal del retail. Homologar implica crear la regla lógica y las tablas de equivalencia para que todos los sistemas entiendan que se trata de la misma entidad.

¿Cómo se detectan los errores de datos maestros antes de salir a producción?

Ejecutando pruebas con volúmenes de datos reales e históricos, no con datos de ejemplo ya limpios. Procesar un lote real saca a la superficie de inmediato los códigos faltantes, los errores de tipeo y las excepciones comerciales que no están documentadas.

¿Por qué es mejor una API propia que escribir directo en la base de datos de SAP?

Escribir directo en la base de datos de un ERP es un riesgo operacional severo: cualquier actualización del sistema puede romper las tablas internas. Una API propia actúa como una frontera segura que aísla los sistemas y hace explícito qué información se comparte y en qué estado.

¿Qué es la automatización de datos de extremo a extremo?

Es un flujo que extrae la información desde el origen, aplica transformaciones y validaciones de negocio, y la entrega directamente en el destino —un ERP o CRM— sin intervención humana en ningún tramo, con registro de estado en cada paso.

Sobre el autor

Luis Márquez es Analytics Manager en datalized desde 2024, tras desempeñarse como Advanced Analytics Lead y Advanced Analytics Engineer en la misma empresa desde 2020. Antes lideró integraciones de datos y proyectos de Business Intelligence para más de 30 clientes en BIWISER. Con cerca de 10 años de experiencia en integración de sistemas y arquitectura analítica, ha liderado proyectos de integración hacia SAP y otros ERP en retail, consumo masivo y logística. Puedes conectar con él a través de LinkedIn o leer más artículos escritos por él en blog.datalized.cl.