Qué es master data management (MDM): datos maestros, golden record y los 4 modelos de implementación
En resumen
El master data management (MDM) es la disciplina que crea y mantiene una versión única y confiable de los datos que describen las entidades centrales de una empresa: clientes, proveedores, productos, materiales, ubicaciones y activos. Su propósito es que todos los sistemas trabajen con la misma información, sin duplicados ni versiones en conflicto.
Existen cuatro modelos de implementación: registry, consolidation, coexistence y transaction. Los primeros tres corrigen el dato después de que ya entró al sistema. El cuarto lo gobierna en el momento de la captura, que es donde se origina el problema.
Un golden record se degrada por dos razones distintas: la captura sigue ocurriendo sin gobierno en múltiples sistemas, y muchas de las validaciones que lo hacen confiable tienen fecha de caducidad.
¿Qué es master data management (MDM)?
El master data management (MDM) es la disciplina que crea y mantiene una versión única y confiable de los datos que describen las entidades centrales de una empresa: clientes, proveedores, productos, materiales, ubicaciones y activos. Su propósito es que todos los sistemas de la organización trabajen con la misma información, sin duplicados ni versiones en conflicto.
La definición es sencilla. Lo que casi nunca se explica es que existen cuatro formas distintas de implementarlo, y que la diferencia entre ellas determina si el proyecto resuelve el problema o solo lo documenta.
Qué son los datos maestros
Los datos maestros son la información que describe las entidades que tu negocio usa una y otra vez, en varios sistemas a la vez. Un proveedor aparece en compras, en cuentas por pagar, en el ERP y en el portal fiscal. Un material aparece en ingeniería, en producción, en inventarios y en el catálogo comercial. Esa información cambia poco, la consultan muchos, y cuando está mal, el error se propaga.
Conviene separarlos de los otros tipos de datos con los que conviven:
Tipo de dato | Qué registra | Ejemplo |
|---|---|---|
Maestro | Las entidades del negocio | El proveedor, el material, el cliente |
Transaccional | Los eventos del negocio | La orden de compra, la factura, el embarque |
De referencia | Los valores permitidos | Códigos de país, monedas, unidades de medida |
Metadatos | Datos sobre los datos | Definiciones de campos, linaje, reglas de negocio |
Una orden de compra es un dato transaccional que apunta a un proveedor (maestro), está expresada en MXN (referencia) y arrastra consigo la definición de qué significa cada campo (metadato). Si el proveedor está duplicado, la orden también lo está.
Los dominios de datos maestros
La literatura suele mencionar cuatro dominios. En la práctica operativa de una empresa industrial o de consumo masivo, son al menos seis:
Proveedor: datos fiscales, bancarios, de contacto, condiciones comerciales
Material: SKU, especificaciones técnicas, unidad de medida, clasificación
Cliente: identidad fiscal, jerarquía comercial, condiciones de crédito
Ubicación: plantas, almacenes, centros de distribución, puntos de venta
Activo: equipos, flotilla vehicular, refacciones
Empleado: identidad, estructura organizacional, roles y permisos
Cada dominio tiene sus propios dueños, sus propias reglas y sus propios sistemas destino. Un MDM que solo resuelve uno de ellos es un proyecto, no una capacidad.
Para qué sirve el master data management
Los síntomas de no tenerlo son casi siempre los mismos, y aparecen en dominios distintos.
Un material duplicado genera escasez artificial. El mismo componente existe con dos números de parte porque dos plantas lo dieron de alta con nomenclaturas distintas. El inventario consolidado muestra cobertura suficiente, pero cada planta ve solo su mitad y ambas compran de emergencia. El costo no es el error de captura, es el capital de trabajo inmovilizado en el mismo producto contado dos veces.
Un catálogo de ubicaciones desactualizado detiene la operación. Los sistemas fiscales y logísticos validan contra catálogos oficiales que cambian con el tiempo. Un código postal, una clave de producto o un dato de vehículo que quedó desalineado provoca rechazos en el momento de la emisión de documentos, no seis meses después. El catálogo de operadores, vehículos y ubicaciones es dato maestro, aunque casi ninguna organización lo administre como tal.
Un proveedor que entra sin verificación se convierte en un problema fiscal. Cuando un proveedor aparece en listas negras, los comprobantes que emitió pueden perder efecto fiscal para quien los recibió. El daño no se descubre en el momento del alta. Se descubre cuando ya hay facturas deducidas y pagos ejecutados.
Los tres casos comparten una estructura: el error entró en el momento de la captura y se manifestó mucho después, en otro sistema, con otro dueño.
Cómo implementar un MDM: fases de un proyecto
Con matices según el proveedor y el alcance, todo proyecto de MDM recorre las mismas etapas:
Identificación de entidades críticas. Cuáles datos merecen ser gobernados como maestros. No todos lo merecen.
Modelo de datos. Qué atributos componen cada entidad, cuáles son obligatorios y cómo se relacionan entre sí.
Reglas de gobierno. Quién puede crear, quién puede modificar, quién aprueba y bajo qué criterios.
Matching y deduplicación. Identificar que dos registros distintos describen la misma entidad real.
Construcción del golden record. La versión que la organización acepta como verdadera.
Distribución. Cómo llega ese registro a los sistemas que lo consumen.
La pregunta que decide el éxito del proyecto no está en esta lista. Está en dónde ocurre el paso 3.
Tipos de MDM: los 4 modelos de implementación
Esta es la parte que la mayoría de las guías omite, y es la más útil para decidir. La industria reconoce cuatro estilos de implementación de MDM que se diferencian por dónde vive el dato maestro y quién tiene autoridad para escribirlo.
Registry (registro). El MDM no almacena el dato. Construye un índice de referencias cruzadas que identifica qué registros de qué sistemas describen a la misma entidad, y les asigna un identificador global. Los sistemas origen siguen siendo la autoridad. Es el modelo más rápido y barato de implementar, y el que menos cambia. Sirve para saber cuántos duplicados tienes. No sirve para dejar de producirlos.
Consolidation (consolidación). El MDM sí almacena una versión consolidada, construida a partir de los sistemas origen mediante limpieza, matching y fusión. Ese golden record vive en el hub y se usa para analítica y reportes. No regresa a los sistemas origen, que siguen operando con sus datos como estaban. Es el modelo más común en proyectos que nacen del área de datos, y el que produce la paradoja más incómoda: el reporte está limpio y la operación sigue sucia.
Coexistence (coexistencia). Igual que el anterior, pero el hub publica las correcciones de vuelta a los sistemas origen. El dato maestro existe en ambos lados y se sincroniza de forma bidireccional. Es un avance real, y también donde aparece la complejidad operativa: si dos sistemas pueden escribir la misma entidad, hay que resolver conflictos de forma permanente. Reltio describe este modelo como una consolidación con funciones de retorno hacia las fuentes, lo que exige que esas fuentes tengan capacidades propias de limpieza.
Transaction o centralized (autoría centralizada). El dato maestro nace dentro del hub. Los usuarios lo capturan ahí, bajo las reglas del hub, y el hub lo escribe hacia los sistemas destino una vez aprobado. Los demás sistemas dejan de ser fuentes y pasan a ser suscriptores. Es el modelo que ofrece mayor control y también el que más exige en diseño, porque implica mover un proceso de negocio, no solo un flujo de datos.
Modelo | Dónde se corrige el dato | Qué exige | Cuándo conviene |
|---|---|---|---|
Registry | En ningún lado, solo se identifica | Bajo esfuerzo | Diagnóstico inicial |
Consolidation | Después, en el hub | Esfuerzo medio | Analítica y reportes |
Coexistence | Después, con retorno al origen | Esfuerzo alto y continuo | Transición hacia mayor gobierno |
Transaction | Antes, en el momento de la captura | Rediseño del proceso | Entidades críticas y reguladas |
Los primeros tres modelos corrigen. El cuarto previene. La mayoría de las organizaciones evoluciona entre estilos conforme madura su gobierno de datos, y eso es razonable. El problema es cuando se quedan indefinidamente en el segundo, convencidas de que tener el golden record en un tablero equivale a tenerlo en la operación.
Qué es un golden record y por qué se degrada
Un golden record es la versión de una entidad que la organización acepta como verdadera y que los demás sistemas deben usar como referencia. Cuando se construye por consolidación, es una fotografía que empieza a envejecer desde el momento en que se toma. Por dos razones distintas, y la segunda casi nunca se discute.
La captura sigue ocurriendo sin gobierno. Mientras el alta de entidades siga sucediendo en doce sistemas con doce criterios, el hub va a estar deduplicando indefinidamente lo que la operación produce cada semana. Es trabajo perpetuo por diseño.
La validez del dato tiene fecha de caducidad. Este es el punto crítico. Muchas de las verificaciones que hacen confiable a un dato maestro no son permanentes. Una verificación contra listas negras es válida el día que se hizo, y el listado cambia después. Una situación fiscal vigente hoy puede no serlo el trimestre próximo. Un registro correcto deja de ser correcto sin que nadie lo haya tocado.
Un MDM que solo deduplica no tiene forma de detectar eso. No hay algoritmo de matching que revele que un proveedor perfectamente único y perfectamente limpio dejó de ser confiable ayer. Detectarlo requiere que el MDM sepa ejecutar la verificación de nuevo y actuar en consecuencia, y eso ya no es una capacidad de repositorio. Es una capacidad de proceso.
MDM y procesos de negocio: gobernar el dato desde la captura
En el mercado, MDM y gestión de procesos de negocio se venden por separado. Se compra una plataforma de MDM para el golden record, se compra un motor de flujos o un portal para las aprobaciones, y después se paga a un integrador para conectarlos. El resultado habitual es una capa intermedia que nadie controla del todo y que se vuelve costosa de modificar.
La alternativa es que el motor que gobierna el dato sea el mismo que ejecuta el proceso que lo produce. En la práctica, eso significa cuatro cosas.
El proceso se diseña, no se programa. El flujo de alta se construye visualmente sobre notación BPMN: quién captura, quién revisa, quién aprueba, qué pasa si se rechaza. Cambiar el flujo no requiere un ciclo de desarrollo.
Las validaciones operan en tres niveles. Regla declarativa para lo simple, como un formato de identificador fiscal o una obligatoriedad condicional. Script para lo que no cabe en una regla, como mostrar únicamente los bancos de un país cuando el proveedor es de ese país. Y llamada a servicio externo para lo que vive fuera de la organización, como la consulta a listas negras.
Aquí conviene distinguir dos tipos de validación que rara vez se separan. Una validación informativa marca el registro y lo deja pasar, para que alguien lo revise después. Una validación bloqueante detiene el proceso. En el caso de las listas negras, la validación es bloqueante: si el resultado es positivo, el registro no avanza y no se escribe en el sistema destino. No hay registro que limpiar después, ni factura que se convierta en contingencia fiscal meses más tarde.
La captura se asiste con automatización. Los documentos que sustentan el alta se procesan para extraer sus campos de forma automática, de modo que el usuario confirma en lugar de transcribir. Una constancia fiscal o un documento de identidad en PDF llenan el formulario sin intervención manual. Esto importa más de lo que parece: la captura manual es precisamente donde nacen los duplicados y las variantes ortográficas que el resto de la industria intenta reparar después con matching difuso. Eliminar la transcripción elimina la causa, no el síntoma.
La escritura llega al sistema destino. Una vez aprobado, el registro se escribe directamente en el ERP, el sistema comercial o donde corresponda, sin intermediarios tecnológicos en medio. El dato no queda esperando a que alguien lo replique.
Hay un beneficio menos evidente en este modelo, y es de velocidad. Las reglas de validación cambian: los catálogos oficiales se actualizan, las obligaciones regulatorias se modifican, las políticas internas se ajustan. Un modelo donde cambiar una regla implica semanas de desarrollo no puede seguirle el paso a ese ritmo. Cuando el proceso se edita visualmente, la distancia entre un cambio normativo y su reflejo en producción se mide en días.
Cómo aplicar MDM a proveedores, materiales, clientes y otros dominios
Un riesgo de explicar este modelo con un solo ejemplo es que parezca una solución para un área específica. No lo es. La mejor forma de verlo es poner tres entidades distintas una junto a otra y observar qué se repite.
Proveedor | Material | Cliente | |
|---|---|---|---|
Quién lo solicita | Compras | Ingeniería o producto | Comercial |
Qué se valida | Identidad fiscal, listas negras, datos bancarios | Especificación técnica, clasificación, unidad de medida | Identidad fiscal, capacidad de crédito |
Quién aprueba | Compras, fiscal, compliance | Ingeniería, calidad, costos | Comercial, crédito y cobranza |
A dónde se escribe | ERP, módulo de proveedores | ERP, módulo de materiales | ERP y sistema comercial |
Las cuatro filas cambian por completo de una columna a otra. Y sin embargo, el mecanismo que las opera es idéntico en los tres casos: un formulario que muestra los campos que corresponden según el contexto, una serie de validaciones que se ejecutan antes de dejar avanzar el registro, un recorrido de revisión y aprobación con responsables definidos, un registro auditable de cada paso, y la escritura al sistema destino únicamente cuando el proceso terminó.
Dicho de otra forma: lo que se construye una vez es el motor. Lo que se configura para cada entidad es el proceso que corre sobre él. Dar de alta un dominio nuevo no significa comprar otro producto ni levantar otro proyecto desde cero, significa diseñar un flujo distinto sobre la misma base.
Esa es la diferencia práctica entre una plataforma de datos maestros y una herramienta que resuelve un solo dominio. La segunda te obliga a repetir la inversión cada vez que el negocio necesita gobernar algo nuevo.
Cómo medir un proyecto de MDM: KPIs y métricas
Los objetivos genéricos no sirven para gobernar un proyecto. Estas métricas sí:
Tiempo de alta por entidad. De solicitud a registro disponible en el sistema destino.
Porcentaje de registros que requieren retrabajo. Cuántos vuelven al origen por información incompleta o incorrecta.
Cobertura de validación. No cuántos registros pasaron, sino qué porcentaje del universo pasó por cada regla. Un 99% de aprobación con 40% de cobertura no significa nada.
Volumen procesado con trazabilidad completa. Cuántas ejecuciones tienen registro auditable de principio a fin.
Tasa de bloqueo por compliance. Cuántas altas se detuvieron y por qué motivo.
Tiempo entre un cambio de regla y su entrada en producción. La métrica que el modelo tradicional no reporta, porque nunca la midió.
MDM y datos listos para IA
Un agente que consulta el catálogo de proveedores hereda cada duplicado que contiene. Un modelo de demanda entrenado sobre materiales mal clasificados aprende la clasificación equivocada. La IA no corrige datos maestros: los amplifica.
Gartner estimó en febrero de 2025 que hasta 2026 las organizaciones abandonarían el 60% de los proyectos de IA que no cuenten con datos preparados para ese uso. En la misma investigación, 63% de las organizaciones consultadas no tenía las prácticas de gestión de datos adecuadas para IA, o no sabía si las tenía.
El punto relevante es que datos limpios y datos listos para IA no son lo mismo. Lo segundo exige linaje, definiciones acordadas de los términos de negocio y mantenimiento continuo, no una limpieza previa al lanzamiento del proyecto. Un dato maestro que se gobierna en el momento de su creación ya cumple buena parte de esas condiciones por construcción.
Caso de éxito: alta de proveedores de meses a minutos
Un líder global en alimentos operaba el alta de proveedores por correo, papel y fotocopias. El proceso tomaba semanas y en algunos casos hasta dos meses, sin trazabilidad y sin validación sistemática: un proveedor en listas negras podía darse de alta sin pasar por ninguna evaluación.
Arkon Data implementó el proceso completo sobre su plataforma, con formularios dinámicos, validaciones automáticas contra listas negras antes de permitir el avance del registro, flujos de aprobación con visibilidad para compras, fiscal y compliance, y escritura directa en el ambiente de Oracle Cloud del cliente. Esa escritura directa eliminó la dependencia del integrador tecnológico que antes operaba como intermediario.
Los resultados a la fecha:
Tiempo de registro reducido de meses a minutos, sujeto a las aprobaciones del proceso
Más de 18,000 ejecuciones mensuales con trazabilidad completa
7 organizaciones operativas en 4 idiomas, con 2,800 usuarios
Alta masiva de 1,200 proveedores en Brasil ante un deadline regulatorio que la consultora global anterior no garantizó
Áreas como marketing, planeación financiera y datos maestros consumiendo la información directamente desde la plataforma
El alta de proveedores fue donde el modelo se probó a mayor escala. La misma arquitectura opera hoy sobre materiales, refacciones y producto terminado.
Preguntas frecuentes sobre master data management
1. ¿Cuál es la diferencia entre MDM y un data warehouse?
Un data warehouse almacena datos para analizarlos. Un MDM define cuál es la versión correcta de una entidad y la distribuye a los sistemas operativos. El warehouse responde qué pasó; el MDM responde quién es el proveedor.
2. ¿MDM y gobierno de datos son lo mismo?
No. El gobierno de datos establece políticas, roles y responsabilidades sobre todos los datos de la organización. El MDM es la implementación concreta de ese gobierno sobre las entidades maestras.
3. ¿Qué es un golden record?
Es la versión de una entidad que la organización acepta como verdadera y que los demás sistemas deben usar como referencia.
4. ¿Cuánto tarda implementar un MDM?
Depende del modelo y del alcance. Un registry puede operar en semanas. Un modelo de autoría centralizada sobre una entidad crítica suele medirse en meses, porque implica rediseñar el proceso de negocio que produce el dato.
5. ¿Se puede hacer MDM sin reemplazar el ERP?
Sí. En el modelo de autoría centralizada el ERP sigue siendo el sistema destino; lo que cambia es que recibe registros ya validados y aprobados en lugar de capturas directas.
6. ¿Cuál es la diferencia entre un MDM y un portal de proveedores?
Un portal de proveedores resuelve la recolección de documentos de un dominio. Un MDM con motor de procesos gobierna cualquier entidad maestra y escribe el resultado en los sistemas operativos. El portal es un caso de uso; el MDM es la capacidad.
Del diagnóstico a la ejecución
La pregunta que conviene responder antes de elegir plataforma es dónde se captura hoy cada entidad maestra y quién la aprueba realmente. Casi siempre la respuesta incumbe a más áreas de las que el proyecto tenía contempladas.
En Arkon Data no entregamos únicamente la plataforma. El equipo de ingenieros de proceso trabaja con tus áreas para levantar y mapear el flujo real de alta de cada entidad, incluidas las reglas que hoy solo existen en la cabeza de quien las aplica, y lo traduce en un proceso ejecutable. Si tu organización ya tiene ese mapeo, partimos de ahí. Si no lo tiene, que es lo más común, esa es la primera parte del trabajo.
Agendemos una conversación corta, sin compromiso, para revisar cómo están entrando hoy tus datos maestros.