Leonardo Peron5 min de leitura
O endereço do cliente foi corrigido pelo vendedor no CRM na terça. Na quarta ele estava errado de novo, com o valor antigo. Ninguém desfez nada: o financeiro tinha editado o mesmo cadastro no ERP, e a sincronização da madrugada levou uma versão por cima da outra. Qual delas depende de quem escreveu por último, segundo o relógio de qual dos dois sistemas.
O chamado que chega é "o endereço voltou sozinho". O defeito é anterior ao código: ninguém decidiu quem é o dono daquele campo.
O que "dono" quer dizer
O dono de um dado é o sistema onde aquele valor é decidido. Todos os outros têm cópia, e cópia se atualiza, não se edita.
A consequência prática é desconfortável. Se o CRM é o dono do telefone, a tela do ERP precisa ser somente leitura — ou, no mínimo, avisar que a edição ali será desfeita. Campo editável cuja edição vai ser descartada mente para quem opera, e a pessoa descobre isso fazendo o mesmo trabalho duas vezes.
O dono é por entidade, não por sistema
A discussão costuma acontecer no nível errado: "o ERP é o sistema mestre". Não existe sistema mestre de tudo, e tratar como se existisse é o que produz o sintoma acima.
Para um mesmo cliente, é comum e correto que os donos sejam diferentes. O documento, a razão social e a condição de pagamento nascem e são validados no ERP, que é onde mora a regra fiscal e de onde sai a nota. O contato comercial, o dono da conta e o estágio da negociação vivem no CRM, que é onde eles existem. O endereço de entrega que o comprador digitou no checkout é dele, não da empresa: quem manda é a loja.
Dentro da mesma entidade a divisão continua. O preço de tabela é do ERP; o preço promocional que o canal aplica é do canal. Isso não é exceção — é o caso normal, e é por isso que a decisão precisa descer ao nível do campo.
Três perguntas que decidem quase todos os casos
Onde o dado nasce? Não onde ele é digitado com mais frequência, mas onde aparece pela primeira vez no fluxo real de trabalho.
Quem responde quando ele está errado? A área que recebe a ligação do cliente, a devolução ou a multa. Responsabilidade e propriedade andam juntas; se elas se separam, quem tem o problema não tem a caneta.
Onde mora a regra que valida? O sistema capaz de recusar um valor inválido impede a entrada do dado ruim em vez de propagá-lo.
Quando as três respostas apontam para o mesmo sistema, a decisão está tomada. Quando divergem, a segunda costuma valer mais que as outras duas.
O campo que os dois precisam editar
Existe, e fingir que não existe é o que trava a conversa. O vendedor atualiza o telefone durante a ligação; o cliente atualiza o mesmo telefone no portal.
Há três saídas, em ordem de custo.
Separar o campo. Dois campos com dois donos — o telefone que o comercial mantém e o que o cliente informou — e uma regra explícita de qual serve para quê. É feio no formulário e é honesto: eram dois dados o tempo todo.
Dono com sugestão. O sistema que não é dono grava uma proposta de alteração, não o valor. No sistema dono aparece uma pendência para alguém aceitar. Custa tela e custa processo, e é o único desenho que não perde informação.
Último a escrever vence, com histórico. O mais barato. Aceitável quando o campo tolera erro e quando dá para responder depois quem mudou, quando e a partir de qual sistema.
O que não é aceitável é a terceira sem o histórico. Sem ele, a discussão sobre o endereço que voltou não tem como terminar — e ela volta todo mês.
"Sincroniza nos dois sentidos" quase sempre é decisão adiada
Dito assim, não é um desenho: é a ausência de um. É a promessa de que os dois lados podem escrever e alguma coisa vai resolver. O que resolve é a ordem de chegada, e ela é arbitrária.
Os sintomas são conhecidos. O campo que volta ao valor antigo. O pingue-pongue, em que a escrita de um lado dispara o aviso que provoca a escrita do outro, sem fim. E a apuração que não conclui nada, porque cada sistema diz ter a versão mais recente segundo o próprio relógio, e os dois relógios não concordam.
Existe sincronização bidirecional legítima. Ela é bidirecional por campo, com dono declarado em cada um, o que é o oposto de "os dois escrevem em tudo".
O artefato é uma tabela
Entidade, campo, sistema dono, direção da cópia e o que acontece no conflito. Uma linha por campo que atravessa a fronteira. É um documento chato, parente próximo do de-para da migração, e é a decisão inteira.
Sem ele a regra existe assim mesmo: escrita no código da sincronização, alterada a cada manutenção, conhecida por uma pessoa.
O teste que confirma
Escolha um cliente e um campo. Altere o valor nos dois sistemas dentro da mesma janela de sincronização: primeiro no A, depois no B. Rode a sincronização e anote o resultado. Devolva tudo ao estado anterior e repita invertendo a ordem.
Se o valor final depende da ordem em que você digitou, não existe dono: existe uma disputa que a operação vem resolvendo por sorteio. Depois pergunte ao histórico quem fez cada alteração e a partir de onde. Se ele não souber responder, essa é a primeira coisa a construir: é ela que vai mostrar quanto o problema custa.