Onde projetos de otimização realmente falham: solver não é estratégia

Um projeto de otimização entra em operação e, alguns meses depois, os planejadores continuam fechando o plano na planilha. Quando alguém pergunta o que deu errado, uma das primeiras respostas costuma ser técnica: o modelo demora para rodar, o servidor é fraco, talvez seja hora de um solver mais potente ou de mais capacidade na nuvem.

Às vezes é isso. Com frequência, não é. Os projetos de otimização que não geram resultado raramente falham no cálculo. Falham antes dele, nos dados e na formulação do problema, ou depois dele, quando o plano precisa virar decisão e ser adotado por quem opera. Comprar mais processamento acelera a parte que já funcionava.

Este artigo percorre as cinco camadas de um projeto de otimização (dado, modelo, solver, decisão e adoção), mostra onde cada uma costuma falhar e ajuda a identificar quando mais capacidade de cálculo de fato resolve.

Projetos de otimização: o solver deixou de ser o diferencial

O solver é o algoritmo que procura a melhor solução para o problema descrito pelo modelo matemático: quanto produzir em cada fábrica, de onde abastecer cada cliente, o que colocar em cada carga. É a peça mais técnica do projeto e, por isso, a que mais chama atenção.

Nas últimas duas décadas, essa peça evoluiu muito. Um estudo publicado em 2022 no EURO Journal on Computational Optimization comparou solvers do início dos anos 2000 com versões recentes. Entre 2001 e 2020, a resolução de problemas de programação inteira mista ficou cerca de mil vezes mais rápida: aproximadamente 20 vezes por causa do hardware e 50 vezes por causa dos algoritmos (Koch et al., 2022). Os autores ressaltam que o ganho varia muito de um problema para outro.

O acesso também ficou mais fácil. Além dos solvers comerciais, há solvers de código aberto competentes, como o HiGHS, distribuído gratuitamente sob licença MIT (HiGHS) e usado pela função de otimização inteira mista da SciPy, biblioteca científica do Python (SciPy). E capacidade de processamento pode ser contratada por hora na nuvem.

A consequência é direta. Quando a mesma ferramenta está ao alcance de qualquer empresa, não é ela que explica por que um projeto gera resultado e outro não. O que diferencia o resultado está nas camadas ao redor do solver.

As cinco camadas de um projeto de otimização

Um projeto de otimização pode ser lido como uma cadeia de cinco camadas. Cada uma depende da anterior, e um erro em qualquer uma delas chega intacto ao resultado, por mais rápido que seja o cálculo.

1. Dado: o modelo só enxerga o que os dados mostram

Um modelo de otimização não observa a operação diretamente. Ele a enxerga pelos números que recebe, e três distorções são comuns.

Capacidade nominal no lugar da capacidade real. O cadastro informa o que a linha produz em condições ideais. A operação conhece paradas, trocas e rendimentos que reduzem esse número semana após semana.

Custo médio no lugar do custo que muda com a decisão. O custo contábil por unidade inclui parcelas fixas que não mudam quando o plano muda. Um modelo que usa o custo médio para decidir onde produzir pode tratar como economia algo que não reduz nenhuma despesa.

Venda registrada no lugar da demanda. O histórico mostra o que foi faturado, não o que os clientes quiseram comprar. Quando houve ruptura, a demanda real ficou acima do registro, e um modelo alimentado só pelo faturamento tende a repetir a falta. Discutimos o custo desse tipo de erro em Previsão de demanda: o custo de errar antes de aparecer no resultado.

Nenhuma dessas distorções é resolvida por um computador mais rápido. Ele apenas processa o dado errado em menos tempo.

2. Modelo: o solver resolve o problema que recebeu, não o que a empresa tem

O modelo traduz a operação em linguagem matemática: um objetivo, as decisões possíveis, as restrições e os parâmetros. O solver não questiona essa tradução. Já mostramos aqui no blog como uma restrição esquecida, um custo mal atribuído ou uma regra informal não capturada levam a planos que a operação rejeita (O modelo precisa conhecer a operação). Duas outras escolhas de modelagem pesam tanto quanto essas.

O objetivo. Minimizar custo, maximizar margem e proteger o nível de serviço de clientes estratégicos levam a planos diferentes. Quando o objetivo é definido pela equipe técnica, sem uma decisão explícita da diretoria, o modelo pode otimizar com precisão algo que a empresa não priorizaria.

O nível de detalhe. Agregar demais esconde restrições que importam. Detalhar demais cria um modelo difícil de alimentar, de manter e de explicar. Aqui, mais capacidade de processamento pode até atrapalhar: quando o cálculo deixa de ser limite, cresce a tentação de incluir tudo, e o modelo passa a exigir dados que ninguém mantém atualizados.

O critério útil não é o maior modelo que o computador consegue resolver. É o menor modelo que representa as decisões e as restrições que mudam o resultado.

3. Solver: quando o tempo de cálculo é, de fato, o problema

Há situações em que a capacidade de cálculo é o limite real. Replanejar a distribuição várias vezes ao dia, comparar dezenas de cenários antes de uma reunião de S&OP ou resolver uma rede com milhares de clientes e produtos são casos em que o tempo de resposta determina se o modelo será usado.

Mesmo nesses casos, a primeira pergunta não é qual servidor comprar. Durante a busca, os solvers de otimização inteira mista informam o gap de otimalidade: a distância máxima entre a melhor solução encontrada e a solução ótima. Uma solução comprovadamente a menos de 1% do ótimo, entregue em cinco minutos, costuma ser mais útil do que a solução ótima entregue depois que a decisão foi tomada. Definir esse critério é uma decisão de negócio, não uma configuração técnica.

A formulação também pesa. O estudo citado acima mostra que, em vinte anos, os algoritmos contribuíram mais para a velocidade do que o hardware. Dentro de um projeto, vale algo parecido: a forma como o problema é escrito, ou dividido em etapas, costuma influenciar o tempo de solução tanto quanto a máquina que o resolve.

Mais processamento resolve quando as camadas de dado e de modelo estão corretas e o tempo de resposta é o que impede a decisão. Fora dessa condição, ele acelera uma resposta que não deveria ser usada.

4. Decisão: o plano precisa chegar a quem decide, a tempo

Um plano ótimo entregue depois da reunião de decisão não tem valor. Um arquivo com dezenas de milhares de linhas também não ajuda quem precisa escolher entre duas alternativas em meia hora.

Essa camada costuma ficar fora do escopo técnico, e é nela que muitos projetos perdem impacto. As perguntas são de processo: quem decide, em que fórum, com que frequência e comparando quais alternativas. O resultado do modelo precisa chegar nesse momento e nesse formato: poucos cenários, com as diferenças de custo, nível de serviço, estoque e risco explicadas em termos de negócio.

É também nesta camada que a velocidade do solver ganha valor: permite comparar cenários antes da reunião, e não depois dela. Mas a velocidade só serve se o processo de decisão já prevê esse uso. Como mostramos em S&OP: por que a causa da ruptura nunca está na reunião, o fórum só funciona quando o plano chega a ele já testado.

5. Adoção: um plano que ninguém usa não gera resultado

Em 1970, John Little, professor do MIT, abriu um artigo na revista Management Science com uma observação que continua atual: um modelo pode ajudar o gestor, mas provavelmente não vai ajudar se não atender a certos requisitos (Little, 1970). Entre eles, ser simples, robusto, fácil de controlar e fácil de se comunicar com quem decide.

Mais de cinquenta anos depois, os sinais de baixa adoção são conhecidos:

• os planejadores recebem o plano do modelo e o refazem na planilha;
• ninguém consegue explicar por que o modelo recomendou uma alternativa;
• as correções manuais não são registradas, e o modelo não aprende com elas;
• o modelo não tem um responsável e deixa de acompanhar as mudanças da operação.

Adoção não se resolve com um treinamento no fim do projeto. Ela é construída ao longo dele: com planejadores participando da validação, com resultados que podem ser explicados e com um processo claro para atualizar o modelo quando a operação muda.

Por que “comprar mais processamento” é a resposta mais tentadora

Se o gargalo raramente está no cálculo, por que a resposta técnica aparece tão cedo? Porque ela é a mais fácil de executar. Processamento é comprável, mensurável e delegável: tem fornecedor, preço e prazo. As outras camadas exigem coisas mais difíceis: tempo de quem conhece a operação, uma decisão da diretoria sobre o que otimizar, mudanças no calendário de decisões e disposição para revisar práticas.

Para quem lidera transformação digital, essa diferença importa. Um investimento em infraestrutura é fácil de aprovar e de reportar ao board. Se o problema estava em outra camada, porém, o investimento não muda o resultado, e a otimização perde credibilidade dentro da empresa, como se a tecnologia não funcionasse.

Cinco perguntas antes de investir em mais capacidade de cálculo

1. O modelo reproduz o passado? Com as decisões reais de um período, os custos, volumes e níveis de serviço calculados se aproximam do realizado?
2. Os dados refletem a operação atual? Capacidades, custos e lead times foram revisados com quem opera, ou vêm direto do cadastro?
3. O objetivo do modelo foi decidido pela diretoria? Ou foi herdado de uma premissa técnica do início do projeto?
4. O resultado chega antes da decisão? E chega em um formato que permite comparar alternativas em poucos minutos?
5. Os planejadores usam o plano? Ou o refazem em uma planilha paralela?

Se as cinco respostas forem positivas e o tempo de solução ainda impedir a decisão, mais capacidade de cálculo provavelmente é um bom investimento. Se alguma for negativa, o retorno está em outra camada.

Como a Linear aborda o problema

Na Linear, um projeto de otimização começa pela decisão que precisa ser tomada e pela operação que a cerca, não pela ferramenta. O trabalho percorre as cinco camadas: validar os dados com quem opera, formular o modelo a partir de um objetivo definido pela empresa, escolher a forma de resolução adequada ao tempo da decisão, entregar resultados que caibam no processo de planejamento e acompanhar a adoção com os planejadores.

Essa lógica vale para o planejamento integrado e tático com o Otimix, da rede ao plano de produção, e para o planejamento diário da distribuição com o iDRP. A decisão continua com as pessoas responsáveis por ela, agora apoiadas por um modelo em que confiam.

Perguntas frequentes

O que é um solver de otimização?

É o algoritmo que encontra a melhor solução para um problema descrito por um modelo matemático, respeitando suas restrições. Exemplos: quanto produzir em cada fábrica, de qual centro de distribuição abastecer cada cliente, como montar as cargas do dia. O solver resolve o problema que recebeu; ele não verifica se o problema representa bem a operação.

Um solver mais rápido melhora o resultado de um projeto de otimização?

Só quando o tempo de solução é o que impede a decisão e as camadas de dado e de modelo estão corretas. Se o modelo está incompleto ou os dados não refletem a operação, um solver mais rápido apenas entrega uma resposta inadequada em menos tempo.

O que é gap de otimalidade?

É a diferença máxima possível entre a melhor solução encontrada pelo solver e a solução ótima. Um gap de 1% indica que a solução encontrada está, no máximo, 1% distante do ótimo. O gap aceitável e o tempo máximo de cálculo devem ser definidos a partir do prazo da decisão de negócio.

Por que projetos de otimização falham?

Com frequência, por causas fora do cálculo: dados que não refletem a operação, um modelo com objetivo ou restrições inadequados, resultados que não chegam a tempo ao processo de decisão e baixa adoção pelos planejadores. Por isso, o diagnóstico deve percorrer todas as camadas antes de concluir que falta capacidade de processamento.

Referências

• Koch, T.; Berthold, T.; Pedersen, J.; Vanaret, C. Progress in mathematical programming solvers from 2001 to 2020. EURO Journal on Computational Optimization, v. 10, 2022. DOI 10.1016/j.ejco.2022.100031.
• Little, J. D. C. Models and Managers: The Concept of a Decision Calculus. Management Science, v. 16, n. 8, p. B466–B485, abr. 1970. DOI 10.1287/mnsc.16.8.B466.
• HiGHS. High performance software for linear optimization. Disponível em: highs.dev. Acesso em: 20 out. 2026.
• SciPy. scipy.optimize.milp: documentação. Disponível em: docs.scipy.org. Acesso em: 20 out. 2026.