SAP MDG ou MDM complementar: quando cada arquitetura faz sentido
Veja quando o SAP MDG é o caminho natural, quando um MDM complementar faz sentido e como os dois convivem sem duplicar o dado mestre no SAP S/4HANA.
Se a sua paisagem é praticamente toda SAP e o objetivo é governar a criação e a alteração de dados mestres dentro dela, o SAP Master Data Governance (SAP MDG) costuma ser o caminho natural. Uma camada de MDM complementar faz sentido quando o dado mestre nasce fora do SAP, circula por mais de um ERP ou depende de validação externa antes de entrar no sistema. Os dois podem conviver, desde que cada dado tenha uma única fonte da verdade.
"Já temos SAP. Por que falaríamos de outro MDM?" Essa pergunta aparece com frequência em reuniões de arquitetura, e ela é justa. O problema é que a conversa quase sempre começa pela ferramenta, quando deveria começar pelo caminho que o dado faz até chegar ao ERP.
Quem já participou de projeto SAP sabe que o cadastro de fornecedor não nasce na transação. Ele nasce no e-mail de um comprador, num formulário de homologação, numa planilha que passou por três áreas. Quando a decisão de arquitetura ignora esse trajeto, a empresa governa muito bem a etapa final e continua recebendo dado ruim na entrada.
O que é o SAP MDG, segundo a própria SAP?
A SAP descreve o SAP Master Data Governance como uma solução de gestão de dados mestres com governança específica por domínio para criar, alterar e distribuir de forma central, ou consolidar, dados mestres (SAP Learning, curso "SAP Master Data Governance on SAP S/4HANA"). Na mesma documentação, a SAP organiza a solução em quatro capacidades principais:
- Governança central (central governance): criação, alteração e distribuição de dados mestres por solicitação de mudança (change request), com workflow, área de preparação (staging), aprovação, ativação e distribuição.
- Consolidação (consolidation): um processo com carga, verificação inicial, padronização, comparação (match), cálculo do melhor registro, validação e ativação, para chegar a uma fonte única da verdade.
- Processamento em massa (mass processing): alterações em volume em dados de parceiro de negócios, cliente, fornecedor e produto.
- Gestão de qualidade de dados (data quality management): definição de regras de qualidade de dados mestres, monitoramento e correção.
Os domínios citados pela SAP no mesmo material são parceiro de negócios (cliente e fornecedor), material e produto e dados financeiros, além de ofertas de parceiros para Enterprise Asset Management e Retail and Fashion Management.
Quais são as opções de implantação do SAP MDG?
A documentação de formação da SAP apresenta duas formas de implantar o SAP MDG em ambiente on-premise e uma oferta em nuvem. Essa escolha já é, na prática, metade da decisão de arquitetura.
| Opção | Como a SAP descreve | Benefícios que a SAP lista |
|---|---|---|
| Co-deployment | O MDG é implantado em um ou mais sistemas SAP S/4HANA locais, ou em um único SAP S/4HANA reutilizado pela paisagem para governança central. | Sem latência de replicação, sem monitoramento entre sistemas, sem integração e serviços externos adicionais. |
| Hub | Dados mestres de um ou mais sistemas entram na solução para verificação antes de serem replicados para a origem e para outros sistemas. | Começo com dados já saneados, independência dos ciclos de manutenção dos outros sistemas, sem carga adicional nos sistemas existentes, mais flexibilidade de mapeamento e de ciclo de vida do dado. |
| Cloud edition | SAP Master Data Governance, cloud edition, oferta em nuvem da SAP. | A SAP cita governança federada e integração com provedores de dados, entre outros recursos. |
Fonte da tabela: SAP Learning, lição "Describing Deployment Options and Landscapes". A SAP também informa que o MDG pode distribuir ou consolidar dados mestres em sistemas SAP Business Suite, SAP S/4HANA e outros sistemas SAP e não SAP.
O que significa ter um MDM complementar ao SAP?
MDM complementar é uma camada de gestão de dados mestres que fica fora do ERP e cuida de partes do ciclo de vida que acontecem antes, ao redor ou entre sistemas. Não é uma disputa de substituição. O ponto é decidir onde cada etapa do dado mestre acontece e quem é dono dela.
Na prática, essa camada costuma assumir uma ou mais destas funções:
- Captura do dado onde ele nasce, inclusive com pessoas que não usam o SAP, como solicitantes de outras áreas ou o próprio fornecedor.
- Validação em fontes externas antes da criação, como dados cadastrais públicos de CNPJ.
- Padronização e saneamento antes da carga, principalmente em migração.
- Distribuição do mesmo registro para mais de um ERP ou sistema satélite.
No caso da 4MDG, a plataforma funciona como registro de referência (golden record) e envia os dados ao ERP por conector, registrando situação, tentativas e retornos, conforme descrito na página Capacidades e arquitetura. Para SAP ECC e SAP S/4HANA, a integração listada inclui IDoc, BAPI, arquivo e API REST.
Em que cenários o SAP MDG tende a fazer mais sentido?
Pelas próprias características descritas pela SAP, o MDG tende a ser a escolha mais direta quando:
- A paisagem é predominantemente SAP S/4HANA e o dado mestre é criado e consumido ali.
- O escopo está nos domínios do padrão: parceiro de negócios, material e dados financeiros.
- Quem solicita, valida e aprova o cadastro já trabalha dentro do SAP.
- A empresa tem time, interno ou de parceiro, com competência para configurar e manter o MDG depois do go-live.
- O objetivo principal é ter solicitação de mudança, aprovação e trilha de auditoria dentro do próprio ambiente SAP.
Em que cenários uma camada de MDM complementar faz sentido?
A camada complementar ganha força quando a pergunta deixa de ser "como governar dentro do SAP" e passa a ser "como governar o dado antes e fora dele". Os sinais mais comuns são:
- Mais de um ERP: SAP na matriz e TOTVS ou Oracle em controladas, com fornecedores e materiais compartilhados.
- Dado que nasce fora do SAP: onboarding de fornecedores por portal, solicitações de áreas que não têm acesso ao ERP.
- Validação externa obrigatória: consulta a fontes públicas antes de liberar o cadastro.
- Autonomia da área de negócio: necessidade de ajustar fluxos e regras sem abrir um projeto SAP a cada mudança.
- Saneamento antes da migração: base legada que precisa ser deduplicada e padronizada antes da carga no S/4HANA.
Nenhum desses sinais, sozinho, define a resposta. Eles mostram onde vale aprofundar a análise.
Dá para usar SAP MDG e um MDM complementar juntos?
Dá, e em empresas grandes é comum que diferentes ferramentas cuidem de etapas diferentes. A condição é uma só: cada atributo precisa ter uma única fonte da verdade e um único fluxo de aprovação. O que não funciona é aprovar o mesmo dado duas vezes, com regras diferentes, em dois lugares.
Três erros aparecem com frequência quando essa divisão não é desenhada:
- Dois registros de referência: cada ferramenta acredita ser a dona do mesmo campo e uma sobrescreve a outra.
- Regras duplicadas: a obrigatoriedade de um campo é configurada em dois lugares e, com o tempo, as versões divergem.
- Aprovação em dobro: o solicitante aprova num fluxo e precisa aprovar de novo no outro, e o prazo de cadastro dobra.
Como decidir: checklist para a reunião de arquitetura
| Pergunta | Por que importa |
|---|---|
| Quantos sistemas recebem cada domínio de dado mestre? | Define se a distribuição é interna ao SAP ou entre plataformas. |
| Onde o dado nasce, de fato? | Mostra se a governança precisa começar antes do ERP. |
| Quem solicita e aprova, e essas pessoas usam o SAP? | Impacta licença, acesso e desenho do fluxo. |
| Quais validações externas são obrigatórias? | Indica integrações com fontes públicas ou provedores de dados. |
| Quais domínios e atributos estão no escopo? | Mostra o que está no padrão e o que exige extensão. |
| Quem mantém regras e fluxos depois do go-live? | Evita uma solução que só o projeto consegue alterar. |
| Qual é a fonte da verdade de cada atributo? | Evita dois registros de referência. |
| Como o cronograma do S/4HANA entra na decisão? | A arquitetura de dados mestres precisa estar definida antes da carga. |
Exemplo hipotético: uma indústria com dois ERPs
Exemplo hipotético, criado para ilustrar o raciocínio. Não se trata de um cliente real.
Uma indústria usa SAP S/4HANA na matriz e TOTVS numa controlada recém-adquirida. Os fornecedores são compartilhados, e o cadastro é feito duas vezes, com regras diferentes.
Desenho A: o SAP MDG em modelo hub passa a ser o ponto de criação do fornecedor e distribui o registro para o SAP S/4HANA e para o TOTVS. A empresa ganha um único fluxo dentro do ecossistema SAP, mas precisa construir e manter o mapeamento e a integração com o TOTVS, e os solicitantes passam a abrir as solicitações no MDG.
Desenho B: uma camada de MDM complementar recebe a solicitação, inclusive do próprio fornecedor, valida os dados cadastrais em fontes públicas e envia o registro aprovado para o parceiro de negócios do SAP S/4HANA e para o TOTVS. A governança da entrada fica fora dos ERPs, e o SAP recebe o dado já validado.
Os dois desenhos são defensáveis. A escolha depende das respostas do checklist, principalmente de onde o dado nasce e de quem vai manter o fluxo depois.
Por onde começar
- Desenhe o caminho do dado por domínio: onde nasce, quem altera, quem consome.
- Liste todos os sistemas que recebem fornecedor, cliente e material.
- Defina, atributo por atributo, qual é a fonte da verdade.
- Meça a qualidade da base atual antes de escolher ferramenta. Se a base estiver ruim, o saneamento de dados mestres vem antes de qualquer arquitetura.
- Faça uma prova de conceito com dados reais da empresa, não com dados de demonstração.
- Amarre a decisão ao cronograma do projeto. Se a empresa está indo para o S/4HANA, veja como a 4MDG trata migração SAP S/4HANA com saneamento antes da carga.
Para entender a diferença de papéis entre ERP e MDM antes dessa decisão, vale ler também MDM vs. ERP: qual a diferença.
Perguntas frequentes
A 4MDG substitui o SAP MDG?
Não é esse o posicionamento. São abordagens diferentes. A 4MDG é uma plataforma de MDM integrada a ERPs como SAP, TOTVS e Oracle, e o desenho adequado depende do cenário, inclusive em arquiteturas em que convive com o SAP MDG.
O SAP MDG trabalha com sistemas que não são SAP?
Segundo a SAP, o MDG pode distribuir ou consolidar dados mestres em sistemas SAP e não SAP. O ponto de atenção é o esforço de mapeamento, integração e monitoramento, que precisa ser dimensionado no projeto.
Preciso decidir isso antes da migração para o SAP S/4HANA?
É o recomendado. A arquitetura de dados mestres define onde o dado será saneado, validado e aprovado. Decidir depois da carga costuma significar migrar o problema e corrigir em produção.
O SAP MDG tem versão em nuvem?
Sim. A SAP oferece o SAP Master Data Governance, cloud edition, além das implantações em SAP S/4HANA. As capacidades variam por edição e versão, então vale conferir a documentação vigente da SAP para o seu cenário.
As descrições de funcionalidades do SAP Master Data Governance foram retiradas da documentação oficial da SAP na data de acesso indicada e podem mudar entre versões. SAP, SAP S/4HANA e SAP Master Data Governance são marcas da SAP SE.
Fontes
- Introducing SAP Master Data Governance, curso "SAP Master Data Governance on SAP S/4HANA". SAP Learning. Acesso em 02/10/2026.
- Describing Deployment Options and Landscapes, curso "Introducing SAP Master Data Governance". SAP Learning. Acesso em 02/10/2026.
- SAP Master Data Governance: Features and Benefits. SAP. Acesso em 02/10/2026.
- Capacidades e arquitetura e Migração SAP S/4HANA. 4MDG. Acesso em 02/10/2026.