Os projetos de custeio baseado em atividades raramente encalham no método. Encalham na terceira semana, quando alguém pergunta que dados o modelo vai precisar e a resposta chega sob a forma de uma lista suficientemente longa para justificar adiar tudo para o ano seguinte. Essa lista está quase sempre errada. Um primeiro modelo ABC precisa de muito menos do que acredita quem a está a compilar, e praticamente tudo já se encontra em sistemas que a empresa usa todos os dias.
Que dados são precisos para começar um modelo ABC?
Quatro entradas. O razão de custos de um período já fechado, uma lista das atividades que as equipas efetivamente executam, uma medida do tempo ou da capacidade que cada atividade consome, e os volumes dos produtos, serviços ou clientes que quer custear. A primeira e a quarta já existem no ERP e no sistema de faturação. A segunda e a terceira vêm dos seus próprios responsáveis, não de software novo. Um primeiro modelo não exige um projeto informático.
Comece pelo custo que já reporta
O custeio baseado em atividades não cria custo. Reencaminha custo que já foi reconhecido, pelo que o ponto de partida é o razão de um período fechado, ao nível de conta e centro de custo que o ERP já produz hoje. Resista à tentação de encomendar uma extração especial. Se a equipa financeira tiver de construir algo novo antes de o modelo poder arrancar, o modelo ganhou uma dependência de que não precisava e um atraso que não vai recuperar.
A única restrição que interessa verdadeiramente é a reconciliação. Tudo o que o modelo alocar tem de somar de volta ao mesmo total que as contas reportam para aquele período, ao cêntimo. Um modelo que não fecha com os números publicados vai ser contestado em vez de utilizado, e todas as discussões passarão a ser sobre o fecho de contas em vez de serem sobre a decisão que o modelo foi construído para apoiar.
As quatro entradas, e onde cada uma já vive
A primeira entrada é o custo por conta e centro de custo, diretamente do ERP. A segunda é a lista das atividades que cada departamento executa, e obtém-se numa sessão curta com quem faz o trabalho, não a partir de um sistema. A terceira é quanto tempo ou capacidade cada atividade consome, construída a partir de efetivos, planos de turnos, horas-máquina e estimativas das chefias. A quarta é o volume por objeto de custo: encomendas, linhas, entregas, chamadas de assistência, doentes ou pedidos, retirados da faturação, do CRM ou do sistema de armazém.
Repare em quais são as duas que geram receio. As entradas dois e três são as que provocam hesitação, e são exatamente as duas que nunca saem de um sistema, em nenhuma empresa e em nenhum grau de maturidade. Esperar que apareçam numa base de dados é esperar por algo que não acontece.
Tempo estimado também é dado. A precisão não é a restrição.
A variante orientada ao tempo do custeio por atividades, publicada por Robert Kaplan e Steven Anderson em 2004, foi desenhada precisamente à volta deste problema: as estimativas são entradas aceitáveis, desde que sejam verificadas. Um responsável que diz que recolher uma linha de encomenda demora cerca de noventa segundos deu-lhe um número utilizável, porque noventa segundos multiplicados pelo volume de linhas podem ser confrontados com as horas que o departamento realmente trabalhou. O valor está na verificação. Uma estimativa que sobrevive a ela é evidência; uma estimativa que falha acaba de lhe indicar onde o modelo está errado.
O erro caro corre no sentido inverso: encomendar um estudo de tempos e métodos antes de existir um primeiro modelo. Isso transforma um exercício de quatro semanas num exercício de seis meses e produz precisão sobre atividades que podem vir a consumir dois por cento da base de custos. Construa o modelo aproximado, veja onde o dinheiro se concentra, e gaste esforço de medição apenas aí.
O que trava mesmo estes projetos, e não é a qualidade dos dados
Há duas coisas que os travam, e nenhuma delas aparece na lista de dados. A primeira é ninguém ter decidido o que está a ser custeado. Se não ficou assente se o modelo vai produzir rentabilidade por produto, por cliente, por canal ou pelos três, qualquer pedido de dados parece não ter limite, porque genuinamente não tem. Fixe primeiro o objeto de custo e o requisito de dados encolhe para algo que uma única pessoa consegue reunir.
A segunda é a lista de atividades não ter dono e derivar. Entre vinte e quarenta atividades chegam para sustentar um primeiro modelo na maioria das organizações de média dimensão. Uma lista que chega às duzentas é sinal de que a sessão desceu do nível de atividade para o nível de tarefa, e o detalhe adicional não compra nada além de um encargo de manutenção que garante que o modelo nunca será atualizado. Para ver a forma que isto assume na prática, uma leitura de custo de servir costuma ser o primeiro corte mais limpo.
A pergunta nunca é se os seus dados são bons o suficiente para modelar. É se a sua alocação seria melhor do que a média que está a usar hoje.
Um teste de uma tarde antes de se comprometer
Escolha um mês já fechado. Extraia o razão por conta e centro de custo. Extraia os volumes do mesmo mês pelo objeto de custo que escolheu. Peça a dois diretores de departamento que listem o que as equipas fazem e que percentagem da semana cada atividade ocupa, aproximadamente. Se conseguir juntar estas quatro coisas numa tarde, tem o suficiente para um modelo piloto e a discussão sobre prontidão dos dados está encerrada.
Se não conseguir produzir volumes por objeto de custo, encontrou a lacuna verdadeira, e vale a pena nomeá-la com precisão: é uma lacuna de reporte, não de custeio. Vai bloquear qualquer análise de rentabilidade que alguma vez tente fazer, seja ela baseada em atividades ou não, e resolve-se normalmente no sistema de origem em dias e não em meses. Todo o resto da lista de desejos habitual de dados para custeio baseado em atividades pode esperar pela versão dois.
O nosso workshop prático de TDABC leva-o de uma extração do razão a um primeiro modelo de rentabilidade, usando as quatro entradas acima e mais nada.