Vou direto ao ponto: um ponto de congelamento de dados nunca é apenas um horário que TI escolhe num slide. É o momento em que um armazém pode se dar ao luxo de parar de operar — e esse preço precisa ser calculado, não chutado. Já vi projetos de WMS demais em que o congelamento foi anotado como «domingo 2:00 AM», só para a última onda da noite ainda estar rodando às 3 AM. O congelamento escorregou até o amanhecer, e o novo sistema entrou no ar no primeiro dia com números de estoque que não batiam com nada.

Em 2021 ajudei um 3PL em Fontana a migrar para um novo WMS — 120,000 pés quadrados, 18,000 pedidos de saída por dia na alta temporada. Fixamos o congelamento para sábado às 10 PM. Por que esse horário? Fizemos as contas: o volume de sábado por lá é cerca de 40% do de um dia de semana. Parar as operações num sábado às 10 PM nos custou no máximo 800 pedidos, e a agenda de domingo podia absorver a recuperação. Domingo 2 AM parecia melhor no papel, mas a última onda do turno da noite cai por volta das 11:30 PM — o prédio nunca fica realmente silencioso. O congelamento tem que cair dentro de um vale real da sua operação, não num número redondo do calendário.

O que você está realmente congelando: três linhas, cada uma pelo nome

A maioria das equipes acha que «congelar» significa «travar o sistema antigo para ninguém tocar». Isso é grosseiro demais. Um congelamento na verdade trava três estados, e você precisa dos três:

Recebimento — a linha de entrada para. Os caminhões continuam na estrada, os horários de agendamento continuam abertos — esse estoque está em trânsito, não faz parte do retrato congelado, mas precisa ser registrado. Pare de criar novos agendamentos de recebimento pelo menos 4 horas antes do congelamento. A carga que já chegou vai para uma área de staging: descarregada, registrada no papel, nunca digitada no sistema. Dê essas horas à sua equipe de descarga — eles precisam de tempo para limpar o que já está nas docas.

Separação (picking) — as ondas zeram. Esta é a perigosa. Antes do congelamento, toda onda viva tem que terminar: pedidos separados são despachados, ondas inacabadas são encerradas à força e devolvidas como «ondas incompletas» no sistema antigo. Num projeto, 37 ondas ainda estavam vivas quando alguém forçou a migração. Cada tarefa de separação dessas ondas sumiu na migração, e o armazém passou dois dias conciliando pedidos à mão. Faça a conta comigo: 8,000 SKUs, dois dias de caos, multas das transportadoras e horas extras — mais de $60,000 perdidos.

Expedição — a porta de saída fecha. Depois do congelamento, nenhum movimento de saída é permitido no sistema antigo. Caixas já separadas mas ainda não carregadas ou são carregadas e despachadas, ou voltam ao estoque e são registradas como tal. Nada pode ficar no limbo do «separado mas não despachado» — o retrato migrado não tem linha para isso, e vira estoque fantasma.

Só quando as três linhas estão definidas o ponto de congelamento é real em vez de decorativo.

Trabalhando de trás para frente: cada hora parada tem um preço

É assim que eu monto o cronograma, trabalhando de trás para frente a partir de um congelamento de sábado às 10:00 PM:

  • 6:00 PM — para a entrada: sem novos agendamentos de recebimento; descarga só para staging
  • 8:00 PM — para a separação: sem novas ondas liberadas; as equipes zeram as vivas
  • 9:30 PM — corte das ondas: ondas inacabadas são encerradas à força, papelada das tarefas recuperada
  • 10:00 PM — congelamento: sistema antigo travado, retrato de estoque exportado
  • 10:00 PM–meia-noite — checagem de divergências: contagem cíclica de SKUs de alto valor e encrenqueiros conhecidos
  • Meia-noite–2:00 AM — importação para o novo sistema, verificação de que as contagens de linhas batem
  • 2:00 AM — ensaio: 3–5 ondas pequenas liberadas no novo sistema, separadores percorrem de verdade
  • 6:00 AM — operações normais retomadas

Cada hora que o prédio fica parado custa dinheiro. Aquele armazém de Fontana perdeu cerca de $9,000 de vazão em quatro horas calmas de sábado. Agora compare: a migração de dados malfeita que eu vivi custou dois dias e mais de $60,000. Duas horas extras de parada planejada compram tranquilidade para a primeira semana inteira. Passe seu chefe por essa aritmética — numa migração de WMS, o item mais caro nunca é a licença do software. É o retrabalho depois de dados ruins.

E uma regra que aprendi do jeito difícil: nunca migre numa segunda-feira. Segundas de manhã empilham o atraso do fim de semana sobre os pedidos novos — uma das janelas mais ocupadas da semana. Vi um cliente insistir numa migração segunda-feira às 12:00 AM porque «a semana começa com dados limpos». O turno de recuperação da noite de domingo se estendeu, o congelamento escorregou para 4 AM, o job de importação nunca terminou, e 60 separadores ficaram parados às 8 AM sem nada para fazer. Minha regra desde então: ponha o congelamento na segunda metade de um vale real de operação. Pare duas horas mais cedo em vez de migrar sob um pico.

Migrando o estoque: três livros-razão, não um

Quando o congelamento chega, você exporta um retrato: cada SKU em cada endereço. Mas o estoque real de um armazém nunca é tão arrumado. Você precisa de mais dois livros-razão ao lado:

O livro de divergências. Depois que o retrato sai, conte ciclicamente uma amostra — eu costumo pegar 10–15% das linhas de SKU, com peso para itens de alto valor e SKUs com histórico de divergência. Investigue na hora qualquer coisa fora por mais de 2%. Importe o resto como está do sistema antigo, mas sinalize como «pendente de revisão» e vigie de perto na primeira semana. Não persiga 100% de conciliação à 1 AM — você não tem tempo, e a equipe está exausta. Errar em 2% dos SKUs custa muito menos que meio dia de parada.

O livro de trânsito. Pallets em staging, caixas separadas-não-despachadas, uma carreta carregada que nunca saiu — o retrato não mostra nada disso, ou só metade. Faça um ticket de papel para cada lote em trânsito: SKU, quantidade, status (aguardando guarda / aguardando despacho / na carreta), e reinsira-os no novo sistema no dia seguinte. O pior caso que já vi: 12 pallets ficaram em staging três dias porque nenhum sistema tinha registro deles. Ninguém soube até um cliente ligar sobre uma entrega faltante.

O livro de ondas inacabadas. Duas opções para ondas que não terminaram: (A) migrar as tarefas da onda para o novo sistema como estão — isso exige que os formatos de tarefa antigo e novo combinem, testado com antecedência; ou (B) matar as ondas, devolver as tarefas ao status não atribuído, e liberá-las de novo no novo sistema. Eu quase sempre escolho B. Incompatibilidade de formato é um risco maior do que liberar de novo, o que custa no máximo uma hora.

Equipe do armazém durante a transição da migração de WMS

A versão em lista de verificação

Algo que você pode usar amanhã. Imprima isto e fixe na parede do escritório do armazém uma semana antes da migração:

  1. Hora do congelamento: ______ (na segunda metade de um vale de operação — sem superstição sobre horas redondas)
  2. A entrada para ____ horas antes (sugiro 4+); a separação para ____ horas antes (sugiro 2+)
  3. Hora de corte das ondas: ______; plano de ondas inacabadas: A migrar / B matar-e-liberar-de-novo (sugiro B)
  4. Responsável pela exportação do retrato: ______; escopo da contagem cíclica: ______ linhas de SKU
  5. Tickets de papel para carga em trânsito impressos: sim / não
  6. Ensaio: 3–5 ondas pequenas, percorridas por separadores reais, aprovado: sim / não
  7. Gatilho de reversão: se a importação falhar, a que horas desistimos e voltamos ao sistema antigo? ______ (decida isso com antecedência — ninguém pensa com clareza às 3 AM)

E uma pergunta real para levar para casa: quanto estoque fantasma seu armazém tem agora — separado mas não despachado, recebido mas não guardado, pedidos criados com a carga intocada? Se você não consegue responder esse número hoje, o cronograma de congelamento mais bonito do mundo não vai salvá-lo. Limpe primeiro o estoque negro, depois falamos de migração.

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.