Como o Grupo JGV transformou a gestão de estoque com análise preditiva e mais de 118 mil produtos processados diariamente
Voltar

Como o Grupo JGV transformou a gestão de estoque com análise preditiva e mais de 118 mil produtos processados diariamente

Como o Grupo JGV transformou a gestão de estoque com análise preditiva e mais de 118 mil produtos processados diariamente

Um sistema inteligente de recomendação que antecipa a demanda, reduz análises manuais e apoia decisões de compra e transferência entre filiais

O Grupo JGV precisava tornar a gestão de peças mais previsível, eficiente e orientada por dados. Para isso, a AutoU desenvolveu uma plataforma integrada ao ERP Sankhya capaz de analisar o estoque das filiais, prever a demanda dos próximos 30 dias e gerar recomendações automáticas de compra ou transferência para validação dos gestores.

1. O Desafio

O Grupo JGV enfrentava um problema que parecia operacional, mas envolvia uma combinação complexa de dados, previsão de demanda e decisões distribuídas entre diferentes filiais.

A análise de compra e venda de peças dependia de registros históricos disponíveis em notas fiscais, movimentações comerciais e dados do ERP. Embora a empresa possuísse um grande volume de informações, transformá-las em uma recomendação prática exigia análises predominantemente manuais.

Esse cenário gerava quatro dificuldades principais:

- Alto volume de dados: milhares de registros precisavam ser analisados entre vendas, estoque, produtos, pedidos e movimentações das filiais.

- Risco de excesso ou ruptura: sem visibilidade consolidada, uma filial poderia comprar além do necessário enquanto outra ficava sem produtos.

- Baixa consideração da sazonalidade: as análises históricas não capturavam adequadamente variações recorrentes na demanda.

- Tomada de decisão reativa: os pedidos eram orientados principalmente pelo histórico de movimentações, e não por uma previsão do comportamento futuro.

O resultado era um processo demorado, sujeito a distorções e altamente dependente da capacidade individual dos gestores de interpretar grandes volumes de informações.

2. Contexto dos Usuários e da Operação

A solução precisava atender uma operação na qual diferentes atores participam da decisão de reposição de estoque.

O gestor de compras é responsável por revisar as necessidades das filiais, ajustar quantidades e aprovar novos pedidos. Já o gestor de vendas participa da validação das transferências entre unidades, confirmando se determinado estoque pode ser movimentado sem comprometer a operação da filial de origem.

Esses profissionais já possuíam conhecimento comercial e operacional relevante. O problema não era a falta de experiência, mas a quantidade de dados que precisavam analisar diariamente para chegar a uma decisão.

Além disso, produtos similares, pedidos em aberto, movimentações administrativas e diferenças entre filiais adicionavam camadas de complexidade à análise. Uma recomendação baseada apenas no saldo atual poderia indicar uma compra desnecessária, ignorar um pedido já realizado ou deixar de aproveitar um produto disponível em outra unidade.

Por isso, a solução não poderia simplesmente automatizar pedidos. Ela precisava organizar as informações, gerar recomendações explicáveis e manter os gestores no controle das decisões.

3. A Ideia

A lógica central do projeto foi transformar o histórico operacional do Grupo JGV em um sistema contínuo de apoio à decisão.

Se o ERP já armazenava vendas, estoques, produtos, filiais e pedidos, esses dados poderiam ser utilizados para estimar a demanda futura e antecipar situações de falta ou excesso.

A estratégia foi estruturada em três etapas:

1. Prever a demanda futura de cada produto em cada filial.

2. Comparar a previsão com o estoque disponível e os pedidos em aberto.

3. Recomendar a ação mais eficiente antes que o problema acontecesse.

Em vez de sugerir diretamente uma nova compra, o sistema primeiro verifica se outra filial do mesmo grupo possui estoque excedente. Quando a transferência é possível, ela passa a ser priorizada como alternativa à aquisição externa.

A hipótese era simples: ao combinar previsão de demanda, regras operacionais e validação humana, seria possível reduzir o esforço manual sem retirar dos gestores o controle comercial sobre os pedidos.

4. Barreiras e Complexidades

A solução parecia simples: analisar o estoque e indicar o que deveria ser comprado. Na prática, gerar uma recomendação confiável exigia resolver diferentes problemas técnicos e operacionais.

Diferenciar demanda real de movimentação administrativa

Nem toda movimentação registrada no ERP representa consumo real.

Transferências internas, reposições e determinadas operações de compra estavam sendo consideradas pelo modelo como demanda, distorcendo o histórico utilizado na previsão. Foi necessário revisar as regras para que apenas movimentações efetivamente relacionadas ao consumo fossem utilizadas.

Passaram a ser mantidos no cálculo:

- Pedidos de venda;

- Requisições com reserva.

Foram removidos:

- Transferências internas;

- Pedidos e movimentações administrativas de compra;

- Operações que não representavam consumo efetivo do estoque.

Considerar pedidos já realizados

Uma previsão de falta poderia gerar uma nova recomendação mesmo quando já existia um pedido de compra em aberto.

A integração foi evoluída para incorporar pedidos solicitados e ainda não recebidos, evitando duplicidades e tornando o cálculo mais próximo da disponibilidade futura real.

Avaliar transferências entre filiais

Não bastava identificar que outra filial possuía o mesmo produto. A transferência precisava respeitar critérios como:

- Filiais pertencentes ao mesmo grupo empresarial;

- Quantidade mínima configurada para transferência;

- Margem de segurança da filial de origem;

- Disponibilidade suficiente após a movimentação.

Trabalhar com produtos similares e substitutos

Em alguns casos, o produto originalmente recomendado poderia ser substituído por outro item oficial já disponível.

Para isso, a solução precisou consultar a relação de produtos substitutos cadastrada no Sankhya, verificar estoque, custo, elegibilidade e restrições comerciais antes de gerar uma sugestão alternativa.

Preservar governança e explicabilidade

Apesar da automação, a decisão final não poderia ser completamente autônoma. Uma recomendação tecnicamente válida poderia não considerar campanhas comerciais, negociações em andamento ou particularidades locais.

Por isso, todas as recomendações permanecem sujeitas à validação humana antes da criação definitiva do pedido no ERP.

5. A Solução

A AutoU desenvolveu uma plataforma de otimização de estoque integrada ao Sankhya, combinando previsão de séries temporais, regras de negócio e um portal web para tomada de decisão.

Todos os dias, o sistema consulta os dados atualizados da operação e analisa cada combinação de produto e filial. O modelo prevê a demanda para os próximos 30 dias e compara o consumo esperado com o estoque atual, os pedidos em aberto, a margem de segurança e as configurações definidas pela empresa.

Quando identifica risco de falta, o sistema segue uma lógica de priorização:

1. Verifica se existe estoque excedente em outra filial do mesmo grupo;

2. Caso exista, gera uma recomendação de transferência;

3. Caso não exista, avalia produtos similares ou substitutos elegíveis;

4. Se nenhuma alternativa estiver disponível, gera uma recomendação de compra.

As sugestões são apresentadas no portal para que os gestores possam aprovar, rejeitar, zerar ou editar as quantidades.

Somente as recomendações aprovadas seguem para o Sankhya, onde o pedido continua submetido ao processo de aprovação já utilizado pelo Grupo JGV.

6. Funcionamento Técnico

A solução opera por meio de um processamento automatizado executado todas as noites.

1. Extração dos dados

O sistema consome informações do Sankhya por meio de APIs e consultas SQL customizadas, incluindo:

- Histórico de vendas;

- Estoque atual de cada filial;

- Produtos ativos;

- Empresas e grupos empresariais;

- Pedidos em aberto;

- Movimentações de estoque;

- Produtos similares e substitutos;

- Atributos e classificações comerciais.

2. Preparação da série histórica

As movimentações são filtradas para remover operações internas e administrativas que não representam consumo real.

A revisão passou a preservar pedidos de venda e requisições com reserva, eliminando transferências internas e outras movimentações que distorciam a demanda.

3. Previsão de demanda

Para cada produto e filial, o Prophet analisa a série temporal dos últimos anos, considerando:

- Tendência;

- Recorrência histórica;

- Variações sazonais;

- Padrões de crescimento ou queda.

O modelo gera uma previsão de consumo para os 30 dias seguintes, utilizada como referência para o cálculo da quantidade necessária.

4. Aplicação das regras de recomendação

A previsão é combinada com regras determinísticas de negócio.

O sistema considera, entre outros fatores:

- Estoque disponível;

- Demanda prevista;

- Pedidos de compra em aberto;

- Lead time;

- Margem de segurança;

- Quantidade mínima para transferência;

- Estoque excedente em outras filiais;

- Produtos congelados ou inelegíveis;

- Disponibilidade de similares e substitutos;

- Marcas habilitadas para análise.

5. Armazenamento e apresentação

As recomendações são registradas no banco da aplicação com status de pendência e apresentadas no portal web.

O histórico é organizado por data para permitir rastreabilidade das recomendações, alterações e decisões tomadas pelos gestores.

6. Integração de saída

Após a aprovação:

- Recomendações de compra geram pedidos no Sankhya;

- Recomendações de transferência são encaminhadas para validação operacional;

- Falhas de integração permanecem sinalizadas para acompanhamento, evitando a perda da recomendação.

7. Experiência do Usuário

A interface foi projetada para reduzir o tempo necessário para revisar um grande volume de recomendações.

Em vez de analisar manualmente diferentes relatórios e consultas no ERP, o gestor acessa uma listagem consolidada com os produtos que exigem alguma decisão.

Para cada recomendação, ele pode:

- Aprovar a quantidade sugerida;

- Alterar a quantidade;

- Rejeitar a recomendação;

- Zerar o item;

- Consultar estoque e previsão;

- Identificar a filial de origem ou destino;

- Visualizar alternativas de transferência;

- Avaliar produtos similares ou substitutos;

- Acompanhar o histórico das recomendações.

A edição das quantidades pode ser feita diretamente na tela de recomendação, com validações automáticas de valor e estoque.

Também foram incluídas ações rápidas para rejeitar ou zerar produtos sem a necessidade de abrir individualmente o detalhe de cada item. Esse ajuste reduziu a fricção especialmente nos momentos de revisão de grandes pedidos.

O dashboard complementa a jornada ao permitir o acompanhamento de:

- Estoque por filial;

- Histórico de previsões;

- Recomendações anteriores;

- Produtos em excesso;

- Itens congelados;

- Pedidos e movimentações geradas.

A preocupação central da experiência foi transformar uma análise operacional complexa em uma sequência clara de decisões, sem ocultar dos gestores as informações que fundamentaram cada recomendação.

8. Principais Evoluções Entregues

O projeto evoluiu ao longo de 6 sprints de desenvolvimento, contemplando melhorias tanto no algoritmo quanto na plataforma.

Entre as principais entregas estão:

Inclusão de pedidos em aberto

Pedidos já realizados e ainda não recebidos passaram a ser considerados no cálculo, reduzindo recomendações duplicadas e compras desnecessárias.

Revisão do cálculo preditivo

O histórico utilizado pelo Prophet foi ajustado para considerar apenas movimentações relacionadas ao consumo real.

Transferência condicional entre filiais

Antes de recomendar uma compra externa, o sistema verifica se existe estoque excedente em outra filial do mesmo grupo.

Substituição automática de produtos

Quando uma compra é sugerida, a solução consulta os substitutos oficiais cadastrados no Sankhya e avalia alternativas disponíveis.

A recomendação de substituto respeita critérios como:

- Estoque maior que zero;

- Custo cadastrado na filial;

- Elegibilidade operacional;

- Ausência de congelamento.

Integração de atributos com o Sankhya

Novos atributos comerciais e operacionais passaram a ser consumidos diretamente do ERP, melhorando a governança das regras.

Filtro de marcas

O gestor pode selecionar quais marcas devem ser analisadas pelo algoritmo e incluídas na geração de recomendações.

Edição direta de quantidades

As quantidades podem ser ajustadas diretamente na listagem, com validações automáticas para preservar a integridade da recomendação.

Ações rápidas de rejeição e zeragem

O usuário pode rejeitar ou zerar um produto sem acessar sua página de detalhes.

Cálculo com data variável

A quantidade sugerida pode ser recalculada conforme o horizonte de tempo selecionado pelo gestor no momento da geração da recomendação.

Organização do histórico

As recomendações passaram a ser estruturadas por data, facilitando auditoria, comparação e acompanhamento das decisões.

Migração para infraestrutura interna

Os ambientes da solução foram migrados para a infraestrutura interna, ampliando o controle sobre operação, dados e sustentação do sistema.

9. Resultados

A plataforma transformou uma análise fragmentada e predominantemente manual em um processo automatizado, recorrente e orientado por previsão.

Entre os principais resultados reportados estão:

- Mais de 118 mil produtos processados automaticamente por dia;

- Aproximadamente 80% de aprovação das recomendações geradas;

- Tempo de processamento inferior a 5 segundos por produto;

- Cerca de 9.700 horas economizadas em atividades de análise.

Além da redução do esforço operacional, a solução passou a antecipar riscos de ruptura, identificar excessos e direcionar o uso do estoque disponível em outras filiais antes da realização de uma nova compra.

O sistema também criou uma camada estruturada de governança sobre as decisões. Cada recomendação possui origem, regras aplicadas, status, alterações e decisão final registradas, permitindo rastreabilidade do processo.

10. Aprendizados

Um dos principais aprendizados do projeto foi que a qualidade da previsão depende menos da complexidade isolada do modelo e mais da qualidade da definição do que representa demanda real.

Inicialmente, diferentes movimentações administrativas eram interpretadas como consumo. Isso fazia com que transferências internas, reposições e outras operações aumentassem artificialmente a série histórica. Ao revisar as regras e manter apenas pedidos de venda e requisições com reserva, as recomendações passaram a refletir melhor o comportamento efetivo de compra dos clientes.

Outro aprendizado foi que prever uma possível falta não é suficiente. Uma boa recomendação precisa considerar o contexto operacional completo.

Neste projeto, isso significou incorporar:

- Pedidos ainda não recebidos;

- Estoque excedente em outras filiais;

- Relações entre grupos empresariais;

- Margens de segurança;

- Produtos similares;

- Produtos congelados;

- Restrições de custo e disponibilidade.

A solução também mostrou que automação e validação humana não são abordagens opostas. O algoritmo reduziu drasticamente o volume de informação que os gestores precisam analisar, enquanto a etapa de aprovação preservou o conhecimento comercial e as exceções que não estão representadas nos dados.

Por fim, o projeto evidenciou uma limitação importante para as próximas evoluções: transferir um produto nem sempre é economicamente melhor do que comprá-lo. A versão atual prioriza disponibilidade e simplicidade operacional, mas uma evolução futura poderá comparar custos de aquisição, logística e transferência antes de indicar a melhor alternativa.

O resultado é uma plataforma que não apenas automatiza uma tarefa manual, mas transforma dados operacionais dispersos em decisões diárias mais rápidas, rastreáveis e antecipatórias.

Voltar