Três meses após o go-live, de volta às planilhas
Um armazém de artigos para o lar gastou $60K em um WMS. Três meses após o go-live, o supervisor do armazém devolveu todo mundo ao Excel. O dono me perguntou se ainda tinha jeito. Depois de um dia no local, minha conclusão: o sistema estava bem — as pessoas e os processos estavam quebrados. Esse é o roteiro compartilhado de quase toda implantação fracassada de WMS.
O segredo aberto do setor: as taxas de fracasso de projetos WMS são muito maiores do que os fornecedores admitem. E as causas se concentram em cinco motivos.
Motivo 1: Começar sem requisitos claros (o maior assassino)
A forma mais comum de morrer. Requisitos vagos na seleção; os consultores configuraram "processos padrão"; no go-live nada batia com a realidade: suas regras de onda não são suportadas, sua lógica de faturamento precisa de desenvolvimento sob medida, ninguém nunca mencionou seu fluxo de devoluções.
Correção: antes de iniciar a implantação, faça um "passeio de processos" — pegue 20 pedidos históricos reais e execute cada um de ponta a ponta, do pedido ao embarque, dentro do sistema. Tudo que não rodar vira uma solicitação de mudança na hora. Não espere o go-live.
Motivo 2: Dados sujos no ar
Um WMS é um sistema de dados: endereços, cadastros de SKU, quantidades de estoque — se qualquer um estiver errado, o go-live é um desastre. O pior que já vi: um armazém entrou no ar com 60% de acurácia de estoque. O sistema atribuía tarefas de picking sobre estoque fantasma, o armazém mergulhou no caos e a operação parou em três dias.
Correção: faça um inventário físico completo antes do go-live; não vire a chave abaixo de 95% de acurácia. Lembre-se da fórmula: garbage in, garbage out — o sistema amplifica a qualidade dos dados, para o bem ou para o mal.
Motivo 3: Sem patrocínio da direção
Implantar um WMS é uma mudança organizacional, não um projeto de TI. Projetos em que "o chefe só assina cheques" fracassam em taxas alarmantes: os departamentos travam sem ninguém para decidir, funcionários veteranos resistem ao novo sistema sem ninguém para impô-lo, e as decisões dos consultores ficam uma semana sem aprovação.
Correção: o dono precisa ouvir um briefing do projeto todo mês e aparecer nos marcos principais (assinatura de processos, cutover). O tempo investido pela direção é o melhor preditor do sucesso do projeto.
Motivo 4: Treinamento relâmpago
Muitos projetos "treinam" com um PowerPoint de duas horas na véspera do go-live. Os operadores pegam o PDA na manhã seguinte perdidos — escaneiam errado e não sabem como desfazer, batem numa exceção e não sabem a quem chamar. Então todo mundo volta discretamente aos velhos hábitos: Excel e papel.
Correção: treine em três níveis — operadores (SOP por função + teste prático; sem aprovação, sem acesso no go-live), gestores (relatórios e tratamento de exceções), TI (administração básica). "Teste para qualificar" é a linha entre treinamento e teatro.
Motivo 5: Cutover agressivo demais — o Big Bang
"Cutover total na próxima segunda!" — a frase mais perigosa do armazém. Grandes armazéns especialmente não podem fazer big-bang: um bug escondido atinge todos os embarques do prédio.
Correção: pilote primeiro. Vire a chave em uma zona, um turno, ou 20% do volume de pedidos; rode 2 a 4 semanas estável, depois expanda. Rodar os dois sistemas em paralelo durante o piloto é exaustivo — e é o seguro mais barato que você já vai comprar.
| Causa de fracasso | Sintoma típico | Custo de prevenção vs. custo de fracasso |
|---|---|---|
| Requisitos vagos | Processos não batem no go-live | 2 semanas de discovery vs. 3 meses de retrabalho |
| Dados sujos | O sistema atribui tarefas impossíveis | 1 inventário completo vs. 3 dias de parada |
| Direção ausente | Decisões atrasadas, guerras de território | 2 horas/mês vs. projeto abandonado |
| Treinamento relâmpago | A equipe volta ao Excel | 1 semana de treinamento prático vs. sistema parado |
| Cutover big-bang | Um bug paralisa o armazém | 1 mês de piloto vs. parada total |
Sinais de alerta precoce: cinco bandeiras vermelhas nos 30 dias antes do go-live
Muitos fracassos são selados antes do go-live. Se você está no meio da implantação e avistar qualquer um destes, pare e corrija imediatamente — nunca aposte no "a gente resolve depois do lançamento":
- Os consultores entendem seus processos pior do que você: se perguntarem "o que este documento significa" mais de três vezes numa reunião, o discovery não foi bem feito.
- Os cadastros não param de escorregar: a duas semanas do go-live e os cadastros de SKU ainda não estão completos — o caos no lançamento está quase garantido.
- Usuários-chave faltam ao treinamento: o supervisor do armazém diz "muito ocupado, manda o Xiao Li no meu lugar". A primeira pessoa a resistir ao novo sistema após o lançamento costuma ser esse supervisor.
- Os testes cobrem só o caminho feliz: os casos de teste exercitam apenas fluxos padrão — sem exceções, sem devoluções, sem divergências de inventário. No primeiro dia do go-live, as exceções vão te colocar no seu lugar.
- A direção falta duas revisões de projeto seguidas: o sinal mais perigoso — o projeto já caiu da lista de prioridades dela.
Os 30 dias antes do go-live são sua última chance de frear. Atrasar o lançamento em duas semanas sempre custa menos do que três meses de operação fracassada.
O treinamento se paga sozinho: uma semana de treinamento prático para operadores custa uma fração de um único dia de caos pós-go-live. E faça o treinamento colar — imprima os 10 fluxos de PDA mais usados em cartões plastificados e prenda um em cada dispositivo. O melhor SOP é o que está ao alcance da mão.
Estudo de caso: um projeto puxado de volta da beira do abismo
Um armazém de autopeças no Texas viu os embarques no prazo caírem de 98% para 82% duas semanas após o go-live do WMS; o dono estava pronto para matar o projeto. Encontrei três problemas: 15% dos SKUs não tinham dados de peso/dimensão (o sistema não conseguia cartonizar), o turno da noite nunca havia sido treinado em exceções, e o cutover big-bang não deixou isolamento. O resgate: duas semanas para completar os cadastros, retreinamento dedicado do turno da noite, e devoluções de volta ao processo antigo. A taxa de embarques no prazo se recuperou para 97% em um mês, 99% em três. A maioria dos projetos "fracassados" não precisa de um sistema novo — precisa de um plano novo.
Conclusão
Os cinco assassinos — requisitos vagos, dados sujos, diretores ausentes, treinamento relâmpago, cutover agressivo — não são nada técnicos. São todos problemas de gestão. O que na verdade é uma boa notícia: problemas técnicos precisam do fornecedor; problemas de gestão você resolve sozinho. Antes do seu próximo projeto WMS, imprima essas cinco armadilhas e fixe-as na parede da sala de reuniões.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
