A auditoria de validade que fizemos errado nas primeiras semanas

Entramos numa rede de mercados com um problema de validade caro. Perecível vencendo na gôndola, perda alta, e um diretor que sabia o tamanho do prejuízo mas não onde ele acontecia.

A hipótese era boa. Um sistema que lê data de validade e prazo de exposição e avisa antes do vencimento. A gente subiu a primeira versão em três semanas. E ela falhou de um jeito que a gente devia ter previsto.

O que a gente encontrou

O problema não estava na falta de aviso. Estava no excesso. Quando começamos a olhar, a equipe de loja já recebia alertas de validade do sistema antigo, e tinha parado de ler.

Alerta demais é igual a alerta nenhum. A primeira coisa que encontramos não foi um buraco de dado; foi fadiga de alerta. O time tinha aprendido que a maioria dos avisos não valia o caminho até a gôndola.

O que a gente mudou, depois de errar

Nas duas primeiras semanas, a gente piorou o problema. Calibramos o sistema para marcar o máximo de itens em risco, orgulhosos da cobertura. Mais alertas, mais “acertos” no painel. E o time ignorou ainda mais.

A gente estava medindo a coisa errada. Otimizamos o que a câmera via, não o que a equipe agia. Um alerta que ninguém atende não é detecção; é ruído com carimbo de IA.

A virada foi inverter o critério. Menos alertas, só os de maior perda evitável, com uma ação clara em cada um. Precisão acima de cobertura. O sistema passou a marcar vinte itens por dia, não duzentos, e cada um valia o caminho.

O número que mexeu

Em sete semanas, a perda por validade na seção piloto caiu cerca de um terço. O time voltou a confiar no alerta, porque o alerta voltou a valer.

A parte honesta: parte da queda veio de ajuste de pedido, não do alerta. Menos compra do que vencia, menos item para vencer. O alerta pegou o que já estava na gôndola; o abastecimento resolveu a montante. Os dois juntos moveram o número, não o alerta sozinho.

O que a gente errou, em uma frase

A gente confundiu detectar com resolver. Passou duas semanas melhorando a detecção quando o gargalo era a ação. O mesmo erro de medir o modelo e não a operação que vimos virar shrinkage que não se decompõe.

O que ficou para trás

Uma regra de alerta com teto: o sistema nunca manda mais avisos do que a equipe consegue atender num turno. Uma definição de perda evitável, separada da perda inevitável. E o time interno tocando a calibração, subindo o teto só quando a ação acompanha.

Pensa no alerta que a tua operação gera e ninguém atende. Relatório que chega e não vira ação. Antes de pedir mais detecção, pergunta se o problema é ver ou agir.

Se essa forma de gap soa familiar, entre o que o sistema marca e o que o time faz, me descreve em um parágrafo o que está acontecendo. A gente entra duas semanas dentro da operação e sai com um documento de uma página que o teu time mantém: o que vimos, o que a métrica não enxergou, e as três mudanças que fecham o gap. É assim que a gente trabalha.