Quando o time contraria o sistema, o time costuma estar certo

127 correções manuais em dois meses. A leitura fácil era falta de disciplina. A verdade era que a regra automática estava invertida.

Por Rodrigo Carvalho ·

Tinha uma regra automática que decidia onde cada ordem de produção seria feita, olhando tamanho e quantidade. Ela estava no ar havia meses, parecia sensata, e ninguém reclamava dela.

Aí eu resolvi medir. Peguei 534 ordens de dois meses e comparei o que a regra sugeriu com o que de fato aconteceu.

Setenta e nove ordens que a regra mandou para fora foram trazidas de volta para dentro pelo operador. Outras quarenta e oito seguiram o caminho contrário. E das ordens que a regra colocou no equipamento interno, 60% estavam abaixo do próprio limite mínimo que ela mesma definia.

Somando tudo, umas 127 correções manuais em dois meses. Todo dia alguém desfazendo a escolha do sistema, em silêncio, sem abrir chamado.

O que eu quis concluir, e o que era

A primeira frase que passa pela cabeça é que o time não está seguindo o processo. Foi a minha primeira frase também, e ela estava errada.

O parâmetro de quantidade estava invertido em relação à prática. Não era uma falha de execução, era um erro de modelo que se manteve porque ninguém tinha comparado a regra com a realidade.

E quando eu fui entender por que o operador acertava mais que o sistema, a resposta era simples. A decisão dependia de duas coisas que não estavam em lugar nenhum: a urgência daquele pedido específico e quanta capacidade o fornecedor tinha naquele dia. O operador sabia das duas. O sistema estava decidindo com metade da informação.

Parar de adivinhar não é desistir

O que fizemos foi deixar a sugestão automática sempre apontando para o destino mais frequente, que dava conta de 71% dos casos, e manter a outra opção a um clique de distância.

O sistema parou de tentar acertar sozinho. Não perdeu função, ganhou honestidade: ele agora oferece o caminho mais provável e deixa a decisão com quem tem a informação que falta.

As três saídas possíveis

Sempre que aparece uma sugestão automática que vive sendo desfeita, existem três caminhos, e eu tentaria nesta ordem.

O primeiro é trazer para o sistema a informação que está faltando, se ela for possível de capturar e estável o suficiente para valer o esforço. Nem sempre é.

O segundo é parar de sugerir e deixar a escolha explícita, quando a variável que decide mora no julgamento de quem está lá. Menos automação, mais clareza.

O terceiro é o meio do caminho que a gente adotou: sugerir o caso mais comum e deixar a alternativa fácil de alcançar.

O que não funciona, e eu já vi tentarem, é insistir na regra e cobrar aderência. Isso não conserta o modelo. Só transfere o custo para a pessoa, e tem um efeito colateral pior: quando o time desiste de corrigir, o erro para de aparecer no relatório e continua acontecendo no chão.

Por que vale medir isso antes de qualquer coisa

Contar quantas vezes uma automação é desfeita é rápido, é barato e quase sempre revela algo. E é um número que praticamente ninguém está olhando.

Ele responde uma pergunta que muito gestor sente mas não sabe formular: em que o meu sistema está atrapalhando em vez de ajudar?

Se você tem alguma regra automática rodando há mais de seis meses sem ninguém ter conferido, essa é a medição que eu faria primeiro.

Próximo passo

Isso acontece na sua operação?

Então vale conversar. Uma hora, sem custo, olhando o seu caso: você sai com um processo escolhido e uma forma de saber se deu certo.

Risco invertido: se em 6 semanas o processo não estiver rodando de verdade na sua operação, a segunda parcela do piloto você não paga.

Falar no WhatsApp