A pergunta chega quase sempre na mesma forma, e é justa: "eu já tenho ERP, mandei fazer uns dashboards ano passado e paguei caro por isso. Por que eu precisaria de mais um sistema?"
Quem pergunta isso não está sendo resistente. Está apontando um fato: os três olham para os mesmos dados. O mesmo pedido, a mesma nota fiscal, o mesmo título vencido aparecem no ERP, no painel do BI e no CRM. Se a matéria-prima é idêntica, a desconfiança de redundância faz sentido.
Só que a matéria-prima não é o que distingue esses sistemas. O que distingue é quem age depois que a tela fecha.
O teste do destinatário
Uma pergunta classifica qualquer software comercial melhor do que qualquer tabela de definições: depois desta tela, quem faz o quê?
ERP. Você emite a nota. Depois desta tela, a empresa cumpre uma obrigação: o produto sai, o imposto é apurado, o título entra no contas a receber. O destinatário é a organização, e a ação é obrigatória — ninguém "decide" emitir a nota do pedido faturado. O ERP existe para que o fato aconteça de forma correta e auditável. É a fonte oficial: cliente, produto, proposta, pedido, nota, financeiro.
BI. Você abre o painel de faturamento por segmento. Depois desta tela, o gestor forma uma opinião: descobre que metalurgia caiu 18% no trimestre, franze a testa, pensa em política de preço. A saída é entendimento — legítima e necessária, mas o destinatário é uma cabeça, não uma agenda. Um gráfico não tem dono nem prazo.
CRM. Você abre a fila do dia. Depois desta tela, o Marcelo liga para a Marcondes Autopeças, porque ela parou de comprar há 74 dias e faturava R$ 38 mil no trimestre anterior. Nome de cliente, nome de vendedor, motivo e valor em jogo. A saída é uma pessoa fazendo algo.
Daí o critério de compra: se a saída da tela não tem nome de cliente e dono, você comprou BI achando que era CRM. O sintoma é sempre o mesmo — o time elogia os painéis nos primeiros dois meses e ninguém abre no terceiro. Não é falta de treinamento. É que gráfico agregado não pede nada de ninguém.
Por que os três coexistem sem serem redundantes
A redundância seria real se as três camadas competissem pela mesma resposta. Elas não competem: o ERP responde o que a empresa deve registrar — a única resposta que precisa estar certa por obrigação legal. O BI responde para onde a coisa está indo. O CRM responde o que eu faço hoje, com quem e por quê — a única das três em que a resposta errada custa uma venda amanhã.
Volte à queda de 18% em metalurgia. É uma leitura de BI: verdadeira, útil e inacionável do jeito que está, porque você não liga para "metalurgia". Alguém precisa transformar aquele bloco em uma lista de doze contas, ordenada por quanto cada uma vale e há quanto tempo sumiu, distribuída entre três vendedores, com um motivo escrito. Essa transformação — do agregado para o nominal — é o trabalho do CRM. Sem ela, o painel vira informação de apoio: o gestor sabe, e nada acontece.
Onde a fronteira realmente dói: cadastro e escrita
Na PME, a discussão de fronteira quase nunca é filosófica. Ela aparece quando alguém pergunta se o cliente vai ser cadastrado em dois lugares.
A resposta boa é uma regra de arquitetura, não um acordo de boa vontade: cada dado tem um dono oficial e só um. Entidades, produtos, propostas, pedidos, notas e financeiro pertencem ao ERP. Relacionamento — contatos complementares, atividades, oportunidades, funil, memória do que foi conversado — pertence ao CRM, porque nunca esteve no ERP e nunca vai estar. O ERP não tem onde guardar "esta gráfica só aprova compra depois da reunião de diretoria da primeira segunda do mês".
Sem essa regra explícita, o CRM ganha um cadastro de cliente "só para facilitar" e, seis meses depois, existem duas verdades sobre o mesmo CNPJ com endereços diferentes. A empresa não tem dois sistemas — tem dois sistemas brigando.
Erros comuns na hora de decidir
- Achar que dashboard sobre o ERP resolve o comercial. Resolve a pergunta do gestor, não produz fila para o vendedor. São problemas diferentes, e a confusão custa a compra errada.
- Tentar fazer o CRM substituir o ERP. A empresa mantém o ERP mesmo assim (nota, fiscal, estoque) e passa a pagar duas vezes pelo mesmo cadastro.
- Comprar CRM genérico e começar com base vazia. Quem tem dez anos de histórico no ERP e começa do zero joga fora o único ativo de vantagem que tinha.
- Achar que o CRM dispensa BI corporativo. Se a necessidade é modelagem livre e cruzamento com fontes de fora do comercial, isso é BI de verdade e continua sendo BI de verdade.
- Julgar pela tela da demonstração. Toda tela é bonita em demonstração. Pergunte quem age depois dela.
Como isso se aplica no zCRM
O prejuízo aqui tem a forma de uma compra errada: a empresa gasta com painel quando o que faltava era fila de trabalho, ou tenta trocar o ERP quando o que faltava era relacionamento.
O zCRM lê o ERP por uma camada de dados — views canônicas como v_crm_entity, v_crm_invoices, v_crm_orders, v_crm_quotes e v_crm_receivables — e não escreve nele. O contrato dessas views é verificado por um comando próprio de validação (crm:validate-erp-views, cobrindo 17 views), porque integração que quebra em silêncio é pior do que integração que não existe.
E sim: o zCRM tem uma camada de BI, e ela é assumida. Há painéis de Pedidos (carteira a faturar), Vendas (demanda por período), Faturamento (receita realizada), Propostas (win/loss e conversão por vendedor e segmento), Potencial × realizado e Financeiro (aging e maiores devedores). Não fingimos que gráfico é supérfluo.
A diferença aparece na saída. O mesmo faturamento que vira barra no painel vira, nas Prioridades do dia, uma linha nominal: cliente, motivo ("sem comprar há N dias, faturava X no trimestre anterior"), sugestão de ação e valor em jogo — com rótulo de ação e rota de destino, para o clique levar a algum lugar. E os painéis, mesmo agregados, têm porta de saída: todo cliente exibido num top tem menu contextual que abre a conta 360. O gráfico não é um beco sem saída.
O gestor troca a pergunta de fechamento: em vez de "por que caiu?", ele passa a perguntar "quem eu chamo por causa disso?" — e a resposta é uma lista com donos.
Os limites, explícitos, porque este é o artigo em que mais se espera a promessa fácil:
- O zCRM não substitui o ERP nem escreve nele. É leitura. O ERP continua sendo a fonte oficial, e quem prometer o contrário está vendendo um problema.
- O zCRM não substitui uma ferramenta de BI corporativa. Os painéis são fixos e comerciais. Modelagem dimensional livre, indicador self-service e fontes externas não estão no escopo.
- Não existe conector pronto para qualquer ERP. A integração se dá pela camada de views canônicas, que precisa existir ou ser criada na base do cliente. Isso é um projeto, curto, mas é um projeto.
- Não é tempo real absoluto. As métricas de RFM vêm de um trabalho diário (02:30). Os painéis leem o ERP na hora, e essa leitura tem custo real — da ordem de 0,6s a 1,2s por ano de dados consultado.
Próxima leitura
- Integrar CRM ao ERP sem trocar o ERP: o que a PME precisa saber.
- ERP como fonte oficial: por que não duplicar cadastro de cliente no CRM.
- Dashboard comercial: por que gráfico bonito não basta.