Usar um LLM para Esboçar um Modelo de Custos, e Onde Falha

Peça a um modelo de linguagem para esboçar um modelo de custos TDABC e ele produz um sem hesitar: cost pools, drivers candidatos, uma taxa de custo de capacidade, até uma equação de tempo com ar plausível. O resultado lê-se como algo escrito por um analista competente. O problema não é estar errado de forma óbvia - um modelo com um número obviamente errado é apanhado depressa. O problema é estar errado da forma como um recém-licenciado brilhante, sem experiência no sector, está errado: fluente, bem estruturado e assente, sem ninguém dar por isso, em pressupostos que nunca foram confirmados na sua empresa.

Onde é genuinamente útil

Dada a descrição de uma empresa, um LLM produz uma lista sensata de cost pools candidatos e um primeiro corte de drivers que raramente é embaraçoso. Conhece o vocabulário do custeio, leu uma quantidade considerável de literatura de contabilidade e é rápido a transformar uma descrição vaga num ponto de partida estruturado. Para uma equipa a olhar para uma folha de cálculo em branco, esse primeiro rascunho pode poupar uma tarde inteira de trabalho útil. É também bom a explicar o método a alguém não especialista, e a gerar a documentação que ninguém quer escrever à mão.

Onde os dados de treino se esgotam

Um modelo de custos só está correto se os seus números descreverem a sua operação, e nenhum desses números esteve em qualquer conjunto de treino. A sua capacidade prática - os minutos que uma equipa tem realmente disponíveis depois de contabilizadas férias, formação e tempos mortos - existe apenas nas suas escalas e no seu ERP. Os volumes dos seus drivers, o número de setups, linhas de encomenda ou pedidos de suporte que a sua empresa produziu de facto no último trimestre, existem apenas nos seus próprios sistemas. Um LLM a quem se peça para estimar qualquer um destes valores produz um número que soa específico e é, na realidade, um palpite disfarçado de facto. Não tem forma de assinalar a diferença, porque os modelos de linguagem são construídos para soar confiantes, não para sinalizar incerteza sobre um facto que não conseguem verificar.

A armadilha da alocação de overhead, em particular

Peça a um modelo para sugerir um driver para o overhead de TI e vai propor, muitas vezes, o número de colaboradores, porque é o driver mais mencionado nos manuais e casos de estudo em que foi treinado. O número de colaboradores é conveniente e quase nunca é causal: dois departamentos com o mesmo número de pessoas podem consumir quantidades muito diferentes de suporte de TI, consoante o número de sistemas que utilizam e a complexidade do seu trabalho. Um modelo leu milhares de exemplos em que o número de colaboradores foi usado como driver e muito poucos em que alguém explicou porque é que essa era a escolha errada para aquela empresa em particular. Reproduz a resposta popular, não a correta para si.

Uma divisão de trabalho que funciona

A divisão útil é estrutura versus facto. Deixe o modelo esboçar a lista de cost pools, propor drivers candidatos para reagir a eles, e escrever a primeira explicação do método para quem não esteve na sala. Não o deixe inventar uma capacidade, um volume de driver ou uma percentagem de repartição entre atividades - esses valores vêm apenas do seu ERP, dos registos de horas, das escalas ou de um estudo de tempos genuíno. Um modelo pode acelerar as partes do trabalho que consistem em organizar factos já conhecidos. Não pode fabricar os próprios factos, por muito confiante que seja a frase que os contém.

Um LLM consegue escrever uma frase muito convincente sobre um número que nunca viu. É precisamente esse o modo de falha que um modelo de custos não se pode permitir.

O que verificar antes de confiar num modelo esboçado por IA

Antes de qualquer alocação esboçada por IA se aproximar de uma decisão de preço ou de uma decisão de conselho de administração, siga cada número até à sua origem. Se um volume de driver não puder ser apontado a um relatório ou sistema específico, é um pressuposto e deve ser rotulado como tal, não publicado como facto. Pergunte se duplicar o driver duplicaria plausivelmente o custo - o teste de causalidade continua a aplicar-se, quer o driver tenha sido proposto por uma pessoa ou por um modelo. E pergunte se alguém na empresa que faz de facto esse trabalho defenderia o número numa sala. Se a resposta a qualquer uma destas perguntas for não, o rascunho precisa de uma pessoa com os dados reais antes de se tornar uma decisão.

Leitura relacionada: onde os LLMs erram na alocação de overhead e passar de folhas de cálculo para um modelo de custos real.