Trocar de software de distribuição sem interromper a operação

A causa mais comum de fracasso é a virada big-bang: numa sexta-feira à noite, desliga-se o sistema antigo, liga-se o novo, e na segunda de manhã toda a empresa descobre o desconhecido ao mesmo tempo. O menor problema — um fluxo não testado, uma permissão ausente, uma tela mal compreendida — propaga-se instantaneamente a todos os armazéns, sem rede de segurança. O que teria sido um incidente menor torna-se uma crise visível a todos os clientes.

A segunda causa, silenciosa mas devastadora, são os dados sujos. Clientes duplicados, produtos fantasma, unidades de medida incoerentes, endereços obsoletos: o sistema antigo os tolerava por hábito, o novo os rejeita ou, pior, os propaga. Nunca se migra um catálogo e um cadastro de clientes «como estão» sem tê-los limpado antes.

A formação negligenciada completa o quadro. Um software excelente usado por uma equipe despreparada produz maus resultados mais rápido do que um software medíocre bem dominado. Por fim, muitas empresas lançam sem plano de reversão: quando algo dá errado, não existe nenhuma forma documentada de voltar atrás, e o pânico substitui a decisão.

O fio condutor de todos esses fracassos é o mesmo: tratar a migração como um evento técnico pontual em vez de um projeto de operações progressivo. As seções seguintes propõem o contrário.

A operação em paralelo consiste em fazer o sistema antigo e o novo funcionarem ao mesmo tempo durante um período definido. Concretamente, por duas a quatro semanas, cada operação crítica — entrada de pedidos, recebimento, expedição, faturamento — é registrada nas duas ferramentas. É um custo extra temporário, mas é o preço de uma rede de segurança real: em nenhum momento você perde a capacidade de atender um cliente.

O coração do método é a reconciliação diária. Ao fim de cada dia, os dois sistemas são comparados por alguns indicadores simples: número de pedidos, valor total faturado, movimentações de estoque, divergências de inventário. Uma divergência não é um fracasso, é informação: revela um mapeamento incorreto, uma regra de negócio mal traduzida ou uma ação de usuário a corrigir. Cada divergência e sua resolução são documentadas.

A virada nunca deve depender do calendário, mas de critérios de confiança mensuráveis definidos com antecedência. Por exemplo: três dias consecutivos sem divergência de faturamento acima de um limite; zero pedidos perdidos; tempo de registro de volta ao normal; taxa de erro de expedição estável. Enquanto esses critérios não forem atingidos, prolonga-se o paralelo em vez de forçar.

Esse período tem ainda uma virtude humana: transforma o medo em hábito. As equipes aprendem a nova ferramenta com dados reais, mas sem riscos irreversíveis, já que o sistema antigo permanece a fonte da verdade até que a confiança seja estabelecida. Com o SupplyCore, a exportação/importação em CSV e JSON e a API REST pública facilitam essa dupla alimentação e a comparação automatizada dos dois conjuntos de dados.

A migração começa com uma exportação completa do sistema antigo, idealmente em CSV ou JSON: clientes, fornecedores, catálogo de produtos, preços, estoques, pedidos em aberto, histórico recente. Essa exportação é sua matéria-prima. A regra de ouro: nunca importar diretamente do antigo para o novo. Passa-se sempre por uma etapa intermediária de limpeza e controle.

A limpeza ataca primeiro a deduplicação. Um mesmo cliente cadastrado três vezes com três grafias, duas referências de produto para um item idêntico, unidades de medida misturadas: são os erros que depois contaminam os estoques e o faturamento. Faz-se a fusão, normalizam-se os formatos (códigos, unidades, moedas), preenchem-se os campos obrigatórios do novo sistema e arquiva-se o que está morto em vez de migrá-lo.

O mapeamento consiste em decidir, campo a campo, no que cada dado se transforma no destino: qual campo de origem alimenta qual campo do SupplyCore, quais valores são convertidos, quais regras se aplicam. Esse documento de correspondência é o contrato da migração; ele é revisado e validado com os responsáveis de negócio, não apenas com a TI.

A validação apoia-se em conjuntos de teste e controles de integridade. Importa-se primeiro uma amostra representativa, verifica-se se os totais batem (número de clientes, valor de estoque, saldos em aberto), reproduzem-se alguns pedidos de ponta a ponta e depois se amplia. Os agentes de IA do SupplyCore e a API REST ajudam a detectar automaticamente anomalias e duplicatas residuais, mas a validação final permanece uma decisão humana, tomada sobre números que se reconciliam.

Em vez de ligar toda a rede de uma vez, a implementação progressiva divide o deploy site por site. Primeiro escolhe-se um armazém piloto: nem o maior, nem o mais crítico, mas representativo dos fluxos, com uma equipe motivada e um responsável local capaz de conduzir a mudança. Esse site absorve os primeiros ajustes, ali onde um erro fica contido.

O piloto serve para descobrir o que nenhum teste de laboratório revela: os hábitos reais, os casos particulares de um cliente histórico, a impressão de etiquetas, as integrações com uma transportadora. Cada problema encontrado é corrigido e documentado num guia de implementação que servirá aos sites seguintes. O piloto não é bem-sucedido quando «funciona» um dia, mas quando roda vários dias sem intervenção excepcional.

Em seguida vem uma onda de dois ou três armazéns adicionais, escolhidos para cobrir outros cenários. Nessa etapa, capitaliza-se: as correções do piloto já estão integradas, a formação está rodada, os critérios go / no-go são conhecidos. A curva de aprendizado da organização acelera a cada onda.

A generalização para toda a rede só acontece quando o modelo está comprovado e estabilizado. Essa abordagem tem uma vantagem decisiva: a todo momento, a maior parte da empresa funciona sobre um sistema conhecido — antigo ou novo — e nunca toda a operação fica exposta simultaneamente ao mesmo risco.

O treinamento que fracassa é aquele que trata todos da mesma forma. Um motorista, um estoquista, um vendedor e um contador não usam o mesmo software: usam quatro softwares diferentes dentro da mesma ferramenta. Cada um deve aprender o seu percurso — as telas que realmente utiliza — e nada mais. Afogar um estoquista em funções de contabilidade garante que ele reterá mal as suas.

Constrói-se então um plano por função. Os vendedores: busca de produto, disponibilidade, entrada de pedidos, preços e descontos. Os estoquistas: recebimento, armazenagem, separação, expedição, inventário. Os motoristas: rotas, comprovantes de entrega, devoluções. A contabilidade: faturamento, recebimentos, conciliações, impostos. A direção: painéis e indicadores de gestão. Cada percurso merece seu material dedicado.

O formato que funciona é feito de sessões curtas e práticas, sobre casos reais da empresa, em vez de longas demonstrações teóricas. Uma hora focada, seguida de prática imediata durante a operação em paralelo, fixa melhor do que um dia inteiro assistindo. Fichas de uma página, afixadas no posto, valem mais do que um manual de cem páginas que ninguém abre.

É útil formar alguns referentes internos por site e por função: colegas que evoluem mais rápido e se tornam o primeiro recurso dos demais. Para necessidades específicas, o SupplyCore oferece suporte nativo em francês e blocos de horas de adaptação a US$ 125/h, mobilizáveis para personalizar uma tela, ajustar um fluxo ou construir um material de treinamento sob medida sem iniciar um projeto pesado.

Um projeto de migração sério prevê o próprio fracasso. O plano de reversão (rollback) é o cenário escrito que responde a uma única pergunta: se o novo sistema ficar inutilizável numa manhã, como retomamos a atividade em menos de uma hora? A resposta honesta, durante todo o período de transição, é manter o sistema antigo disponível em modo somente leitura: os pedidos em andamento continuam consultáveis, o histórico permanece acessível e, se necessário, pode-se registrar ali novamente uma operação crítica.

O plano de reversão não é um documento guardado numa gaveta. Ele especifica quem decide, quem executa, em que ordem e quais dados devem ser ressincronizados no retorno. É testado ao menos uma vez antes da virada, como um simulado de evacuação: um rollback que nunca foi ensaiado é apenas uma intenção.

Em cada etapa — fim da migração de dados, fim do piloto, antes de cada onda, antes da generalização — toma-se uma decisão explícita go / no-go. O «go» nunca é uma sensação; apoia-se em critérios quantificados fixados de antemão: totais reconciliados, zero pedidos perdidos, prazos de processamento dentro da norma, taxa de erro abaixo de um limite, equipes formadas e confiantes. Se um único critério bloqueante não for atendido, é «no-go», e corrige-se antes de avançar.

Esse enquadramento desloca a decisão do terreno emocional para o terreno factual. Ninguém precisa «sentir» que é o momento certo: os números decidem. É precisamente o que permite a uma direção de operações conduzir a mudança com serenidade, sabendo que uma volta atrás limpa permanece possível a cada instante.

Uma implementação do SupplyCore organiza-se tipicamente ao longo de duas a seis semanas, conforme o tamanho da rede e a complexidade dos fluxos. Um distribuidor de site único com processos padrão fica na extremidade baixa; uma rede multiarmazém com integrações e casos particulares fica na extremidade alta. O importante não é a duração absoluta, mas o encadeamento lógico das etapas.

Semana 1 — enquadramento e dados. Alinham-se os objetivos, identificam-se os papéis e os referentes, lança-se a exportação do sistema antigo e a limpeza. Redige-se o documento de mapeamento e prepara-se o ambiente. Em paralelo, definem-se por escrito os critérios go / no-go e o plano de reversão. Semana 2 — importação e validação. Importa-se um primeiro conjunto, lançam-se os controles de integridade, reproduzem-se pedidos de teste e corrige-se o mapeamento até que os totais se reconciliem. Começam as primeiras formações por função.

Semanas 3 a 4 — piloto e paralelo. O armazém piloto passa à operação em paralelo: registro duplo, reconciliação diária, ajustes. O sistema antigo permanece a fonte da verdade em leitura. Só se faz a virada do piloto quando os critérios de confiança se mantêm por vários dias seguidos. O guia de implementação enche-se com os casos reais encontrados.

Semanas 5 a 6 — ondas e generalização. Apoiando-se no piloto, implementam-se os armazéns seguintes por ondas, com formação e paralelo comprimidos graças à experiência adquirida, até a generalização. Mantém-se o sistema antigo acessível em modo somente leitura por algum tempo após a virada completa, e depois retira-se assim que a confiança estiver definitivamente estabelecida. Ao longo de todo o processo, o suporte nativo em francês, os agentes de IA e os blocos de horas de adaptação permitem absorver os imprevistos sem descarrilar o cronograma — e sem nunca interromper a operação.