Fracionamento de pedidos e compras emergenciais: detectar e evitar

Publicado em Atualizado em 10 min de leituraPor Alex Meincheim, CEO & Co-founder, UpFlux

Como evitar fracionamento de pedidos e compras emergenciais: as regras para detectar os dois desvios nos dados do Protheus e do SAP, como corrigir a causa na origem e por que negociar a cauda tira o incentivo de fracionar.

Para evitar fracionamento de pedidos e compras emergenciais, a empresa precisa de duas coisas ao mesmo tempo: regras que detectem os dois desvios nos dados do próprio ERP, pedido a pedido, e uma correção na origem que tire o motivo de quem fraciona ou compra às pressas. A detecção mostra onde agir; a correção na origem e a execução sobre a cauda fazem o número cair, e a mesma medição confirma que caiu.

O motivo quase sempre é o mesmo: cotar e aprovar demoram, e o requisitante encontra o atalho. Quando cada pedido pequeno passa a ser negociado em minutos, o atalho deixa de compensar. Numa multinacional industrial, R$ 22 milhões processados na cauda devolveram R$ 1,6 milhão ao caixa, sem contratação nova (resultados), mais de 6% de saving sobre a base, justamente no tipo de gasto em que o fracionamento costuma se esconder.

A seguir: o que são os dois desvios, as regras de detecção com os dados do ERP que cada uma usa, como corrigir a causa e onde a IA entra. Para o tema dentro da operação de compras, veja inteligência de compras.

O que é fracionamento de pedidos

Fracionamento de pedidos é dividir uma necessidade única em várias compras menores para que cada uma fique abaixo de um limite: a alçada de aprovação, a exigência de cotação com três fornecedores ou o valor a partir do qual a compra precisa passar por contrato.

Nem todo pedido repetido é fracionamento. Uma obra que consome cimento toda semana gera pedidos parecidos por natureza. O que caracteriza o desvio é a combinação de três sinais: soma acima do limite, intervalo curto e ausência de motivo operacional para a divisão. Na empresa privada, a régua é a política de compras e a alçada configurada no ERP.

O que é compra emergencial

Compra emergencial é a compra feita sem o planejamento e sem a concorrência que a política prevê, porque a necessidade apareceu tarde. O requisitante pede para amanhã um item com lead time de dez dias, e o comprador aceita o primeiro preço disponível.

Existe emergência legítima: quebra de equipamento crítico, exigência regulatória, acidente. O problema começa quando ela vira rotina de uma área ou de uma família de itens, um processo paralelo sem cotação e sem alçada efetiva. Os dois desvios andam juntos: quem compra com pressa tende a fracionar para não esperar a aprovação do nível de cima.

Por que fracionamento e compra emergencial custam caro

Não há estatística pública confiável sobre quanto o fracionamento custa em média no Brasil. O custo aparece em três frentes que você pode medir na sua própria base.

  • Preço. Pedido pequeno, sem cotação e com prazo apertado, sai no preço de balcão. A diferença aparece quando se compara o preço pago com o menor preço que a empresa já pagou pelo mesmo item.
  • Risco de compliance. Fracionar é contornar um controle. A alçada existe para que alguém com responsabilidade olhe a compra; quatro pedidos de R$ 4.900 não passam por esse olhar. Pedido emitido depois da nota fiscal significa compromisso assumido fora do sistema. Em casos extremos, os dois escondem conflito de interesse entre requisitante e fornecedor.
  • Perda de poder de negociação. Dez pedidos de R$ 4.000 dão ao fornecedor dez vendas pequenas. Um pedido de R$ 40.000, ou um contrato anual, dá à empresa volume para negociar preço, prazo de pagamento e frete.

Como detectar fracionamento e compra emergencial nos dados do ERP

Os dois desvios deixam rastro no ERP. Não é preciso instalar nada para encontrá-los: um export de doze meses de solicitações, pedidos, liberações e notas de entrada basta. Colocar esses eventos em sequência por documento, como faz o process mining, mostra o caminho real de cada compra e é a base sobre a qual as regras abaixo rodam. Os campos citados são os padrões do Protheus e do SAP ECC/S/4HANA; ambientes customizados podem ter nomes diferentes, então confirme com o time de TI antes de rodar.

Regra de detecção O que indica Dados usados
Mesmo fornecedor + mesmo item ou família + janela de N dias + soma acima da alçada, com cada pedido abaixo dela Fracionamento para fugir da aprovação Fornecedor, item, família, data e valor dos pedidos
Concentração de pedidos logo abaixo do limite (por exemplo, entre 90% e 100% da alçada) Valores ajustados para caber na faixa Valor dos pedidos comparado às faixas de aprovação
Mesmo solicitante abrindo várias requisições do mesmo item em poucos dias Fracionamento já na origem Solicitante, item e data das requisições
Prazo pedido na requisição menor que o lead time padrão do item Compra emergencial por falta de planejamento Data de necessidade da requisição comparada ao prazo de entrega cadastrado do item
Pedido com data de emissão posterior à nota fiscal Compra feita fora do sistema e regularizada depois Data do pedido comparada à data da nota de entrada
Pedido sem solicitação ou sem cotação vinculada, acima do valor que exigiria cotação Concorrência pulada Vínculo do pedido com requisição, cotação ou contrato
Aprovações em bloco, dezenas no mesmo minuto pelo mesmo aprovador Alçada que virou formalidade Data e hora das liberações por aprovador
Taxa de pedidos urgentes por centro de custo ou família muito acima da média Emergência como rotina, não como exceção Centro de custo e família dos pedidos marcados como urgentes

Dois cuidados evitam alerta demais. Agrupe por família, não só por código: quem fraciona às vezes troca a referência do item, e cadastros antigos têm grupos genéricos. Separe o padrão do caso: um par de pedidos suspeito pode ter explicação, vinte ocorrências do mesmo solicitante com o mesmo fornecedor num semestre formam um padrão. O relatório útil é por solicitante, centro de custo, fornecedor e família, com a janela calibrada pelo ciclo de consumo de cada família.

Se a alçada do seu Protheus ainda não foi revista, comece por ela: o artigo sobre alçada de aprovação de compras no Protheus mostra onde ela é configurada e como medir o tempo de aprovação pelo registro de liberações.

Exemplo ilustrativo de detecção

Exemplo ilustrativo, com números hipotéticos.

Uma indústria tem alçada de nível 1 até R$ 5.000 e exige três cotações acima desse valor. A manutenção precisa repor rolamentos para uma parada programada. Em seis dias, o mesmo solicitante abre quatro requisições, que viram quatro pedidos ao mesmo distribuidor.

Pedido Dia Família Valor
1 Segunda Rolamentos R$ 4.800
2 Quarta Rolamentos R$ 4.900
3 Quinta Rolamentos R$ 4.750
4 Sábado Rolamentos R$ 4.950
Soma 6 dias R$ 19.400

A regra de fracionamento dispara: mesmo fornecedor, mesma família, janela de sete dias, cada pedido abaixo de R$ 5.000 e soma quatro vezes acima da alçada. A regra de concentração também dispara, porque os quatro valores estão entre 95% e 99% do limite. E a regra de emergência dispara na terceira requisição, que pedia entrega em dois dias para um item com lead time cadastrado de dez.

A parada era programada, então a necessidade era conhecida semanas antes. A causa provável é a falta de um gatilho de planejamento ligado ao calendário de manutenção, somada a uma cotação mais lenta do que a parada podia esperar. Contra o menor preço pago nos rolamentos nos últimos doze meses, os quatro pedidos saíram mais caros.

Como evitar fracionamento e compras emergenciais na origem

As medidas abaixo mudam o que leva as pessoas ao atalho e funcionam melhor combinadas.

Planejamento ligado à demanda real. Compra emergencial recorrente quase sempre é necessidade previsível que ninguém antecipou: parada de manutenção, sazonalidade, consumo de material de uso contínuo. Ligar a requisição ao calendário de manutenção ou ao ponto de pedido do estoque reduz a urgência fabricada.

Contratos guarda-chuva para o que se repete. Se a mesma família é comprada do mesmo fornecedor todo mês, ela pede um contrato com preço e condições fixados por período. O pedido passa a ser uma chamada contra o contrato, sem cotação a cada vez e sem motivo para fracionar. No Protheus, isso costuma ser feito com autorização de entrega ou contrato de parceria; no SAP, com contrato básico ou programa de remessas.

Alçada por família, não só por valor. Uma alçada única para tudo faz o gestor aprovar cem pedidos de material de escritório para olhar dois de matéria-prima. Faixas por família e por criticidade colocam o controle onde há risco e liberam o resto.

Aprovação por exceção. Em vez de exigir aprovação de tudo acima de um valor, defina regras: preço dentro de uma tolerância sobre o histórico, fornecedor homologado, prazo compatível com o lead time. O que cumpre a regra segue; o que sai dela vai a um aprovador com o motivo descrito, e a fila curta faz quem aprova olhar de verdade.

Fluxo formal para a emergência legítima. Proibir a compra urgente não funciona; ela acontece por fora. Um fluxo de emergência com justificativa obrigatória, aprovação rápida e revisão posterior transforma a exceção em dado. Mostrar a cada área, todo mês, quantos pedidos dela caíram nas regras e quanto custaram a mais muda comportamento mais rápido que uma nova circular.

Onde a IA ajuda: detectar e tirar o incentivo de fracionar

A IA ajuda em duas frentes que se completam: a leitura dos dados do processo, que mostra onde o desvio acontece, e a execução, que age sobre ele.

Detectar melhor. Sobre a base de eventos do processo, um modelo de linguagem classifica itens por família a partir da descrição, lê a justificativa escrita na requisição para separar emergência real de urgência de planejamento e agrupa casos por padrão, de modo que o gestor receba dez padrões em vez de quinhentos alertas.

Tirar o motivo. O fracionamento existe porque cotar e aprovar um pedido pequeno custa mais tempo do que o pedido vale. Quando um time digital de compras, com agentes de IA operados por especialistas, cota e negocia cada pedido da cauda dentro do ERP, com o histórico de preço do item como âncora, o pedido de R$ 4.900 passa a ter cotação e negociação no mesmo dia. Fracionar para fugir da cotação deixa de poupar tempo, e o pedido que saía no preço de balcão passa a sair no preço negociado.

Na UpFlux, a régua é declarada antes: o saving é a menor proposta válida da primeira tomada de preço menos o valor comprado, e o histórico de preço do item funciona como âncora da negociação e trava do resultado. O ganho é apurado pedido a pedido e reconciliado com o lançamento no ERP. Para dimensionar essa cauda, veja tail spend.

Perguntas frequentes

Como evitar fracionamento de pedidos e compras emergenciais?

Combinando detecção e correção na origem. Na detecção, rode regras sobre os dados do ERP: mesmo fornecedor e mesma família em janela curta com soma acima da alçada, prazo pedido menor que o lead time do item e pedido emitido depois da nota fiscal. Na origem, ligue a requisição ao planejamento, crie contratos guarda-chuva para o que se repete, defina alçada por família, aprove por exceção e dê à emergência legítima um fluxo próprio. E torne a cotação da cauda rápida, para que fracionar deixe de compensar.

Qual a diferença entre fracionamento de pedidos e compra emergencial?

Fracionamento é dividir uma necessidade em pedidos menores para ficar abaixo da alçada ou da exigência de cotação. Compra emergencial é comprar sem planejamento e sem concorrência porque a necessidade apareceu tarde. São desvios diferentes, mas costumam aparecer juntos: quem compra com pressa tende a fracionar para não esperar a aprovação do nível de cima.

Todo pedido repetido para o mesmo fornecedor é fracionamento?

Não. Consumo recorrente, como material de uso contínuo ou serviço mensal, gera pedidos parecidos por natureza. O fracionamento se caracteriza pela soma acima do limite em intervalo curto e por valores concentrados logo abaixo da alçada. Quando o recorrente é legítimo, a solução é um contrato guarda-chuva, que acaba com os pedidos avulsos.

Quais dados do ERP são necessários para detectar fracionamento?

Doze meses de pedidos de compra (fornecedor, item, data e valor), de requisições (solicitante e data de necessidade), do cadastro de itens (família e prazo de entrega), das notas de entrada (para comparar a data da nota com a do pedido) e do registro de liberações da alçada. Tudo isso já existe no Protheus, no Datasul e no SAP, e sai num export simples.

A IA consegue impedir o fracionamento?

Ela detecta melhor, classificando itens por família pela descrição e agrupando alertas em padrões sobre os dados do processo. E tira o incentivo: quando os pedidos da cauda são cotados e negociados no mesmo dia por agentes dentro do ERP, fracionar para fugir da cotação deixa de poupar tempo. A emergência legítima continua precisando de fluxo próprio e de aprovação humana.

Próximo passo

Na primeira medição, os dois desvios costumam se concentrar em poucas áreas e famílias. Para ver como a UpFlux mede esses desvios e negocia a cauda dentro do Protheus, do Datasul ou do SAP, conheça a inteligência de compras e a visão geral da operação em compras.

Onde isto vira operação

Leia também