A Resposta Curta
Master Data Management (MDM) não é um repositório; é um acordo. Este acordo define quem estabelece a entidade, quem está autorizado a modificá-la, como identificar duas entradas como a mesma entidade e o que acontece quando os sistemas divergem. A tecnologia apenas garante a aplicação do que foi acordado.
O erro comum é começar pela escolha da ferramenta. Uma organização que não definiu claramente o que constitui um "cliente" acabará com uma ferramenta que unificará essa mesma ambiguidade, porém de forma mais rápida e com um custo mais elevado.
O Que Entra e o Que Não Entra no Master Data
| Tipo de Dado | Exemplo | É Master Data? |
|---|---|---|
| Master Data | Cliente, Produto, Fornecedor, Local | Sim |
| Reference Data | Países, Moedas, Códigos de Indústria | Gerenciamento separado e mais simples |
| Transacional | Pedido, Fatura, Case | Não |
| Analítico | Segmentação, Pontuação, Previsão | Não - É derivado |
Esta distinção é crucial, pois cada tipo requer uma governança diferente. O Reference Data é controlado em uma pequena tabela com um único proprietário; os dados Transacionais permanecem no sistema que os gerou; e os dados Analíticos não devem se tornar uma fonte de verdade, pois são o produto de um cálculo que pode mudar.
Três Estilos de Implementação
Registry - Gerencia apenas uma tabela de identificadores que interliga registros em diferentes sistemas. É de baixo custo, rápido, não altera nenhum sistema existente e fornece uma visão unificada para consulta. Quase sempre adequado como primeira etapa.
Consolidation - Cria um Golden Record para fins de relatório e análise, sem sincronizar de volta aos sistemas de origem. Adequado quando a principal dor é a duplicação de relatórios.
Centralized - O Master Data se torna a fonte autoritativa, e os sistemas consomem dele. Oferece o maior valor, mas também exige a maior governança e processos de aprovação. Organizações que pulam diretamente para esta etapa descobrem que não possuem as equipes (Stewards) para operá-lo.
A abordagem prática é gradual: comece com um Registry para uma única entidade e, em seguida, expanda — com base em valor comprovado, e não em um plano mestre.
Survivorship: As Regras Que Determinam o Que Permanece
O cerne do Golden Record são as regras de Survivorship em nível de campo: para cada campo, há uma fonte preferencial e uma regra de fallback quando a fonte preferencial está vazia. Além disso, os identificadores dos sistemas de origem são sempre mantidos para que cada valor possa ser rastreado.
Um princípio que evita discussões: o Golden Record não apaga os registros de origem e não se propõe a substituí-los. É uma camada que os referencia. Isso significa que uma regra pode ser corrigida e recalculada – uma capacidade ausente para quem consolidou tudo na fase de carregamento.
Uma discussão mais aprofundada sobre a propriedade dos dados é abordada em Source of Truth na Organização e na eliminação de duplicidades que precede isso em Eliminação de Duplicidades no Salesforce.
Stewardship: O Papel Que Determina o Sucesso
Todo regime de MDM gera uma fila de decisões: correspondências sobre as quais o sistema não tem certeza, solicitações para criar novas entidades e inconsistências entre as fontes. Se não houver uma pessoa com tempo alocado para resolver essa fila, ela crescerá até ser ignorada.
Alcance realista: em uma organização de médio porte, isso significa algumas horas por semana para uma única entidade, geralmente alguém do lado comercial e não da TI. Este é o investimento que define se o MDM prospera ou se torna uma infraestrutura esquecida.
Cenário: Um Fabricante Com Três Sistemas e Um Cliente
Um fabricante industrial gerenciava seus clientes em três locais: ERP, Salesforce e um sistema de serviço. A mesma empresa aparecia como três entidades distintas, e um relatório de "receita por cliente" era gerado manualmente em Excel a cada trimestre.
Em vez de um projeto completo de MDM, a organização começou com um Registry: foi criada uma tabela de identificadores no Data 360 que vinculava os três registros usando CPF/CNPJ e uma chave secundária, e só depois foi construído um Golden Record para consulta. O Salesforce não teve sua estrutura alterada; ele recebeu um campo de identificador global e uma visualização de "toda a atividade do grupo".
O resultado após um trimestre: o relatório manual foi eliminado, e os vendedores viram pela primeira vez o risco de crédito em nível de grupo – o que impulsionou uma decisão de precificação que recuperou o custo da fase inicial. A expansão para um modelo Centralized foi considerada somente após a comprovação de que havia um Steward ativamente resolvendo a fila.
Riscos Comuns e Ações Preventivas
| Risco | Como se manifesta na prática | Ação Preventiva |
|---|---|---|
| Começar pela ferramenta | Um repositório unificado que reflete a ambiguidade existente | Definições de entidade e propriedade antes da escolha da ferramenta |
| Muitas entidades | Projeto longo sem valor visível | Uma entidade até a produção, depois expansão |
| Ausência de Steward | Fila de reconciliações que cresce e é abandonada | Função com tempo alocado e SLA |
| Fusão destrutiva | Impossibilidade de explicar ou reverter valores | Preservar identificadores de origem e permitir recálculo |
| Centralized prematuro | Todos os sistemas dependem de uma infraestrutura imatura | Começar com Registry |
Como Medir o Sucesso
| Área | O Que Medir | Frequência de Verificação |
|---|---|---|
| Cobertura | Percentual de registros vinculados a um identificador global | Mensal |
| Precisão | Taxa de vínculos cancelados ou corrigidos | Mensal |
| Fila de Stewardship | Itens abertos e tempo médio de resolução | Semanal |
| Valor de Negócio | Relatórios manuais eliminados, decisões em nível de grupo | Trimestral |
A construção de um regime de MDM escalonado é realizada como parte dos serviços de integração e dados.
Checklist Antes de Iniciar o MDM
- ☐ Foram escolhidas até três entidades para a primeira fase
- ☐ Para cada entidade, existe uma definição de negócio documentada
- ☐ O estilo de implementação foi selecionado: Registry, Consolidation ou Centralized
- ☐ Chaves de identificação robustas foram identificadas para cada fonte
- ☐ Regras de Survivorship foram escritas em nível de campo
- ☐ Identificadores de origem são mantidos e permitem recálculo
- ☐ Um Steward foi nomeado com tempo alocado e SLA
- ☐ Foi definido um processo de aprovação para a criação de novas entidades
- ☐ Foi estabelecida uma métrica de valor para a primeira fase
- ☐ Há uma decisão sobre quando considerar uma ferramenta especializada
Recursos Profissionais
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data