Um dashboard de BI de estoque mostra onde o nível está baixo: saldo atual, cobertura em dias, SKUs abaixo do mínimo. Isso é visibilidade, não decisão. A ruptura nasce de uma cadeia de decisões anteriores ao momento em que o painel acende vermelho, o parâmetro de reposição, o lead time real do fornecedor, o ponto de pedido, a revisão periódica do plano. Um dashboard sem essa cadeia de decisão anexada funciona como retrovisor: mostra com exatidão o que já degradou, não o que fazer antes da degradação.
O que o painel mostra, e o que deixa para alguém decidir
Um dashboard de BI de estoque cumpre uma função específica e a cumpre bem: lê o ERP, agrega saldo por SKU e por localização, calcula cobertura em dias sobre a demanda projetada, e ordena por criticidade para que a exceção mais grave apareça primeiro. É uma função de leitura. Bem construída, ela é rápida, atualizada e confiável. O problema não está na leitura. Está no que acontece, ou deixa de acontecer, depois que o número aparece na tela.
O painel não recalcula o parâmetro de reposição quando o padrão de demanda de um SKU muda de patamar. Não verifica se o lead time cadastrado do fornecedor ainda corresponde ao lead time real, medido pelo tempo entre o pedido emitido e a entrega confirmada. Não revisa o ponto de pedido quando a variabilidade da demanda aumenta. Não dispara uma ordem de compra. Cada uma dessas ações é uma decisão, e decisão exige um agente: uma pessoa com autoridade e rotina para revisar a exceção, ou um sistema com lógica de decisão embutida, não apenas lógica de exibição, configurado para agir dentro de limites definidos.
Essa distinção costuma passar despercebida porque, no dia a dia, o dashboard "funciona": carrega rápido, atualiza no horário certo, exporta o número que o comitê pede. A sensação de que a ferramenta está cumprindo seu papel é real e ao mesmo tempo irrelevante para a pergunta que importa, que é o que aconteceu com o SKU sinalizado há três semanas. Se a resposta é "ninguém sabe", a falha não está no painel. Está no elo seguinte, o que estrutura o resto deste artigo.
A cadeia de decisões entre o dado e a ruptura
Entre o momento em que o dashboard exibe um saldo baixo e o momento em que a ruptura acontece de fato, existem quatro decisões específicas. Nenhuma delas é automática só porque o dado está visível.
Parâmetro de reposição
É a regra que define quanto e quando repor cada combinação de SKU e local: estoque mínimo, lote de compra, frequência de revisão. Esse parâmetro é calibrado sobre um padrão de demanda observado num momento específico. Quando a demanda muda de patamar, sazonalidade nova, mudança de canal, descontinuação de um concorrente, o parâmetro antigo continua rodando até alguém revisá-lo. O dashboard mostra o efeito da defasagem. Não mostra que o parâmetro está desatualizado.
Lead time real do fornecedor
O cadastro traz o lead time contratual. A operação vive o lead time real, medido do pedido emitido até a entrega confirmada no armazém, que costuma divergir do contratual e variar por época do ano, por rota e por fornecedor específico. Se ninguém atualiza esse número no sistema, cada cálculo posterior, cobertura, ponto de pedido, herda o erro. O painel exibe a conta certa sobre uma premissa errada.
Ponto de pedido
É o nível de estoque que deveria disparar um novo pedido: a demanda esperada durante o lead time, somada ao estoque de segurança que absorve a variabilidade. Os dois insumos dessa conta, demanda e lead time, mudam ao longo do tempo. Se o ponto de pedido não é recalculado com a mesma frequência, o gatilho dispara tarde, mesmo que o dashboard esteja perfeitamente atualizado no instante em que alguém olha para ele.
Revisão periódica do plano
É a cadência, semanal, quinzenal, o que a operação suportar, em que alguém olha para as exceções sinalizadas e decide o que fazer com cada uma antes da próxima rodada. Sem essa cadência definida, com dono e prazo, a exceção fica no painel esperando que alguém a note por conta própria. Entre uma rodada e a próxima, o intervalo é exatamente onde a ruptura acontece.
Visibilidade e decisão lado a lado
Separar o que um dashboard entrega do que fica pendente de decisão ajuda a diagnosticar onde uma operação específica está travando. A tabela abaixo compara as duas colunas para os mesmos quatro pontos.
| Ponto da cadeia | O que o dashboard mostra | O que exige decisão |
|---|---|---|
| Nível de estoque | Saldo atual e cobertura em dias | Se o parâmetro de reposição ainda reflete a demanda atual |
| Prazo de entrega | Cobertura calculada sobre o lead time cadastrado | Se o lead time cadastrado bate com o lead time real medido |
| Gatilho de reposição | SKU sinalizado abaixo do mínimo | Se o ponto de pedido precisa ser recalculado |
| Exceção pendente | Lista de SKUs em risco, ordenada por criticidade | Quem é o dono da exceção e até quando ela precisa ser tratada |
| Ruptura passada | Histórico de rupturas já ocorridas | Se existe revisão agendada para tratar o padrão antes da próxima |
A coluna da esquerda é o que qualquer ferramenta de BI competente entrega por padrão. A coluna da direita é onde a maioria das implementações para: o investimento vai inteiro para melhorar a leitura, mais SKUs cobertos, mais frequência de atualização, mais filtros, e nenhum recurso sobra para fechar o loop de decisão do outro lado.
Onde o mecanismo se repete entre setores, e onde muda de forma
Os quatro pontos da cadeia, parâmetro de reposição, lead time real, ponto de pedido, revisão do plano, não são específicos de um setor. Aparecem em qualquer operação que carregue estoque físico. O que muda de um contexto para outro é onde a fricção se concentra, e essa comparação só é possível para quem já operou dos dois lados.
Na gestão de planejamento logístico do Grupo Panvel, varejo farmacêutico, a operação envolvia centros de distribuição em três estados, abastecendo cerca de 600 filiais e 8.000 clientes por dia. A fricção ali se concentra na malha de distribuição: o mesmo SKU tem parâmetro de reposição diferente por loja, porque o padrão de demanda de uma filial de bairro não é o de uma filial de rodovia. Revisar o parâmetro exige granularidade por ponto de venda, não uma média de rede.
Em passagens pela indústria farmacêutica, na Hypera/Brainfarma e na Eurofarma, a mesma cadeia de decisões existe, mas a fricção se desloca para a capacidade de produção. O lead time real não depende só do fornecedor de matéria-prima, depende do tempo de changeover entre lotes na própria fábrica e da sequência de produção definida semanas antes. O ponto de pedido de um insumo crítico precisa considerar essa fila interna, não apenas o trânsito externo. E há uma camada adicional que o varejo não tem: limites regulatórios de estoque máximo e mínimo para produtos controlados, que restringem o intervalo dentro do qual qualquer parâmetro pode ser ajustado.
Na cosmética, com a Natura, a fricção típica vem do calendário de campanhas comerciais. A demanda de um SKU dispara em janelas previsíveis, mas com volume que varia por ciclo e por região de um jeito que um parâmetro de reposição estático não absorve. Ali, a revisão do plano não pode seguir uma cadência genérica de "toda segunda-feira", precisa estar amarrada ao calendário comercial, porque tratar a demanda de campanha como se fosse consumo recorrente distorce o ponto de pedido do ciclo seguinte inteiro.
atribuída ao método
ciclo de S&OP
Resultados documentados durante a gestão de Andrea Marchtein como Gerente de Planejamento Logístico do Grupo Panvel. Histórico da gestão, atribuído ao fechamento do loop de decisão descrito neste artigo, não uma projeção de resultado para qualquer operação nova.
O detalhe relevante sobre esses dois números é a origem: não vieram de um dashboard mais bonito ou de mais dados disponíveis. Vieram da mesma cadeia descrita acima, revisada com disciplina, parâmetro de reposição recalibrado por criticidade e por ponto de venda, lead time real monitorado por fornecedor, ponto de pedido recalculado com a frequência que a variabilidade exigia, e uma cadência de revisão do plano com dono definido para cada exceção. O mecanismo de como reduzir ruptura sem inflar o estoque médio no processo, um resultado que costuma soar contraditório até se ver a lógica por trás, está descrito com mais profundidade em outro artigo deste blog sobre reduzir ruptura de estoque sem aumentar o estoque médio.
"Painel que aponta ruptura sem alguém, ou alguma lógica de decisão, agindo sobre o dado antes do vermelho é retrovisor: preciso e tardio."
Fechar o loop não depende de mais telas
A reação mais comum quando uma operação percebe essa lacuna é pedir mais dashboard: mais SKUs cobertos, mais atualização em tempo real, mais alertas. Isso resolve um sintoma adjacente, atraso na leitura, e não toca no problema descrito aqui, que é a ausência de decisão anexada ao dado. Duplicar a qualidade da visibilidade sobre uma cadeia de decisão que já não funciona só entrega o mesmo diagnóstico tardio com mais detalhe visual.
O que de fato fecha o loop é diferente e, na prática, menos vistoso: um dono nomeado para cada tipo de exceção, um parâmetro de reposição com data de próxima revisão marcada, um processo de verificação do lead time real contra o cadastrado, e uma cadência de revisão do plano que trate a exceção antes que ela se torne ruptura visível. Isso pode ser executado por uma pessoa com rotina definida, por uma equipe pequena com escopo claro, ou por um sistema com lógica de decisão embutida, capaz de recalcular parâmetros e sinalizar ação dentro de limites configurados, não apenas de exibir o estado atual. A diferença entre as duas últimas opções está em capacidade de execução, não em princípio: em qualquer dos dois casos, o requisito é o mesmo loop.
Não é correto descrever essa lacuna como "falta de inteligência artificial". É mais preciso descrevê-la como uma lacuna entre visibilidade e ação. Um sistema pode integrar inteligência artificial e ainda assim não fechar esse loop, se a lógica embutida se limitar a prever ou classificar sem estar conectada a uma ação concreta com dono e prazo. A forma como essa integração é estruturada dentro do ERP, e onde ela de fato passa a decidir em vez de só exibir, está detalhada em outro artigo deste blog sobre como integrar IA ao ERP. Quando a própria cadência de revisão do plano é automatizada, o mecanismo correspondente está descrito em outro artigo deste blog sobre S&OP automatizado.
Perguntas frequentes
Porque o dashboard cumpre uma função de leitura: agrega dados do ERP, calcula cobertura em dias e sinaliza quando um SKU cruza um limite. Ele não recalcula o parâmetro de reposição, não verifica se o lead time cadastrado do fornecedor ainda bate com o lead time real, não revisa o ponto de pedido e não aciona uma reposição. Essas são decisões. Sem alguém, ou alguma lógica de decisão, agindo sobre o dado antes de ele virar ruptura, o painel só documenta o problema depois que ele já aconteceu.
Visibilidade é saber o estado atual: saldo, cobertura, SKUs abaixo do mínimo. Decisão de reposição é agir sobre esse estado antes que ele se deteriore: ajustar o parâmetro de reposição quando o padrão de demanda muda, corrigir o lead time cadastrado quando ele diverge do real, recalcular o ponto de pedido, e revisar o plano com uma cadência que trate a exceção antes da próxima ruptura. Um dashboard entrega a primeira parte. A segunda depende de um processo ou sistema com lógica de decisão anexado a ele.
Um loop de decisão: um dono nomeado para cada exceção sinalizada, um parâmetro de reposição que é revisado quando a demanda muda de padrão, um lead time do fornecedor monitorado contra o real, não o contratual, e uma cadência de revisão do plano que trate as exceções antes que virem ruptura visível. Esse loop pode ser executado por uma pessoa com rotina definida ou por um sistema com lógica de decisão, não apenas de exibição, mas sem ele o dashboard funciona como retrovisor.
Sim. O ponto de pedido é calculado sobre a demanda esperada durante o lead time mais o estoque de segurança. Se o lead time real do fornecedor mudou e o cadastro não foi atualizado, ou se o padrão de demanda mudou e o parâmetro não foi revisado, o gatilho de reposição dispara tarde, mesmo que o dashboard esteja exibindo o número certo com precisão perfeita. O painel não erra a leitura. O erro está no parâmetro que ninguém revisou.
O mecanismo, parâmetro de reposição, lead time real, ponto de pedido, revisão do plano, se repete em setores diferentes. O que muda é onde a fricção se concentra: na malha de distribuição por loja do varejo farmacêutico, na capacidade de produção e no changeover entre lotes da indústria farmacêutica, ou no ciclo de campanhas comerciais da cosmética. A pergunta que fecha o loop é a mesma em qualquer um desses contextos. A resposta muda de lugar conforme a estrutura da operação.
Um dashboard bem construído continua sendo pré-requisito, não é o argumento deste artigo contra a ferramenta. O ponto é que ele resolve a metade errada do problema quando fica sozinho. A metade que reduz ruptura é a cadeia de decisões anexada ao dado, com dono, com parâmetro revisado e com cadência definida. Mais análises sobre esse tipo de mecanismo operacional estão reunidas no blog da Think Process.