Agente de master data: registos limpos no ERP e no CRM

Quase todas as empresas mid-market com que trabalhamos já fizeram uma limpeza de dados. Alguém passou seis semanas a fundir clientes duplicados, a normalizar descrições de artigos e a corrigir dados bancários de fornecedores. Funcionou. E ao fim de dois ou três trimestres o conjunto de dados tinha voltado a degradar-se, porque nada mudou na forma como os registos são criados e mantidos.

Esta é a característica definidora do master data — os dados mestre da empresa: não é um projeto com um estado de conclusão, é uma condição contínua. Os registos são criados diariamente por pessoas sob pressão de tempo que estão a tentar fazer outra coisa: registar uma encomenda, lançar uma compra, anotar um lead. Cada um desses momentos é uma oportunidade para um duplicado, um número de identificação fiscal mal formado, uma unidade de medida inconsistente. O ritmo de criação é constante, pelo que qualquer solução que não seja igualmente constante perde.

E é isso que faz da custódia de dados um bom encaixe para um agente. Não porque detetar duplicados seja tecnicamente difícil, mas porque o trabalho é interminável, sem brilho e sempre o primeiro a ser adiado quando uma pessoa tem algo mais urgente para fazer.

Este artigo trata do agente e do modelo de custódia contínua. A questão anterior — o que é de facto um cliente e que sistema é proprietário de que campo — é tratada separadamente em Um cliente, dois sistemas, e o agente aqui descrito depende de essas decisões já estarem tomadas.

Porque é que isto importa

A qualidade do master data é o substrato sobre o qual tudo o resto funciona, pelo que as suas falhas aparecem como problemas de outras pessoas. A previsão da equipa comercial não é fiável. As compras não conseguem ver a despesa consolidada por fornecedor. O armazém prepara o artigo errado porque dois registos descrevem a mesma coisa de forma diferente. A área financeira não consegue calcular a rentabilidade por cliente. Cada um destes casos é investigado como um problema separado e todos remetem para a mesma causa.

Os custos mais fáceis de quantificar são normalmente os menos importantes. Registos de fornecedor duplicados são um vetor real de fraude em pagamentos: uma alteração fraudulenta de dados bancários é materialmente mais difícil de detetar quando existem três registos do mesmo fornecedor. Dados de artigo inconsistentes provocam imprecisão de inventário, que provoca tanto ruturas de stock como abates. E ao abrigo do RGPD, um pedido de apagamento ou de acesso não pode ser satisfeito de forma fiável se não conseguir afirmar com confiança que registos se referem à mesma pessoa.

Existe também um efeito cumulativo. Cada integração, cada relatório, cada automatização construída sobre master data deficiente herda o problema e acrescenta a sua própria lógica para o contornar. Dois anos disso produzem um parque de sistemas em que ninguém consegue explicar porque é que dois relatórios divergem, e a resposta é sempre a mesma.

Num relance: o que o agente monitoriza e o que pode decidir

A linha dos dados bancários de fornecedor é a que deve interiorizar. Um agente que pode atualizar os dados de pagamento de um fornecedor é um agente que pode ser manipulado para redirecionar os seus pagamentos. Essa autoridade não deve existir, por conveniente que fosse.

O que funciona e sobre o que ser honesto

O que funciona:

Prevenção no momento da criação, à frente da deteção posterior. Um agente que avisa um comercial, a meio do registo, de que já existe uma conta semelhante evita um duplicado a custo quase nulo. Detetar esse mesmo duplicado uma semana depois custa vários minutos a um responsável de dados e uma decisão de fusão. Distribua o esforço em conformidade — a maioria das implementações faz isto ao contrário.

Uma banda de confiança com três zonas. Acima do limiar superior, fundir automaticamente com trilho de auditoria. Abaixo do limiar inferior, ignorar. Entre os dois, encaminhar para um responsável de dados. A banda intermédia é onde deve estar o esforço de desenho, e a sua largura deve estreitar à medida que o agente acumula histórico de resoluções.

Reversibilidade em cada ação automatizada. Cada fusão, normalização e sobreposição tem de ser reversível individualmente, com o estado anterior conservado. É isto que torna a fusão automatizada aceitável para os auditores e para as pessoas cujos registos estão a ser alterados, e é isto que permite apertar limiares conservadores ao longo do tempo.

Um responsável de dados com nome por domínio. Os dados de cliente, artigo e fornecedor precisam de um proprietário — uma pessoa, não um comité. O agente faz o trabalho; o responsável decide os casos ambíguos e responde pela métrica de qualidade. As implementações sem um responsável com nome acumulam uma fila desacompanhada e falham em silêncio.

A divergência como métrica visível. Número de registos divergentes, duplicados detetados, tempo até à resolução, registos criados sem validação. Quando isto está num dashboard pelo qual alguém responde, o comportamento muda a montante — e isso faz mais pela qualidade dos dados do que qualquer volume de limpeza a jusante.

Sobre o que ser honesto:

O agente não consegue corrigir um modelo de dados indefinido. Se não existe uma resposta acordada quanto a se um grupo e as suas subsidiárias são um cliente ou cinco, o agente aplicará essa ambiguidade de forma consistente e em escala. O trabalho de definição vem primeiro e não pode ser automatizado.

A correspondência difusa produz falsos positivos e falsos negativos, permanentemente. Não há limiar que elimine ambos. Está a escolher que erro prefere e, em master data, a preferência correta é quase sempre tolerar duplicados em vez de arriscar fusões erradas — um duplicado é um incómodo, uma fusão errada pode colocar as transações de um cliente na conta de outro.

Um backlog tem de ser limpo em separado, e é a parte cara. O agente mantém limpo um conjunto de dados limpo. Não limpa com eficiência um conjunto sujo, porque um grande backlog histórico é composto sobretudo por casos ambíguos que exigem juízo humano. Orce a limpeza do backlog como uma linha de trabalho própria.

Os dados de artigo são muito mais difíceis do que os de cliente. Os clientes têm número de identificação fiscal — uma chave de correspondência forte e quase única. Os artigos habitualmente não têm. A correspondência de artigos depende de descrições, especificações e códigos internos aplicados de forma inconsistente, e a desduplicação automatizada de artigos é, por consequência, menos fiável e precisa de uma banda de revisão humana mais larga.

Alguma divergência é legítima. O endereço de faturação de um cliente ser diferente do seu endereço de entrega não é um erro. Um fornecedor conhecido pelo nome comercial no CRM e pela denominação legal no ERP pode estar inteiramente correto. Regras que tratam toda a diferença como erro geram uma fila de não problemas e treinam os responsáveis de dados a ignorar a fila.

Quadro de decisão: por onde começar

Percorra por ordem. Pare na primeira correspondência.

1. Tem um modelo de dados acordado e uma matriz de propriedade ao nível do campo?
Se não, comece por aí — veja o artigo complementar. Todos os passos seguintes dependem dele, e um agente implementado sem ele vai sistematizar a ambiguidade atual.

2. Existe um responsável de dados com nome para cada domínio de master data?
Se não, nomeie-os antes de construir qualquer coisa. O agente cria uma fila de decisões; uma fila sem proprietário é pior do que fila nenhuma, porque produz a aparência de governação sem a substância.

3. Continuam a ser criados duplicados e registos mal formados todos os dias?
Se sim, corrija primeiro a criação: avisos de duplicado durante o registo, validação do número de identificação fiscal por país, obrigatoriedade de campos, vocabulários controlados para os atributos de artigo. Isto é mais barato do que tudo o resto nesta lista e tem o maior efeito.

4. Tem um backlog histórico significativo?
Limpe-o como uma linha de trabalho definida, com um limiar de confiança, um trilho de auditoria e uma quarentena para o remanescente ambíguo. Aceite que um resíduo persistirá permanentemente. Não tente isto antes do passo 3, ou estará a limpar um conjunto de dados que continua a deteriorar-se.

5. Consegue medir a divergência e a duplicação?
Instrumente-o antes de implementar o agente, para ter uma linha de base. Sem ela não conseguirá demonstrar que o agente está a funcionar, e estas implementações são frequentemente postas em causa ao quarto mês.

6. Tudo o anterior já está no lugar?
Implemente, começando apenas com monitorização e deteção — sem fusão automatizada — durante o primeiro mês. Reveja o que teria fundido. Depois ative a ação automatizada na banda de confiança elevada e vá alargando à medida que a evidência se acumula.

7. Já implementado e os registos continuam a derivar?
O problema está no comportamento a montante e não na custódia. Verifique se as pessoas estão a criar registos no sistema errado, se o processo de registo do sistema proprietário é tão pesado que está a ser evitado, e se a matriz de propriedade é de facto imposta por permissões e não meramente documentada.

Custo e esforço indicativos

Pressupõe uma instância de CRM e uma de ERP com volumes de registos típicos do mid-market. Várias instâncias de CRM resultantes de aquisições, ou mestres de artigos com centenas de milhares de referências, alargam isto de forma material. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

O agente pode fundir registos sem revisão humana?
Na banda de confiança elevada, sim — mesmo número de identificação fiscal, mesma denominação legal, sem histórico transacional em conflito — desde que cada fusão seja registada e reversível. Na banda ambígua nunca deve fundir de forma autónoma, porque a assimetria de custo é severa: um duplicado não fundido é desarrumação, um par mal fundido mistura o histórico financeiro de duas empresas.

Como tratamos o problema do grupo e das subsidiárias?
Como uma decisão de modelação, não como um problema de correspondência. Decida se o grupo é um registo com hierarquia ou vários registos ligados, codifique essa estrutura em ambos os sistemas e então o agente terá algo inequívoco para aplicar. Tratado como problema de correspondência, produz falsos positivos constantes ou duplicados reais que ficam sem deteção.

E os dados bancários de fornecedor?
O agente deteta e sinaliza uma alteração e nunca deve aplicá-la. As alterações de dados bancários exigem verificação por canal alternativo com o fornecedor através de um contacto conhecido — uma chamada para um número que já tinha, não uma resposta ao e-mail que pede a alteração. Esta é uma das fraudes mais comuns e mais custosas contra empresas mid-market, e automatizá-la seria ativamente perigoso.

Isto exige uma plataforma MDM separada?
Normalmente não à escala mid-market. Um agente a operar sobre o CRM e o ERP existentes, com uma matriz de propriedade definida e uma fila para o responsável de dados, alcança a maior parte do benefício sem introduzir outro sistema para manter. As plataformas MDM dedicadas justificam o seu custo a maior escala, com muitos sistemas de origem ou hierarquias genuinamente complexas.

Quanto tempo até podermos confiar nos dados?
A prevenção do lado da criação melhora as coisas em semanas. Confiar num número que atravessa sistemas — pipeline reconciliado com o rédito, despesa consolidada por fornecedor — leva normalmente dois a três trimestres, porque exige o backlog limpo mais um período de operação limpa antes de os valores serem defensáveis.

Com que rapidez pode o agente ser ligado aos dois sistemas?
A ligação em si é rápida — um parceiro de implementação certificado como Stacksync pode ter a sincronização CRM-ERP bidirecional em tempo real a funcionar em semanas, que é exatamente a camada de dados de que este tipo de agente precisa. O que demora mais é o trabalho de governação acima: acordar a propriedade dos campos e as regras de fusão. Ligue o agente a definições limpas, não só a canos limpos.

Fecho — Próximos passos

O master data é uma função de manutenção que a maioria das empresas financia como projeto, e é por isso que a mesma limpeza é encomendada a cada poucos anos. O agente altera a economia da manutenção o suficiente para a tornar contínua em vez de periódica — mas apenas sobre um modelo definido, uma matriz de propriedade imposta e uma pessoa com nome que responda pelas decisões ambíguas.

Um diagnóstico útil que leva uma tarde: conte os seus registos de cliente em cada sistema, tente uma correspondência por número de identificação fiscal e conte quantos registos foram criados no último trimestre sem um número válido. O primeiro valor diz-lhe a dimensão do seu backlog. O segundo diz-lhe se ele continua a crescer — e isso determina em que passo do quadro começa realmente.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comercial e financeira. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis que se monitorizam a si próprios.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são ao nível do editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de registos de entidade e de artigo — https://docs.oracle.com/en/cloud/saas/netsuite/
• DAMA International, Data Management Body of Knowledge (DMBOK) — master data e dimensões da qualidade dos dados — https://www.dama.org
• Comissão Europeia, Regulamento Geral sobre a Proteção de Dados da UE — direitos do titular dos dados entre sistemas — https://commission.europa.eu/law/law-topic/data-protection_en
• Agencia Tributaria (Espanha), formato e validação do NIF — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), informação sobre NIF/NIPC — https://info.portaldasfinancas.gov.pt
• Experiência de projetos da Atypical Tech, programas de dados de CRM e ERP no mid-market em toda a Ibéria
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog