Mantendo dados ruins do lado de fora

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · 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 por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 2 de 6 do capítulo Qualidade e governança de dados, capítulo 5 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: A governança é projetada dentro da org · Próximo: Conheça 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 ruins: impedi-los antes que entrem, ou limpá-los depois. Você vai fazer um pouco de cada. Mas, podendo escolher, prefiro evitar o problema a montar uma organização em torno de limpá-lo para sempre. Duplicatas, identificadores ruins, informação faltando, valores fora do padrão, usuários alterando campos de que outro sistema é dono, integrações sobrescrevendo dados bons com ruins: tudo isso vira o projeto de limpeza de alguém. Então a pergunta de design é que dados ruins consigo razoavelmente manter do lado de fora, para começo de conversa? E “razoavelmente” importa, porque a resposta não é travar cada campo até o sistema ficar inutilizável.

“Bom o bastante” é uma definição de negócio

Antes de impedir dados ruins, defina o que é bom. Não há uma definição única. Bom pode significar completo o bastante para rodar o processo, preciso o bastante para decidir com base nele, atual o bastante para a carga de trabalho, consistente o bastante para combinar com outros sistemas, único o bastante para saber de qual cliente estamos falando, padronizado o bastante para a automação, rastreável o bastante para saber de onde veio. Depende dos dados. Se a Steve Trucking está faturando um Parceiro varejista, a identidade legal do parceiro precisa estar certa. Se um vendedor está anotando algo depois de uma reunião, ninguém precisa de um comitê aprovando cada frase. “Bom o bastante” é uma definição de negócio; o arquiteto a torna mensurável e aplicável.

Evite os erros caros

Nem todo campo ruim merece a mesma atenção. Me importo mais com os erros que têm consequências adiante. Um cliente duplicado significa dois históricos de vendas, dois históricos de atendimento, dois conjuntos de contatos, dois IDs externos, duas integrações sincronizando a mesma empresa, duas versões no data warehouse e no Data 360 e, no fim, um agente decidindo qual cliente é o verdadeiro. Isso é muito mais caro do que um erro de digitação numa descrição. Então não comece por “como validamos cada campo?” Comece por quais dados ruins criam o maior problema de negócio ou de arquitetura? e coloque ali os controles mais fortes.

Aberta ou travada?

A criação de contas é o exemplo clássico. Todo vendedor deve poder criar uma conta? Minha resposta: depende da governança em torno dos dados. Para a maioria das orgs pequenas e médias, a criação aberta serve. Um vendedor conhece um prospect, cria a conta, começa a trabalhar; é para isso que serve o CRM. Regras de duplicidade, informação obrigatória e stewardship cuidam da qualidade. Não acrescento um processo pesado de aprovação só porque governança soa 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 vendedor criam a mesma empresa, qual vence, qual identificador as integrações usam, qual registro guarda o histórico? A criação aberta deixa de ser uma questão de usabilidade e vira uma questão de dados mestres. Quando as contas são mestres num ERP ou sincronizadas com ele, trave a criação.

Mas travar completamente também falha. O vendedor conheceu um prospect que não está no ERP e quer abrir uma oportunidade, e o modelo de governança diz “nada de conta para você”. Então ele espera três dias pelo Financeiro, ou liga a oportunidade à conta errada, ou guarda o prospect num campo de observações ou numa planilha. Protegemos o modelo de dados e prejudicamos o negócio.

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

Eis o caminho do meio de que gosto. Deixe vendas criar a conta com um tipo de registro específico, um tipo prospect ou provisório, e controle a conversão dela para o tipo governado. Vendas registra a empresa e começa a vender. O registro diz com clareza: ainda não estabelecido no sistema com autoridade. Depois um processo controlado o converte: o Financeiro o aprova, ou uma integração o submete ao ERP, que o casa com um cliente existente ou cria um novo e devolve o identificador com autoridade. Agora o registro cruza uma fronteira, provisório → governado, o que é muito diferente de dois sistemas criando, cada um, o que acreditam ser o registro mestre.

O tipo de registro é o mecanismo que ensino. Seja o que for que você use, torne o estado visível nos dados: de onde o registro veio, se já cruzou a fronteira, quem pode alterá-lo 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 registro para cada fluxo

Coloque o fluxo inteiro numa só imagem e você vai ver por que isso funciona. Clientes e produtos entram vindos do ERP. Oportunidades e seus itens de linha saem e viram os pedidos do ERP. E as contas? Algumas entram, algumas saem. Então um padrão comum que já vi em várias implementações são dois tipos de registro em Conta, um para cada direção. Uma conta de Vendas (Sales) nasce no Salesforce: os vendedores a criam, editam, vendem para ela e, quando ela vira cliente, ela é enviada ao ERP. Uma conta ERP (já a chamei de Customer, ou simplesmente SAP) nasce no ERP e entra pela integração. Ninguém cria esse tipo de registro a não ser a integração, e os campos de dados mestres dele (razão social, endereços, condições de pagamento) são somente leitura para os usuários. O tipo de registro diz para que lado o registro flui, então a direção do gerenciamento de dados mestres está ali mesmo, no registro.

Click to enlarge

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

Isso 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 algum jeito a verificação de duplicidade não pegou. Agora você está mesclando, reatribuindo os filhos a outro pai e decidindo qual registro sobrevive (capítulo 6, módulo 3).

E não se prenda ao tipo de registro em si. Normalmente eu evito tipos de registro, a menos que haja um bom motivo para eles. Usei aqui porque, antes do Dynamic Forms, o tipo de registro escolhia o layout de página, e um layout mostrava os campos do ERP como somente leitura. Com o Dynamic Forms, regras de visibilidade podem mostrar e ocultar campos conforme o valor de um campo, um campo pode ser somente 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 tipos de registro de que você 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 somente leitura numa página é somente leitura naquela página: a API, uma carga de dados ou uma integração ainda podem gravar o campo. A aplicação de verdade é a segurança em nível de campo ou uma regra de validação; validação na interface não é validação de dados (capítulo 3, módulo 9). Os tipos de registro ainda merecem seu lugar quando os dois tipos de conta precisam de valores de lista de opções ou processos de negócio diferentes. O que importa mesmo é que algum campo diga claramente de onde o registro veio: a própria chave do ERP, um indicador de dados mestres ou uma lista de opções de origem. Então controle a possibilidade de edição a partir desse campo.

Click to enlarge

De provisório a governado: vendas começa a vender na hora; só o processo autoritativo torna o registro governado.

Proteja o registro governado

Depois que o cliente volta do ERP, o ID do ERP, a razão social, o identificador fiscal e os dados de cobrança são atributos governados. O vendedor deve alterá-los? Não, se o ERP é dono deles. É a política do módulo 1 precisando do seu ponto de aplicação: o ID do ERP somente leitura, a identidade legal controlada, enquanto o vendedor continua editando território, observações de relacionamento 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 você obtém no fim é um golden record que, na verdade, é híbrido. Os campos de dados mestres do ERP entram: razão social, endereços de cobrança e de entrega, condições de pagamento. Depois o Salesforce acrescenta campos próprios que nunca voltam: uma classificação de vendas, a data do último pedido, 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 precise que a razão social no ERP mude de Steve’s Plumbing para Steve’s Plumbing LLC. Nesses mesmos cinco minutos, alguém no ERP a muda para Steve’s Plumbing L.L.C. A mudança de quem vence? Esta é a mentalidade: se um campo tem o ERP como mestre, você não está alterando o campo, está pedindo para alterá-lo. Decida o que acontece quando o pedido colide: o ERP vence, o pedido é rejeitado se o valor mudou nesse meio-tempo, ou ele espera uma pessoa resolver. E decida se campos relacionados viajam juntos como uma só mudança ou um de cada vez. O capítulo 6 leva as colisões mais adiante (Loops e colisões).

Barre as duplicatas na porta

Duplicatas se acumulam. Pegue uma antes de ser criada e é um problema pequeno. Encontre-a dois anos depois, com oportunidades, casos, contatos, faturas, integrações e análises penduradas nas duas, e é um problema grande. O módulo 7 do capítulo 3 cobriu os mecanismos (regras de correspondência, regras de duplicidade, IDs externos únicos), então não vou ensiná-los de novo. A pergunta de governança é onde precisamos impedir a duplicação, e onde vamos tolerá-la e resolvê-la 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

Texto livre é maravilhoso para pessoas e terrível quando um sistema precisa interpretá-lo. Coloque Arizona, AZ, Ariz., região de Phoenix e Sudoeste num campo que determina a roteirização, e você 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 ele precisa ser. Nem todo campo de texto vira 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 controle mais forte.

Não deixe campos obrigatórios criarem dados falsos

Decidimos que um campo importa e o tornamos obrigatório. O usuário não sabe a resposta, o sistema não o deixa continuar, então ele digita N/A, Desconhecido, 999999 ou teste@teste.com. O campo está completo; os dados são lixo. Antes de exigir algo, pergunte se o usuário realmente sabe aquilo naquele momento. Se não, exija mais adiante no processo, deixe outro sistema fornecer, use o estado provisório, ou ofereça um Desconhecido explícito quando desconhecido for uma resposta legítima. Uma regra de validação consegue aplicar uma política. Não consegue fazer alguém saber o que não sabe.

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

As pessoas não são a única fonte de dados ruins; as integrações os produzem mais rápido. O manifesto de um Parceiro varejista chega com algumas centenas de linhas. Um punhado tem CEPs inválidos, algumas citam um centro de distribuição desconhecido, duas repetem a mesma referência de pedido. O que acontece? Rejeitar o arquivo inteiro? Aceitar as linhas boas e devolver as ruins? Carregar tudo e limpar depois? Colocar as exceções em quarentena? Quem é avisado, e como o parceiro fica sabendo do que falhou? Não há resposta universal, mas precisa haver uma. O capítulo 4 disse que toda seta precisa de um mecanismo. Acrescente: toda fronteira de dados precisa de uma decisão de qualidade: o que aceitamos, rejeitamos ou colocamos em quarentena, e quem é dono da exceção.

Click to enlarge

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

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é o padrão de hoje antes de movê-los? Provavelmente não, automaticamente. Para que eles servem: operação diária, referência, reclamações, relatórios, análise de tendências? Todos precisam estar no Salesforce, ou alguns podem ficar em outro lugar? O capítulo de migração vai fundo. O ponto de governança: o histórico não precisa automaticamente do mesmo padrão que os dados ativos. Se você vai tomar decisões com base nele, a qualidade importa. Se o está guardando como referência, outro padrão pode bastar. Saiba o propósito antes de gastar uma fortuna limpando o passado.

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

A governança nunca termina, então você precisa ver quando a qualidade escorrega: taxa de duplicatas subindo, mais registros em quarentena, mais rejeições de integração, valores de preenchimento se espalhando, mais pedidos de desvio, relatórios que não fecham mais. 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 um endereço utilizável, referências de pedido 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. Dados ruins viram, cada vez mais, ações ruins. Uma pessoa pode perceber que um telefone parece errado antes de ligar; um agente simplesmente usa o valor que recebe. Clientes duplicados, status desatualizados, valores obrigatórios falsos e identificadores errados viram direto a mensagem errada ou a atualização errada. Isso aumenta o valor da prevenção. Não elimina a necessidade de stewardship.

O que um arquiteto decide aqui

• Quais falhas de qualidade causam dano suficiente para justificar controles preventivos.
• Se os registros governados são criados livremente, só pelo sistema com autoridade, ou por um caminho de provisório para governado.
• De quais atributos o Salesforce é dono e quais ele só referencia.
• O que acontece com os dados de entrada que reprovam nas verificações (aceitar, rejeitar ou colocar em quarentena) e quem é dono da exceção.
• Quais sinais de qualidade são medidos, para que os stewards vejam o escorregão.

Você nunca vai impedir todo registro ruim. O trabalho não são dados perfeitos; é impedir que dados ruins evitáveis virem dados caros. Barre a duplicata antes que ela tenha dois anos de histórico. Proteja o identificador antes que dez integrações dependam do errado. Deixe vendas criar o prospect, mas não finja que ele é o cliente governado até que seja. E, quando algo ruim passar, garanta que alguém consiga vê-lo, assumi-lo e corrigi-lo.

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.