Quando um plano otimizado \u00e9 rejeitado pela opera\u00e7\u00e3o, a primeira suspeita costuma recair sobre o algoritmo. Muitas vezes, o problema est\u00e1 antes dele: o modelo de otimiza\u00e7\u00e3o n\u00e3o representava a opera\u00e7\u00e3o que deveria otimizar.<\/p>\n\n\n\n
Um algoritmo de otimiza\u00e7\u00e3o resolve com precis\u00e3o o problema que recebeu. Se esse problema deixa de fora uma restri\u00e7\u00e3o, atribui mal um custo ou ignora uma regra que s\u00f3 existe na pr\u00e1tica, a resposta ser\u00e1 \u00f3tima para uma opera\u00e7\u00e3o que n\u00e3o existe.<\/p>\n\n\n\n
Para o Diretor de Supply Chain, isso significa planos que ningu\u00e9m executa. Para quem lidera transforma\u00e7\u00e3o digital, significa um investimento em tecnologia que perde credibilidade na primeira reuni\u00e3o com a opera\u00e7\u00e3o.<\/p>\n\n\n\n
Todo modelo de otimiza\u00e7\u00e3o tem quatro partes:<\/p>\n\n\n\n
O algoritmo, tamb\u00e9m chamado de solver<\/em>, procura a melhor combina\u00e7\u00e3o de decis\u00f5es dentro do que foi descrito. “\u00d3timo” \u00e9 sempre relativo a essa descri\u00e7\u00e3o. Um solver<\/em> mais r\u00e1pido encontra a resposta em menos tempo, mas n\u00e3o enxerga o que n\u00e3o foi escrito.<\/p>\n\n\n\n Por isso a pergunta “qual algoritmo voc\u00eas usam?” diz menos sobre a qualidade de uma solu\u00e7\u00e3o do que a pergunta “como voc\u00eas sabem que o modelo representa a minha opera\u00e7\u00e3o?”.<\/p>\n\n\n\n Uma linha de envase tem capacidade para 400 mil unidades por semana. O modelo distribui a produ\u00e7\u00e3o de 12 produtos nessa linha usando a capacidade total. O que ficou de fora: cada troca de produto exige limpeza e ajuste, e leva horas.<\/p>\n\n\n\n O plano parece vi\u00e1vel no papel e \u00e9 invi\u00e1vel no ch\u00e3o de f\u00e1brica. O planejador corrige manualmente, agrupando produtos e cortando trocas. As corre\u00e7\u00f5es consomem parte do ganho que a otimiza\u00e7\u00e3o prometia, e ningu\u00e9m mede quanto. J\u00e1 falamos sobre esse ajuste manual, e sobre o custo de for\u00e7ar um cen\u00e1rio invi\u00e1vel<\/a>, em outro artigo do blog.<\/p>\n\n\n\n O modelo trata o frete como um custo fixo por tonelada. O contrato real tem frete m\u00ednimo por viagem. Resultado: o modelo enxerga cargas pequenas para destinos distantes como baratas, porque calcula o custo proporcional ao peso, e recomenda entregas fracionadas que, na fatura, custam bem mais.<\/p>\n\n\n\n Nesse caso o plano \u00e9 execut\u00e1vel. O problema \u00e9 mais sutil: a decis\u00e3o parece econ\u00f4mica no modelo e n\u00e3o \u00e9 na pr\u00e1tica. O erro s\u00f3 aparece semanas depois, no relat\u00f3rio de custo log\u00edstico<\/a>.<\/p>\n\n\n\n Ulisses Assis, CEO da Linear, contou no podcast O Executivo um caso de planejamento de compra de leite para uma grande ind\u00fastria de latic\u00ednios. A decis\u00e3o envolvia quanto comprar, quanto desnatar e quanto transformar em leite em p\u00f3, com pre\u00e7os que variam ao longo do ano.<\/p>\n\n\n\n Havia uma regra que n\u00e3o estava em nenhum sistema: o creme que sobra do desnate dura muito pouco e precisa ser processado no mesmo dia. Se a f\u00e1brica n\u00e3o tem capacidade, o creme s\u00f3 pode seguir para uma unidade pr\u00f3xima, ou azeda no caminho. Sem essa regra, o modelo poderia recomendar desnatar onde fosse mais barato, sem considerar o destino do creme.<\/p>\n\n\n\n Regras desse tipo s\u00e3o comuns. Clientes que s\u00f3 recebem em determinados hor\u00e1rios, produtos que n\u00e3o podem viajar juntos, turnos definidos em acordo coletivo, um fornecedor preferido por raz\u00f5es que n\u00e3o est\u00e3o no contrato. Elas vivem na cabe\u00e7a de quem opera, em planilhas paralelas e em e-mails. Raramente est\u00e3o no ERP.<\/p>\n\n\n\n Fidelidade \u00e0 opera\u00e7\u00e3o n\u00e3o significa copiar a pr\u00e1tica atual. Quando o resultado do modelo surpreende quem opera, h\u00e1 duas possibilidades: ou o modelo est\u00e1 errado, ou a opera\u00e7\u00e3o tem um custo que ningu\u00e9m via.<\/p>\n\n\n\n O creme que azeda \u00e9 uma restri\u00e7\u00e3o f\u00edsica. “Sempre carregamos assim” pode ser apenas um h\u00e1bito. O trabalho de modelagem \u00e9 separar uma coisa da outra: incorporar o que \u00e9 restri\u00e7\u00e3o real e questionar o que \u00e9 costume. As duas conversas geram valor.<\/p>\n\n\n\n Cinco pr\u00e1ticas ajudam a validar um modelo de otimiza\u00e7\u00e3o antes de confiar nas suas recomenda\u00e7\u00f5es:<\/p>\n\n\n\n Projetos de otimiza\u00e7\u00e3o costumam reservar or\u00e7amento e prazo para integra\u00e7\u00e3o de dados. Faz sentido: o modelo precisa de dados confi\u00e1veis. Mas integrar o ERP n\u00e3o traz as regras que nunca entraram nele.<\/p>\n\n\n\n Capturar a opera\u00e7\u00e3o \u00e9 um trabalho \u00e0 parte, feito em conversa com planejadores, supervisores e equipes de ch\u00e3o de f\u00e1brica. Quando esse trabalho fica fora do escopo, o projeto entrega um modelo tecnicamente correto que a opera\u00e7\u00e3o n\u00e3o adota. Para o board, o resultado \u00e9 indistingu\u00edvel de uma tecnologia que n\u00e3o funciona.<\/p>\n\n\n\n Na Linear, um modelo de otimiza\u00e7\u00e3o come\u00e7a pela opera\u00e7\u00e3o, n\u00e3o pelo algoritmo. O trabalho envolve entender o processo com quem opera, transformar regras de capacidade, validade, frota e contratos em restri\u00e7\u00f5es e validar o resultado com os planejadores antes de usar o modelo para decidir.<\/p>\n\n\n\n Essa l\u00f3gica vale para o planejamento integrado com o Otimix<\/a>, da rede ao plano de produ\u00e7\u00e3o, e para o dia a dia da distribui\u00e7\u00e3o com o iDRP<\/a>. A decis\u00e3o continua com as pessoas respons\u00e1veis por ela, agora apoiadas por um modelo que conhece a opera\u00e7\u00e3o.<\/p>\n\n\n\n Quer saber se os modelos de planejamento da sua empresa representam a opera\u00e7\u00e3o real? Converse com um especialista da Linear.<\/p>\n\n\n\nTr\u00eas falhas comuns de modelagem<\/h2>\n\n\n\n
1. A restri\u00e7\u00e3o esquecida<\/h3>\n\n\n\n
2. O custo mal atribu\u00eddo<\/h3>\n\n\n\n
3. A regra informal n\u00e3o capturada<\/h3>\n\n\n\n
Falha<\/th> O que o modelo recomenda<\/th> O que acontece na opera\u00e7\u00e3o<\/th> Quando o erro aparece<\/th><\/tr><\/thead> Restri\u00e7\u00e3o esquecida<\/td> Plano que usa capacidade que n\u00e3o existe<\/td> Plano invi\u00e1vel, corrigido \u00e0 m\u00e3o<\/td> Na hora de executar<\/td><\/tr> Custo mal atribu\u00eddo<\/td> Alternativa que parece mais barata<\/td> Custo real maior que o previsto<\/td> Semanas depois, no resultado<\/td><\/tr> Regra informal n\u00e3o capturada<\/td> Plano que viola uma regra da pr\u00e1tica<\/td> Perda, retrabalho ou rejei\u00e7\u00e3o do plano<\/td> Na primeira conversa com a opera\u00e7\u00e3o<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Nem toda obje\u00e7\u00e3o da opera\u00e7\u00e3o est\u00e1 certa<\/h2>\n\n\n\n
Como saber se o modelo conhece a opera\u00e7\u00e3o<\/h2>\n\n\n\n
\n
Para quem lidera transforma\u00e7\u00e3o digital<\/h2>\n\n\n\n
Como a Linear aborda o problema<\/h2>\n\n\n\n
Talk to Linear<\/h2>\n\n\n\n