Integrar CRM, ERP, ecommerce, atendimento ao cliente e ferramentas internas não resolve, por si só, os problemas de dados. Pode até amplificá-los quando cada aplicação mantém uma versão diferente de um cliente, preço ou pedido. A pergunta decisiva não é quais sistemas estão ligados, mas qual sistema tem autoridade sobre cada dado e em que condições.
Uma fonte de verdade não precisa ser uma única plataforma para toda a empresa. Trata-se de uma decisão por entidade e atributo: o ERP pode governar o stock e as faturas; o ecommerce, o carrinho e o estado de pagamento visível para o comprador; o CRM, a atividade comercial; e a ferramenta de suporte, os casos de atendimento. O objetivo é que todas as pessoas e processos saibam onde criar, editar, consultar e resolver discrepâncias.
A fonte de verdade não é apenas o local onde o dado está armazenado
Um sistema pode conter uma cópia de um dado sem ser a sua fonte de verdade. Por exemplo, o CRM pode mostrar o saldo de um cliente proveniente do ERP. Se um comercial alterar esse saldo no CRM, terá modificado uma réplica, não necessariamente o dado válido para as finanças.
Para atribuir autoridade, convém separar quatro responsabilidades frequentemente confundidas:
- Fonte de criação: o sistema que gera pela primeira vez o registo e o seu identificador de negócio.
- Fonte de atualização: o sistema autorizado a alterar um atributo específico.
- Fonte de consulta: a interface através da qual utilizadores ou serviços precisam de ler o valor, mesmo que seja uma cópia sincronizada.
- Responsável operacional: a equipa que define regras, qualidade, permissões e decisões perante exceções.
Esta separação evita regras simplistas como “o CRM é o mestre dos clientes”. Um cliente não é um bloco indivisível: nome legal, morada de entrega, limite de crédito, consentimento comercial, proprietário comercial e preferências de contacto podem ter responsáveis diferentes. A autoridade deve ser definida ao nível do atributo quando o processo assim o exigir.
Também é necessário distinguir a verdade operacional da verdade histórica. O preço atual de um produto pode estar no ERP ou numa plataforma de catálogo, mas o preço aplicado a um pedido já confirmado deve ser preservado como uma fotografia do pedido. Recalculá-lo com base na tabela de preços em vigor destrói a rastreabilidade e pode alterar relatórios ou reclamações.
Crie o inventário antes de desenhar sincronizações
Antes de escolher conectores, webhooks ou integrações bidirecionais, faça um inventário dos dados que atravessam os sistemas. Não comece pelos ecrãs: comece pelas entidades, pelos seus atributos, pelos processos que os alteram e pelos efeitos de cada alteração.
Uma matriz de autoridade simples deve incluir, no mínimo:
- Entidade e atributo, como produto/SKU, produto/stock disponível ou cliente/email.
- Sistema de criação, sistema de atualização e sistemas de consulta.
- O evento que provoca a alteração: criação, pagamento confirmado, devolução, ajuste de inventário ou encerramento de caso.
- Identificador interno e, quando aplicável, identificadores externos.
- Direção da sincronização, frequência e mecanismo: evento, processo agendado ou consulta a pedido.
- Regra de conflito, responsável pela revisão e registo de auditoria.
Em seguida, classifique cada campo pela sua natureza. Os dados de referência, como um catálogo de produtos, costumam exigir controlo editorial. Os dados transacionais, como pedidos e faturas, devem ser imutáveis ou alteráveis através de eventos claramente definidos, como um cancelamento ou uma nota de crédito. Os dados derivados, como o valor de vida estimado de um cliente, não devem substituir dados operacionais: precisam de fórmula, origem e data de cálculo.
Perguntas que obrigam a uma decisão útil
- Que equipa responde se o dado estiver incorreto e causar um incidente?
- Que processo precisa da alteração para que ela seja válida: comercial, logístico, fiscal ou de atendimento?
- Qual é a consequência de aceitar um valor desatualizado durante alguns minutos ou horas?
- É possível reconstruir o valor a partir de eventos ou deve ser conservado como estado?
- Que utilizador tem contexto e permissões para o corrigir sem criar um risco financeiro ou de conformidade?
Se não existir uma resposta explícita, não existe autoridade definida; há apenas um hábito de utilização que falhará quando o volume aumentar ou outra aplicação for adicionada.
Atribua autoridade por tipo de dado e processo de negócio
Existem padrões recorrentes, mas não regras universais. A decisão certa depende do sistema que executa o processo e assume as suas consequências.
- Clientes: o CRM costuma governar oportunidades, proprietário comercial e atividade de vendas. O ERP pode ser a autoridade para dados fiscais, condições de pagamento e limite de crédito. O ecommerce pode recolher moradas e preferências associadas a uma compra, que devem ser validadas antes de substituírem dados fiscais.
- Produtos: uma ferramenta de catálogo, o ERP ou um sistema interno podem criar SKU e atributos de produto. O ecommerce costuma enriquecer descrições comerciais, imagens e visibilidade por canal. Defina os campos de cada domínio para evitar que uma importação apague conteúdo editorial.
- Preços: a tabela de preços em vigor deve ter uma fonte autorizada. As promoções podem ter um responsável distinto se o respetivo motor aplicar regras específicas. O montante de um pedido confirmado não deve mudar quando a tabela de preços é alterada.
- Pedidos: o ecommerce pode criar o pedido e registar a intenção de compra; o ERP pode ser a autoridade para preparação, expedição, faturação e devoluções. Utilize estados com significado preciso, em vez de um único campo ambíguo como “concluído”.
- Stock: o sistema que regista receções, reservas, ajustes e expedições deve governar o stock vendável. Publicar uma cópia no ecommerce é habitual, mas permitir que este ajuste o inventário sem uma regra controlada provoca vendas acima do stock e reconciliações manuais.
- Consentimentos: a autoridade deve ser o sistema que regista a prova necessária: canal, finalidade, data, origem e retirada. Copiar um simples valor booleano sem contexto reduz a capacidade de demonstrar o que aconteceu.
- Casos de atendimento: a ferramenta de suporte pode governar o histórico do caso, enquanto uma devolução aprovada ou um reembolso deve iniciar um processo no sistema financeiro ou operacional adequado.
Num cenário hipotético, o ecommerce cria o pedido e emite um evento de pagamento confirmado. O ERP cria a ordem operacional e atualiza os seus estados logísticos. O CRM recebe um resumo da compra para segmentação, mas não pode editar o pedido. O atendimento ao cliente consulta ambos os sistemas e abre um pedido de devolução; o ERP confirma o movimento e devolve o resultado. Esta matriz reduz a tentação de permitir que todos os sistemas escrevam em todos.
Escolha um padrão de integração que limite conflitos
A sincronização unidirecional é a opção predefinida quando há uma autoridade clara: o sistema mestre publica e os consumidores recebem. É mais simples de depurar, protege a origem e reduz ciclos de atualização.
A sincronização bidirecional só é razoável quando se verificam três condições: cada sistema possui atributos distintos, as regras de edição são explícitas e existem mecanismos de conflito e rastreabilidade. Não é uma solução para “manter tudo igual”; essa promessa costuma esconder decisões por resolver.
- Eventos: adequados para alterações relevantes, como pedido criado, pagamento confirmado, stock ajustado ou fatura emitida. Devem incluir identificador, tipo de evento, data, versão e origem.
- Processos agendados: úteis para reconciliar alterações perdidas, cargas históricas ou informação que não exige imediatismo.
- Consulta a pedido: apropriada quando o consumidor necessita do valor atual e a latência é aceitável. Evita cópias, mas cria dependência da disponibilidade e do desempenho.
- Réplica de leitura: necessária para análise, pesquisa ou velocidade da interface. Deve ser tratada como uma projeção, não como um local de edição.
Desenhe os consumidores para que os eventos sejam idempotentes: processar a mesma mensagem duas vezes não deve duplicar um pedido nem aplicar dois ajustes. Guarde uma chave de evento ou uma versão por entidade. Se chegar uma atualização antiga, o consumidor deve detetá-la em vez de substituir silenciosamente um valor mais recente.
Defina conflitos, identificadores e histórico antes de serem necessários
Uma regra segundo a qual “vence a última atualização” parece objetiva, mas é insegura se os relógios não estiverem sincronizados, um sistema repetir mensagens ou uma importação em massa tiver uma data enganadora. Use-a apenas para atributos de baixo risco e quando a marca temporal representar realmente o momento de negócio.
Para dados críticos, prefira prioridades por domínio e transições de estado válidas. Por exemplo, um pedido pago não deve voltar a “pendente” porque uma sincronização atrasada enviou um estado anterior. Uma devolução pode exigir revisão humana se o pedido de suporte contradisser o estado logístico do ERP.
Cada entidade partilhada precisa de uma estratégia de identificação:
- Um identificador estável no sistema de origem e referências externas guardadas sem reutilização.
- Regras de correspondência para migrações e criações manuais, sobretudo para clientes e contactos.
- Proteção contra duplicados: o email pode ajudar, mas nem sempre identifica de forma única uma pessoa ou empresa.
- Histórico de alterações com valor anterior, valor novo, origem, interveniente ou processo e momento da alteração.
Evite substituir registos durante importações. Uma operação de atualização deve saber qual a versão que altera e que campos tem autorização para modificar. Quando a incerteza for elevada, encaminhe o caso para uma fila de revisão em vez de fundir automaticamente dois clientes ou substituir uma morada.
Sinais de alerta e checklist para aprovar uma integração
Há sintomas claros de uma arquitetura sem fonte de verdade: equipas que corrigem o mesmo dado em várias ferramentas, relatórios com totais incompatíveis, integrações que “sincronizam tudo”, campos sem descrição de origem ou incidentes resolvidos com exportações e folhas de cálculo. É também um alerta quando ninguém consegue explicar por que motivo um valor mudou ou o que acontecerá ao editá-lo.
Antes de aprovar uma nova integração, valide este checklist:
- Cada atributo transferido tem uma fonte de criação, atualização e consulta documentada?
- Está definido que sistema pode escrever e quais apenas podem ler?
- Existe um identificador estável e uma regra para criações duplicadas?
- A direção da sincronização responde a uma necessidade concreta?
- Os eventos incluem versão, origem e capacidade de repetição segura?
- Os estados e as transições inválidas estão definidos?
- Existe uma regra de conflito e um responsável pelas exceções?
- É conservado histórico suficiente para investigar alterações e reconciliar falhas?
- Foram testados atrasos, duplicados, indisponibilidades temporárias e alterações fora de ordem?
A melhor integração não é a que replica mais dados, mas a que preserva a autoridade do processo. Comece por uma matriz pequena sobre as entidades que provocam maior fricção, transforme-a numa decisão operacional partilhada e utilize-a como requisito para qualquer novo sistema. Assim, as integrações deixam de ser canais opacos e passam a integrar, de forma controlada, a arquitetura de negócio.