{"id":1417,"date":"2026-10-23T13:14:30","date_gmt":"2026-10-23T16:14:30","guid":{"rendered":"https:\/\/linearsm.com.br\/?p=1417"},"modified":"2026-10-23T13:19:14","modified_gmt":"2026-10-23T16:19:14","slug":"onde-projetos-de-otimizacao-realmente-falham-solver-nao-e-estrategia","status":"publish","type":"post","link":"https:\/\/linearsm.com.br\/en\/onde-projetos-de-otimizacao-realmente-falham-solver-nao-e-estrategia\/","title":{"rendered":"Onde projetos de otimiza\u00e7\u00e3o realmente falham: solver n\u00e3o \u00e9 estrat\u00e9gia"},"content":{"rendered":"

Um projeto de otimiza\u00e7\u00e3o entra em opera\u00e7\u00e3o e, alguns meses depois, os planejadores continuam fechando o plano na planilha. Quando algu\u00e9m pergunta o que deu errado, uma das primeiras respostas costuma ser t\u00e9cnica: o modelo demora para rodar, o servidor \u00e9 fraco, talvez seja hora de um solver mais potente ou de mais capacidade na nuvem.<\/p>\n\n\n\n

\u00c0s vezes \u00e9 isso. Com frequ\u00eancia, n\u00e3o \u00e9. Os projetos de otimiza\u00e7\u00e3o<\/strong> que n\u00e3o geram resultado raramente falham no c\u00e1lculo. Falham antes dele, nos dados e na formula\u00e7\u00e3o do problema, ou depois dele, quando o plano precisa virar decis\u00e3o e ser adotado por quem opera. Comprar mais processamento acelera a parte que j\u00e1 funcionava.<\/p>\n\n\n\n

Este artigo percorre as cinco camadas de um projeto de otimiza\u00e7\u00e3o (dado, modelo, solver, decis\u00e3o e ado\u00e7\u00e3o), mostra onde cada uma costuma falhar e ajuda a identificar quando mais capacidade de c\u00e1lculo de fato resolve.<\/p>\n\n\n\n

Projetos de otimiza\u00e7\u00e3o: o solver deixou de ser o diferencial<\/h2>\n\n\n\n

O solver \u00e9 o algoritmo que procura a melhor solu\u00e7\u00e3o para o problema descrito pelo modelo matem\u00e1tico: quanto produzir em cada f\u00e1brica, de onde abastecer cada cliente, o que colocar em cada carga. \u00c9 a pe\u00e7a mais t\u00e9cnica do projeto e, por isso, a que mais chama aten\u00e7\u00e3o.<\/p>\n\n\n\n

Nas \u00faltimas duas d\u00e9cadas, essa pe\u00e7a evoluiu muito. Um estudo publicado em 2022 no EURO Journal on Computational Optimization<\/em> comparou solvers do in\u00edcio dos anos 2000 com vers\u00f5es recentes. Entre 2001 e 2020, a resolu\u00e7\u00e3o de problemas de programa\u00e7\u00e3o inteira mista ficou cerca de mil vezes mais r\u00e1pida: aproximadamente 20 vezes por causa do hardware e 50 vezes por causa dos algoritmos (Koch et al., 2022<\/a>). Os autores ressaltam que o ganho varia muito de um problema para outro.<\/p>\n\n\n\n

O acesso tamb\u00e9m ficou mais f\u00e1cil. Al\u00e9m dos solvers comerciais, h\u00e1 solvers de c\u00f3digo aberto competentes, como o HiGHS, distribu\u00eddo gratuitamente sob licen\u00e7a MIT (HiGHS<\/a>) e usado pela fun\u00e7\u00e3o de otimiza\u00e7\u00e3o inteira mista da SciPy, biblioteca cient\u00edfica do Python (SciPy<\/a>). E capacidade de processamento pode ser contratada por hora na nuvem.<\/p>\n\n\n\n

A consequ\u00eancia \u00e9 direta. Quando a mesma ferramenta est\u00e1 ao alcance de qualquer empresa, n\u00e3o \u00e9 ela que explica por que um projeto gera resultado e outro n\u00e3o. O que diferencia o resultado est\u00e1 nas camadas ao redor do solver.<\/p>\n\n\n\n

As cinco camadas de um projeto de otimiza\u00e7\u00e3o<\/h2>\n\n\n\n

Um projeto de otimiza\u00e7\u00e3o 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\u00e1pido que seja o c\u00e1lculo.<\/p>\n\n\n\n

Camada<\/th>Pergunta que responde<\/th>Falha t\u00edpica<\/th>Mais processamento ajuda?<\/th><\/tr><\/thead>
Dado<\/strong><\/td>O que sabemos sobre a opera\u00e7\u00e3o?<\/td>Capacidades, custos e demanda que n\u00e3o refletem a opera\u00e7\u00e3o atual<\/td>N\u00e3o: processa o dado errado mais r\u00e1pido<\/td><\/tr>
Modelo<\/strong><\/td>Que problema estamos resolvendo?<\/td>Objetivo herdado, restri\u00e7\u00e3o esquecida, n\u00edvel de detalhe inadequado<\/td>N\u00e3o, e pode estimular modelos maiores que o necess\u00e1rio<\/td><\/tr>
Solver<\/strong><\/td>Qual \u00e9 a melhor solu\u00e7\u00e3o para o problema descrito?<\/td>Tempo de resposta incompat\u00edvel com a decis\u00e3o<\/td>Sim, quando esta \u00e9 de fato a camada limitante<\/td><\/tr>
Decis\u00e3o<\/strong><\/td>O plano chega a quem decide, a tempo e no formato certo?<\/td>Resultado entregue depois da reuni\u00e3o, ou sem alternativas compar\u00e1veis<\/td>Pouco: gera cen\u00e1rios mais r\u00e1pido, mas n\u00e3o os encaixa no processo<\/td><\/tr>
Ado\u00e7\u00e3o<\/strong><\/td>A opera\u00e7\u00e3o usa o plano?<\/td>Planilha paralela, desconfian\u00e7a, modelo sem respons\u00e1vel<\/td>N\u00e3o<\/td><\/tr><\/tbody><\/table>

As cinco camadas de um projeto de otimiza\u00e7\u00e3o e onde mais processamento ajuda.<\/figcaption><\/figure>\n\n\n\n

1. Dado: o modelo s\u00f3 enxerga o que os dados mostram<\/h3>\n\n\n\n

Um modelo de otimiza\u00e7\u00e3o n\u00e3o observa a opera\u00e7\u00e3o diretamente. Ele a enxerga pelos n\u00fameros que recebe, e tr\u00eas distor\u00e7\u00f5es s\u00e3o comuns.<\/p>\n\n\n\n

Capacidade nominal no lugar da capacidade real.<\/strong> O cadastro informa o que a linha produz em condi\u00e7\u00f5es ideais. A opera\u00e7\u00e3o conhece paradas, trocas e rendimentos que reduzem esse n\u00famero semana ap\u00f3s semana.<\/p>\n\n\n\n

Custo m\u00e9dio no lugar do custo que muda com a decis\u00e3o.<\/strong> O custo cont\u00e1bil por unidade inclui parcelas fixas que n\u00e3o mudam quando o plano muda. Um modelo que usa o custo m\u00e9dio para decidir onde produzir pode tratar como economia algo que n\u00e3o reduz nenhuma despesa.<\/p>\n\n\n\n

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

Nenhuma dessas distor\u00e7\u00f5es \u00e9 resolvida por um computador mais r\u00e1pido. Ele apenas processa o dado errado em menos tempo.<\/p>\n\n\n\n

2. Modelo: o solver resolve o problema que recebeu, n\u00e3o o que a empresa tem<\/h3>\n\n\n\n

O modelo traduz a opera\u00e7\u00e3o em linguagem matem\u00e1tica: um objetivo, as decis\u00f5es poss\u00edveis, as restri\u00e7\u00f5es e os par\u00e2metros. O solver n\u00e3o questiona essa tradu\u00e7\u00e3o. J\u00e1 mostramos aqui no blog como uma restri\u00e7\u00e3o esquecida, um custo mal atribu\u00eddo ou uma regra informal n\u00e3o capturada levam a planos que a opera\u00e7\u00e3o rejeita (O modelo precisa conhecer a opera\u00e7\u00e3o<\/a>). Duas outras escolhas de modelagem pesam tanto quanto essas.<\/p>\n\n\n\n

O objetivo.<\/strong> Minimizar custo, maximizar margem e proteger o n\u00edvel de servi\u00e7o de clientes estrat\u00e9gicos levam a planos diferentes. Quando o objetivo \u00e9 definido pela equipe t\u00e9cnica, sem uma decis\u00e3o expl\u00edcita da diretoria, o modelo pode otimizar com precis\u00e3o algo que a empresa n\u00e3o priorizaria.<\/p>\n\n\n\n

O n\u00edvel de detalhe.<\/strong> Agregar demais esconde restri\u00e7\u00f5es que importam. Detalhar demais cria um modelo dif\u00edcil de alimentar, de manter e de explicar. Aqui, mais capacidade de processamento pode at\u00e9 atrapalhar: quando o c\u00e1lculo deixa de ser limite, cresce a tenta\u00e7\u00e3o de incluir tudo, e o modelo passa a exigir dados que ningu\u00e9m mant\u00e9m atualizados.<\/p>\n\n\n\n

O crit\u00e9rio \u00fatil n\u00e3o \u00e9 o maior modelo que o computador consegue resolver. \u00c9 o menor modelo que representa as decis\u00f5es e as restri\u00e7\u00f5es que mudam o resultado.<\/p>\n\n\n\n

3. Solver: quando o tempo de c\u00e1lculo \u00e9, de fato, o problema<\/h3>\n\n\n\n

H\u00e1 situa\u00e7\u00f5es em que a capacidade de c\u00e1lculo \u00e9 o limite real. Replanejar a distribui\u00e7\u00e3o v\u00e1rias vezes ao dia, comparar dezenas de cen\u00e1rios antes de uma reuni\u00e3o de S&OP ou resolver uma rede com milhares de clientes e produtos s\u00e3o casos em que o tempo de resposta determina se o modelo ser\u00e1 usado.<\/p>\n\n\n\n

Mesmo nesses casos, a primeira pergunta n\u00e3o \u00e9 qual servidor comprar. Durante a busca, os solvers de otimiza\u00e7\u00e3o inteira mista informam o gap de otimalidade<\/strong>: a dist\u00e2ncia m\u00e1xima entre a melhor solu\u00e7\u00e3o encontrada e a solu\u00e7\u00e3o \u00f3tima. Uma solu\u00e7\u00e3o comprovadamente a menos de 1% do \u00f3timo, entregue em cinco minutos, costuma ser mais \u00fatil do que a solu\u00e7\u00e3o \u00f3tima entregue depois que a decis\u00e3o foi tomada. Definir esse crit\u00e9rio \u00e9 uma decis\u00e3o de neg\u00f3cio, n\u00e3o uma configura\u00e7\u00e3o t\u00e9cnica.<\/p>\n\n\n\n

A formula\u00e7\u00e3o tamb\u00e9m pesa. O estudo citado acima mostra que, em vinte anos, os algoritmos contribu\u00edram mais para a velocidade do que o hardware. Dentro de um projeto, vale algo parecido: a forma como o problema \u00e9 escrito, ou dividido em etapas, costuma influenciar o tempo de solu\u00e7\u00e3o tanto quanto a m\u00e1quina que o resolve.<\/p>\n\n\n\n

Mais processamento resolve quando as camadas de dado e de modelo est\u00e3o corretas e o tempo de resposta \u00e9 o que impede a decis\u00e3o. Fora dessa condi\u00e7\u00e3o, ele acelera uma resposta que n\u00e3o deveria ser usada.<\/p>\n\n\n\n

4. Decis\u00e3o: o plano precisa chegar a quem decide, a tempo<\/h3>\n\n\n\n

Um plano \u00f3timo entregue depois da reuni\u00e3o de decis\u00e3o n\u00e3o tem valor. Um arquivo com dezenas de milhares de linhas tamb\u00e9m n\u00e3o ajuda quem precisa escolher entre duas alternativas em meia hora.<\/p>\n\n\n\n

Essa camada costuma ficar fora do escopo t\u00e9cnico, e \u00e9 nela que muitos projetos perdem impacto. As perguntas s\u00e3o de processo: quem decide, em que f\u00f3rum, com que frequ\u00eancia e comparando quais alternativas. O resultado do modelo precisa chegar nesse momento e nesse formato: poucos cen\u00e1rios, com as diferen\u00e7as de custo, n\u00edvel de servi\u00e7o, estoque e risco explicadas em termos de neg\u00f3cio.<\/p>\n\n\n\n

\u00c9 tamb\u00e9m nesta camada que a velocidade do solver ganha valor: permite comparar cen\u00e1rios antes da reuni\u00e3o, e n\u00e3o depois dela. Mas a velocidade s\u00f3 serve se o processo de decis\u00e3o j\u00e1 prev\u00ea esse uso. Como mostramos em S&OP: por que a causa da ruptura nunca est\u00e1 na reuni\u00e3o<\/a>, o f\u00f3rum s\u00f3 funciona quando o plano chega a ele j\u00e1 testado.<\/p>\n\n\n\n

5. Ado\u00e7\u00e3o: um plano que ningu\u00e9m usa n\u00e3o gera resultado<\/h3>\n\n\n\n

Em 1970, John Little, professor do MIT, abriu um artigo na revista Management Science<\/em> com uma observa\u00e7\u00e3o que continua atual: um modelo pode ajudar o gestor, mas provavelmente n\u00e3o vai ajudar se n\u00e3o atender a certos requisitos (Little, 1970<\/a>). Entre eles, ser simples, robusto, f\u00e1cil de controlar e f\u00e1cil de se comunicar com quem decide.<\/p>\n\n\n\n

Mais de cinquenta anos depois, os sinais de baixa ado\u00e7\u00e3o s\u00e3o conhecidos:<\/p>\n\n\n\n