Vamos à verdade incômoda sobre demos de WMS: elas são teatro. Teatro ensaiado, roteirizado e coreografado. E a maioria dos compradores sai do teatro, assina um contrato e passa o ano seguinte se perguntando por que o software que parecia tão fácil na tela do projetor desmorona no seu armazém.
Vi isso acontecer em 2019 com um distribuidor de artigos para o lar nos arredores de Los Angeles. A demo foi impecável — escanear um código de barras, ondas liberadas instantaneamente, rotas de picking otimizadas como o diagrama de um livro didático. O dono assinou na hora. Nove meses depois, na semana do go-live, o armazém acumulava 6,000 pedidos em atraso e o dono gritava comigo do outro lado do pátio: "Na demo funcionava bem!"
Claro que sim. Essa era a ideia.
Três truques de demo para ficar de olho
Primeiro, dados higienizados. O banco de dados da demo tem talvez 500 SKUs perfeitos — cada item com código de barras, cada lote limpo, cada endereço atribuído. Seu armazém tem 20,000 SKUs, incluindo os que têm códigos de barras faltando, caixas amassadas e três lotes misturados no mesmo pallet. O software parece rápido porque nunca conheceu dados sujos.
Segundo, o caminho feliz. Demos de vendas sempre percorrem a estrada dourada: recebimento, armazenamento, picking, embalagem, expedição. Pergunte sobre o processamento de devoluções e você ouve "é configurável". Pergunte sobre rastreabilidade por número de série e você ouve "nós suportamos isso". Essas duas palavras — configurável, suportado — costumam se traduzir em uma segunda fatura de desenvolvimento customizado durante a implementação. Peça para eles rodarem seu fluxo real de devoluções ao vivo, na hora. A maioria não vai fazer.
Terceiro, o operador errado. Quem faz a demo geralmente é um engenheiro de pré-vendas ou um consultor sênior de implementação que poderia operar o sistema de olhos fechados. A equipe que vai implementar seu projeto será outra — possivelmente consultores com três meses de treinamento. A fluidez da demo não tem quase nada a ver com a qualidade da sua implementação.
Tire o roteiro das mãos do fornecedor
Uma POC de verdade tem um único princípio: o roteiro é escrito pelo comprador.
Escreva o seu antes de o fornecedor tocar em qualquer coisa. Limite-o a cerca de dez cenários, todos extraídos de pedidos que seu armazém processou de verdade nos últimos três meses. Minha lista recomendada: recebimento e armazenamento padrão, recebimento de pallet cheio com avaria, inserção de pedido urgente em uma onda, realocação por picking incompleto, devoluções de itens serializados, reposição a partir de pallet quebrado, ajuste de variação de inventário cíclico, reetiquetagem. Anexe dados reais — pelo menos 2,000 dos seus SKUs de verdade, incluindo os feios — mais uma semana real de volume de pedidos.
Depois defina as regras do jogo: nada de dados pré-carregados do fornecedor; eles importam os seus na hora; o operador precisa ser seu supervisor de armazém, não o consultor deles pilotando o mouse; cada cenário é cronometrado.
Essa regra do "sem ajuda" é a mais importante. Já assisti a POCs em que o consultor do fornecedor ficava atrás do operador narrando cada clique, praticamente movendo o mouse por ele. Isso testa o consultor, não o software. Coloque seu supervisor menos técnico na cadeira. Se ele aprender durante a sessão, o sistema é utilizável.
Quantifique a linha de aprovação ou nem tente
Quando a POC terminar, nunca pergunte à sala "o que vocês acharam?". Sentimentos são o pior critério de aceitação já inventado.
Escreva os critérios de aprovação na primeira página do seu roteiro de POC e faça o fornecedor assinar. Por exemplo: pelo menos sete de oito cenários concluídos de ponta a ponta sem nenhuma ajuda do fornecedor; liberação de uma onda de 500 pedidos concluída em menos de dois minutos; um ajuste de inventário cíclico em no máximo cinco cliques; seu supervisor operando de forma independente por duas horas sem erro.
Não atingiu a linha? Duas opções: o fornecedor admite que precisa de desenvolvimento customizado e coloca o escopo e o preço por escrito, ou está fora. A frase a temer é "vamos analisar isso" — ela significa "não funciona hoje".
Uma armadilha que preciso apontar especificamente: o tour guiado. Alguns fornecedores vão rodar seus cenários por você — o consultor deles dirige, seu pessoal assiste — e vão chamar isso de POC. Isso é uma demo com seu logotipo em cima, não uma prova de conceito. Se as mãos do fornecedor estão no teclado mais do que as da sua equipe, pare a sessão e redefina as regras. Uma POC em que o comprador nunca toca no software não prova nada, exceto que o fornecedor sabe operar o próprio produto, o que nunca esteve em dúvida.
Mais um movimento: leve seu líder de TI à POC e peça para ele avaliar a camada de integração. Seu WMS vai conversar com seu ERP, seu TMS, suas plataformas de e-commerce. Meio dia é suficiente para saber se a documentação da API é real e se existe um ambiente sandbox. Peça também os limites de taxa da API — um sistema que limita você a algumas centenas de chamadas por hora vai engasgar no momento em que seu volume de pedidos disparar. Um sistema com interfaces podres vai arrastar sua implementação para o fundo.
Três perguntas antes de assinar
A POC passou. Antes do contrato, obtenha por escrito essas três respostas como anexo do contrato.
Um: para cada cenário aprovado na POC, quem paga o desenvolvimento customizado se não funcionar no go-live? Muitos contratos cotam a implementação como uma "estimativa" com excedentes faturados à parte. Anexe a lista de cenários aprovados como critérios de aceitação — se não funcionar, o problema é do fornecedor.
Dois: quem está exatamente na equipe de implementação? Coloque os nomes dos consultores líderes no contrato, com uma cláusula de que substituições precisam da sua aprovação. Promessas verbais de "nossa melhor equipe" não valem nada.
Três: tempos de resposta nos primeiros 90 dias após o go-live. Alguma coisa vai quebrar — a questão é a rapidez com que eles aparecem. Escreva: atendimento remoto em até quatro horas para problemas críticos, no local em 24 horas.
Aquele cliente de artigos para o lar? Eles trocaram de sistema. Na segunda rodada de seleção, fiz com que rodassem uma POC de três semanas com dados reais e mais de 200 pedidos reais. No dia do go-live no novo sistema, o armazém fechou com duas horas extras. O dono me disse depois que gostaria de ter feito assim da primeira vez.
Uma POC é o único momento antes de assinar em que você pode fazer o fornecedor fazer trabalho de verdade. Não desperdice.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
