MDM de un dominio o multidominio: por dónde empezar sus datos

Separe dos decisiones: la arquitectura y el alcance. Elija una plataforma que soporte varios dominios, para no crear silos cuando llegue el segundo, y empiece por un solo dominio: aquel en el que el problema de negocio se puede medir, el dueño del dato está disponible y el resultado es visible para quien financia el programa. Materiales, proveedores o clientes: la decisión la toma el problema, no quien habla más fuerte en la reunión.

He visto esta reunión en muchos proyectos. El programa de MDM está aprobado, el presupuesto existe y alguien pregunta: "¿Por qué datos maestros empezamos?"

Compras quiere proveedores, porque ahí aparecen proveedores sin homologar o con documentos vencidos. Ingeniería y mantenimiento quieren materiales, porque el mismo artículo está registrado con descripciones distintas y nadie encuentra la pieza correcta. Ventas quiere clientes, porque los pedidos se bloquean por una dirección equivocada o un límite de crédito desactualizado. Cada director tiene razón sobre su propio problema. Lo que falta en la mesa es un criterio para elegir.

¿Qué es un MDM de un solo dominio y qué es un MDM multidominio?

SAP define la disciplina así: "La gestión de datos maestros es la disciplina de crear y mantener una vista única y confiable de los datos de negocio más importantes de una organización en todos los sistemas." La misma página explica que los datos maestros suelen organizarse en dominios según el tipo de entidad de negocio central, como clientes, proveedores, productos, materiales y activos (SAP, ¿Qué es la gestión de datos maestros?).

A partir de ahí, así es como explico los términos:

• Dominio: un tipo de entidad de negocio con modelo, reglas y dueños propios. Material, proveedor, cliente, finanzas y datos de referencia son los más comunes.
• Dominio único: el programa y la herramienta cubren un solo tipo de entidad. Por ejemplo, solo materiales.
• Multidominio: una plataforma, un modelo y una gobernanza que cubren varios dominios, con reglas, flujos de trabajo y datos de referencia compartidos.
• Varios dominios en herramientas separadas: cada dominio tiene su herramienta, sus reglas y su equipo. En el organigrama parece multidominio, pero en la operación son silos que no se comunican.

Si quiere repasar el concepto de MDM y su relación con el ERP, escribí sobre eso en qué es MDM y cómo sostiene el ERP.

¿Elegir multidominio y elegir por dónde empezar son la misma decisión?

No. Y es aquí donde muchas reuniones se pierden.

La decisión de arquitectura responde: ¿la plataforma que vamos a usar puede gestionar más de un dominio con el mismo modelo de flujo de trabajo, las mismas reglas, el mismo historial y los mismos datos de referencia? Esta decisión mira los próximos años.

La decisión de alcance responde: ¿qué dominio entra en la primera ola, con qué recorte, qué dueño y qué resultado esperado? Esta decisión mira los próximos meses.

Una no obliga a la otra. Se puede tener una plataforma multidominio y empezar solo por materiales. Y se puede comprar una herramienta de dominio único y descubrir, cuando el dominio de proveedores entre en la agenda, que hará falta otra herramienta, otro contrato y otra integración. El multidominio indica adónde quiere llegar. El primer dominio indica dónde pisa mañana.

¿Qué criterios usar para elegir el primer dominio?

La tabla siguiente es la guía que recomiendo llevar a la reunión. Haga las preguntas para cada dominio candidato y compare las respuestas. No existe un peso universal: la estrategia de la empresa en ese momento define cuánto cuenta cada criterio.

Criterio	Pregunta	Señal de buen candidato
Problema de negocio medible	¿Qué perjuicio causan hoy estos datos y en qué indicador aparece?	El problema se ve en la operación: compras repetidas, pedidos bloqueados, pagos retenidos, facturas rechazadas.
Dueño del dato disponible	¿Quién define la regla y aprueba las excepciones?	Hay una persona con nombre, tiempo y autoridad para decidir.
Volumen y reincidencia de errores	¿El error es puntual o vuelve cada semana?	El mismo tipo de error se repite y genera retrabajo.
Dependencia de otros procesos	¿Cuántos procesos se detienen cuando estos datos están mal?	El dominio alimenta compras, inventario, impuestos, facturación o mantenimiento al mismo tiempo.
Datos de referencia compartidos	¿Qué tablas comunes usa este dominio?	Diseñar el dominio obliga a ordenar unidades, países o condiciones de pago que los próximos dominios reutilizarán.
Proyecto ancla	¿Hay una migración, implantación o cambio regulatorio con fecha fija?	El dominio está en la ruta crítica de un proyecto como la migración a SAP S/4HANA o la reforma tributaria del consumo en Brasil.
Riesgo de cumplimiento	¿Un dato erróneo expone a la empresa a sanciones fiscales, fraude o multas?	Un error en este dominio genera riesgo fiscal, pagos indebidos o relación con terceros no homologados.
Capacidad de mostrar resultados	¿Se puede comparar el antes y el después en pocas semanas?	Hay una línea base medida y un recorte lo bastante pequeño para mostrar avances pronto.

Observe que "quién es el patrocinador" no está en la tabla. Sin patrocinio el programa ni siquiera existe, pero la elección del dominio debe seguir al problema. Si el dominio del patrocinador también es el del problema, perfecto. Si no lo es, conviene una conversación franca antes de empezar.

¿Qué cambia entre materiales, proveedores y clientes?

Cada dominio exige un tipo de regla, de dueño y de validación. Conocer esa diferencia ayuda a estimar el esfuerzo y a elegir el equipo.

Materiales

El problema más común es la descripción libre: cada persona escribe a su manera y el mismo artículo termina registrado más de una vez. El trabajo consiste en estandarizar la descripción, definir atributos por familia, organizar la clasificación (incluida la clasificación fiscal, como la NCM, la nomenclatura de mercancías usada en Brasil y en el Mercosur) e involucrar a ingeniería, mantenimiento, abastecimiento e impuestos. Si este es su problema, vale la pena leer cómo identificar materiales duplicados.

Proveedores

En Brasil, los proveedores duplicados tienden a ser menos frecuentes cuando el CNPJ (el registro nacional de empresas brasileño) se usa como clave, siempre que se traten la matriz y las sucursales, además de las personas físicas (identificadas por el CPF, el registro de contribuyentes individuales brasileño) y los proveedores extranjeros. El problema es otro: proveedores sin homologar, documentos vencidos, datos bancarios sin verificar, una situación registral que no coincide con la fuente oficial. El trabajo consiste en validar los datos en fuentes oficiales, controlar documentos y plazos de homologación y dar a compras, finanzas y cumplimiento roles claros en el flujo.

Clientes

El problema aparece en el pedido y en la cobranza: dirección de entrega equivocada, grupo económico mal armado, límite de crédito que no refleja la realidad, datos fiscales desactualizados. El trabajo involucra a ventas, crédito, logística e impuestos, y la regla debe respetar la jerarquía del grupo económico.

En las empresas que usan SAP S/4HANA, clientes y proveedores conviven en el Business Partner, y eso cambia la conversación sobre separar ambos dominios. Escribí sobre ese punto en Business Partner en S/4HANA.

¿Por qué los datos de referencia van antes que cualquier dominio?

Unidades de medida, países, regiones, monedas, condiciones de pago, tablas fiscales como la NCM: son listas que casi todos los dominios utilizan. Si cada dominio diseña su propia versión, la empresa termina con tres tablas de unidades de medida y ninguna confiable.

Mi recomendación es diseñar los datos de referencia una sola vez, en la primera ola, aunque el primer dominio use solo una parte. Es la pieza de la arquitectura multidominio que más rinde cuando llega el segundo dominio, porque ya encuentra la base lista.

¿Cómo se ve esta elección en un caso concreto?

Ejemplo hipotético: una empresa industrial con SAP ECC prepara la migración a S/4HANA. En la reunión de alcance, compras pide proveedores, mantenimiento pide materiales y ventas pide clientes.

Al aplicar la tabla, el equipo percibe tres cosas. Materiales tiene el problema más reincidente (descripciones libres, artículos repetidos en el almacén), un dueño disponible en ingeniería y está en la ruta crítica de la migración, porque cargar artículos duplicados en el sistema nuevo solo cambia el problema de lugar. Proveedores tiene un riesgo de cumplimiento alto, pero su regla principal (validación en fuentes oficiales y homologación) puede entrar justo después, aprovechando los mismos datos de referencia. Clientes depende de decisiones sobre el Business Partner que todavía están abiertas en el proyecto de migración.

La decisión queda así: plataforma multidominio desde el inicio, primera ola en materiales con saneamiento antes de la carga (vea saneamiento de datos), datos de referencia diseñados para servir a todos, segunda ola en proveedores y tercera en clientes, cuando el diseño del Business Partner esté cerrado. Compras y ventas salen de la reunión sabiendo cuándo les toca y por qué.

¿Cuándo es momento de abrir el segundo dominio?

No puedo indicar un plazo, porque cada empresa avanza a su ritmo. Prefiero observar señales:

• El primer dominio funciona en el día a día sin depender del equipo del proyecto para cada excepción.
• Los indicadores de calidad mejoraron frente a la línea base y dejaron de oscilar.
• El dueño del dato decide reglas y excepciones sin escalarlo todo.
• Los datos de referencia están estables y documentados.
• El área del próximo dominio tiene un dueño designado y tiempo reservado.

Si la mayor parte de estas señales todavía no aparece, abrir el segundo dominio suele dividir la atención del equipo y retrasar ambos.

¿Qué errores evitar en la elección?

• Comprar una herramienta de un solo dominio sin pensar en el segundo. Resuelve el problema de hoy y crea el silo de mañana.
• Querer abordar todos los dominios a la vez. El programa se convierte en una lista de pendientes sin resultado visible.
• Empezar por el dominio del patrocinador en lugar del dominio del problema. La primera ola debe demostrar valor, y eso es más difícil donde el problema es menor.
• Saltarse la línea base. Sin medir antes, nadie puede mostrar qué mejoró después.
• Dejar los datos de referencia para después. Cada dominio inventa su tabla y el retrabajo vuelve en la segunda ola.

¿Por dónde empezar?

1. Cierre la decisión de arquitectura. Defina si la plataforma debe cubrir varios dominios, con reglas, flujos de trabajo y datos de referencia comunes. Esta decisión va antes de elegir el primer dominio.
2. Mida la línea base de cada dominio candidato. Use indicadores simples y comparables. El paso a paso está en cómo medir la calidad de los datos maestros.
3. Puntúe a los candidatos con la tabla de criterios. Lleve las respuestas a la reunión y decida a partir de ellas.
4. Designe al dueño del dato del primer dominio. Una persona, con tiempo y autoridad, antes de empezar.
5. Diseñe los datos de referencia compartidos. Una sola vez, para todos los dominios.
6. Evalúe el software y pruébelo con sus propios datos. Para los criterios de evaluación, use el checklist de software de MDM. Una vez elegido el dominio, pruebe con una muestra real siguiendo la guía de prueba de concepto con sus datos.
7. Defina las señales de salida de la primera ola. Acuerde de antemano qué señales habilitan el segundo dominio, para que la decisión no vuelva a ser una disputa entre directores.

Preguntas frecuentes

¿Cuál es la diferencia entre un MDM multidominio y tener varias herramientas de MDM?

En el multidominio, una plataforma cubre varios dominios con el mismo modelo, las mismas reglas de flujo de trabajo, el mismo historial y los mismos datos de referencia. Con varias herramientas, cada dominio tiene su lógica, su integración con el ERP y su equipo, y las tablas comunes tienden a repetirse con diferencias entre ellas.

¿Se puede empezar con un solo dominio en una plataforma multidominio?

Sí, y es el camino que recomiendo. La plataforma garantiza que el segundo dominio aprovechará lo que ya se hizo. El alcance pequeño garantiza foco, un dueño claro y un resultado visible en la primera ola.

¿Qué dominio suele dar retorno más rápido?

Depende de la empresa, y conviene desconfiar de quien responde sin mirar sus datos. El retorno más rápido suele venir del dominio donde el problema es reincidente, tiene indicador, tiene un dueño disponible y está en la ruta de un proyecto con fecha fija. La tabla de criterios de este artículo sirve para descubrir cuál es el suyo.

¿Cuánto esperar antes de abrir el segundo dominio?

En lugar de un plazo, use señales: el primer dominio funciona sin el equipo del proyecto, los indicadores mejoraron y se estabilizaron, el dueño decide las excepciones y los datos de referencia están estables. Cuando esas señales aparecen, el segundo dominio entra con menos riesgo.

¿Los datos de referencia son un dominio?

Pueden tratarse como un dominio propio, con dueño y reglas. En mi opinión, lo importante es tratarlos como una base común: diseñados una sola vez, con dueño definido y reutilizados por materiales, proveedores y clientes.

¿El ERP no es ya multidominio?

El ERP almacena varios tipos de datos maestros, pero almacenar no es gobernar. El MDM se ocupa de cómo nace y cambia el dato: quién lo solicita, quién lo valida, qué regla se aplica, quién lo aprueba y qué se envió al ERP. Por eso la decisión de arquitectura del MDM sigue siendo necesaria aunque todos los datos maestros ya estén en el mismo ERP.

Cómo 4MDG puede ayudar

La plataforma SaaS de 4MDG cubre material, proveedor, cliente, finanzas y referencia en la misma plataforma, con cada registro configurado como flujo de trabajo. Por eso se puede empezar por un dominio y abrir el siguiente sobre los mismos flujos y datos de referencia, con integración a ERP como SAP, TOTVS y Oracle. Los detalles están en capacidades y arquitectura.

Si todavía duda por qué dominio empezar, puede solicitar el diagnóstico: usted envía una muestra de materiales, proveedores y clientes en hoja de cálculo o extracción, no se instala nada en su entorno, y recibe el índice de duplicidad, la completitud por atributo, la conformidad registral, la calidad de la descripción y una recomendación de camino.

Fuentes

• SAP. ¿Qué es la gestión de datos maestros? Consultado el 14/10/2026.