Leonardo Peron5 min de leitura
O pedido chega quase sempre no segundo ano de operação, com a mesma frase: queremos que o CRM converse com o ERP. Os dois têm cadastro de cliente, os dois têm alguma noção de produto, e um deles tem pedido. O trabalho não é ligar os dois — é decidir onde termina cada um.
Integração sem essa fronteira desenhada não fica pela metade: fica duplicada. O mesmo dado passa a existir dos dois lados com duas regras, e a operação ganha uma terceira tarefa, que é conferir se bateram.
A fronteira: proposta no CRM, pedido no ERP
A separação que se sustenta é entre intenção e compromisso.
A proposta é intenção: é editada, tem versão, é enviada, pode ser recusada e desaparecer sem consequência nenhuma. Pertence ao processo comercial, e o lugar dela é o CRM.
O pedido é compromisso: a partir dele há reserva de estoque, obrigação de entrega, apuração fiscal e um documento que sai para fora. Pertence ao ERP, onde moram as regras capazes de recusá-lo.
O evento que atravessa a fronteira é o aceite, e ele é um só, numa direção só. O erro mais comum é mandar cada rascunho de proposta para o ERP "para já ir adiantando": o ERP passa a ter registros que não são pedidos, alguém precisa limpá-los, e a contagem de pedidos do mês para de significar o que significava.
Quem é o dono do cadastro do cliente
É a decisão que os dois lados acham que já está tomada, cada um do seu jeito. O critério geral está em qual sistema é o dono do cadastro; o que é específico do par CRM–ERP é o momento.
O lead nasce no CRM sem documento, às vezes sem nome completo, quase sempre sem endereço fiscal. O ERP não aceita um registro assim, e nem deveria: ele valida para poder emitir. São duas entidades em dois momentos — um interessado e um cliente — e a integração acontece na promoção de um para o outro, quando o documento aparece.
Tratar as duas como o mesmo registro desde o primeiro contato enche o ERP de cadastros incompletos que são clientes do ponto de vista fiscal — e aí ninguém consegue mais responder quantos clientes a empresa tem.
Depois da promoção, a divisão continua campo a campo, pelo mesmo critério. O que os dois lados editam precisa de regra declarada, e "sincroniza nos dois sentidos" não é uma.
Preço e disponibilidade moram no ERP e são usados no CRM
O vendedor precisa dos dois para montar a proposta, e os dois são decididos do outro lado. Há dois desenhos, e o arranjo prático usa ambos.
Copiar a tabela periodicamente é barato, funciona mesmo com o ERP lento e envelhece: serve para montar proposta e simular. Consultar na hora é frágil — depende de o ERP estar de pé e rápido, com o cliente esperando na frente do vendedor.
A regra que resolve é consultar no único momento em que estar errado custa dinheiro: o aceite. Até ali a cópia serve; na hora de virar pedido, confirma-se preço e disponibilidade contra a fonte, e a divergência aparece antes de o cliente ser informado.
E a proposta guarda o preço que usou. Reprocessar uma proposta antiga com a tabela nova não é atualizar: é criar outra proposta com o mesmo número, e a discussão sobre o que foi combinado deixa de ter resposta.
O caminho de volta, que quase nunca é construído
Essa integração costuma ser desenhada em uma direção: o pedido vai, e acabou. Só que metade das perguntas do comercial se responde com o que acontece depois.
O faturamento precisa voltar para o funil por três motivos concretos. Porque a comissão pode ser sobre o faturado ou sobre o recebido, e a diferença é decidida por um dado que só existe do lado do ERP. Porque o vendedor é quem o cliente liga para perguntar onde está o pedido, e mandá-lo abrir outro sistema é o mesmo que não integrar. E porque negócio ganho sem faturamento correspondente é promessa, não resultado.
Junto com o faturamento voltam duas coisas menos lembradas. O cancelamento, que precisa estornar ou reabrir o que o funil deu como ganho. E a recusa: o ERP pode rejeitar o que o CRM aceitou, por crédito bloqueado, cadastro reprovado ou produto sem tributação para aquele estado. Essa rejeição precisa voltar ao negócio com motivo legível em vez de morrer num log, que é o desenho de o que acontece com o que falhou.
O que a parte técnica exige
Duas coisas, e as duas conhecidas. O mesmo aceite não pode virar dois pedidos quando a chamada é repetida por retentativa ou por alguém clicando duas vezes — é a chave que impede o pedido gêmeo. E o formato dos dois lados não coincide: unidade de medida, código de produto, forma de pagamento e situação são listas diferentes com nomes parecidos, o que é trabalho de de-para.
O resto vale para qualquer projeto assim e está em o que é integração de ERP e em integração de sistemas.
O rastreamento para fazer hoje
Pegue um negócio fechado no mês passado e siga-o pelos dois sistemas, anotando quatro coisas: onde o cadastro do cliente foi criado e por quem; qual preço a proposta usou e se ele ainda pode ser recuperado; onde está a nota; e se o CRM sabe que ela foi emitida.
O primeiro "não sei" que aparecer é a fronteira que ainda não foi decidida. E se o CRM não souber do faturamento, você encontrou o caminho de volta que falta — costuma ser mais barato que a ida, porque não exige decidir nada: só trazer o que já aconteceu.