Do Projecto a um Modelo Que Funciona: Fechar o Fosso da Implementação
O modelo de custos mais caro é aquele que foi lindamente desenhado e nunca chegou a funcionar. Este texto é um cenário compósito, extraído de experiência real de terreno em várias implementações de modelos de custos; o sector, os intervenientes e todos os números são ilustrativos e não representam nenhum cliente concreto. Trata da falha silenciosa e comum na contabilidade de gestão: um desenho conceptual impecável, muitas vezes validado por uma consultora global, que fica encalhado algures entre o baralho de slides e um motor vivo que responde a perguntas numa manhã de segunda-feira.
O fosso da implementação é a distância entre um modelo de custeio que está desenhado e um que efectivamente opera, actualizando-se com dados reais, produzindo números que um controller vai defender e mudando aquilo que os gestores decidem. A maioria dos desenhos não falha porque a contabilidade esteja errada; falha na execução. Três forças fazem o estrago: não existe um implementador que detenha na mesma cabeça tanto a lógica de contabilidade de gestão como a competência na plataforma, pelo que o desenho é passado de mão em mão através de um fosso de tradução; a plataforma foi escolhida pelo prestígio e pelo conforto do procurement em vez de por alguém conseguir de facto operá-la; e o âmbito ultrapassa os dados, prometendo uma granularidade que os sistemas de origem não conseguem alimentar. A implementação especializada fecha o fosso ao construir o modelo como um activo operacional desde o primeiro dia, uma arquitectura de custos defensável, um pipeline de dados que sobrevive ao fecho mensal seguinte e resultados ligados a decisões reais. O ganho não é um modelo mais bonito; é a passagem de discutir os números para agir sobre eles. Com a Cost and Profitability, a plataforma CostCtrl e o mapeamento assistido por IA, a ponte que antes exigia muitos meses de esforço de consultoria pode agora ser atravessada em dias.
Um desenho é uma promessa; um modelo a funcionar é o pagamento
Existe um tipo particular de documento que circula dentro das grandes organizações: o projecto do modelo de custos. Costuma ser excelente. Tem diagramas de fluxo de cost pools e actividades, um driver para cada alocação, um organigrama de governação e um anexo que antecipa as perguntas incómodas. Foi produzido por gente competente, muitas vezes uma Big Four ou uma consultora global, e sobrevive ao seu comité de acompanhamento com aplausos calorosos. E depois, num número surpreendente de casos, nada acontece. Doze ou dezoito meses mais tarde o desenho continua a ser um desenho, as velhas alocações em folha de cálculo continuam a gerir o negócio, e o patrocinador já seguiu discretamente em frente.
Isto é o fosso da implementação, e não é um acidente raro. A longa investigação CHAOS do Standish Group tem constatado, ao longo de décadas, que apenas uma minoria dos projectos apoiados em tecnologia termina a tempo, dentro do orçamento e com o resultado pretendido, sendo os programas grandes e complexos os que pior se saem. Um modelo de custeio é exactamente esse tipo de programa: parte contabilidade, parte engenharia de dados, parte gestão da mudança. Um projecto é uma promessa sobre como o negócio vai compreender a sua própria economia. Um modelo que funciona é o pagamento dessa promessa, e os dois estão separados por trabalho que nenhum slide pode fazer por si.
Como um desenho forte encalha, numa história compósita de terreno
Imagine um grande operador de infra-estruturas intensivo em capital, por volta de 2019, os detalhes são um compósito, extraído de vários projectos e representando nenhum em concreto. Encomendou um desenho completo de custeio baseado em actividades a uma consultora global. O entregável era genuinamente bom: uma arquitectura de custos multicamada, várias centenas de actividades, dezenas de definições de driver e um objectivo de alocar o custo partilhado de rede e de suporte até ao nível de serviço e de percurso. O conselho de administração aprovou-o. Depois, o modelo teve de ser construído numa pesada plataforma empresarial de gestão de custos que o grupo havia licenciado, escolhida, como tantas vezes acontece, por ser o nome seguro e prestigiado que o procurement e a auditoria assinavam sem hesitação.
Foi aí que encalhou, e as razões rimam em muitos projectos deste género. Não havia uma única pessoa que compreendesse tanto a intenção contabilística como a plataforma. A equipa de consultoria conhecia o desenho mas não a ferramenta; a equipa interna de TI conhecia os sistemas mas não o porquê de a actividade A dever absorver o cost pool B. A plataforma, poderosa no papel, precisava de uma configuração especializada que ninguém disponível conseguia fornecer, pelo que uma alteração a um único driver levava semanas e uma fila de espera. E o âmbito tinha sido traçado contra um modelo de dados idealizado: a granularidade que o desenho pressupunha simplesmente não estava presente, nem limpa, nos razões de origem e nos feeds operacionais. Cada uma destas três falhas é sobrevivível isoladamente. Juntas, são o modo como um modelo aprovado pelo conselho passa dois anos como documento.
Os três fossos entre o baralho de slides e o motor
O fosso de competências. Um modelo de custeio vive num cruzamento invulgar. Precisa de alguém que consiga defender por que razão um custo é atribuído da maneira que é, a lógica de contabilidade de gestão sobre a qual um controller será interrogado, e, na mesmíssima decisão, alguém que consiga fazer a plataforma executá-lo de facto. Na maioria dos programas, essas são duas pessoas diferentes em dois contratos diferentes, e o desenho atravessa um fosso de tradução sempre que muda de mãos. O sentido escapa-se nessa fronteira. O implementador que detém ambas as competências ao mesmo tempo é raro, e a sua ausência é o preditor mais fiável de que um bom desenho não chegará a produção.
O fosso da plataforma. O software empresarial é frequentemente escolhido por razões que nada têm a ver com a possibilidade de alguém conseguir correr o modelo lá dentro: conforto de marca, uma licença existente, familiaridade da auditoria, uma grelha de avaliação de procurement. Uma pesada suíte empresarial de custeio pode ser inteiramente capaz e ainda assim ser a escolha errada se cada alteração exigir um especialista escasso e um ticket de várias semanas. A usabilidade não é um luxo num modelo de custos; é o que decide se o modelo continua a ser actualizado depois de os consultores saírem, ou se congela no dia em que o fazem. A nossa nota complementar sobre porque os modelos derivam de volta para folhas de cálculo é, no fundo, uma história sobre este fosso.
O fosso dos dados. A ambição num desenho de custeio mede-se em granularidade, alocar tudo, ao objecto mais baixo possível, com os drivers mais finos. Mas um modelo só pode ser tão detalhado quanto os dados que o alimentam todos os meses, de forma limpa e a horas. Quando o âmbito ultrapassa os sistemas de origem, o modelo ou não consegue sequer ser preenchido ou é preenchido com um esforço manual heroico que se desmorona no segundo fecho mensal. A investigação da Gartner sobre analítica tem constatado repetidamente que uma grande parte dos activos construídos nunca chega a um uso de negócio real e sustentado, e um modelo de custeio que não pode ser alimentado é a versão contabilística exactamente disso.
Construir o modelo como activo operacional, não como documento
A implementação especializada não é "o desenho, mas mais depressa". É uma disciplina diferente, e parte de uma pergunta diferente: não "esta arquitectura é elegante?" mas "isto vai continuar a funcionar, sem vigilância, no terceiro fecho?" Essa reformulação muda todas as escolhas. Os cost pools são moldados em torno de drivers que os dados conseguem efectivamente fornecer, não dos drivers que um quadro branco preferiria. A lógica de alocação é construída para que um controller consiga rastrear qualquer número até à sua origem e defendê-lo, a mesma rastreabilidade de que a gestão baseada em actividades depende para mudar comportamentos em vez de apenas reportar. E todo o conjunto está ligado a um pipeline de dados repetível, de modo que a actualização mensal seja uma rotina, não um projecto.
O especialista faz também a triagem pouco glamorosa que decide o sucesso: quais os 20% do desenho que carregam 80% do valor de decisão, para que o modelo possa entrar em produção útil e crescer, em vez de esperar anos para entrar em produção completo. Kaplan e Anderson defenderam exactamente este argumento quando introduziram o custeio baseado em actividades e no tempo, que os modelos ABC mais antigos, totalmente elaborados, colapsavam sob o seu próprio peso de manutenção, e que uma abordagem mais enxuta, assente em equações de tempo, era o que permitia a um modelo manter-se de facto vivo numa empresa real. A implementação especializada é a expressão operacional dessa lição: construir o modelo para funcionar, não para impressionar, e deixar que o funcionamento ganhe o direito a mais detalhe.
O que muda quando o modelo sai do slide
A forma mais clara de ver o valor de fechar o fosso é observar o que acontece às decisões. A tabela abaixo contrasta como uma questão de gestão é tratada quando o modelo de custos vive num baralho de slides face a quando funciona como um motor vivo. Os exemplos são ilustrativos, representativos do padrão e não dos resultados de qualquer cliente concreto.
| Decisão | Projecto em PowerPoint | Modelo que funciona (ilustrativo) |
|---|---|---|
| "Que serviços perdem de facto dinheiro?" | Um estudo pontual, com meses de idade, discutido porque ninguém consegue reproduzir os números | Actualizado a cada fecho; um serviço deficitário fica visível no mês em que vira, com o rasto de custo anexado |
| Precificar um novo contrato | Intuição mais uma taxa média agregada, porque o modelo não pode ser corrido sobre o novo cenário | O cost-to-serve específico é modelado em minutos, para que a proposta reflicta a economia real e não uma média |
| Cortar custos sob pressão | Cortes percentuais transversais, porque não há uma visão defensável de onde o custo se concentra | Dirigido às actividades e à capacidade ociosa que o modelo expõe, dimensionado contra um preço-sombra e não um palpite |
| Rever capacidade não utilizada | Invisível; o custo fixo é totalmente absorvido no output e o desperdício esconde-se dentro das taxas | O custo da capacidade não utilizada é discriminado de forma explícita, transformando uma perda oculta num número gerido |
| Perguntas do conselho e dos investidores | Respondidas lentamente, na defensiva, com ressalvas sobre a idade e os pressupostos do modelo | Respondidas na própria reunião, a partir de um modelo vivo, com drill-down quando alguém insiste sobre um número |
| Confiança nos números | O debate é sobre se o modelo está certo | O debate é sobre o que fazer, porque o modelo deixou de ser o argumento |
Essa última linha é o verdadeiro prémio. O objectivo de fechar o fosso da implementação não é vaidade analítica; é deslocar toda a energia da organização de litigar os números para agir sobre eles. É também a base para tudo o que vem a jusante, KPIs de rentabilidade honestos, uma visão de valor económico acrescentado que imputa o capital que cada unidade consome, ou um diagnóstico de rentabilidade ao nível de portefólio, transversal às participadas. Nenhum deles pode assentar num modelo que existe apenas como slide.
As ciladas que mantêm o fosso aberto
Tratar o arranque em produção como a linha de chegada. Um modelo que funciona uma vez não é um modelo a funcionar. Se não houver um dono da actualização mensal nem uma forma simples de alterar um driver, o activo apodrece no dia em que os implementadores saem. A investigação Pulse of the Profession do PMI tem, há muito, associado maus resultados a fraca titularidade e disciplina de mudança, e um modelo de custos está invulgarmente exposto a ambas.
Confundir o poder da plataforma com o sucesso do projecto. A suíte empresarial mais capaz do mundo nada acrescenta se ninguém na equipa a conseguir operar entre projectos. A pergunta certa nunca é "quão poderosa é a ferramenta?" mas "quem altera um driver no próximo trimestre, e quanto tempo lhe leva?"
Desenhar para uma realidade de dados que não existe. Granularidade que os sistemas de origem não conseguem alimentar não é ambição; é um encalhe à espera de acontecer. Dimensione o modelo aos dados que tem de facto todos os meses, e deixe que dados mais limpos ganhem mais detalhe depois.
Âmbito big-bang. Um desenho que insiste em alocar tudo antes de produzir seja o que for produzirá, em geral, nada. Os modelos que sobrevivem entram em produção estreitos e úteis, e depois alargam.
Sem fio do número até à decisão. Se um gestor não conseguir rastrear um resultado até a um custo que reconhece, não vai confiar nele, e números em quem não se confia não mudam comportamentos. A adesão é uma restrição de desenho, não uma reflexão tardia.
Fechar o fosso em dias, não em trimestres
O que tornava o fosso da implementação tão largo era que as três falhas eram caras de corrigir à mão. Encontrar uma pessoa com as competências contabilísticas e de plataforma era raro; configurar uma suíte pesada era lento; e mapear dados de origem confusos para um modelo de custos limpo eram meses de reconciliação manual. Cada um deles é agora um problema diferente. A Cost and Profitability traz a disciplina combinada, lógica de contabilidade de gestão e implementação prática na mesma equipa, para que o desenho nunca atravesse um fosso de tradução. O CostCtrl substitui a plataforma pesada em prestígio e só para especialistas por uma construída para ser operada pela própria equipa de finanças, onde alterar um driver é uma tarefa, não um ticket. E o mapeamento assistido por IA colapsa o fosso dos dados, propondo como as contas de origem e os feeds operacionais mapeiam para cost pools e drivers, de modo que o pipeline que antes levava um trimestre de reconciliação é montado e validado em dias.
A afirmação é deliberadamente modesta e específica: não que a contabilidade se torna trivial, um modelo de custos defensável continua a exigir critério, mas que a distância entre um desenho sólido e um modelo que funciona colapsou genuinamente. O projecto já não tem de ficar numa gaveta à espera de um implementador escasso, de uma plataforma mais amigável e de um milagre de dados. É isto que significa fechar o fosso da implementação: o modelo que foi desenhado é, em dias, o modelo que funciona.
Perguntas frequentes sobre o fosso da implementação do modelo de custos
- Porque é que tantos modelos de custos bem desenhados nunca chegam a ser implementados?
- Porque desenho e implementação são disciplinas diferentes que raramente estão nas mesmas mãos. Um modelo encalha quando ninguém detém tanto a lógica de contabilidade de gestão como a competência na plataforma, pelo que o desenho perde sentido de cada vez que é passado entre equipas; quando o software foi escolhido pelo prestígio e não pela usabilidade, pelo que cada alteração exige um especialista escasso; e quando o âmbito pressupõe uma granularidade de dados que os sistemas de origem não conseguem de facto fornecer todos os meses. A investigação ampla sobre projectos, como os estudos CHAOS do Standish, mostra há muito que os programas grandes e complexos falham na execução muito mais vezes do que no conceito, e um modelo de custeio é exactamente esse tipo de programa.
- Qual é a diferença entre um modelo de custos que está desenhado e um que funciona?
- Um modelo desenhado é um projecto, arquitectura, drivers, governação, que descreve como o custeio deveria funcionar. Um modelo a funcionar actualiza-se com dados reais a cada fecho, produz números que um controller consegue rastrear e defender, e alimenta decisões concretas. O fosso entre eles é operacional, não conceptual: um pipeline de dados que sobrevive ao fecho de mês seguinte, uma plataforma que alguém consegue de facto actualizar, e resultados ligados a escolhas de preço, custo e capacidade. O desenho é uma promessa; o modelo a funcionar é o pagamento.
- Comprar uma poderosa plataforma empresarial de custeio garante o sucesso?
- Não, e muitas vezes o oposto. Uma pesada suíte empresarial pode ser inteiramente capaz e ainda assim ser a escolha errada se apenas um especialista escasso a conseguir operar e cada alteração levar semanas. As plataformas escolhidas por conforto de marca ou familiaridade de procurement congelam frequentemente o modelo no dia em que os consultores saem, porque a equipa de finanças não o consegue manter. A pergunta decisiva não é quão poderosa é a ferramenta, mas quem actualiza um driver no próximo trimestre e quanto tempo lhe leva.
- Como é que a implementação especializada fecha de facto o fosso?
- Construindo o modelo como um activo operacional desde o primeiro dia, e não como um documento. Isso significa moldar os cost pools em torno de drivers que os dados conseguem realmente fornecer, tornar cada alocação rastreável para que um controller a possa defender, montar um pipeline mensal repetível e entrar em produção com os 20% de alto valor do desenho em vez de esperar pelos 100% completos. É a forma operacional do argumento que Kaplan e Anderson defenderam para o custeio baseado em actividades e no tempo: construir um modelo suficientemente enxuto para se manter vivo numa empresa real, e deixar que o seu uso ganhe mais detalhe.
- Podem a IA e as ferramentas modernas encurtar mesmo a implementação de um modelo de custos para dias?
- Para as partes que antes consumiam o calendário, sim. Os três atrasos clássicos, encontrar um implementador de dupla competência, configurar uma plataforma pouco amigável e mapear manualmente dados de origem confusos, são cada um deles resolvidos por uma equipa de implementação combinada, uma plataforma construída para ser operada pela própria área financeira e o mapeamento assistido por IA das contas de origem para cost pools e drivers. O que não encolhe é o critério numa arquitectura de custos defensável. Por isso a afirmação honesta é mais estreita do que "custeio instantâneo": a distância de um desenho sólido a um modelo vivo colapsou de trimestres para dias, não a própria contabilidade.
Referências
Standish Group, CHAOS Report (taxas de sucesso e de falha de projectos, com os programas grandes e complexos a saírem-se pior). · Project Management Institute, Pulse of the Profession (a ligação entre resultados de projecto, titularidade e disciplina de mudança). · Investigação da Gartner sobre analítica e adoção de dados e analítica (o fosso persistente entre activos construídos e activos utilizados). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (porque colapsam os modelos de custos elaborados sob a manutenção, e o modelo mais enxuto que sobrevive). · Kaplan, R. S. & Cooper, R. Cost & Effect (desenhar sistemas de custos que informam decisões em vez de apenas reportar).