Isto é o que ninguém lhe conta sobre os go-lives de um WMS: o software raramente é o problema. O problema é a primeira semana.
Já vi go-lives em que o sistema passou em todos os testes, todas as interfaces retornaram verde e o plano de corte tinha 40 páginas — e mesmo assim, às 9h da manhã do primeiro dia o armazém estava em chamas. Processos novos, códigos de localização novos, dispositivos novos, tudo caindo na mesma manhã sobre pessoas que aprenderam o novo fluxo numa sessão de treinamento de duas horas três semanas antes. A sala de guerra é a única coisa que se interpõe entre esse caos e um cutoff de transportadora perdido. Mas a maioria das salas de guerra que já vi são apenas algumas pessoas sentadas respondendo telefones. O incêndio arde de qualquer jeito, porque ninguém decidiu de antemão como a primeira semana realmente seria.
Os três incêndios que você vai combater, garantido
O primeiro incêndio são os dados mestres. Códigos de barras que não escaneiam, códigos de localização que não conferem, conversões de unidade de medida erradas. Em 2023 acompanhei um go-live num armazém 3PL de 120.000 pés quadrados em Ontario, Califórnia. Para cumprir o prazo, a equipe adiou o carregamento dos códigos de barras de mais de 200 SKUs de baixo giro para "depois do go-live". Toda manhã da primeira semana, uma dúzia de ordens de onda travavam na estação de auditoria porque não havia código de barras para escanear, e os auditores tinham que revirar as caixas à mão. Zero dificuldade técnica, puro trabalho de preparação incompleto — e o incêndio mais desgastante da semana. Nunca mata você, só arde todos os dias.
O segundo incêndio são as interfaces. Do WMS para o OMS, para as transportadoras, para o EDI — algo vai falhar na primeira semana. Os pedidos não descem, as atualizações de status se perdem, uma liberação de onda morre no meio do caminho. A parte ruim é que o armazém não consegue ver esse tipo de problema: os separadores só sabem que "não há pedidos para separar". Se a sala de guerra não estiver vigiando as filas de interfaces, você descobre duas horas depois quando o backlog já está nos milhares. E aí vem o detalhe — muitas vezes não é culpa do WMS. A outra parte mudou um campo e esqueceu de avisar. Por isso a sala de guerra precisa de alguém que saiba ler logs e consiga o engenheiro da outra parte no telefone com uma única ligação.
O terceiro incêndio são as pessoas. O novo fluxo parece estranho, então os trabalhadores contornam o sistema discretamente: separam no papel primeiro, digitam depois; pulam o coletor RF porque escrever à mão é mais rápido. Se você não matar esses processos paralelos na primeira semana, nunca vai matar. Depois que os dados sujam, a acurácia do inventário nunca se recupera. Dos projetos que vi ainda conciliando inventário três meses depois do go-live, nove em cada dez enterraram o problema na primeira semana. Minha regra de sala de guerra: na primeira vez que alguém burla o sistema, é uma conversa naquele mesmo dia. Na segunda vez, vai direto ao gerente do armazém. Parece duro. É a única forma de proteger os dados.
Quem está na sala de guerra importa mais do que onde ela fica
A configuração que melhor funciona é uma ou duas pessoas de cada um dos três lados. Operações manda um supervisor de armazém — alguém que conheça o processo e possa decidir coisas como "este pedido pode sair manualmente". TI manda a pessoa de interfaces e infraestrutura — alguém que saiba ler logs e reiniciar um serviço sem abrir um chamado. O implementador manda um consultor que conheça a configuração — alguém que consiga corrigir um parâmetro errado na hora. Os três são inegociáveis. Sem operações, os incidentes não podem ser triados. Sem TI, os problemas de interface recebem olhares vazios. Sem o implementador, um item de configuração pode paralisá-lo por meio dia.
Trabalhe em dois turnos, não três. O turno da manhã cobre a liberação de ondas até o pico da tarde; o turno da noite cobre o fechamento, com uma sobreposição de duas horas para a passagem de turno. Trave a escala três dias antes do go-live, imprima, cole na parede. Se alguém precisar de folga, arruma seu próprio substituto. "Suporte por telefone" não conta. Na primeira semana, uma pessoa na sala e uma pessoa no telefone são dois níveis completamente diferentes de poder de fogo.
O mais importante: nomeie um tomador de decisões, geralmente o gerente de projeto do lado do negócio. A doença mais mortal da sala de guerra é ter três pessoas e nenhuma decisão. Quando chega um P1, o tomador de decisões diz uma frase — para a linha e corrige, ou contorna e protege o despacho. Essa pessoa precisa ter autoridade para interromper os embarques e autoridade para dizer "vamos no manual por duas horas". Uma sala de guerra com autoridade difusa vai debater por duas horas o que um tomador de decisões claro resolve numa frase.
Seis números no painel. Nem um a mais.
O painel da primeira semana deve ser enxuto. Eu acompanho seis números: backlog de pedidos não liberados, taxa de sucesso de liberação de ondas, coletores RF online, profundidade das filas de interfaces e maior tempo de espera, taxa de exceções de auditoria e taxa de embarques no prazo no mesmo dia. Cada um tem uma linha vermelha — por exemplo, uma fila de interfaces com mais de 200 pedidos sem movimento por 15 minutos é automaticamente escalada para P1, sem relatório necessário. Os três lados acordam as linhas vermelhas antes do go-live, escrevem no papel, colam na parede e não tocam nelas a semana inteira. Uma linha vermelha que muda todo dia não é uma linha vermelha.
Os níveis de severidade P1/P2/P3 precisam existir desde o dia um, e as definições devem ser claras e concretas. P1: não conseguimos embarcar, ou os dados vão corromper. P2: o throughput cai mais da metade, mas ainda conseguimos embarcar. P3: problemas de usabilidade que não afetam o embarque. Uma sala de guerra sem severidade clara tem tudo "meio urgente", o que significa que nada é priorizado. Mais uma regra de ferro: do momento em que um P1 é detectado até alguém assumir a responsabilidade, no máximo 15 minutos. Se estourar o prazo, o telefone do tomador de decisões toca diretamente.
Um plano de rollback não é uma vergonha. É um seguro.
Duas coisas precisam estar prontas antes do go-live. Primeiro, formulários de pedido em papel de contingência e um processo manual. Se o sistema realmente cair, o armazém não para: separa no papel, registra à mão, digita depois. Imprima os formulários com antecedência e deixe-os no chão — não saia procurando impressora quando as coisas já estão quebradas. E ensaie o fluxo manual pelo menos uma vez. Os líderes de turno devem percorrer o processo completo em papel com as próprias mãos, ou no dia ruim não vão saber nem como usar o papel que têm nas mãos.
Segundo, pontos de restauração de dados. Um backup completo toda noite, mais um backup separado antes de qualquer mudança importante de dados mestres. Rollback não significa desinstalar o sistema — significa "a mudança de configuração de hoje quebrou algo, e podemos voltar ao estado de ontem à noite". Honestamente, poucos projetos realmente usam o plano de rollback na primeira semana. Mas ter um muda completamente a psicologia da equipe. Uma equipe com plano vai mexer na configuração. Uma equipe sem plano não muda um único parâmetro, e um problema P2 se arrasta até virar P1.
Então: antes da semana do go-live, imprima as definições P1/P2/P3 e a lista de telefones de escalação, cole-as na parede da sala de guerra e coloque ao lado uma pilha de formulários de contingência em papel. No último dia da primeira semana, faça uma retrospectiva com três perguntas: qual incêndio queimou mais forte, qual métrica alarmou primeiro e qual solução manual deveria virar um processo permanente do sistema. Depois desmanche a sala de guerra — mantê-la aberta significa que você ainda não confia no sistema.
Uma última pergunta para você. Se você tivesse que desligar o sistema antigo com as próprias mãos na manhã do primeiro dia — teria coragem? Se não, seu plano de rollback não está pronto. Corrija isso agora, enquanto ainda há tempo.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
