Manter os dados maus lá fora

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

Módulo 2 de 6 do capítulo Qualidade e governação de dados, capítulo 5 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: A governação é projetada dentro da org · Próximo: Conheça os seus dados

A pergunta que este módulo responde: Como manter os dados bons, e mantê-los assim?

Há duas formas de lidar com dados maus: impedi-los antes de entrarem, ou limpá-los depois. Vai fazer um pouco de cada. Mas, podendo escolher, prefiro evitar o problema a montar uma organização à volta de o limpar para sempre. Duplicados, identificadores maus, informação em falta, valores fora do padrão, utilizadores a alterar campos de que outro sistema é dono, integrações a sobrescrever dados bons com maus: tudo isso se torna o projeto de limpeza de alguém. Por isso a pergunta de design é que dados maus consigo razoavelmente manter lá fora, à partida? E «razoavelmente» importa, porque a resposta não é trancar cada campo até o sistema ficar inutilizável.

«Suficientemente bom» é uma definição de negócio

Antes de impedir dados maus, defina o que é bom. Não há uma definição única. Bom pode significar suficientemente completo para correr o processo, suficientemente preciso para decidir com base nele, suficientemente atual para a carga de trabalho, suficientemente consistente para combinar com outros sistemas, suficientemente único para saber de que cliente estamos a falar, suficientemente padronizado para a automação, suficientemente rastreável para saber de onde veio. Depende dos dados. Se a Steve Trucking está a faturar um Parceiro retalhista, a identidade legal do parceiro tem de estar certa. Se um comercial está a tomar notas depois de uma reunião, ninguém precisa de um comité a aprovar cada frase. «Suficientemente bom» é uma definição de negócio; o arquiteto torna-a mensurável e aplicável.

Evite os erros caros

Nem todos os campos maus merecem a mesma atenção. Importo-me mais com os erros que têm consequências a jusante. Um cliente duplicado significa dois históricos de vendas, dois históricos de atendimento, dois conjuntos de contactos, dois IDs externos, duas integrações a sincronizar a mesma empresa, duas versões no data warehouse e no Data 360 e, no fim, um agente a decidir qual é o cliente verdadeiro. Isso é muito mais caro do que um erro de escrita numa descrição. Por isso não comece por «como validamos cada campo?» Comece por que dados maus criam o maior problema de negócio ou de arquitetura? e ponha ali os controlos mais fortes.

Aberta ou trancada?

A criação de contas é o exemplo clássico. Cada comercial deve poder criar uma conta? A minha resposta: depende da governação à volta dos dados. Para a maioria das orgs pequenas e médias, a criação aberta serve. Um comercial conhece um prospect, cria a conta, começa a trabalhar; é para isso que serve o CRM. As regras de duplicados, a informação obrigatória e o stewardship tratam da qualidade. Não acrescento um processo pesado de aprovação só porque governação soa a responsável.

Agora mude o panorama. O cliente legal é mestre no ERP, entra no Salesforce com um identificador do ERP, e o ERP tem autoridade. Agora criação aberta significa duas formas de criar a mesma entidade governada. Quando o ERP e um comercial criam a mesma empresa, qual ganha, que identificador usam as integrações, que registo guarda o histórico? A criação aberta deixa de ser uma questão de usabilidade e passa a ser uma questão de dados mestres. Quando as contas são mestres num ERP ou sincronizadas com ele, tranque a criação.

Mas trancar completamente também falha. O comercial conheceu um prospect que não está no ERP e quer abrir uma oportunidade, e o modelo de governação diz «nada de conta para si». Então espera três dias pelas Finanças, ou liga a oportunidade à conta errada, ou guarda o prospect num campo de notas ou numa folha de cálculo. Protegemos o modelo de dados e prejudicámos o negócio.

O caminho do meio: um tipo de registo provisório

Eis o caminho do meio de que gosto. Deixe as vendas criarem a conta com um tipo de registo específico, um tipo prospect ou provisório, e controle a sua conversão para o tipo governado. As vendas registam a empresa e começam a vender. O registo diz com clareza: ainda não estabelecido no sistema com autoridade. Depois um processo controlado converte-o: as Finanças aprovam-no, ou uma integração submete-o ao ERP, que o faz corresponder a um cliente existente ou cria um novo e devolve o identificador com autoridade. Agora o registo atravessa uma fronteira, provisório → governado, o que é muito diferente de dois sistemas a criarem, cada um, o que acreditam ser o registo mestre.

O tipo de registo é o mecanismo que ensino. Seja o que for que use, torne o estado visível nos dados: de onde veio o registo, se já atravessou a fronteira, quem o pode alterar agora, e o identificador que o liga ao sistema com autoridade. O ID de cliente do ERP, que só existe depois da conversão, é o sinal mais claro de todos.

Um tipo de registo para cada fluxo

Ponha o fluxo inteiro numa só imagem e vai ver porque é que isto funciona. Os clientes e os produtos entram vindos do ERP. As oportunidades e os seus itens de linha saem e tornam-se as encomendas do ERP. E as contas? Algumas entram, algumas saem. Por isso, um padrão comum que já vi em várias implementações são dois tipos de registo em Conta, um para cada direção. Uma conta de Vendas (Sales) nasce no Salesforce: os vendedores criam-na, editam-na, vendem-lhe e, quando se torna cliente, é enviada para o ERP. Uma conta ERP (já lhe chamei Customer, ou simplesmente SAP) nasce no ERP e entra pela integração. Ninguém cria esse tipo de registo a não ser a integração, e os campos de dados mestres dela (denominação social, moradas, condições de pagamento) são só de leitura para os utilizadores. O tipo de registo diz para que lado o registo flui, por isso a direção da gestão de dados mestres está ali mesmo, no registo.

Click to enlarge

Um tipo de registo para cada fluxo: as contas de Vendas saem, as contas do ERP entram.

Isto não elimina o caso difícil. Um vendedor converte um lead da Steve’s Plumbing, mas a Steve’s Plumbing já existe como conta do ERP e, de alguma forma, a verificação de duplicados não a apanhou. Agora está a fundir, a reatribuir os filhos a outro pai e a decidir que registo sobrevive (capítulo 6, módulo 3).

E não se prenda ao tipo de registo em si. Normalmente evito tipos de registo, a menos que haja uma boa razão para eles. Usei-os aqui porque, antes do Dynamic Forms, o tipo de registo escolhia o layout de página, e um layout mostrava os campos do ERP como só de leitura. Com o Dynamic Forms, as regras de visibilidade podem mostrar e ocultar campos conforme o valor de um campo, um campo pode ser só de leitura numa determinada página, e a própria Salesforce diz que o Dynamic Forms reduz o número de layouts de página e de tipos de registo de que precisa (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab); em inglês). Mas só de leitura numa página é só de leitura nessa página: a API, um carregamento de dados ou uma integração ainda podem escrever no campo. A verdadeira aplicação é a segurança em nível de campo ou uma regra de validação; a validação na interface não é validação de dados (capítulo 3, módulo 9). Os tipos de registo continuam a merecer o seu lugar quando os dois tipos de conta precisam de valores de lista de opções ou de processos de negócio diferentes. O que importa mesmo é que algum campo diga claramente de onde veio o registo: a própria chave do ERP, um indicador de dados mestres ou uma lista de opções de origem. Depois, controle a possibilidade de edição a partir desse campo.

Click to enlarge

De provisório a governado: as vendas começam a vender de imediato; só o processo autoritativo torna o registo governado.

Proteja o registo governado

Depois de o cliente voltar do ERP, o ID do ERP, a denominação social, o número de identificação fiscal e os dados de faturação são atributos governados. O comercial deve alterá-los? Não, se o ERP é dono deles. É a política do módulo 1 a precisar do seu ponto de aplicação: o ID do ERP só de leitura, a identidade legal controlada, enquanto o comercial continua a editar território, notas da relação e as classificações próprias do Salesforce. O objetivo não é uma conta intocável. É uma linha clara entre dados de que o Salesforce é dono e dados que o Salesforce referencia. (O prefixo erp_ do capítulo 4 torna essa linha visível no esquema.)

O que obtém no fim é um golden record que, na verdade, é híbrido. Os campos de dados mestres do ERP entram: denominação social, moradas de faturação e de entrega, condições de pagamento. Depois o Salesforce acrescenta campos próprios que nunca voltam: uma classificação de vendas, a data da última encomenda, praticamente tudo o que o marketing usa. A mesma conta, dois tipos de campo, e cada tipo tem uma única origem.

O mais difícil são os bidirecionais. Digamos que um vendedor precisa que a denominação social no ERP mude de Steve’s Plumbing para Steve’s Plumbing LLC. Nesses mesmos cinco minutos, alguém no ERP muda-a para Steve’s Plumbing L.L.C. A mudança de quem prevalece? Esta é a mentalidade: se um campo tem o ERP como mestre, não está a alterar o campo, está a pedir para o alterar. Decida o que acontece quando o pedido colide: o ERP prevalece, o pedido é rejeitado se o valor mudou entretanto, ou fica à espera de que uma pessoa o resolva. E decida se os campos relacionados viajam juntos como uma só mudança ou um de cada vez. O capítulo 6 leva as colisões mais longe (Ciclos e colisões).

Barre os duplicados à porta

Os duplicados acumulam-se. Apanhe um antes de ser criado e é um problema pequeno. Encontre-o dois anos depois, com oportunidades, casos, contactos, faturas, integrações e análises pendurados nos dois, e é um problema grande. O módulo 7 do capítulo 3 tratou dos mecanismos (regras de correspondência, regras de duplicados, IDs externos únicos), por isso não os vou voltar a ensinar. A pergunta de governação é onde precisamos de impedir a duplicação, e onde a vamos tolerar e resolver depois? Um lead casual de marketing convive com ambiguidade. Um cliente governado pelo ERP, com transações financeiras, não.

Padronize o que as máquinas leem

O texto livre é maravilhoso para pessoas e terrível quando um sistema o tem de interpretar. Ponha Arizona, AZ, Ariz., região de Phoenix e Sudoeste num campo que determina o planeamento de rotas, e tem um problema de qualidade. Se um valor determina automação, integração, relatórios, segurança, atribuição ou a ação de um agente, pense bem em quão padronizado tem de ser. Nem todos os campos de texto passam a lista de opções, mas distinga informação que as pessoas leem de informação com base na qual as máquinas decidem. A segunda merece um controlo mais forte.

Não deixe campos obrigatórios criarem dados falsos

Decidimos que um campo importa e tornamo-lo obrigatório. O utilizador não sabe a resposta, o sistema não o deixa continuar, por isso escreve N/A, Desconhecido, 999999 ou teste@teste.com. O campo está completo; os dados são lixo. Antes de exigir algo, pergunte se o utilizador sabe realmente isso naquele momento. Se não sabe, exija-o mais adiante no processo, deixe outro sistema fornecê-lo, use o estado provisório, ou ofereça um Desconhecido explícito quando desconhecido é uma resposta legítima. Uma regra de validação consegue aplicar uma política. Não consegue pôr alguém a saber o que não sabe.

Cada fronteira de dados precisa de uma decisão de qualidade

As pessoas não são a única fonte de dados maus; as integrações produzem-nos mais depressa. O manifesto de um Parceiro retalhista chega com algumas centenas de linhas. Um punhado tem códigos postais inválidos, algumas referem um centro de distribuição desconhecido, duas repetem a mesma referência de encomenda. O que acontece? Rejeitar o ficheiro inteiro? Aceitar as linhas boas e devolver as más? Carregar tudo e limpar depois? Pôr as exceções em quarentena? Quem é avisado, e como fica o parceiro a saber do que falhou? Não há resposta universal, mas tem de haver uma. O capítulo 4 disse que cada seta precisa de um mecanismo. Acrescente: cada fronteira de dados precisa de uma decisão de qualidade: o que aceitamos, rejeitamos ou pomos em quarentena, e quem é dono da exceção.

Click to enlarge

Cada fronteira de dados precisa de uma decisão de qualidade.

Os dados históricos são diferentes

O RouteDesk guarda oito anos do histórico da Steve Trucking, e a qualidade varia por centro de distribuição. Devemos limpar os oito anos até ao padrão de hoje antes de os mover? Provavelmente não, automaticamente. Para que servem: operação diária, referência, reclamações, relatórios, análise de tendências? Têm todos de estar no Salesforce, ou alguns podem ficar noutro lado? O capítulo de migração vai a fundo. O ponto de governação: o histórico não precisa automaticamente do mesmo padrão que os dados ativos. Se vai tomar decisões com base nele, a qualidade importa. Se o está a guardar como referência, outro padrão pode bastar. Saiba o propósito antes de gastar uma fortuna a limpar o passado.

Meça aquilo sobre o que alguém vai agir

A governação nunca termina, por isso precisa de ver quando a qualidade escorrega: taxa de duplicados a subir, mais registos em quarentena, mais rejeições de integração, valores de preenchimento a espalhar-se, mais pedidos de desvio, relatórios que já não batem certo. Mas não construa 150 métricas para ignorar 143 delas. Para a Steve Trucking, talvez sejam entregas sem uma referência de parceiro válida, entregas sem uma morada utilizável, referências de encomenda repetidas, mensagens de parceiro rejeitadas, contas presas no estado provisório. Um dashboard cheio de bolinhas verdes não significa que os dados são bons. Meça aquilo sobre o que alguém está disposto a agir.

Além do exame: o que a IA muda. Os dados maus transformam-se, cada vez mais, em ações más. Uma pessoa pode reparar que um telefone parece errado antes de ligar; um agente simplesmente usa o valor que recebe. Clientes duplicados, estados desatualizados, valores obrigatórios falsos e identificadores errados transformam-se diretamente na mensagem errada ou na atualização errada. Isso aumenta o valor da prevenção. Não elimina a necessidade de stewardship.

O que um arquiteto decide aqui

• Que falhas de qualidade causam dano suficiente para justificar controlos preventivos.
• Se os registos governados são criados livremente, só pelo sistema com autoridade, ou por um caminho de provisório para governado.
• De que atributos o Salesforce é dono e quais só referencia.
• O que acontece aos dados de entrada que chumbam nas verificações (aceitar, rejeitar ou pôr em quarentena) e quem é dono da exceção.
• Que sinais de qualidade são medidos, para que os stewards vejam o escorregar.

Nunca vai impedir todos os registos maus. O trabalho não são dados perfeitos; é impedir que dados maus evitáveis se tornem dados caros. Barre o duplicado antes de ele ter dois anos de histórico. Proteja o identificador antes de dez integrações dependerem do errado. Deixe as vendas criarem o prospect, mas não finja que é o cliente governado até que o seja. E, quando algo mau passar, garanta que alguém o consegue ver, assumir e corrigir.

Para saber mais

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) e Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (em inglês), consultados em 2026-10-14.