ETL para Análise de Custos e Rentabilidade

O que um modelo de rentabilidade realmente precisa dos seus dados

Antes de qualquer conversa sobre ferramentas, vale ser preciso sobre os insumos. Um modelo de custeio baseado em atividades e tempo precisa, no seu núcleo, de apenas duas coisas, como Kaplan e Anderson o formularam: o custo por unidade de tempo de disponibilizar capacidade, e o tempo que cada transação, produto ou cliente consome. Tudo o que o ETL faz está a serviço de produzir esses dois números de forma limpa e repetível.

Na prática, isso se resolve em um pequeno número de domínios de dados. Cada um tem um sistema de origem natural e um modo de falha diferente, e é exatamente por isso que vale a pena separá-los na entrada.

Repare que só o primeiro domínio é estritamente financeiro. O sinal de custeio que separa um bom modelo de uma planilha vive nos três últimos: sem volumes e drivers você consegue ratear custo, mas não consegue explicá-lo. É por isso que um projeto de ETL para custeio é um exercício de finanças e operações, e não só de finanças.

Do razão bruto aos pools de recursos e drivers

Extrair e carregar são os verbos fáceis. Transformar é onde um pipeline de custeio ganha o seu sustento, e a etapa se decompõe em quatro tarefas que devem ser construídas e testadas em ordem.

Limpar e conciliar. Eliminar duplicidades, corrigir tipos de dados, padronizar datas e moedas, e provar que a soma do que foi carregado é igual ao balancete, ao centavo. Se o custo extraído não amarra com as contas auditadas, nada rio abaixo é crível. Esse portão de conciliação é inegociável e deve ser automatizado, não conferido no olho.

Mapear centros de custo para pools de recursos. Um pool de recursos agrupa custos que se comportam da mesma forma e são consumidos pelo mesmo driver: uma equipe de separação, uma frota, uma central de atendimento, uma célula CNC. Os centros de custo do ERP foram desenhados para orçamento e responsabilidade, não para causalidade, então o mapeamento raramente é um-para-um. Alguns centros se dividem entre pools; alguns pools bebem de vários centros. Essa tabela de mapeamento, a ponte da estrutura contábil para o modelo de custos, é o artefato mais importante de todo o pipeline e o que mais merece controle de versão e aprovação formal.

Derivar os drivers de atividade. Transformar eventos brutos nas quantidades de driver que o modelo consome: contar linhas de pedido por cliente, somar minutos de máquina por produto, agregar entregas por rota. Em um modelo baseado em tempo, é também aqui que as equações de tempo são alimentadas, traduzindo as características das transações em minutos estimados, para que o tempo de processamento flutue com a complexidade do mundo real em vez de uma média chapada. Veja o método TDABC para o papel das equações de tempo no motor.

Conformar chaves e hierarquias. Dar a cada produto, cliente e objeto de custo uma chave única e estável, e ligá-la às hierarquias sobre as quais o negócio reporta: custo para servir por canal, margem por segmento, contribuição por mix de produtos. Sem chaves conformadas, um cliente que aparece três vezes sob três grafias vai exibir três margens enganosas.

Armadilhas comuns: lixo na entrada, excesso de granularidade, lógica de driver quebrada

A maioria dos modelos de custeio que perdem a credibilidade da sala o fazem por razões de insumo, não de método. Quatro padrões de falha se repetem com frequência suficiente para merecer nome.

Lixo na entrada. Extrações não conciliadas, provisões lançadas errado e centros de custo carregando custos que pertencem a outro lugar. Se a entrada não amarra com o balancete, o modelo herda cada erro e não ganha nenhuma das desculpas. Corrija isso no portão de conciliação, nunca depois.

Excesso de granularidade. O instinto de modelar cada micro-atividade produz pipelines frágeis, lentos de atualizar e impossíveis de explicar. Um modelo com 400 atividades costuma ser menos preciso do que um com 40, porque as 360 extras são movidas por dados chutados. A granularidade deve parar onde os dados de driver deixam de ser confiáveis.

Lógica de driver quebrada. Um driver que não causa de fato o custo, uma contagem de pedidos fazendo as vezes do esforço de armazém quando os itens por pedido variam dez vezes, redistribui lucro entre clientes em silêncio. É a armadilha mais perigosa, porque o modelo continua fechando; ele está simplesmente errado de um jeito que nenhuma conciliação pega. A escolha de drivers merece o mesmo escrutínio que o mapeamento de custos.

Pipelines de uma vez só. Uma construção manual heroica que ninguém consegue atualizar no trimestre seguinte é um relatório, não um modelo. Se recarregar os dados exige uma semana da memória de um analista, o insight apodrece antes de ser usado. Automatize a extração e a transformação para que a atualização mensal seja um botão, não um projeto.

Perguntas frequentes

De quais dados eu preciso para construir um modelo de rentabilidade?

No mínimo: um razão geral ou balancete com detalhe de centro de custo, os cadastros mestres que definem o plano de contas e as hierarquias de produtos e clientes, e as quantidades de driver operacionais (linhas de pedido, horas-máquina, entregas, FTEs) que explicam quem consumiu o quê. Os dados financeiros sozinhos permitem ratear custo; os drivers são o que permite atribuí-lo de forma causal.

Posso começar um modelo de custeio a partir dos arquivos fiscais eletrônicos?

Muitas vezes, sim. As escriturações contábeis eletrônicas que a empresa já entrega ao fisco reúnem o razão geral, o plano de contas e os cadastros de clientes, fornecedores e produtos em uma exportação única e governada, e por isso são com frequência o ponto de partida mais limpo. Você ainda vai precisar de dados operacionais de driver vindos de fora desses arquivos para passar do rateio de custos à atribuição genuína baseada em atividades.

Qual ferramenta de ETL é melhor para análise de custos e rentabilidade?

Aquela que a sua equipe consegue manter. Alteryx e Power Query servem à combinação de exportações conduzida por analistas; o dbt é o padrão para transformações nativas de warehouse com controle de versão; o Talend se encaixa na integração multi-fonte de escala corporativa; o KNIME é uma opção forte de código aberto. A lógica de custeio é idêntica em todas, então a escolha é sobre o seu stack e as suas competências, não sobre o modelo.

Por que o meu modelo de custeio discorda do balancete?

Quase sempre é um problema de ETL: uma extração que pulou um razão, uma moeda ou provisão tratada de forma inconsistente, ou custos mapeados para o pool errado. Por isso um portão duro de conciliação, provando que o custo carregado é igual ao balancete auditado ao centavo, pertence ao início de todo pipeline e deve ser automatizado em vez de conferido à mão.

Quão granular deve ser um modelo de custos?

Tão granular quanto os seus dados de driver forem confiáveis, e nada mais. Modelar centenas de micro-atividades sobre dados chutados produz um pipeline frágil que é menos preciso do que um mais enxuto, e não mais. Pare de acrescentar detalhe no ponto em que as quantidades de driver deixam de ser dignas de confiança, e gaste o esforço poupado em disciplina de atualização.