Eu estava em minha terceira reunião daquela semana discutindo os mesmos problemas. Picking com variação de 0,5% pra 3% de erro sem explicação. Conferência oscilava. Paradas de linha aconteciam e ninguém sabia por quê. Todo mundo vinha com suposição: “aquele funcionário não estava focado”, “falta treinamento”, “o processo está errado”. Mas ninguém tinha dado real. Ninguém tinha conseguido conectar os pontos.
Eu estava literalmente desperdiçando horas em reunião tentando resolver com opinião o que deveria ser resolvido com informação.
Então eu comecei a pensar: por que a gente trata o sistema Andon só como alarme? E se a gente usasse os dados que ele gera pra entender de verdade os padrões de performance de cada pessoa?
Comecei a extrair dados do Andon e do WMS. Não era pra perseguir ninguém. Era pra ver o que realmente estava acontecendo. Que horas as paradas aconteciam, de que tipo eram, quem estava operando. Cruzei tudo com os KPIs que a gente já media. Tempos de picking, erros de recebimento, taxa de conferência. Tudo integrado.
O que surgiu foi padrões que você nunca vê em reunião. Você vê em dados.
Um colaborador tinha picking excelente, mas produtividade abaixo da média. Ao invés de dizer “você é lento”, olhei os dados e vi que a queda acontecia quando ele separava produtos de uma linha específica. Cinco porquês depois: o layout da área de picking era ruim, forçava muito movimento. Era ergonomia, não falta de foco. Ajustei o layout. Performance normalizou. Ele saiu aliviado.
Outro caso: picking excelente à noite, queda de dia. Cinco porquês: ele tinha muito conhecimento de processos, então ficava resolvendo problemas de outras áreas durante o dia. Quando ajustei o escopo dele, virou top performer.
Em três meses: picking com redução de erro de 1,5% para 0,7%, conferência pegando 98% dos erros antes do cliente.
Mas o melhor ganho foi nas reuniões.
Ao invés de 3 reuniões semanais de uma hora discutindo com suposição, tive uma reunião de 30 minutos com dados. Mostrava o gráfico. Mostrava o problema. Mostrava quem estava fazendo certo. Não tinha espaço pra opinião. Era fato.
E sabe qual é o efeito colateral melhor? As pessoas entenderam que a gente não estava lá pra ferrar com elas. A gente estava lá pra ajudar a melhorar. Porque quando você mostra dados, não é perseguição. É suporte.
Dados não são pra controlar. Dados são pra libertar.
Qual é a operação que você supervisiona onde você tem a mesma reunião três vezes por semana com o mesmo problema? Qual KPI você olha todo dia vendo variação absurda sem entender por quê? Qual dado você está gerando mas não está usando?
O passo que eu dei não foi usar tecnologia nova. Foi usar a tecnologia que já existia de um jeito diferente. A pergunta que mudou tudo foi: que dados eu tenho que ninguém tá olhando?
Se você tem um desafio parecido, me chama.
contato@marcelosantosgomes.com.br
wa.me/5521987612861
Este vídeo é sobre como eu consegui eliminar três dessas reuniões semanais construindo um dashboard que faz o trabalho que a gente tentava fazer em conversas intermináveis. E mais importante: como a gente finalmente entendeu de verdade o que estava acontecendo no chão de fábrica.
Meu nome é Marcelo e na ocasião eu era líder em uma indústria multinacional. E essa história começa em um lugar que a maioria dos especialistas de logística nunca pensa em olhar.
Você conhece o sistema Andon? Provavelmente sim. É aquele sistema de sinalização visual que a gente usa na produção para parar a linha quando tem problema. Originalmente foi criado para enxergar gargalos na manufatura em tempo real. Mas aqui está o ponto: na fábrica, a gente tinha esse sistema rodando já há anos. E ninguém estava usando os dados dele para nada além de contar quantas vezes a linha parou.
Meu trabalho era monitorar performance. Recebimento, armazenagem, picking, conferência, abastecimento da linha de produção, retornos, expedição e transporte. Esses são alguns dos pilares de qualquer operação de supply chain. E o que eu via eram padrões inconsistentes. Um dia o pessoal de picking despacha com taxa de erro de ponto cinco por cento. No dia seguinte, três por cento. A embalagem oscilava. A conferência variava. E quando você marcava a reunião pra tentar resolver, todo mundo vinha com suposições. Ah, aquele funcionário não estava focado. Ah, faltava treinamento. Ah, o processo estava errado. Mas ninguém tinha dado real. Ninguém tinha conseguido conectar os pontos.
Então eu comecei a pensar: por que a gente trata o Andon só como um alarme? E se a gente usasse os dados que ele gera para entender os padrões de performance de cada pessoa?
Aqui é onde a maioria dos gestores param. Eles acham que é invasão de privacidade, ou que é muito complexo, ou que não vale a pena o esforço. Mas eu estava literalmente em minha terceira reunião daquele mês discutindo os mesmos problemas sem nenhuma nova informação. Algo tinha que mudar.
Eu comecei a extrair dados do sistema Andon e dos WMS. Não era pra perseguir ninguém. Era pra ver de verdade o que estava acontecendo. Que horas as paradas aconteciam, de que tipo eram, em qual estação, e mais importante: quem estava operando quando aquilo acontecia. E cruzei tudo isso com os KPIs que a gente já media. Tempos do picking, erros de recebimento, taxa de conferência, velocidade de armazenamento. Tudo integrado.
O que surgiu foi um padrão que você não vê em uma reunião. Você vê em dados.
Tem colaborador que tem performance absolutamente consistente em picking, mas que tem paradas frequentes quando passa pra abastecimento. Outro que despacha rápido demais no início do turno, e aí a conferência fica abarrotada no final do dia. Tem um que trabalha bem, mas tem uma queda significativa de performance entre onze da manhã e uma da tarde. Você não descobre isso em uma reunião. Você descobre quando você tem dados de verdade ao longo de semanas e acompanha a operação de perto.
Eu decidi construir um dashboard. Tabelas de KPI por colaborador, por área, por turno, por dia da semana. Mapas de calor mostrando onde as paradas aconteciam com mais frequência. Gráficos de tendência de cada pessoa ao longo do tempo. Intervalos entre as separações. E mais importante: alertas automáticos quando alguém saía do padrão esperado.
Mas construir o dashboard foi só o começo. O trabalho real foi o que a gente fez com as informações.
Eu peguei cada caso de baixo desempenho que aparecia nos dados e apliquei o método que qualquer profissional de qualidade usa: Ishikawa e cinco porquês. Você conhece Ishikawa? É aquele diagrama de causa e efeito. Você coloca o problema no final, e aí você vai escavando as possíveis causas em diferentes categorias: pessoas, processos, equipamento, materiais, ambiente, método. Não é pra culpar ninguém. É pra entender de verdade.
E os cinco porquês é simples: você pega uma causa e pergunta por quê cinco vezes até você chegar na raiz real.
Um colaborador tinha um bom picking, mas produtividade abaixo da média. Eu poderia ter simplesmente dito a ele “você é lento” — mas preferi olhar o dashboard, que mostrava que a queda acontecia especificamente quando ele separava produtos da linha X. Ao aplicar os cinco porquês, ficou claro: o layout da área de picking era ruim, obrigando-o a andar muito, abrir caixas e usar equipamento para descer material. Era um problema de ergonomia e abastecimento do picking, não de falta de foco. Ajustamos o layout, e a performance dele normalizou.
Outro caso: tem uma pessoa com picking excelente no turno da noite, mas que caia muito de dia. Cinco porquês: ele é um funcionário com muito conhecimento de processos, então ele tinha paradas frequentes pra resolver problemas de outras áreas, o que não acontecia a noite, pois a equipe de Serviços não estava trabalhando. Não era preguiça. Era conflito de responsabilidade. A gente ajustou o escopo dele. Performance estabilizou.
E aí tem o melhor parte: quando você identifica quem está fazendo certo e você consegue replicar.
O dashboard mostrou quem eram os top performers em cada área. E não era só uma pessoa. Cada área tinha gente que performava acima da média. Picking tinha gente que consistentemente despacha com taxa de erro abaixo de ponto dois por cento. Armazenagem tinha gente que nunca saía do padrão de velocidade. Conferência tinha gente que pega noventa e oito por cento dos erros antes de ir pro cliente. Esses dados abriram a porta pra disseminar as melhores práticas de verdade, não as que a gente achava que eram melhores.
Você chama aquele top performer de picking e diz: me mostra como você trabalha. E ele mostra. Mas ele não sabe explicar tudo que ele faz instintivamente. Com os dados, você consegue ser mais específico. Ele segue um padrão particular de leitura do picking list? Ele agrupa itens de uma forma particular? Ele tem uma sequência que ele sempre segue? Quando você sabe o que procurar, você consegue documentar e ensinar.
Em três meses, o desempenho geral da equipe melhorou. Picking teve redução média de erro de um ponto cinco por cento pro ponto sete por cento, com ganho de velocidade sem perda de qualidade. Conferência começou a pegar mais erros porque a gente treinou a equipe em cima do que os top performers faziam.
Mas o ganho maior foi o que aconteceu com as reuniões.
Ao invés de três reuniões semanais de uma hora onde a gente tentava adivinhar o que estava errado, a gente teve uma reunião de trinta minutos. Uma. Por semana. E naquela reunião, a gente tinha dados. Mostrava o gráfico. Mostrava onde estava o problema. Mostrava quem estava fazendo certo. Não tinha espaço pra suposição. Não tinha espaço pra política de departamento. Eram dados.
E sabe qual é o efeito colateral melhor? As pessoas começaram a entender que a gente não estava lá pra ferrar com elas. A gente estava lá pra ajudar elas a melhorar. Porque quando você mostra dados, não é opinião. É fato. E quando você mostra solução baseada em análise real, não é perseguição. É suporte.
Agora, deixa eu ser honesto: isso não foi mágica. Isso foi trabalho. Eu passei semanas estudando como extrair dados do sistema Andon de forma segura. Tive que validar cada métrica com o pessoal de TI pra garantir que a gente tava sendo ético na coleta de dados. Tive que treinar o time pra entender o dashboard, porque não adianta ter informação se ninguém sabe ler.
E tem um aspecto que eu acho que é crucial: a gente não usou isso contra as pessoas. A gente usou pra apoiar as pessoas. Aquele cara que estava com performance ruim? A gente descobriu que ele tinha um problema ergonômico, não um problema de atitude. Ele saiu aliviado quando a gente ajustou a estação.
O cara que estava com performance variando? A gente descobriu que ele estava dividido entre duas funções. Quando a gente desfez aquela divisão, ele virou um dos top performers. Satisfação dele subiu porque ele finalmente conseguia fazer um trabalho bem feito.
Isso é o que eu acho que as pessoas não entendem sobre dados em supply chain. Dados não são pra controlar. Dados são pra libertar. Porque quando você tem informação real, você consegue resolver problemas de verdade em vez de ficar em reunião infinita tendo conversa vaga.
E deixa eu ser claro: isso vale pra você que está assistindo também. Qual é a operação que você está supervisando onde você tem a mesma reunião acontecendo três vezes por semana com o mesmo problema sendo discutido sem solução? Qual é o KPI que você olha todo dia e vê variação absurda sem entender por quê? Qual é o dado que você está gerando mas não está usando?
Eu chutaria que em noventa por cento das operações de supply chain que eu conheço, tem gente medindo coisa que não está usando pra nada além de ficar em reunião. Você tem sistema de picking que registra cada movimento. Você tem sistema de embalagem que registra cada detalhe. Você tem sistema de conferência que registra cada parada. E aí você fica em reunião tentando resolver problema com opinião.
O passo que eu dei não foi usar tecnologia nova. Foi usar a tecnologia que já existia de um jeito diferente. O sistema Andon já tava lá e o WMS. O que mudou foi a pergunta. Em vez de perguntar por quê as reuniões não estavam resolvendo nada, eu perguntei: que dados eu tenho que ninguém tá olhando?
E quando você começa a fazer essa pergunta, você descobre que tem informação sendo gerada que ninguém está aproveitando.
Meu desafio pra você é esse: procura um KPI que você está medindo mas não está usando pra tomar decisão. Qualquer um. Picking, embalagem, conferência, armazenamento, transportes, e outros. Pega aquele KPI e pergunta: se eu tivesse os dados desse KPI detalhados por pessoa, por hora, por situação, o que eu conseguia resolver que eu não tô resolvendo agora?
Provavelmente você consegue resolver mais coisa. E provavelmente você consegue eliminar pelo menos uma reunião que não está sendo útil.
Se você tem um desafio parecido na sua operação, me chama. Eu gosto de ajudar gente que está pensando em dados em supply chain de forma real.
📩 CONTATO E SERVIÇOS
E-mail: contato@marcelosantosgomes.com.br
Site: https://marcelosantosgomes.com.br
Serviços de consultoria: https://marcelosantosgomes.com.br/#servicos
WhatsApp: https://wa.me/5521987612861
Deixe um comentário