O pior go-live de WMS que já vi foi assim: ao meio-dia do dia do lançamento, as pistolas RF dos separadores não conseguiam puxar as listas de tarefas, e 40 pessoas ficaram paradas diante das prateleiras sem nada para fazer. O dono batia na mesa, o pessoal de TI trocava acusações numa sala de reunião — porque ninguém tinha decidido quem dá a palavra final quando algo quebra.
Depois disso aprendi a lição: na primeira semana de qualquer lançamento de sistema, o armazém precisa de uma war room. Não uma sala de reunião — um posto de comando. Quem se senta nela, que ferramentas traz e com que ritmo trabalha, tudo se decide antes do go-live. Aqui está o playbook que refinei ao longo de vários lançamentos. Use à vontade.
Três lançamentos que vi falhar — todos por «ninguém conseguia decidir»
Primeiro, três lições reais, e você verá por que a war room é inegociável.
O papel de etiquetas. No dia dois, todas as impressoras pararam — não era um bug do sistema. O papel de etiquetas acabou. A administração o havia estocado com base no consumo do sistema antigo, mas o novo formato de impressão dobrou o consumo. Trinta funcionários do armazém esperaram a manhã toda pela entrega de um motoboy. Desde então, o checklist da war room traz esta linha: estoque consumíveis para três dias.
A interface morreu às 2 da manhã. O feed de pedidos do ERP caiu às 2 da manhã e o WMS parou de receber pedidos. O TI de plantão era novo e não sabia quem detinha os direitos de reinício da interface; ele marcou @everyone no chat do grupo e levou 40 minutos para achar a pessoa certa. Nesses 40 minutos, o plano de ondas das 6 da manhã desmoronou. Desde então, a escala traz nomes e telefones, fixada na parede da war room.
O dono assumiu o comando. No dia três, um S2: a TI precisava de 4 horas para corrigir, a operação não podia esperar. O dono invadiu o chão de fábrica, passou por cima da war room e começou a redirecionar o fluxo de trabalho ele mesmo — o que conflitou com a lógica do sistema e criou 200 exceções naquele dia. Depois disso criei uma regra de ferro: na primeira semana, o chão recebe ordens de uma única voz — a war room. Donos com opinião falam dentro da war room.
Três fracassos, três formas de morrer, uma causa raiz: no momento crítico, ninguém conseguia decidir — ou decidiu a pessoa errada.
As 5 pessoas que precisam estar na sala
Com as pessoas erradas, a war room é só um lugar para discutir. Estes cinco papéis são inegociáveis:
O comandante do chão (uma pessoa, palavra final). Precisa ser um líder de operações que conheça o negócio — não de TI. Tem exatamente um poder: dentro de 5 minutos de um incidente, decidir «continuar» ou «parar». A primeira semana não sobrevive a decisões de comitê.
O implementador do WMS, presencial. Quando um bug de configuração aparece, só eles conseguem corrigir na hora. Coloque o suporte presencial no contrato para a semana do go-live — já vi o suporte só remoto falhar.
O líder de TI / integração. Um WMS nunca é uma ilha: o feed de pedidos do ERP, a API de etiquetas da transportadora e as interfaces de faturamento podem, cada um, parar o armazém se caírem. Essa pessoa detém os direitos de monitoramento e reinício de cada interface.
Líderes de turno do chão. Um da separação, um do recebimento e um da auditoria. São os sensores humanos do sistema — os primeiros a sentir uma tela lenta ou um fluxo estranho. Dê a eles um canal direto para reportar, não apenas um papel de repasse.
O escriba e gestor de escalação. Cada incidente é registrado, classificado por severidade e acompanhado até o fechamento. Essa pessoa decide o que espera até amanhã e o que escala agora — a ordem da sala depende dela.
Em uma linha: se a war room está cheia, o chão fica calmo.
O checklist de 48 horas antes do lançamento
A war room é montada dois dias antes do lançamento, não na manhã do dia. Marque um por um:
- Congelamento de dados: o momento exato em que o sistema antigo para de receber lançamentos, sincronizado em toda a empresa. Antes de congelar, valide três coisas: dados mestres de SKU, localizações e saldos de estoque. Se qualquer um dos três não fechar, você não lança.
- Consumíveis de impressão: etiquetas de expedição, etiquetas de código de barras, ribbons — estoque para três dias. Ria se quiser; já vi um armazém parado no dia dois esperando a entrega de papel de etiquetas.
- Simulado de rollback: rollback não é «voltamos ao sistema antigo se ficar ruim». Escreva: condições de gatilho, quem dá a ordem, como os dados voltam, de quantas horas o sistema antigo precisa para se recuperar. Passe por isso ao menos uma vez no papel antes do lançamento.
- Escala de turnos: a primeira semana roda com dois turnos de 12 horas por dia (dia e noite, sem parar), sete dias seguidos. Nomes e telefones no papel. Às 3 da manhã, você precisa saber exatamente para quem ligar — não @everyone num chat de grupo.
- A sala em si: uma tela grande mostrando o fill rate de pedidos ao vivo, o volume de backlog e o status das interfaces; um quadro branco com os 3 principais riscos do dia; lanches e água estocados. Ninguém come bem na primeira semana.
O ritmo da primeira semana: três standups + níveis de severidade
Três standups por dia, sem exceção. Manhã (30 min antes do início do turno): zera as pendências de ontem, confirma o plano de ondas de hoje. Checagem do meio-dia: revisa o backlog e as exceções da manhã, decide se adiciona gente para a tarde. Retrô da noite (após o fechamento): percorre a lista de incidentes do dia, classifica a severidade, atribui responsáveis e prazos. Trinta minutos no máximo cada um. Em pé.
Matriz de severidade e escalação — imprima na parede:
| Nível | Definição | Resposta |
|---|---|---|
| S1 | Sistema fora do ar / armazém inteiro parado | Escalar ao comandante do chão em 15 min; contorno em 1 hora |
| S2 | Fluxo principal bloqueado (p. ex., etiquetas não imprimem) | Responder em 30 min; resolver ou degradar em 4 horas |
| S3 | Anomalia local (uma localização, um documento) | Resolver no mesmo dia |
| S4 | Polimento / melhorias de UX | Registrar no backlog; tratar na segunda semana |
Quando declarar: as linhas vermelhas de rollback
A chamada mais difícil não é corrigir um bug — é admitir «hoje não dá para lançar». Escreva as linhas vermelhas com antecedência, no plano de lançamento, com a assinatura do dono:
- O fill rate de pedidos cai abaixo de 80% sem tendência de melhora por 2 horas;
- O backlog excede 1.5× a capacidade diária e continua subindo;
- Uma interface principal (pedidos do ERP / etiquetas da transportadora) está fora do ar há mais de 4 horas sem caminho de recuperação;
- As divergências de estoque se espalham e as contagens não convergem.
Qualquer uma dispara: o comandante do chão declara a parada e inicia o rollback. Lembre-se: rollback não é fracasso — é controle de perdas. Perder todos os clientes aguentando três dias é o verdadeiro fracasso. Dos lançamentos que conduzi, aquele em que demos rollback com decisão saiu limpo duas semanas depois; aquele que empurramos à força custou um mês de dor.
Quando desmontar a war room
Também há um padrão para isso — não «parece que já está bem»: três dias seguidos sem incidentes S1/S2, fill rate de volta à linha de base pré-lançamento, backlog zerado. Depois uma retrô final: arquiva o log de incidentes, entrega o backlog para a operação diária, reduz a escala para plantão. Apaga o quadro branco. Desmonta.
A primeira semana de um lançamento se vence com organização, não com tecnologia. O sistema mais estável não sobrevive a 40 pessoas que não sabem a quem ouvir. Monte a war room, defina as regras e a primeira semana sai bem — uma lição que paguei com várias noites em claro.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
