MDM de um domínio ou multidomínio: por onde começar o cadastro

Separe duas decisões: a arquitetura e o escopo. Escolha uma plataforma que suporte vários domínios, para não criar silos quando o segundo cadastro chegar, e comece por um domínio só: aquele em que a dor de negócio pode ser medida, o dono do dado está disponível e o resultado aparece para quem paga a conta. Material, fornecedor ou cliente: quem decide é a dor, não quem fala mais alto na reunião.

Já vi essa reunião em muitos projetos. O programa de MDM foi aprovado, a verba existe, e alguém pergunta: "Por qual cadastro a gente começa?"

Compras quer fornecedor, porque é ali que aparece fornecedor sem homologação ou com documento vencido. Engenharia e manutenção querem material, porque o mesmo item está cadastrado com descrições diferentes e ninguém acha a peça certa. Comercial quer cliente, porque pedido trava por endereço errado ou limite de crédito desatualizado. Cada diretor tem razão sobre a própria dor. O que falta na mesa é um critério para escolher.

O que é MDM de um domínio e o que é MDM multidomínio?

A SAP define a disciplina assim: "O gerenciamento de dados mestre é a disciplina de criar e manter uma visão única e confiável dos dados de negócios mais importantes de uma organização em todos os sistemas." Esses dados descrevem entidades "como clientes, fornecedores, produtos, materiais e ativos", e a mesma página explica que "Os dados mestre são normalmente organizados em domínios com base no tipo de entidade de negócios central" (SAP, O que é gerenciamento de dados mestre (MDM)?).

A partir daí, a forma como eu explico os termos é esta:

• Domínio: um tipo de entidade de negócio com modelo, regras e donos próprios. Material, fornecedor, cliente, financeiro e dados de referência são os mais comuns.
• Domínio único: o programa e a ferramenta cuidam de um tipo de entidade só. Por exemplo, apenas materiais.
• Multidomínio: uma plataforma, um modelo e uma governança cobrindo vários domínios, com regras, workflows e dados de referência compartilhados.
• Vários domínios em ferramentas separadas: cada domínio tem a sua ferramenta, as suas regras e a sua equipe. Parece multidomínio no organograma, mas na operação são silos que não conversam.

Se quiser revisar o conceito de MDM e a relação com o ERP, escrevi sobre isso em o que é MDM e como ele sustenta o ERP.

Escolher multidomínio e escolher por onde começar são a mesma decisão?

Não. E é aqui que muita reunião se perde.

A decisão de arquitetura responde: a plataforma que vamos usar consegue cuidar de mais de um domínio, com o mesmo modelo de workflow, as mesmas regras, o mesmo histórico e os mesmos dados de referência? Essa decisão olha para os próximos anos.

A decisão de escopo responde: qual domínio entra na primeira onda, com qual recorte, qual dono e qual resultado esperado? Essa decisão olha para os próximos meses.

Uma não obriga a outra. Dá para ter uma plataforma multidomínio e começar só por materiais. E dá para comprar uma ferramenta de domínio único e descobrir, quando fornecedor entrar na pauta, que vai ser preciso outra ferramenta, outro contrato e outra integração. Multidomínio diz onde você quer chegar. O primeiro domínio diz onde você pisa amanhã.

Quais critérios usar para escolher o primeiro domínio?

A tabela abaixo é o roteiro que eu recomendo levar para a reunião. Faça as perguntas para cada domínio candidato e compare as respostas. Não existe peso universal: quem define o peso de cada critério é a estratégia da empresa naquele momento.

Critério	Pergunta a fazer	Sinal de bom candidato
Dor de negócio mensurável	Que prejuízo esse cadastro causa hoje e como ele aparece em indicador?	A dor tem número na operação: compra repetida, pedido travado, pagamento retido, nota rejeitada.
Dono do dado disponível	Quem decide a regra e aprova a exceção?	Existe uma pessoa com nome, tempo e autoridade para decidir.
Volume e reincidência de erro	O erro é pontual ou volta toda semana?	O mesmo tipo de erro se repete e alimenta retrabalho.
Dependência de outros processos	Quantos processos param quando esse cadastro está errado?	O domínio alimenta compras, estoque, fiscal, faturamento ou manutenção ao mesmo tempo.
Dados de referência compartilhados	Que tabelas comuns esse domínio usa?	Desenhar o domínio obriga a organizar unidades, países ou condições de pagamento que os próximos domínios vão reaproveitar.
Projeto âncora	Existe migração, implantação ou mudança regulatória com data marcada?	O domínio está no caminho crítico de um projeto como a migração para o SAP S/4HANA ou a adequação à Reforma Tributária.
Risco de compliance	O cadastro errado expõe a empresa a autuação, fraude ou sanção?	Um erro nesse domínio gera risco fiscal, de pagamento indevido ou de relacionamento com terceiro não homologado.
Capacidade de mostrar resultado	Dá para comparar antes e depois em poucas semanas?	Há linha de base medida e um recorte pequeno o bastante para mostrar ganho cedo.

Repare que "quem é o patrocinador" não está na tabela. Sem patrocínio o programa nem existe, mas a escolha do domínio precisa seguir a dor. Se o domínio do patrocinador também for o da dor, ótimo. Se não for, vale a conversa franca antes de começar.

O que muda entre materiais, fornecedores e clientes?

Cada domínio pede um tipo de regra, um tipo de dono e um tipo de validação. Conhecer essa diferença ajuda a estimar esforço e a escolher a equipe.

Materiais

A dor mais comum é a descrição livre: cada pessoa escreve do seu jeito, e o mesmo item acaba cadastrado mais de uma vez. O trabalho está em padronizar a descrição, definir atributos por família, organizar a classificação (incluindo a classificação fiscal, como o NCM, Nomenclatura Comum do Mercosul) e envolver engenharia, manutenção, suprimentos e fiscal. Se essa é a sua dor, vale ler como identificar materiais duplicados.

Fornecedores

Aqui a duplicidade tende a ser menor quando o CNPJ é usado como chave, desde que se tratem raiz e filiais, além de pessoa física (CPF) e fornecedor estrangeiro. A dor é outra: fornecedor sem homologação, documento vencido, dados bancários sem conferência, situação cadastral que não confere com a fonte oficial. O trabalho está em validar dados em fonte oficial, controlar documentos e prazos de homologação e deixar compras, financeiro e compliance com papéis claros no fluxo.

Clientes

A dor aparece no pedido e na cobrança: endereço de entrega errado, grupo econômico mal montado, limite de crédito que não reflete a realidade, dados fiscais desatualizados. O trabalho envolve comercial, crédito, logística e fiscal, e a regra precisa respeitar a hierarquia do grupo econômico.

Em quem usa SAP S/4HANA, cliente e fornecedor convivem no Business Partner, e isso muda a conversa sobre separar os dois domínios. Escrevi sobre esse ponto em Business Partner no S/4HANA.

Por que os dados de referência vêm antes de qualquer domínio?

Unidades de medida, países, regiões, moedas, condições de pagamento, tabelas fiscais como o NCM: são listas que quase todos os domínios usam. Se cada domínio desenhar a sua versão, a empresa termina com três tabelas de unidade de medida e nenhuma confiável.

Minha recomendação é desenhar os dados de referência uma vez, na primeira onda, mesmo que o primeiro domínio use só parte deles. É o pedaço da arquitetura multidomínio que mais rende quando o segundo domínio chega, porque ele já encontra a base pronta.

Como essa escolha fica num caso concreto?

Exemplo hipotético: uma indústria com SAP ECC prepara a migração para o S/4HANA. Na reunião de escopo, compras pede fornecedor, manutenção pede material e comercial pede cliente.

Aplicando a tabela, o time percebe três coisas. Materiais tem a dor mais reincidente (descrições livres, itens repetidos no almoxarifado), um dono disponível na engenharia e está no caminho crítico da migração, porque carregar item duplicado no sistema novo só muda o problema de lugar. Fornecedores tem risco de compliance alto, mas a regra principal (validação em fonte oficial e homologação) pode entrar logo em seguida, aproveitando os mesmos dados de referência. Clientes depende de decisões sobre o Business Partner que ainda estão abertas no projeto de migração.

A decisão fica assim: plataforma multidomínio desde o início, primeira onda em materiais com saneamento antes da carga (o tema de saneamento de cadastro), dados de referência desenhados para servir a todos, segunda onda em fornecedores e terceira em clientes, depois que o desenho do Business Partner estiver fechado. Compras e comercial saem da reunião sabendo quando chega a vez deles e por quê.

Quando é hora de abrir o segundo domínio?

Não tenho um prazo para indicar, porque cada empresa anda num ritmo. Prefiro olhar sinais:

• O primeiro domínio roda no dia a dia sem depender da equipe do projeto para cada exceção.
• Os indicadores de qualidade melhoraram em relação à linha de base e pararam de oscilar.
• O dono do dado decide regra e exceção sem escalar tudo.
• Os dados de referência já estão estáveis e documentados.
• A área do próximo domínio tem dono nomeado e tempo reservado.

Se a maior parte desses sinais ainda não aparece, abrir o segundo domínio costuma dividir a atenção do time e atrasar os dois.

Quais erros evitar na escolha?

• Comprar ferramenta de um domínio só sem pensar no segundo. Resolve a dor de hoje e cria o silo de amanhã.
• Querer fazer todos os domínios de uma vez. O programa vira uma lista de pendências sem resultado visível.
• Começar pelo domínio do patrocinador em vez do domínio da dor. A primeira onda precisa provar valor, e isso é mais difícil onde a dor é menor.
• Pular a linha de base. Sem medir antes, ninguém consegue mostrar o que melhorou depois.
• Deixar dados de referência para depois. Cada domínio inventa a sua tabela e o retrabalho volta na segunda onda.

Por onde começar?

1. Feche a decisão de arquitetura. Defina se a plataforma precisa cobrir vários domínios, com regras, workflow e dados de referência comuns. Essa decisão vem antes da escolha do primeiro domínio.
2. Meça a linha de base de cada domínio candidato. Use indicadores simples e comparáveis. O passo a passo está em como medir a qualidade do cadastro.
3. Pontue os candidatos com a tabela de critérios. Leve as respostas para a reunião e decida com base nelas.
4. Nomeie o dono do dado do primeiro domínio. Uma pessoa, com tempo e autoridade, antes de começar.
5. Desenhe os dados de referência compartilhados. Uma vez, para todos os domínios.
6. Avalie o software e teste com os seus dados. Para os critérios de avaliação, use o checklist de software de MDM. Depois de escolher o domínio, teste com uma amostra real seguindo o roteiro de prova de conceito com seus dados.
7. Defina os sinais de saída da primeira onda. Combine antes quais sinais liberam o segundo domínio, para a decisão não voltar à disputa entre diretores.

Perguntas frequentes

Qual a diferença entre MDM multidomínio e ter várias ferramentas de MDM?

No multidomínio, uma plataforma cobre vários domínios com o mesmo modelo, as mesmas regras de workflow, o mesmo histórico e os mesmos dados de referência. Com várias ferramentas, cada domínio tem a sua lógica, a sua integração com o ERP e a sua equipe, e as tabelas comuns tendem a se repetir com diferenças entre elas.

Dá para começar com um domínio só numa plataforma multidomínio?

Dá, e é o caminho que eu recomendo. A plataforma garante que o segundo domínio vai aproveitar o que já foi feito. O escopo pequeno garante foco, dono claro e resultado visível na primeira onda.

Qual domínio costuma dar retorno mais rápido?

Depende da empresa, e desconfie de quem responde sem olhar os seus dados. O retorno mais rápido costuma vir do domínio em que a dor é reincidente, tem indicador, tem dono disponível e está no caminho de um projeto com data marcada. A tabela de critérios deste artigo serve para descobrir qual é o seu.

Quanto tempo esperar antes de abrir o segundo domínio?

Em vez de prazo, use sinais: o primeiro domínio roda sem a equipe do projeto, os indicadores melhoraram e estabilizaram, o dono decide exceções e os dados de referência estão estáveis. Quando esses sinais aparecem, o segundo domínio entra com menos risco.

Dados de referência são um domínio?

Podem ser tratados como um domínio próprio, com dono e regras. Na minha visão, o importante é tratá-los como base comum: desenhados uma vez, com dono definido, e reaproveitados por material, fornecedor e cliente.

O ERP já não é multidomínio?

O ERP guarda vários tipos de cadastro, mas guardar não é governar. O MDM cuida de como o dado nasce e muda: quem pede, quem valida, que regra se aplica, quem aprova e o que foi enviado ao ERP. Por isso a decisão de arquitetura do MDM continua necessária mesmo quando todos os cadastros já moram no mesmo ERP.

Como a 4MDG pode ajudar

A plataforma SaaS da 4MDG cobre material, fornecedor, cliente, financeiro e referência na mesma plataforma, com cada cadastro configurado como workflow. Por isso dá para começar por um domínio e abrir o próximo sobre os mesmos fluxos e dados de referência, com integração a ERPs como SAP, TOTVS e Oracle. Os detalhes estão em capacidades e arquitetura.

Se a dúvida ainda é por qual domínio começar, você pode pedir o diagnóstico: você envia uma amostra de materiais, fornecedores e clientes em planilha ou extração, nada é instalado no seu ambiente, e recebe índice de duplicidade, completude por atributo, conformidade cadastral, qualidade da descrição e uma recomendação de caminho.

Fontes

• SAP. O que é gerenciamento de dados mestre (MDM)? Acesso em 14/10/2026.