Checklist do primeiro dia: quais dados do ERP carregar no CRM

O pior resultado de uma implantação não é a tela vazia. É a tela cheia e errada.

Cena típica: liga-se o CRM na sexta, o painel abre bonito na segunda, e o gerente encontra um cliente grande com R$ 180 mil de faturamento onde ele sabe que foram R$ 320 mil. Ninguém errou uma conta. O cadastro do ERP tem a mesma empresa em dois CNPJs — um com zero à esquerda, outro sem — e o histórico se partiu em duas. Nenhum sistema acusou erro: os dois números estão certos, e somados dariam o certo.

Por isso o checklist do primeiro dia não é uma lista de views para ligar. É uma ordem de dependência, e o primeiro item não é dado — é diagnóstico. Carregar na ordem errada não produz mensagem de falha: produz painel que mente com confiança. E credibilidade queimada na primeira semana não volta com correção na terceira.

Item zero: medir o que está quebrado antes que qualquer número apareça

Todo ERP com dez anos de rodagem tem sujeira de cadastro. Não é acusação, é rotina: o vendedor saiu e a carteira ficou órfã, o pedido urgente entrou sem data de entrega, alguém digitou o CNPJ sem os zeros. Enquanto o dado ficou no ERP, ninguém sentiu. Quando vira painel comercial, cada buraco tem efeito exato numa tela específica:

• Cliente sem vendedor responsável. A conta entra sem dono e ninguém a enxerga no escopo de carteira: existe no banco, não aparece para ninguém. É a mais grave da lista — o cliente some sem deixar rastro na tela.
• CNPJ duplicado. A mesma empresa vira duas contas. O faturamento se parte, o RFM classifica os dois pedaços como clientes médios, e o cliente grande sai da lista de prioridade.
• Item em aberto sem data de entrega. A prioridade "entrega vencida" nunca dispara. O sinal não fica errado: fica mudo, que é pior — ninguém procura o que nunca apareceu.
• Nota sem vendedor. O relatório de performance sai com buraco, e o vendedor descobre na reunião de comissão.
• CNPJ inválido, sem contato, e-mail inválido, produto sem descrição ou sem unidade, cliente sem segmento, sem UF, sem cidade. Cada um derruba um filtro, um agrupamento ou uma ação que o time ia usar.

Isso precisa ser contado antes, não descoberto depois pelo usuário. A diferença entre "o número está errado" e "o dado do ERP está assim, olha a amostra" é a diferença entre um projeto que sobrevive e um que morre de desconfiança.

Contrato e conteúdo são duas verificações diferentes

Aqui mora uma confusão que custa caro. Verificar se a view existe não é verificar se o dado presta.

O contrato pergunta: a view v_crm_entity existe? Tem a coluna salesperson_code? O tipo bate? Falhou aqui, nada funciona — erro duro, aparece na hora.

O conteúdo pergunta: a coluna existe, mas está preenchida em quantos por cento das contas? Falhou aqui, tudo "funciona" e a tela mente — erro silencioso.

Implantação que só roda o validador de schema entrega um sistema tecnicamente correto e comercialmente inútil.

A ordem de dependência é real, não estética

A sequência abaixo não é organizada por importância, e sim por dependência: cada item precisa do anterior para significar alguma coisa.

1. v_crm_entity primeiro. Sem ela não há conta — e sem conta, não há a que pendurar nota, pedido ou proposta.
2. Validar o contrato das views. Existência, colunas, tipos. Evita descobrir na semana três que uma coluna vem como texto onde o CRM espera data.
3. Sincronizar as contas. A carteira nasce, com dono e empresa. É quando "cliente sem vendedor" vira conta invisível.
4. Notas e itens de nota. O histórico de faturamento.
5. Calcular as métricas da conta. RFM, segmento, risco — depois das notas, porque recência e frequência derivam do faturamento. Rodar antes produz uma carteira inteira classificada como inativa.
6. Recebíveis, pedidos com itens e propostas. Os sinais que alimentam Prioridades: título vencido, entrega vencida, proposta vencida em aberto.

Inverta 4 e 5 e nada quebra visivelmente. Só sai errado.

Ensaie a carga antes de valer

Rode em seco, com limite. Sincronizar cem contas sem gravar mostra o que ia acontecer, com tempo de olhar — e é barato descobrir ali que a normalização por empresa está colapsando cadastro que não devia.

Performance é parte da ordem, não ajuste posterior. A view de pedidos precisa filtrar só a carteira aberta na base, antes de agregar os itens: no ERP de referência, a diferença entre alguns segundos e milissegundos por consulta. Painel que demora sete segundos para abrir não é lento — é painel que ninguém usa.

Os cenários que reprovam a carga

Estes não são teste de programador: são critério de aceite comercial, e cada um tem a frase que o usuário vai dizer quando falhar.

• "Não estou vendo a nota X." Cliente trocou de vendedor; a nota antiga tem o vendedor anterior. O acesso chaveia pelo vendedor atual da conta, nunca pelo da nota.
• "O total dá 100 e as notas somam 90." Resumo e detalhe precisam do mesmo escopo: empresa, visibilidade, status e período.
• Soma dobrada. Somar o total do cabeçalho na view de itens repete o valor a cada linha.
• Visibilidade composta. Quem vê a empresa A e o vendedor X enxerga a interseção dos dois eixos, não a união.
• Cadastro colapsado por empresa. Onde o ERP duplica o cliente por empresa, as transações aparecem sob uma conta só, sem perder faturamento no caminho.

Erros comuns neste checklist

• Começar pelo que impressiona. Dashboard bonito antes de carteira com dono é demonstração, não implantação.
• Tratar o diagnóstico como etapa opcional. É ele que decide se os outros itens valem alguma coisa.
• Vender prazo antes de conferir se as views existem. Onde não existem, a DDL precisa ser escrita e validada — antes do item 1, não dentro dele.

Como isso se aplica no zCRM

O estrago tem hora marcada: painel que abre com número errado no primeiro dia e queima a confiança do time antes de o CRM provar valor.

O ErpDataHealthService roda 18 checagens de qualidade do dado — não de schema — sobre o cadastro e o movimento do ERP. Para cada uma devolve a contagem, uma amostra concreta e o percentual de registros ok sobre a população, com severidade: cliente sem vendedor responsável, sem CNPJ, CNPJ inválido, CNPJ sem zeros à esquerda, duplicado, cliente sem contato, e-mail inválido, item em aberto sem data de entrega, produto sem descrição, produto sem unidade, item × nota divergente, vendedor órfão, inativo com pedido em aberto, nota sem vendedor, proposta vencida em aberto, sem segmento, sem UF, sem cidade. Cada checagem é isolada: uma view ausente degrada só aquela linha — o relatório não cai. Ao lado dele, o ErpViewSchemaValidator cobre as 17 views do contrato: existência, colunas e tipos. Ferramentas diferentes, porque são perguntas diferentes.

A decisão que muda: em vez de ligar tudo e torcer, a implantação passa a ser negociada com número na mesa. "Um terço das contas está sem vendedor responsável" vira tarefa com dono e prazo — e antecipa quais telas nascem capengas se ninguém mexer.

O limite, explícito: o zCRM não conserta o dado. Ele conta e mostra a amostra; a correção é feita por gente, no ERP — o CRM não escreve lá. Não há deduplicação automática de CNPJ, preenchimento automático de vendedor responsável nem enriquecimento de cadastro. E o diagnóstico não é auditoria de banco: são 18 checagens conhecidas sobre o contrato de views, que não cobrem customizações do ERP. É diagnóstico de implantação — não certificação de qualidade nem selo de saúde do seu ERP.

Próxima leitura

• Qualidade dos dados do ERP: por que CRM bom depende de cadastro confiável.
• CRM integrado ao ERP: como carregar histórico no primeiro dia.
• O que significa valor no primeiro dia em um CRM.