SAP MDG o MDM complementario: cuándo tiene sentido cada arquitectura

Si su entorno es prácticamente todo SAP y el objetivo es gobernar la creación y la modificación de datos maestros dentro de él, SAP Master Data Governance (SAP MDG) suele ser el camino natural. Una capa de MDM complementaria tiene sentido cuando el dato maestro nace fuera de SAP, circula por más de un ERP o depende de una validación externa antes de entrar al sistema. Ambos pueden convivir, siempre que cada dato tenga una única fuente de verdad.

Nota de contexto: este artículo fue escrito para empresas que operan en Brasil, donde es común usar SAP junto con ERP locales como TOTVS y donde los registros de proveedores y clientes suelen verificarse en registros públicos del CNPJ, el número de identificación fiscal de las personas jurídicas brasileñas. El razonamiento de arquitectura vale para cualquier mercado.

"Ya tenemos SAP. ¿Por qué hablaríamos de otro MDM?" Esta pregunta aparece con frecuencia en reuniones de arquitectura, y es legítima. El problema es que la conversación casi siempre empieza por la herramienta, cuando debería empezar por el camino que recorre el dato hasta llegar al ERP.

Quien ya participó en un proyecto SAP sabe que el registro de un proveedor no nace en la transacción. Nace en el correo de un comprador, en un formulario de homologación, en una planilla que pasó por tres áreas. Cuando la decisión de arquitectura ignora ese recorrido, la empresa gobierna muy bien la etapa final y sigue recibiendo datos malos en la entrada.

¿Qué es SAP MDG, según la propia SAP?

SAP describe SAP Master Data Governance como una solución de gestión de datos maestros con gobierno específico por dominio para crear, modificar y distribuir de forma central, o consolidar, datos maestros (SAP Learning, curso "SAP Master Data Governance on SAP S/4HANA"). En el mismo material, SAP organiza la solución en cuatro capacidades principales:

• Gobierno central (central governance): creación, modificación y distribución de datos maestros mediante solicitudes de cambio (change requests), con workflow, área de preparación (staging), aprobación, activación y distribución.
• Consolidación (consolidation): un proceso con carga, verificación inicial, estandarización, comparación (match), cálculo del mejor registro, validación y activación, para llegar a una fuente única de verdad.
• Procesamiento masivo (mass processing): cambios en volumen en datos de socio comercial, cliente, proveedor y producto.
• Gestión de calidad de datos (data quality management): definición de reglas de calidad de datos maestros, monitoreo y corrección.

Los dominios que SAP menciona en el mismo material son socio comercial (cliente y proveedor), material y producto y datos financieros, además de ofertas de socios para Enterprise Asset Management y Retail and Fashion Management.

¿Cuáles son las opciones de implementación de SAP MDG?

La documentación de formación de SAP presenta dos formas de implementar SAP MDG on premise y una oferta en la nube. En la práctica, esta elección ya es la mitad de la decisión de arquitectura.

Opción	Cómo la describe SAP	Beneficios que SAP enumera
Co-deployment	MDG se implementa en uno o más sistemas SAP S/4HANA locales, o en un único SAP S/4HANA reutilizado en todo el entorno para el gobierno central.	Sin latencia de replicación, sin monitoreo entre sistemas, sin integración ni servicios externos adicionales.
Hub	Los datos maestros de uno o más sistemas ingresan a la solución para su verificación antes de replicarse al origen y a otros sistemas.	Inicio con datos ya depurados, independencia de los ciclos de mantenimiento de otros sistemas, sin carga adicional en los sistemas existentes, más flexibilidad de mapeo y de ciclo de vida del dato.
Cloud edition	SAP Master Data Governance, cloud edition, la oferta en la nube de SAP.	SAP menciona gobierno federado e integración con proveedores de datos, entre otras funciones.

Fuente de la tabla: SAP Learning, lección "Describing Deployment Options and Landscapes". SAP también indica que MDG puede distribuir o consolidar datos maestros en sistemas SAP Business Suite, SAP S/4HANA y otros sistemas SAP y no SAP.

¿Qué significa tener un MDM complementario a SAP?

Un MDM complementario es una capa de gestión de datos maestros que está fuera del ERP y se ocupa de partes del ciclo de vida que ocurren antes, alrededor o entre sistemas. No es una disputa de reemplazo. El punto es decidir dónde ocurre cada etapa del dato maestro y quién es su dueño.

En la práctica, esta capa suele asumir una o más de estas funciones:

• Captura del dato donde nace, incluso con personas que no usan SAP, como solicitantes de otras áreas o el propio proveedor.
• Validación en fuentes externas antes de la creación, como los datos públicos del CNPJ en Brasil.
• Estandarización y depuración antes de la carga, sobre todo en migraciones.
• Distribución del mismo registro a más de un ERP o sistema satélite.

En el caso de 4MDG, la plataforma funciona como registro de referencia (golden record) y envía los datos al ERP mediante un conector, registrando estado, intentos y respuestas, según se describe en la página Capacidades y arquitectura. Para SAP ECC y SAP S/4HANA, la integración incluye IDoc, BAPI, archivo y API REST.

¿En qué escenarios SAP MDG tiende a tener más sentido?

Según las características que describe la propia SAP, MDG tiende a ser la opción más directa cuando:

• El entorno es predominantemente SAP S/4HANA y el dato maestro se crea y se consume allí.
• El alcance está en los dominios estándar: socio comercial, material y datos financieros.
• Quienes solicitan, validan y aprueban el registro ya trabajan dentro de SAP.
• La empresa cuenta con un equipo, interno o de un socio, capaz de configurar y mantener MDG después del go-live.
• El objetivo principal es tener solicitud de cambio, aprobación y pista de auditoría dentro del propio entorno SAP.

¿En qué escenarios tiene sentido una capa de MDM complementaria?

La capa complementaria gana peso cuando la pregunta deja de ser "cómo gobernar dentro de SAP" y pasa a ser "cómo gobernar el dato antes de SAP y fuera de él". Las señales más comunes son:

• Más de un ERP: SAP en la casa matriz y TOTVS u Oracle en filiales, con proveedores y materiales compartidos.
• Datos que nacen fuera de SAP: alta de proveedores mediante un portal, solicitudes de áreas sin acceso al ERP.
• Validación externa obligatoria: consulta a fuentes públicas antes de liberar el registro.
• Autonomía del negocio: necesidad de ajustar flujos y reglas sin abrir un proyecto SAP para cada cambio.
• Depuración antes de la migración: una base heredada que debe deduplicarse y estandarizarse antes de la carga en SAP S/4HANA.

Ninguna de estas señales, por sí sola, define la respuesta. Muestran dónde vale la pena profundizar el análisis.

¿Se pueden usar SAP MDG y un MDM complementario juntos?

Sí, y en las grandes empresas es común que distintas herramientas se ocupen de distintas etapas. La condición es una sola: cada atributo necesita una única fuente de verdad y un único flujo de aprobación. Lo que no funciona es aprobar el mismo dato dos veces, con reglas diferentes, en dos lugares.

Tres errores aparecen con frecuencia cuando esa división no se diseña:

1. Dos registros de referencia: cada herramienta cree ser la dueña del mismo campo y una sobrescribe a la otra.
2. Reglas duplicadas: la obligatoriedad de un campo se configura en dos lugares y, con el tiempo, las versiones divergen.
3. Aprobación doble: el solicitante aprueba en un flujo y debe aprobar de nuevo en el otro, y el plazo de alta se duplica.

Cómo decidir: checklist para la reunión de arquitectura

Pregunta	Por qué importa
¿Cuántos sistemas reciben cada dominio de datos maestros?	Define si la distribución queda dentro de SAP o cruza plataformas.
¿Dónde nace realmente el dato?	Muestra si el gobierno debe empezar antes del ERP.
¿Quién solicita y aprueba, y esas personas usan SAP?	Afecta licencias, accesos y diseño del flujo.
¿Qué validaciones externas son obligatorias?	Indica integraciones con fuentes públicas o proveedores de datos.
¿Qué dominios y atributos están en el alcance?	Muestra qué es estándar y qué requiere extensión.
¿Quién mantiene reglas y flujos después del go-live?	Evita una solución que solo el equipo del proyecto puede modificar.
¿Cuál es la fuente de verdad de cada atributo?	Evita dos registros de referencia.
¿Cómo influye el cronograma de SAP S/4HANA en la decisión?	La arquitectura de datos maestros debe estar definida antes de la carga.

Ejemplo hipotético: una industria con dos ERP

Ejemplo hipotético, creado para ilustrar el razonamiento. No se trata de un cliente real.

Una industria usa SAP S/4HANA en la casa matriz y TOTVS en una filial adquirida recientemente. Los proveedores son compartidos y el registro se hace dos veces, con reglas diferentes.

Diseño A: SAP MDG en modelo hub pasa a ser el punto de creación del proveedor y distribuye el registro a SAP S/4HANA y a TOTVS. La empresa gana un único flujo dentro del ecosistema SAP, pero debe construir y mantener el mapeo y la integración con TOTVS, y los solicitantes pasan a abrir sus solicitudes en MDG.

Diseño B: una capa de MDM complementaria recibe la solicitud, incluso del propio proveedor, valida los datos de registro en fuentes públicas y envía el registro aprobado al socio comercial (business partner) de SAP S/4HANA y a TOTVS. El gobierno de la entrada queda fuera de los ERP, y SAP recibe el dato ya validado.

Ambos diseños son defendibles. La elección depende de las respuestas del checklist, sobre todo de dónde nace el dato y de quién mantendrá el flujo después.

Por dónde empezar

1. Dibuje el recorrido del dato por dominio: dónde nace, quién lo modifica, quién lo consume.
2. Liste todos los sistemas que reciben datos de proveedores, clientes y materiales.
3. Defina, atributo por atributo, cuál es la fuente de verdad.
4. Mida la calidad de la base actual antes de elegir una herramienta. Si la base está en mal estado, la depuración de datos maestros va antes de cualquier arquitectura.
5. Haga una prueba de concepto con datos reales de la empresa, no con datos de demostración.
6. Vincule la decisión al cronograma del proyecto. Si la empresa va hacia SAP S/4HANA, vea cómo 4MDG aborda la migración a SAP S/4HANA con depuración antes de la carga.

Para entender los distintos papeles del ERP y del MDM antes de esta decisión, lea también MDM vs. ERP: cuál es la diferencia.

Preguntas frecuentes

¿4MDG reemplaza a SAP MDG?

Ese no es el posicionamiento. Son enfoques diferentes. 4MDG es una plataforma de MDM integrada con ERP como SAP, TOTVS y Oracle, y el diseño adecuado depende del escenario, incluso en arquitecturas en las que convive con SAP MDG.

¿SAP MDG funciona con sistemas que no son SAP?

Según SAP, MDG puede distribuir o consolidar datos maestros en sistemas SAP y no SAP. El punto de atención es el esfuerzo de mapeo, integración y monitoreo, que debe dimensionarse en el proyecto.

¿Necesito decidir esto antes de migrar a SAP S/4HANA?

Es lo recomendable. La arquitectura de datos maestros define dónde se depurará, validará y aprobará el dato. Decidir después de la carga suele significar migrar el problema y corregirlo en producción.

¿SAP MDG tiene una versión en la nube?

Sí. SAP ofrece SAP Master Data Governance, cloud edition, además de las implementaciones en SAP S/4HANA. Las capacidades varían según la edición y la versión, por lo que conviene revisar la documentación vigente de SAP para su escenario.

Las descripciones de funciones de SAP Master Data Governance se tomaron de la documentación oficial de SAP en la fecha de acceso indicada y pueden cambiar entre versiones. SAP, SAP S/4HANA y SAP Master Data Governance son marcas de SAP SE.

Fuentes

• Introducing SAP Master Data Governance, curso "SAP Master Data Governance on SAP S/4HANA". SAP Learning. Fecha de acceso: 02/10/2026.
• Describing Deployment Options and Landscapes, curso "Introducing SAP Master Data Governance". SAP Learning. Fecha de acceso: 02/10/2026.
• SAP Master Data Governance: Features and Benefits. SAP. Fecha de acceso: 02/10/2026.
• Capacidades y arquitectura y Migración SAP S/4HANA. 4MDG. Fecha de acceso: 02/10/2026.