Direto ao ponto: quando um projeto de WMS atrasa, oito em cada dez vezes não é o software — são os dados. Entre em produção com dados sujos e você não comprou um WMS, comprou um razão caro que registra os números errados.

Já vi esse buraco três vezes. Sempre o mesmo roteiro: o cliente diz «nossos dados estão prontos», no primeiro dia o sistema diz que uma posição tem estoque e está vazia, o sistema diz que uma posição está vazia e há três paletes sentados nela. Tudo para para uma recontagem completa, o go-live atrasa duas semanas e o chefe perde a cabeça.

Por que a migração de dados é a assassina nº 1 dos WMS

Simples: um WMS é um amplificador. Na era do Excel, dados sujos eram sobrevivíveis porque humanos os disfarçavam — o velho Zhang lembrava que o palete da zona A estava danificado, não toque nele. Depois do go-live, o sistema atribui posições automaticamente, libera ondas automaticamente, sugere reabastecimentos automaticamente. Os dados sujos são amplificados pela máquina — fielmente, sem descanso — até virarem incidentes de produção.

Três espécies de dados sujos para caçar:

SKU mortos ocupando posições premium. A maioria dos armazéns tem 10–20% dos SKU intocados há um ano, ainda sentados nas faces de picking douradas. Migrá-los como estão é importar para o novo sistema também o trabalho de separar o lixo.

Divergências entre contábil e físico. O contábil diz 100, o chão tem 80, e os 20 que faltam são uma diferença de inventário de três anos atrás que ninguém ajustou. «Todo mundo sabia» no sistema antigo. No sistema novo, são 20 unidades fantasmas disparando reabastecimentos falsos e rupturas fantasmas.

Cadastros de itens sem campos. Sem comprimento, largura, altura ou peso, e as recomendações de posição, a cartonização e as estratégias de onda do WMS são decorativas. O pior que já vi: 3.000 SKU, menos de 400 com dados de dimensão.

O manual: três checklists

4–6 semanas antes: faxina (a parte que mais importa)

É assim que cada uma das três espécies de dados sujos se limpa na prática.

SKU mortos. Não apenas liste — caminhe pelo chão. Eu obrigo o cliente a visitar fisicamente os 50 principais SKU mortos por volume cúbico. Metade das vezes, SKU «mortos» acabam sendo mal etiquetados ou armazenados sob o código errado, o que já é um problema de dados que vale a pena corrigir. Os genuinamente mortos recebem uma decisão de destino com nome e data: «Zhang Wei, descarte até 15 de novembro». Sem dono, sem data = nunca acontece.

Divergências entre contábil e físico. O truque é conciliar no sistema antigo, não durante a migração. Rode um inventário total ou ciclo completo 2–3 semanas antes da virada, ajuste tudo, depois congele os ajustes. Qualquer diferença descoberta após o congelamento ganha um log de divergências com causa raiz — não um ajuste silencioso. Ajustes silenciosos são como os fantasmas nascem.

Lacunas no cadastro de itens. Priorize pela velocidade cúbica: os 20% dos SKU que puxam 80% dos picks recebem dimensões primeiro. Para a cauda longa, uma estação de dimensionamento de $200 (balança + moldura de medição + leitor de código de barras) no recebimento captura as dimensões na próxima entrada — sem projeto de arqueologia. Digo aos clientes: você não precisa medir os 3.000 SKU antes do go-live; precisa medir os 600 principais e ter um processo que capture o resto em 90 dias.

  1. Extraia SKU sem movimentação em 12 meses. O negócio decide: descarte, liquidação ou mover para armazenagem de baixo custo. Meta: zero SKU morto nas faces de picking douradas.
  2. Rode um ciclo de inventário completo e ajuste cada divergência. Nada de «consertamos depois». Já vi esse buraco três vezes — cada divergência adiada virou um incidente P0 depois do go-live.
  3. Complete o cadastro de itens: dimensões, peso, flags de rastreamento de lote, flags de validade. O que não puder ser completado ganha a tag «pendente» e passa por um workflow de confirmação manual no WMS como paliativo.
  4. Congele o cadastro de posições uma semana antes: códigos, tipos, atributos. Qualquer posição nova passa pelo controle de mudanças.

Semana de migração: conciliação em via dupla

  1. Exporte do sistema antigo, importe para o novo, depois produza o mesmo relatório de saldos por SKU dos dois lados e concilie linha por linha. Mais de 0.5% de divergência = pare. «Perto o bastante» não é padrão.
  2. Verifique fisicamente 10% das posições, priorizando SKU de alto valor e com divergência.
  3. Rode três dias em paralelo: o sistema antigo continua emitindo pedidos, o novo sistema os acompanha em sombra, compare a acurácia de picking.

Primeiras duas semanas no ar: observe três métricas

  1. Diário: taxa de sugestões do sistema vs. overrides manuais. Overrides acima de 30% significa que os dados sujos ainda estão sabotando você — vá achá-los.
  2. Progresso do descarte de SKU mortos: tudo que foi realocado durante a migração deve ser descartado em 60 dias, ou volta quietinho.
  3. Queima de «pendentes» do cadastro de itens: 200 SKU por semana, zerado em um mês.

Checklist da véspera do go-live (decore isto)

  • Divergências de inventário históricas não ajustadas carregadas para o novo sistema
  • Apenas SKU com estoque migrados; SKU legados com estoque zero ignorados, quebrando referências de pedidos antigos
  • Atributos de lote/validade que eram notas de texto livre no sistema antigo nunca estruturados — rastreamento de lote morto ao nascer
  • Códigos de posição com caixa/espaços inconsistentes criando «A-01-01» e «a-01-01» como duas posições
  • Migração agendada para sexta à noite, ninguém alcançável o fim de semana todo, go-live na segunda em chamas

Uma regra contraintuitiva para fechar: quanto mais rápida a migração de dados, mais rápido o projeto morre. Todo cliente que me diz «a migração de dados leva três dias» ganha o go-live adiado em um mês. Devagar é rápido. Dados limpos são a única infraestrutura real que um go-live de WMS tem.

Por Lin Xiao, Consultor de implementação de WMS

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