O modelo de custeio que morreu (e como manter o seu vivo)
Este é um cenário compósito, construído a partir de experiência real de terreno em várias implementações de modelos de custo; os detalhes, o setor e todos os números são ilustrativos e não representam nenhum cliente em concreto. É a história de um modelo de custeio elegante que demorou cerca de três anos e um orçamento de seis dígitos altos a construir, produziu conhecimento genuíno durante um ano glorioso e depois morreu em silêncio. O que o matou não foi a matemática. Foi aquilo que quase ninguém inclui no plano do projeto.
Um grande operador de infraestruturas, intensivo em capital, contratou uma consultora global para desenhar um modelo de custeio. O desenho era excelente. Implementá-lo numa pesada plataforma empresarial de gestão de custos demorou cerca de dezoito meses só para encontrar alguém capaz de o construir, e mais dezoito para o construir. Quando finalmente funcionou, produziu respostas reais: custo verdadeiro por atividade, uma curva da baleia da rentabilidade, decisões que antes eram palpites tornadas defensáveis. Depois as equipas de entrega foram-se embora. Ninguém dentro da organização era dono do modelo, ninguém o atualizava, e no espaço de um ano tinha-se afastado tanto da realidade que as pessoas deixaram de confiar nele. O investimento, ilustrativo, mas confortavelmente na casa dos seis dígitos altos, foi dado como perdido. A lição é incómoda e bem documentada: os modelos de custeio raramente falham no método. Falham na propriedade e na manutenibilidade. A mesma ambição, hoje, construída com uma ferramenta moderna, IA e um dono interno claro, chega a um primeiro modelo defensável em dias em vez de anos, mantém todos os números rastreáveis e vive dentro de algo que o cliente consegue efetivamente operar. É essa a diferença entre um modelo que morre e um que se mantém vivo.
Um desenho elegante, e toda a gente na sala acenou que sim
Começou, como estas coisas muitas vezes começam, com um bom diagnóstico. Por volta de 2019, um grande operador de infraestruturas, intensivo em capital, sabia aquilo que qualquer diretor financeiro na sua posição sabe: os números que saem do razão geral diziam-lhe quanto tinha gasto, mas não quanto qualquer coisa efetivamente custava. Custo por departamento, sim. Custo por atividade, por serviço, pelas coisas sobre as quais a organização realmente decidia, não. Por isso fez o sensato e trouxe uma consultora global para desenhar um modelo de custo em condições.
O desenho era, genuinamente, bom. Uma arquitetura de atividades limpa. Recursos a fluir para atividades, atividades a fluir para os serviços e resultados que importavam, indutores escolhidos com verdadeiro cuidado. Estava reconhecidamente na tradição do custeio baseado em atividades por tempo, a disciplina que Kaplan e Anderson tinham exposto uma década antes: modelar a capacidade, modelar o tempo que cada atividade consome e deixar o custo seguir a causa em vez de médias convenientes. Os consultores documentaram-no de forma exemplar e recomendaram que fosse implementado numa pesada plataforma empresarial de gestão de custos, do tipo sério e caro que as grandes organizações compram precisamente porque a ambição é grande. Toda a gente no comité de acompanhamento acenou que sim. No papel, a parte difícil estava feita.
No papel. O projeto respondia ao quê do modelo. Ficava mais calado sobre quem o iria construir, quem o iria operar e quem ainda se importaria com ele três ciclos orçamentais mais tarde. É nesse silêncio que a história verdadeiramente vive.
Dezoito meses à procura de alguém que o soubesse construir
Aqui está a parte que o projeto não antecipou. Ter um desenho elegante e ter o desenho numa plataforma estão separados por um abismo, e o operador passou cerca de dezoito meses no fundo dele. O modelo conceptual era sólido. A plataforma era capaz. Mas a competência específica de traduzir este desenho para aquela plataforma, as pessoas capazes de o fazer de facto, revelou-se genuinamente rara e, na sua maioria, indisponível.
Por isso o projeto ficou numa prateleira. Não metaforicamente; havia um documento encadernado, e ficou ali. Rondas de compras vieram e foram-se. Candidatos foram entrevistados e, discretamente, verificou-se que nunca tinham feito aquilo, apenas algo adjacente. A janela em que os patrocinadores originais estavam entusiasmados com o projeto estreitou-se. Este é o ato menos dramático da história e, de certa forma, o mais instrutivo: dezoito meses de tempo decorrido e de esforço pago produziram exatamente zero modelos a funcionar, e ninguém tinha feito nada de errado. O desenho não era a restrição. O recurso escasso era a capacidade de o implementar, e os recursos escassos, como qualquer modelo de custo lhe dirá, são onde o custo verdadeiro se esconde. A organização já estava a pagar, em tempo e em impulso, muito antes de sair um único número.
Funcionou, e durante um ano foi magnífico
Acabou por se encontrar um implementador especialista, alguém que tinha efetivamente feito isto nesta classe de plataforma, e a construção começou a sério. Demorou mais cerca de dezoito meses. Isto não é um escândalo; um modelo desta ambição, numa plataforma deste peso, é um projeto de construção sério, com alimentações de dados, lógica de alocação, reconciliação e testes. Mas significa que, quando o modelo produziu o seu primeiro resultado fiável, tinham passado cerca de três anos desde a aprovação do projeto.
E então funcionou. Esta é a parte em que vale a pena demorarmo-nos, porque foi real. O modelo produziu custo verdadeiro por atividade, não médias departamentais disfarçadas. Permitiu à organização traçar uma curva da baleia da rentabilidade, a curva de lucro acumulado que revela como uma minoria de serviços e relações gera bastante acima do lucro total, enquanto uma longa cauda, discretamente, o devolve (padrão ilustrativo, mas familiar). Decisões que durante anos tinham sido tomadas por instinto, o que preçar, o que internalizar, onde a capacidade estava genuinamente a ser consumida em vez de meramente assumida, tornaram-se defensáveis. As pessoas levavam os números do modelo para salas onde antes levavam opiniões. Durante algum tempo, a organização conseguia ver-se com clareza, parte dela pela primeira vez. Três anos e um investimento de seis dígitos altos, ilustrativo, tinham comprado algo que genuinamente funcionava.
Depois as equipas foram-se, e ninguém era o dono
A morte não foi um colapso. Ninguém desligou o modelo. Morreu como a maioria dos modelos de custeio morre, lentamente, em silêncio, de um abandono que nenhuma pessoa em concreto escolheu.
Quando a implementação foi declarada concluída, as equipas de entrega fizeram o que as equipas de entrega fazem: foram-se embora. A consultora saiu. O implementador especialista passou para o próximo projeto. E o modelo, esta máquina intrincada que transformava dados brutos do razão em conhecimento, foi entregue a uma organização que não tinha ninguém cuja função real fosse mantê-lo vivo. Não havia dono interno. Não havia cadença de manutenção, nenhum ritmo mensal de atualizar os dados, rever as taxas dos indutores, verificar se os pressupostos de capacidade ainda correspondiam a uma operação entretanto alterada. Não havia responsabilização, porque a propriedade nunca tinha sido desenhada; o projeto tinha especificado o modelo, não o responsável pela manutenção.
Por isso a realidade moveu-se, como a realidade faz, e o modelo não se moveu com ela. As atividades mudaram. Os volumes deslocaram-se. A organização reestruturou-se um pouco, como as organizações fazem. A cada mês sem atualização, o fosso entre o que o modelo dizia e o que era verdade alargava-se uma fração. No espaço de um ano, os números do modelo já não correspondiam à experiência vivida por ninguém do negócio, e o momento em que um modelo de custeio deixa de corresponder à realidade é o momento em que as pessoas deixam de confiar nele. Assim que deixam de confiar, deixam de o usar. Assim que deixam de o usar, ninguém consegue justificar o esforço de o manter, o que garante que se afasta ainda mais, uma espiral de morte silenciosa. O modelo não foi desativado numa reunião. Foi simplesmente, gradualmente, abandonado. O investimento de seis dígitos altos, ilustrativo, foi dado como perdido não porque o modelo estivesse errado quando foi construído, mas porque nada estava em vigor para o manter correto.
Nunca foi a matemática
É tentador culpar o método, ou a plataforma, ou o prazo de três anos. Resista. O desenho era bom. A construção foi competente. O modelo, no dia em que entrou em produção, estava certo. O que o matou foi estrutural, e é a mesma coisa que mata a maioria destes projetos: o esforço foi quase todo para construir o modelo e quase nenhum para ser dono dele. E a evidência de que este é o modo de falha normal, e não azar, é esmagadora.
Os grandes projetos de tecnologia e de mudança falham a taxas que deviam fazer refletir qualquer um. A investigação CHAOS, de longa data, do Standish Group tem verificado ao longo dos anos que apenas uma minoria de projetos termina no prazo, no orçamento e com o resultado pretendido, e que os projetos maiores e mais ambiciosos falham com mais frequência, que é precisamente a categoria onde se enquadra uma construção de modelo de vários anos numa plataforma pesada. O trabalho Pulse of the Profession do Project Management Institute faz o ponto mais profundo: a falha não está frequentemente na entrega, mas na concretização de benefícios, as organizações concluí-lo o projeto e depois nunca institucionalizam o valor, porque ninguém é dono do resultado depois de a equipa se dispersar. E do lado da adoção, a investigação da Gartner sobre analítica tem repetidamente verificado que uma grande fatia dos ativos analíticos e de BI está subutilizada ou nunca é sequer adotada, não por falta de qualidade, mas por falta de um dono, de uma cadença e de uma razão para confiar neles. A nossa história não é uma exceção. É a taxa de base.
| O que toda a gente assumiu que o mataria | O que realmente o matou |
|---|---|
| Um desenho conceptual falhado | O desenho era sólido; nunca foi o problema |
| A metodologia errada | A lógica de atividades e de tempo foi a escolha certa |
| Uma plataforma subdimensionada | A plataforma era capaz; a capacidade não era a falha |
| Maus números no primeiro dia | Os números estavam certos no primeiro dia, e só no primeiro dia |
| Nada | Nenhum dono interno, nenhuma cadença de manutenção, nenhuma responsabilização |
Leia a coluna da direita outra vez. Quatro das cinco causas assumidas nunca foram reais. A que era real, a propriedade e a manutenibilidade, foi aquela que ninguém tinha orçamentado, porque não aparece num documento de desenho nem numa demonstração de plataforma. Aparece dezoito meses mais tarde, como silêncio, quando o modelo precisa de uma atualização e não há ninguém cuja função seja dá-la. Um modelo de custo não é um entregável que se termina. É um instrumento vivo, e as coisas vivas precisam de cuidado. É também por isto que a inteligência de custos pertence perto da gestão, e não fechada na plataforma de um especialista: as práticas por trás da gestão baseada em atividades só compensam quando alguém dentro do negócio age sobre elas mês após mês, e a disciplina de custear a capacidade não utilizada só se mantém honesta se os pressupostos de capacidade forem revistos à medida que a operação muda.
Dias, não anos, e um modelo que se mantém vivo
Aqui está o que torna a velha história digna de ser contada: a mesma ambição, hoje, não tem de acabar da mesma forma. A organização da história não estava errada em querer custo verdadeiro por atividade, uma curva da baleia, decisões defensáveis. Foi desiludida por quanto tempo a ambição demorou a alcançar e por quão pouco dela foi construído para durar. Ambas as coisas mudaram.
Com a Cost and Profitability, a CostCtrl e a IA a trabalharem em conjunto, um primeiro modelo defensável é uma questão de dias em vez de anos. O estrangulamento que custou ao operador os seus primeiros dezoito meses, encontrar alguém capaz de traduzir um desenho para uma plataforma pesada, dissolve-se em grande parte, porque o método de modelação e a ferramenta são feitos um para o outro e a IA faz o trabalho pesado de estruturar dados, propor indutores e pôr de pé uma primeira versão depressa. Todos os números se mantêm rastreáveis: pode seguir qualquer resultado para trás, através das atividades e dos indutores, até ao valor de origem, que é exatamente a propriedade que permite às pessoas continuar a confiar num modelo à medida que este é questionado. E, crucialmente, o modelo vive dentro de uma ferramenta que o cliente consegue efetivamente operar e manter, e não uma caixa preta de especialista que se vai embora quando os especialistas se vão. É isso que o torna aderente: o dono é interno por desenho, a cadença de manutenção está embebida na forma como a ferramenta é usada, e atualizar o modelo todos os meses é uma rotina, não um projeto. Tudo isto por uma fração do investimento antigo.
| Antes (a história) | Agora (Cost and Profitability + CostCtrl + IA) |
|---|---|
| ~18 meses para encontrar alguém capaz de o construir | Método e ferramenta desenhados em conjunto; a IA acelera a construção |
| ~18 meses adicionais até um primeiro modelo a funcionar | Um primeiro modelo defensável em dias |
| Números de confiança apenas até a equipa sair | Cada número rastreável até à sua origem, a pedido |
| Vivia numa caixa preta de especialista | Vive numa ferramenta que o cliente opera e mantém |
| Sem dono, sem cadença, morte silenciosa em um ano | Propriedade interna e cadença mensal embebidas |
| Investimento de seis dígitos altos dado como perdido | Uma fração do custo, e mantém-se vivo |
Isto não é um argumento de venda para comprar uma plataforma diferente. É uma teoria diferente sobre o que um modelo de custeio é. Trate-o como um projeto de construção único e comportar-se-á como um edifício que ninguém mantém. Trate-o como um instrumento vivo com um dono, e ele acumula valor, a curva da baleia que traça este ano vale mais no próximo porque continua a ser verdadeira. Se quiser ver a versão mais nítida do contraste, é a diferença exposta em CostCtrl versus folhas de cálculo, e o valor de um modelo que continua a produzir KPIs de rentabilidade e medidas de desempenho fiáveis muito depois de os consultores se irem embora. Para investidores, a mesma durabilidade é o que transforma um diagnóstico de rentabilidade de portefólio pontual numa capacidade que a empresa mantém.
Perguntas frequentes sobre porque falham os modelos de custeio
- Porque falham os modelos de custeio?
- Muito mais por abandono do que por mau método. Um modelo bem desenhado está normalmente correto no dia em que entra em produção; falha mais tarde, quando ninguém é dono dele, ninguém atualiza os dados e as taxas dos indutores, e ele afasta-se lentamente de um negócio em mudança até as pessoas deixarem de confiar nele. A evidência é consistente na investigação sobre projetos e analítica: os estudos CHAOS do Standish mostram que as construções maiores e mais ambiciosas falham com mais frequência, e o trabalho de concretização de benefícios do PMI mostra que o valor se perde frequentemente depois da entrega, e não durante ela. A matemática raramente é a vilã. A propriedade e a manutenibilidade são.
- Quem deve ser o dono de um modelo de custo?
- Alguém dentro da organização, nomeado, antes de o modelo ser construído, e não a equipa de implementação, que se irá embora. Na prática, o dono situa-se na função financeira ou de controlo de gestão, próximo o suficiente do negócio para saber quando a realidade se moveu e sénior o suficiente para ser responsável por manter o modelo atualizado. A coisa mais útil que pode fazer no início de um projeto de custeio é decidir quem o opera depois de os consultores saírem, e desenhar a ferramenta e a cadença para que essa pessoa consiga efetivamente fazê-lo. Um modelo sem um dono interno nomeado é um modelo com prazo de validade.
- Quanto tempo deve demorar a construir um modelo de custeio?
- Historicamente, os modelos ambiciosos em pesadas plataformas empresariais demoravam meses a anos, e uma parte significativa disso era simplesmente encontrar pessoas capazes de implementar o desenho. Com uma abordagem moderna que emparelha o método de modelação com uma ferramenta construída para o efeito e usa IA para estruturar dados e propor uma primeira versão, um primeiro modelo defensável é realisticamente uma questão de dias, depois refinado de forma iterativa. A velocidade importa por mais do que o custo: quanto mais depressa um modelo produz uma resposta fiável, mais cedo conquista a confiança e a propriedade interna que o mantêm vivo.
- Como se evita que um modelo de custeio se desatualize?
- Construa a manutenção desde o início, em vez de a tratar como uma reflexão tardia. Isso significa um dono nomeado, uma cadença mensal fixa para atualizar dados e rever as taxas dos indutores e os pressupostos de capacidade, e rastreabilidade total para que qualquer número possa ser seguido até à sua origem quando é questionado. Significa também que o modelo tem de viver numa ferramenta que a organização consiga operar sozinha, e não num ambiente de especialista que sai porta fora. O desvio não é inevitável; é o que acontece quando não existe uma rotina para o prevenir.
- O problema foi a plataforma, o método ou as pessoas?
- Nenhum deles, na história aqui. O desenho conceptual era sólido, a plataforma era capaz e as pessoas que o construíram eram competentes. A falha foi estrutural: o esforço foi para construir o modelo e quase nenhum para ser dono dele e o manter após a passagem de testemunho. Culpar a ferramenta ou a técnica é reconfortante porque implica uma correção fácil, mas interpreta mal a causa. A correção é tratar um modelo de custo como um instrumento vivo com um dono interno permanente, e não como um projeto que termina no dia em que entra em produção.
Referências
The Standish Group, CHAOS Report (taxas de sucesso, falha e projetos comprometidos, e a relação entre a dimensão do projeto e a falha). · Project Management Institute, Pulse of the Profession (desempenho de entrega e a perda de valor na concretização de benefícios após o encerramento do projeto). · Gartner, investigação sobre a adoção de analítica e de business intelligence (o fosso persistente entre os ativos analíticos construídos e os ativos analíticos efetivamente utilizados). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (Harvard Business School Press) e Kaplan, R. S. & Cooper, R. Cost & Effect (desenhar e, sobretudo, sustentar sistemas de custeio baseados em atividades). · Todos os detalhes de projeto, o setor e os números nesta peça são ilustrativos e compósitos, e não representam nenhum cliente em concreto.