Deixe-me dar o veredito primeiro: o maior risco numa implementação de WES não é o software. É entrar em operação com regras de onda que ninguém jamais aprovou de verdade.
Seu fornecedor pode integrar seus sistemas e fazer teste de estresse nos servidores. Mas a questão de como um pedido vira um conjunto de tarefas de separação? Só sua equipe pode responder isso. Se ninguém assina o nome na resposta, uma implementação de WES é uma aposta, não um projeto.
Já vi projetos demais morrerem nesta frase: «Vamos entrar em operação com a estratégia de ondas como está e ajustar depois.» Francamente, isso é construir sobre areia movediça. Parece rápido até você tentar morar nele.
Aqui vai um que eu vivi. 2022, um armazém 3PL no Inland Empire, cerca de 120.000 pés quadrados, expedindo cerca de 12.000 pedidos por dia — uma mistura de pacotes de e-commerce e atacado para algumas marcas pequenas. No blueprint travamos as regras de onda: cortar ondas por horário de corte de pedido, cada onda cobrindo 90 minutos de pedidos, contas-chave nas suas próprias ondas. Três rodadas de testes, e a orquestração de tarefas, os caminhos de separação e os destinos de triagem todos alinhados. A equipe de implementação achou que essa estava no papo.
Três dias antes do cutover, o VP de Operações decidiu recortar as ondas por transportadora — pedidos da UPS numa onda, da FedEx noutra — porque facilitaria cumprir os horários de fechamento das carretas. Uma frase, três meses de estratégia no lixo. A equipe reconfigurou as regras de madrugada. Reteste? Sem tempo. Direto para o go-live.
Dia do cutover, 10h. A primeira onda caiu, e o WES mandou quase todos os separadores para o mesmo corredor. Recortadas por transportadora, a distribuição de localizações dos pedidos tinha mudado completamente, e toda suposição de densidade no motor de tarefas estava errada. Os separadores fizeram fila no corredor esperando tarefas. O sorter rodou vazio por quase duas horas. Nenhum corte da tarde foi cumprido. Naquela noite revertemos para as regras de onda do blueprint, e o sistema só estabilizou na manhã seguinte. Uma ida e volta queimou um dia inteiro de throughput — multas de atraso de clientes por cima.
Dois lados nisso. O lado técnico: mude as regras de onda e o WES tem que recomputar a orquestração de tarefas, a alocação de mão de obra e o ritmo dos equipamentos — tudo se move de uma vez, e não existe «só uma pequena mudança». O lado da gestão: por que as regras ainda podiam mudar três dias antes do cutover? Porque ninguém teve coragem de assinar no blueprint; o VP ficava dizendo «deixe-me pensar sobre isso». Depois de todos esses anos em implementação, aprendi que problemas técnicos sempre têm solução alternativa. Problemas que ninguém decide são os que matam você.
Então aqui está o checklist que entrego para todo armazém prestes a implementar um WES. Oito portões, uma linha de aceitação cada. Se não conseguir limpar a linha, não avance — avançar significa apostar a alta temporada na esperança.
Portão Um da Implementação de WES: Congele o Blueprint, Assine Toda Mudança
O momento mais perigoso do projeto inteiro é a noite antes do go-live, quando alguém com autoridade decide que as regras de onda precisam de «um pequeno ajuste». Congele o blueprint: estratégia de ondas, prioridades de tarefas e fluxos de exceção, tudo assinado e lacrado. Depois do congelamento, toda mudança passa por um pedido formal de mudança. Pedidos verbais não valem. Quem quiser uma mudança assina o nome nela — essa única regra filtra noventa por cento das ideias de última hora.
O Checklist de Aceitação de Go-Live de WES de 8 Portões
| # | Portão | Como é o «pronto» |
|---|---|---|
| 1 | Congelamento do blueprint | Estratégia de ondas, prioridades de tarefas e fluxos de exceção assinados; qualquer mudança pós-congelamento exige um pedido formal de mudança |
| 2 | Prontidão dos dados mestres | Mestres de SKU, códigos de localização e specs de embalagem carregados; conferir fisicamente localizações contra o sistema, zero registros mestres faltando |
| 3 | Testes de integração | WMS, sorter, pick-to-light e impressoras todos conversando; rodar um drill de queda de rede e um drill de equipamento parado — sem mensagens perdidas ou duplicadas |
| 4 | Configuração de ondas e tarefas | Regras configuradas conforme o blueprint; reproduzir pelo menos três rodadas de pedidos históricos reais e conferir manualmente as atribuições de tarefas |
| 5 | Testes de estresse | Testar no volume da alta temporada, não no volume médio; o despacho de tarefas se mantém responsivo e nada quebra no pico |
| 6 | Operação em paralelo | Sistemas novo e antigo rodando lado a lado; conciliação pedido a pedido, três dias seguidos com zero divergência antes de falar em cutover |
| 7 | Janela de cutover | Escolher o turno de menor volume; equipe dobrada no turno do cutover e manter o sistema antigo quente e pronto para reverter |
| 8 | Hypercare | Duas a quatro semanas pós go-live; equipe central no local, problemas triados por severidade, problemas críticos têm um decisor em duas horas |
Dois portões merecem atenção extra. A operação em paralelo é onde a maioria das equipes trapaceia — elas rodam por um dia, olham alguns pedidos por cima e chamam de bom. Três dias seguidos de zero divergência é a linha. Parece lento; é mais barato que uma reversão. E o hypercare não é «a linha de suporte do fornecedor». É sua própria equipe central, fisicamente no prédio, com autoridade para tomar decisões. Uma linha de suporte não pode decidir se recorta uma onda às 2h da manhã. Seu líder de turno pode — se você deu a ele essa autoridade por escrito antes do go-live.
Big Bang ou Armazém por Armazém? Dois Lados
Aqui está o trade-off que ninguém quer discutir. Um cutover big-bang concentra o risco: se falhar, o prédio inteiro para. A recompensa é que a dor é curta — a equipe foca uma vez, e você não mantém dois conjuntos de lógica de processo em paralelo. Serve para uma instalação única com volume diário gerenciável e operações diretas.
Um cutover faseado, armazém por armazém, espalha o risco: a falha de um prédio não toca os outros, e as lições do prédio um se transferem direto para o prédio dois. O custo é um cronograma mais longo, overhead de gestão dobrado durante a sobreposição, e lógica especial para transferências entre armazéns. Serve para redes multi-site, ou uma instalação única cujo volume é tão grande que um dia parado quebra ossos.
Minha decisão: um prédio, corte uma vez, não arraste. Múltiplos prédios, corte um de cada vez, não seja ganancioso. O pior padrão é «faseado no nome, mas todo prédio perseguindo o mesmo prazo» — você paga os dois custos e não coleta nenhum benefício.
Uma visão contrária antes de fechar: a maioria acha que o maior risco num go-live de WES é bug de software. Francamente, bugs sempre têm solução alternativa. O que mata projetos é entrar em operação com regras de onda que ninguém decidiu de verdade. Com as regras definidas, até um sistema medíocre roda bem. Sem elas, a configuração mais bonita é só adivinhação.
Então parem de me perguntar qual fornecedor de WES escolher. Perguntem a si mesmos primeiro: há alguém disposto a assinar o documento de regras de ondas? Se não, o fornecedor não importa.
Por Lao Mi, Veterano de cadeia de suprimentos (20 anos)
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
