A PME quer um CRM, chama o fornecedor, e ouve alguma variação disto: "com o seu ERP não dá; é antigo demais, customizado demais, regional demais". A alternativa oferecida é trocar o ERP — parar a operação inteira, refazer fiscal, refazer estoque, retreinar todo mundo — para melhorar a rotina de seis vendedores.
O interessante não é a desproporção. É o diagnóstico: quem diz que a integração exige trocar o ERP está confessando como pretende integrar. E a maneira que ele escolheu é a que quebra.
O que realmente amarra o CRM ao ERP
Todo CRM integrado toca o banco do ERP em algum ponto. A pergunta que decide o resto é: quanto ele toca?
O caminho fácil é ler as tabelas reais. Alguém abre o banco, descobre que o cliente está em CADCLI, que a razão social é NOME1, que o status vem de uma flag SITUACAO com os valores A, I e X — e escreve as consultas do CRM em cima disso. Funciona na demonstração. Funciona por uns meses.
Aí vem o primeiro upgrade. O fornecedor renomeia uma coluna, quebra uma tabela em duas, muda o significado do X. E o CRM, que não fez nada de errado, para. A PME não pode mais atualizar o ERP sem quebrar o CRM, nem mexer no CRM sem chamar quem escreveu as consultas. Virou refém — e trocar o ERP depois disso ficou mais caro, não menos.
Essa é a superfície de acoplamento: quantos detalhes internos do ERP o CRM precisa conhecer para viver. Quanto maior ela é, mais o tempo cobra.
O contrato de views: uma superfície que a PME controla
O desenho alternativo tem nome na engenharia de software — anti-corruption layer — e uma consequência bem prática: entre o CRM e o ERP existe uma camada fina de views de leitura, e só ela é o que o CRM enxerga. Ele pede v_crm_quotes e recebe colunas com nome estável e significado combinado. Onde isso mora dentro do ERP é problema da view, não dele.
Duas coisas mudam de dono aí. A primeira é o conhecimento sujo: a bagunça toda — NOME1, o X do SITUACAO, a tabela que é join de outras três — fica dentro da DDL da view, escrita uma vez, na implantação. É o único lugar onde o esquema nativo do ERP aparece. A segunda é o controle: essa DDL vive no banco da PME, que pode lê-la, versioná-la, entregá-la ao DBA. Não é binário fechado de terceiro consultando a base dela — é contrato legível, feito para ser conferido.
E aqui a virada: com esse desenho, o ERP regional e customizado deixa de ser o obstáculo. Ele é justamente onde estão dez anos de histórico de compra que nenhum CRM genérico tem. O problema nunca foi o ERP ser esquisito. Foi alguém querer lê-lo por dentro.
O que quebra e o que apenas degrada
Contrato bom não é o que nunca é violado; é o que falha de forma previsível. A diferença entre quebrar e degradar decide se uma sexta-feira de upgrade vira crise ou vira bilhete.
Faltou coluna opcional? Some o recurso dela, e nada mais. Sem a unidade de medida do item, a tela mostra "un" e a vida segue. Sem a data de entrega prevista, o calendário de entregas some e o resto da agenda continua de pé. Sem o código do vendedor na view de propostas, o recorte por vendedor não se aplica ali; o painel não morre. O mesmo vale por fonte: se uma view der erro no meio da agenda, aquela fonte volta vazia e as outras continuam aparecendo.
O que quebra de verdade é ausência de coluna obrigatória — sem identificador de cliente, não há o que ler. Por isso o contrato separa as duas categorias, e existe um comando de validação que roda contra o banco do cliente e avisa, antes de qualquer usuário reclamar: esta view sumiu, aquela perdeu coluna obrigatória, esta tem colunas extras ignoradas.
Note o que isso significa para o upgrade. Ele não muda o CRM, mas pode exigir revisar a DDL das views. O trabalho não some; fica confinado a um arquivo de SQL, e você descobre em dois minutos de validador em vez de na reclamação do vendedor.
Trocar o ERP debaixo do CRM: o que é preciso de fato
O teste honesto da arquitetura: e se, daqui a três anos, a PME trocar o ERP mesmo?
Se a superfície é o contrato de views, a resposta é: escrever a DDL nova traduzindo o esquema do ERP novo, rodar o validador até passar, apontar a conexão. O código do CRM não muda nem uma linha — porque ele nunca soube o nome de uma tabela do ERP antigo para desaprender. A camada que protege da troca é a mesma que protege do upgrade: o mesmo mecanismo em duas escalas de tempo.
Mas fique claro onde está o custo: alguém tem que escrever essa DDL. Não é plug-and-play, e a condição não é só técnica — se o suporte do seu ERP proíbe criar objeto no banco, o problema mudou de sala.
Erros comuns nessa decisão
- Aceitar o diagnóstico do fornecedor. "Seu ERP não integra" quase sempre significa "eu só sei integrar do meu jeito". Pergunte qual é a superfície: ele lê tabela ou lê contrato?
- Deixar a permissão dentro da view. Parece esperto uma view que já filtra o que o usuário pode ver. Aí cada usuário precisa da sua, e o job noturno, que não é usuário nenhum, não tem nenhuma. A view expõe empresa e vendedor de forma neutra e deixa o filtro para a aplicação — assim uma view serve todo mundo.
- Achar que view esconde só nome feio. Ela esconde patologia também: um campo calculado que divide pela quantidade estoura quando a quantidade é zero. Dá para contornar no aplicativo, mas o conserto de verdade é na view, no cliente.
- Não versionar o contrato. Mudança incompatível gera versão nova documentada: muda a DDL da implantação, não o consumidor. Sem isso, o contrato vira acordo verbal — e volta a ser acoplamento.
Como isso se aplica no zCRM
Nada disso é abstrato: a PME quer usar o histórico comercial que já tem e ouve que, para isso, precisa trocar o sistema que roda a empresa.
No zCRM, o ERP é enxergado por dezessete views v_crm_* — clientes, notas, pedidos, propostas, recebíveis, produtos, estoque, potencial, contatos, endereços e usuários, entre outras. O código não referencia nenhuma tabela nativa do ERP. Cada assunto tem uma porta em App\Services\Erp\Contracts, com implementação Firebird e uma implementação nula: o CRM consome a porta, não o banco — o que abre espaço para implementações alternativas sem tocá-lo. O comando php artisan crm:validate-erp-views --connection=erp_firebird confere existência, colunas e tipos das dezessete, falha quando falta coluna obrigatória e avisa sobre colunas extras ignoradas. E a compatibilidade convive com o legado: o adaptador prefere v_crm_entity, com colunas em inglês, e mantém o desvio para a v_crm_entidade antiga enquanto a migração de uma implantação não termina.
A decisão que muda para o dono: ele para de escolher entre "ter CRM" e "manter o ERP que funciona", e passa a fazer a pergunta certa na mesa de negociação — qual é a superfície que este software vai tocar no meu banco, e quem a controla?
Os limites, explícitos. Não há escrita no ERP: proposta, pedido e nota continuam nascendo lá; o zCRM vincula proposta e pedido à oportunidade, não os gera — quem quer montar proposta ou CPQ dentro do CRM não é atendido hoje. Não é plug-and-play: alguém escreve a DDL traduzindo o esquema do seu ERP, e é aí que está o custo; não existe conector pronto por marca nem catálogo de integrações. E "funciona com qualquer ERP" só vale qualificado: qualquer ERP cujo banco permita criar as views do contrato e cujo fornecedor aceite. Fora disso, é conversa antes de projeto.
Próxima leitura
- ERP como fonte oficial: por que não duplicar cadastro de cliente no CRM.
- Checklist do primeiro dia: quais dados do ERP carregar no CRM.
- Qualidade dos dados do ERP: por que CRM bom depende de cadastro confiável.