Do Primeiro Contacto a um Modelo de Rentabilidade Vivo e de Confiança
Escolher um parceiro de custeio é uma aposta sobre se os números aguentarão quando uma administração, uma entidade financiadora ou um comprador os contestarem. Esta página expõe exatamente como a Cost and Profitability Consulting leva um cliente de uma primeira conversa a um modelo de rentabilidade governado e atualizável a correr no CostCtrl. O caminho é deliberado e repetível: diagnosticar a pergunta, desenhar o modelo de custos com o custeio baseado em atividades e orientado pelo tempo, construir o pipeline de dados, validar cada número face às contas auditadas, entrar em produção, depois governar e iterar. O TDABC é a espinha dorsal de todo o projeto, e são anos de implementação prática que nos permitem comprimir o prazo sem esvaziar o método.
Em resumo. O percurso tem seis etapas: diagnosticar a pergunta de negócio e confirmar que os dados existem para lhe responder; desenhar um modelo de custos TDABC em torno de conjuntos de recursos, taxas de custo de capacidade e equações de tempo; construir o pipeline de ETL que o alimenta; validar reconciliando cada valor de volta ao balancete; entrar em produção no CostCtrl para que a gestão leia curvas da baleia e custo de servir em vez de médias agregadas; depois governar e iterar para que o modelo se atualize mensalmente e se mantenha de confiança durante anos. O que torna isto rápido e defensável não é uma ferramenta mas uma disciplina. O TDABC precisa apenas de dois dados por atividade, o custo de fornecer capacidade e o tempo que cada transação consome, e implementámo-lo na prática durante tempo suficiente para saber onde se dobra e onde se parte. Fica com um modelo que a sua própria equipa consegue operar; nós garantimos que está certo antes de alguém agir sobre ele.
Porque um percurso definido vence um estudo pontual
A maioria do trabalho de rentabilidade falha não porque a aritmética esteja errada mas porque o projeto não tem forma. Um consultor chega, constrói uma folha de cálculo heroica, apresenta um slide impressionante, e vai-se embora. Três meses depois os números estão obsoletos, ninguém os consegue atualizar, e a conclusão que era suposto mudar a política de preços degradou-se silenciosamente num ficheiro que ninguém abre. O problema nunca foi o método; foi a ausência de um caminho da pergunta ao modelo vivo.
Um percurso definido corrige isso fazendo com que cada etapa produza um artefacto de que a etapa seguinte depende, e tornando o cliente um dono e não uma audiência. O diagnóstico produz uma pergunta delimitada e um inventário de dados. O desenho produz um modelo de custos documentado. A construção produz um pipeline que a sua equipa consegue operar. A validação produz uma reconciliação que bate ao cêntimo. A entrada em produção produz decisões. A governação mantém tudo isto verdadeiro. Nada é resolvido no ar, e nada sai com o consultor.
É também assim que a confiança se ganha em vez de se afirmar. Uma administração não confia num número porque um consultor está confiante; confia num número que viu sobreviver a um portão de reconciliação e a uma sessão de contestação. O percurso abaixo está construído para que, no momento em que a gestão age sobre a curva da baleia, já tenha visto o modelo defender-se a si próprio. Essa é a diferença entre uma história de margem e um facto de margem.
Diagnosticar: a pergunta antes do modelo
O primeiro encontro é uma conversa, não uma proposta. Antes de alguém falar de conjuntos de recursos ou de ETL, precisamos de saber que decisão o modelo é suposto informar. Está a tentar retarifar uma cauda de clientes geradora de prejuízo, decidir que linhas de produto manter, justificar uma sobretaxa de serviço, ou entregar a um proprietário de private equity uma ponte de margem para os primeiros cem dias? A forma da pergunta determina o grão do modelo, e construir no grão errado é o erro mais dispendioso no trabalho de custeio.
A par da pergunta, corremos um inventário rápido de dados. Um modelo de custeio precisa de três tipos de dados: dinheiro, do razão geral e dos saldos de centro de custo; estrutura, do plano de contas e das hierarquias de produto e de cliente; e comportamento, dos indutores operacionais que registam quem consumiu o quê. Onde uma extração direta de ERP é impraticável, um ficheiro SAF-T dá-nos muitas vezes o razão e os dados mestre num único pacote governado, o que permite a um cliente começar sem esperar por uma integração completa. O diagnóstico termina com uma declaração clara do que conseguimos responder já, do que precisa de mais dados, e aproximadamente do que o modelo irá mostrar. A Cost and Profitability empacota isto frequentemente como um Profitability Health Check de âmbito fixo, para que o cliente veja a forma do prémio antes de se comprometer com a construção completa.
Desenhar o modelo de custos com TDABC
Esta é a etapa onde a experiência separa um modelo durável de um frágil, e é onde os nossos anos de implementação prática de custeio baseado em atividades e orientado pelo tempo ganham o seu lugar. O TDABC de Robert Kaplan e Steven Anderson reduz todo o problema a dois números por atividade: a taxa de custo de capacidade, um custo anual de um conjunto de recursos a dividir pela sua capacidade prática, e uma equação de tempo que diz quantos minutos cada transação consome. Acerte nesses dois e o modelo imputa-se a si próprio a partir dos dados de transação.
O trabalho de desenho é decidir quais são os conjuntos de recursos, como se mapeiam a partir dos centros de custo contabilísticos, e como as equações de tempo devem flexibilizar-se com a complexidade real em vez de uma média fixa. Os centros de custo foram construídos para orçamentação e responsabilização, não para causalidade, pelo que a passagem da estrutura contabilística para o modelo de custos raramente é de um-para-um e é o artefacto de desenho mais importante do projeto. Fixamos a capacidade prática com honestidade, em cerca de 80 a 85 por cento da teórica, para que a capacidade ociosa apareça como um número visível em vez de ser diluída no produto e fazer produtos saudáveis parecerem caros.
Dois juízos decidem se um modelo envelhece bem, e ambos vêm de ter construído muitos deles.
| Juízo de desenho | O instinto inexperiente | A escolha experiente |
|---|---|---|
| Granularidade | Modelar cada microatividade em nome da precisão | Parar onde os dados de indutor deixam de ser fiáveis; quarenta boas atividades vencem quatrocentas adivinhadas |
| Escolha do indutor | Usar qualquer contagem que seja mais fácil de extrair | Escolher o indutor que efetivamente causa o custo, mesmo quando é mais difícil de obter |
| Capacidade | Custear à capacidade teórica e esconder a folga | Custear à capacidade prática para que a capacidade não utilizada seja uma linha reportada |
| Equações de tempo | Um único minuto médio por transação | Equações que flexibilizam com a dimensão de encomenda, o canal e a complexidade |
O resultado desta etapa é um desenho de modelo documentado: os conjuntos, as taxas, as equações de tempo e a tabela de mapeamento, tudo numa forma que o cliente consegue ler e contestar antes de se construir uma linha de pipeline.
Construir: o pipeline de dados que alimenta o modelo
Com o desenho acordado, a etapa de construção transforma extrações em bruto no conjunto de dados limpo, mapeado e pronto por indutor que o motor de custeio consome. Esta é a camada de ETL, e o seu valor concentra-se no passo de transformação: limpar e reconciliar as extrações, mapear centros de custo para os conjuntos de recursos do desenho, derivar quantidades de atividade a partir de eventos operacionais, e conformar cada produto e cliente a uma única chave estável para que uma conta não apareça três vezes sob três grafias.
Somos deliberadamente agnósticos quanto à ferramenta aqui, porque o pipeline tem de ser mantível pela sua equipa depois de sairmos. Construímos dentro do que a sua equipa de dados já usa com confiança, seja Alteryx, Power Query, KNIME, Talend, dbt ou SQL simples. Um cliente cujos dados já aterram num data warehouse na nuvem obtém transformações versionadas e testáveis que um auditor respeitará; um cliente a trabalhar a partir de extrações de ERP e de folhas de cálculo obtém uma combinação amigável para o analista que chega a um modelo mais depressa. A lógica de custeio é idêntica em todos eles; só a sintaxe muda. O que nunca muda é a regra de que a extração e a transformação têm de ser automatizadas, para que uma atualização mensal seja um botão e não um projeto.
Validar: provar cada número antes de alguém agir
Nenhum número sai desta etapa sem ter sobrevivido a dois portões. O primeiro é o portão de reconciliação: a soma de cada custo carregado no modelo tem de igualar o balancete auditado ao cêntimo. Se o custo extraído não bater com as contas, nada a jusante é credível, e automatizamos esta verificação em vez de a conferir a olho para que corra em cada atualização, e não apenas no arranque. Um modelo de custeio que discorda do balancete é quase sempre um problema de ETL, um razão esquecido ou uma especialização inconsistente de um acréscimo, e o portão é onde isso é apanhado.
O segundo portão é uma sessão de contestação com as pessoas que conhecem o negócio. Levamos o modelo às equipas de operações e comercial e testamos os seus resultados contra a intuição delas. Quando o modelo diz que uma conta emblemática é não rentável, a pergunta é se isso é uma verdadeira conclusão de custo de servir ou um indutor partido que redistribui silenciosamente lucro entre clientes. Um indutor que não causa verdadeiramente um custo é o erro mais perigoso no custeio porque o modelo continua a bater certo; está apenas errado de uma forma que nenhuma reconciliação apanha. Passar os resultados pelas pessoas mais próximas do trabalho é como encontramos esses erros antes de uma decisão assentar neles. O modelo que emerge é ao nível da decisão e defensável sob escrutínio de um diretor financeiro, de uma entidade financiadora ou da equipa de diligência de um comprador.
Entrar em produção no CostCtrl
A entrada em produção é o ponto em que o modelo validado deixa de ser um projeto e passa a ser um instrumento que a gestão lê. O CostCtrl consome os dados conformados, os conjuntos de recursos com os seus custos, os objetos de custo com as suas chaves e as quantidades de indutor por período, e corre o cálculo TDABC por cima: taxas de custo de capacidade, consumo por equação de tempo, reporte de capacidade não utilizada, e as visões de rentabilidade e de curva da baleia sobre as quais a liderança atua. A divisão de trabalho é deliberada. O pipeline detém a correção e a repetibilidade dos dados de entrada; o CostCtrl detém o método de custeio e os resultados.
O que muda para o cliente é a natureza da conversa. Em vez de uma média agregada que esconde a distribuição por trás dela, a gestão vê cada cliente, produto e canal ordenado por margem líquida verdadeira, e a curva da baleia que mostra o lucro cumulativo a subir bem acima do total reportado antes de uma cauda geradora de prejuízo o puxar de volta para baixo. Essa diferença é o prémio recuperável, e é agora algo sobre o qual a equipa pode agir: retarifar, reescalonar o serviço, definir regras de encomenda mínima ou renegociar termos. Como o modelo é vivo e não uma folha de cálculo estática, um controller consegue responder a uma pergunta da administração em minutos em vez de semanas, e a resposta liga-se às contas.
Governar e iterar: manter o modelo de confiança
Um modelo vivo não é um modelo acabado. A última etapa é a governação: as rotinas que mantêm o modelo verdadeiro à medida que o negócio muda, para que a confiança ganha na validação não se erosione ao longo do ano seguinte. Um modelo que estava certo no arranque e nunca mais foi tocado é um regresso lento à folha de cálculo obsoleta de que todo o percurso pretendia escapar.
A governação é sobretudo um punhado de hábitos permanentes. A atualização mensal corre o pipeline automatizado e volta a passar o portão de reconciliação, para que o desvio seja apanhado no mês em que aparece e não no fecho do ano. A tabela de mapeamento e as equações de tempo são versionadas e levam aprovação, para que uma mudança na estrutura organizativa ou uma nova linha de produto atualize o modelo deliberadamente e não por acidente. A propriedade fica com a equipa financeira do cliente, connosco à mão para a revisão periódica, para que o modelo não dependa da memória de uma única pessoa. Os mesmos dados governados estendem-se depois naturalmente para a gestão baseada em atividades e para os KPI de rentabilidade, para que a margem recuperada se mantenha visível no painel da administração e os ganhos apareçam nos números trimestre após trimestre. O custeio mantém-se rigoroso; o modelo mantém-se seu.
- Quanto tempo demora o percurso do primeiro contacto a um modelo vivo?
- Para uma empresa de mercado intermédio com dados de ERP utilizáveis, um modelo ao nível da decisão pode estar em produção em semanas em vez de trimestres. O TDABC precisa apenas de dois dados por atividade, uma taxa de custo de capacidade e uma equação de tempo, pelo que um primeiro modelo pode levantar-se depressa e ser refinado à medida que as decisões são escolhidas. Muitos clientes começam com um Profitability Health Check de âmbito fixo para dimensionar o prémio, e depois avançam para a construção completa assim que a forma da resposta está clara.
- Porque é que o TDABC importa tanto na vossa abordagem?
- O custeio baseado em atividades e orientado pelo tempo é o que torna o modelo simultaneamente rápido e defensável. Reduz o custeio a dois números por atividade, o custo de fornecer capacidade e o tempo que cada transação consome, o que nos permite construir sobre dados que uma empresa já guarda e separar o custo do trabalho feito do custo da capacidade ociosa. São anos de implementação prática que nos permitem escolher a granularidade e os indutores certos, os juízos que decidem se um modelo envelhece bem ou se desmorona.
- Ficamos com o modelo, ou ele sai com o consultor?
- Fica com ele. O pipeline é construído na ferramenta que a sua equipa de dados já usa com confiança, o desenho do modelo é documentado, e a propriedade fica com a sua equipa financeira. Somos o parceiro de implementação em toda a cadeia, do diagnóstico à governação, mas o que entregamos é um modelo auditável que a sua equipa consegue operar sem nós, não uma caixa negra que sai porta fora.
- Como garantem que os números são de confiança antes de agirmos sobre eles?
- Dois portões. Cada custo carregado no modelo tem de reconciliar com o balancete auditado ao cêntimo, e essa verificação é automatizada para que corra em cada atualização. Depois os resultados vão a uma sessão de contestação com as equipas de operações e comercial para os testar contra a realidade e apanhar qualquer lógica de indutor partida, que é o único erro que uma reconciliação não consegue encontrar. Só um modelo que sobrevive a ambos os portões é usado para uma decisão.
- O que acontece depois de o modelo entrar em produção?
- A governação mantém-no verdadeiro. Uma atualização mensal corre o pipeline automatizado e volta a passar o portão de reconciliação, a tabela de mapeamento e as equações de tempo são versionadas com aprovação, e a propriedade fica com a sua equipa, connosco à mão para a revisão periódica. Os mesmos dados governados estendem-se para a gestão baseada em atividades e para os KPI de rentabilidade, para que a margem recuperada se mantenha visível e o modelo se mantenha de confiança durante anos em vez de se degradar numa folha de cálculo obsoleta.
Fontes e leitura adicional: Robert S. Kaplan & Steven R. Anderson, Time-Driven Activity-Based Costing (Harvard Business Review, 2004; Harvard Business Review Press) · OCDE, Guidance for the Standard Audit File - Tax (SAF-T) · IMA e literatura de praticantes sobre a implementação do custeio baseado em atividades e os seus requisitos de dados