Modelo de custo de servir sempre foi um dos exercícios mais caros de um projeto de supply chain. Cruzar centro de custo, driver de alocação e demonstrativo de resultado por cliente exige levantar premissa por premissa e reconciliar cada bloco contra a origem dos números. Esse trabalho de montagem, historicamente o item mais caro da análise, é hoje o que ferramentas de IA generativa fazem em uma fração do tempo.
Em um projeto recente, montei com o Claude Code, em poucos dias, um modelo de custo de servir que consumiria várias semanas de um consultor experiente trabalhando pelo método tradicional. A ferramenta usou como referência os modelos e a metodologia de custo de servir de projetos anteriores, e o resultado fechou ao centavo contra a demonstração de resultado. Mesmo assim, encontrei três erros básicos no modelo.
Os três erros tinham uma característica em comum: todos redistribuíam custo entre clientes sem alterar o total. Numa conferência que olha apenas se o modelo bate com a DRE, os três passam despercebidos, porque o total bater é justamente o que essa conferência mede. A distância entre um modelo que fecha e um modelo que está correto é o que ainda depende de alguém ter visto aquele custo se formar na operação.
Dois erros que a máquina pega
Dois dos três erros eram de execução: uma dupla contagem e uma unidade trocada. Um agente reconciliando cada bloco do modelo contra a fonte de dados original, célula a célula, encontra os dois em minutos. É exatamente o tipo de conferência que antes consumia horas de alguém com formação para analisar criticamente a estrutura do modelo, e que hoje uma rotina automatizada faz de forma sistemática.
Essa capacidade muda o risco do projeto de forma direta. Sem essa conferência, o erro de execução passa para a recomendação da mesma forma que passava antes, quando dependia inteiramente da atenção de um analista revisando linha por linha sob pressão de prazo. Automatizar a reconciliação não elimina o erro de execução, mas reduz a chance de ele escapar por cansaço ou por falta de tempo de quem revisa.
O erro que nenhuma conferência pega
O terceiro erro estava na regra de rateio, não na execução da conta. Ela aplicava uma média para repartir custo entre clientes, num contexto em que o custo real varia com a característica de cada cliente: volume, frequência de pedido, complexidade de atendimento. A aritmética estava correta; a escolha metodológica por trás da regra de rateio não resistia à mesma checagem.
O efeito prático foi inverter a ordem entre cliente caro e cliente barato. Um modelo que reconcilia perfeitamente contra a demonstração de resultado pode, ainda assim, recomendar otimizar o contrato errado, porque a conferência contra a DRE testa se o total bate, não se a distribuição entre clientes está certa. Nenhuma rotina de reconciliação, automatizada ou manual, foi desenhada para pegar esse tipo de erro, porque o modelo nunca declara a premissa de rateio como algo a testar. Ela está embutida na fórmula, não na lista do que se confere.
Reconhecer que aquela curva de custo por cliente não fazia sentido veio de já ter visto esse custo se formar na operação em outros projetos, de saber, olhando o resultado, que características de cliente pesam de forma desigual no custo de atendê-lo. É um julgamento que se forma vendo o padrão se repetir em operações diferentes, não um passo de checklist que se aprende uma vez.
Implicação para gestores
O padrão revelado por esse projeto tem uma implicação direta para quem aprova análise construída com apoio de IA: dois dos três erros eram do tipo que qualquer processo de conferência estruturada pega, e um não era. Isso desloca o que vale a pena perguntar antes de aprovar. Confirmar que o modelo fecha contra a DRE deixou de ser suficiente, porque essa pergunta testa apenas o subconjunto de erros que a reconciliação automática já cobre.
A pergunta que continua exigindo julgamento humano é outra: a regra de alocação usada faz sentido para a característica de cada cliente, ou está aplicando uma média onde a operação real varia caso a caso? Essa pergunta não tem verificação automática porque questiona a premissa metodológica do modelo, não a execução dele. Quem aprova precisa ter na mesa, ou trazer para ela, alguém que já viu aquele tipo de custo se formar na operação, capaz de testar se a distribuição final faz sentido.
O momento em que essa checagem é barata é antes da aprovação, enquanto a análise ainda é recomendação. Depois que ela vira decisão, o contrato já foi renegociado com base na ordem errada e o investimento já foi priorizado sobre a premissa errada. Corrigir depois custa a credibilidade da análise inteira, não apenas o tempo de refazer o modelo.
Uma análise que fecha ao centavo ainda pode estar errada na única pergunta que importa: se o rateio reflete a operação real ou apenas a média dela. Isso não muda com a próxima geração de modelo de IA, porque não é um problema de precisão aritmética. É um problema de quem, na sala, já viu aquele custo se formar o suficiente para desconfiar da curva antes de ela virar decisão.