ETL para análise de custos e rentabilidade
Um modelo de rentabilidade nunca é melhor do que os dados nele despejados. O ETL, a camada de extração, transformação e carregamento, é o trabalho de retirar transações do razão, dados mestre e indutores operacionais do seu ERP e modelá-los nos conjuntos de recursos, atividades e indutores de custo que um motor TDABC ou ABC consegue realmente utilizar. Faça bem essa camada de entrada e todo o modelo torna-se fiável, rápido de atualizar e defensável perante uma administração.
Em resumo. Um modelo de custeio precisa de três tipos de entrada: dinheiro (saldos do razão geral e dos centros de custo), estrutura (o plano de contas, os centros de custo, os produtos, os clientes e as suas hierarquias) e comportamento (os indutores operacionais que dizem quem consumiu o quê). O ETL é a forma de passar de um ficheiro SAF-T em bruto ou de uma exportação SAP para um conjunto de dados limpo, mapeado e pronto para indutores. O passo de transformação é onde se concentram tanto o valor como o risco: mapear centros de custo para conjuntos de recursos, derivar quantidades de atividade e reconciliar cada euro com o balancete. A Cost and Profitability constrói estes pipelines na ferramenta que o cliente já utiliza - Alteryx, Power Query, Talend, KNIME, dbt ou SQL simples - e coloca o resultado no CostCtrl como motor de custeio. A ferramenta é negociável; a disciplina dos dados não é.
O que um modelo de rentabilidade precisa realmente dos seus dados
Antes de se falar de ferramentas, vale a pena ser preciso quanto às entradas. Um modelo de custeio baseado em atividades e orientado pelo tempo precisa, no seu cerne, apenas de duas coisas, tal como Kaplan e Anderson o formularam: o custo por unidade de tempo de fornecer capacidade e o tempo que cada transação, produto ou cliente consome. Tudo o que o ETL faz está ao serviço de produzir esses dois números de forma limpa e repetível.
Na prática, isso resolve-se num pequeno número de domínios de dados. Cada um tem um sistema de origem natural e um modo de falha diferente, e é precisamente por isso que vale a pena separá-los à entrada.
| Domínio de dados | O que fornece | Origem típica | Granularidade desejada |
|---|---|---|---|
| Saldos do razão geral e centros de custo | O dinheiro a alocar: salários, depreciação, ocupação, TI, serviços externos | Razão geral do ERP, ficheiro contabilístico SAF-T | Conta x centro de custo x período |
| Dados mestre / hierarquias | A estrutura: plano de contas, centros de custo, hierarquias de produtos e clientes | Ficheiros mestre do ERP, ficheiros mestre SAF-T | Uma linha por entidade, com chaves-pai |
| Volumes de transações | Quantidades de atividade: encomendas, linhas, entregas, faturas, preparações, chamadas | Módulos de vendas, logística, serviço e CRM | Uma linha por evento, datada e com chave |
| Indutores operacionais | Intensidade física: horas-máquina, quilómetros, efetivos, metros quadrados, SKUs | Sistemas MES, WMS, de frota, de RH e de património | Indutor x objeto consumidor x período |
| Dados de RH e de tempo | Capacidade disponível e consumida: FTEs, turnos, minutos práticos | Processamento salarial, escalas, folhas de horas | Função ou equipa x período |
Repare que apenas o primeiro domínio é estritamente financeiro. O sinal de custeio que separa um bom modelo de uma folha de cálculo vive nos últimos três: sem volumes e indutores é possível distribuir custo, mas não explicá-lo. É por isso que um projeto de ETL de custeio é um exercício de finanças e operações, e não apenas de finanças.
Onde vivem os números: ERP, SAF-T e sistemas operacionais
A maior parte do dinheiro entra pelo ERP. No SAP (ECC ou S/4HANA) os extratos úteis são os lançamentos de centros de custo e ordens internas do Controlling (tabelas e relatórios em torno do CO-OM), mais o balancete de FI para reconciliação. O Oracle (E-Business Suite ou Fusion) expõe detalhe equivalente de razão geral e de subrazões, e o Microsoft Dynamics 365 Finance oferece lançamentos do razão etiquetados por dimensão que já transportam grande parte da estrutura analítica de que precisa. Em empresas de engenharia, construção e orientadas a projetos, o Primavera e sistemas de projeto semelhantes contêm os dados de mão de obra, equipamento e progresso que nenhum razão financeiro capta.
Onde uma extração direta do ERP é impraticável, o ficheiro SAF-T é muitas vezes o ponto de partida único mais limpo. A norma da OCDE define quatro secções: um cabeçalho, ficheiros mestre (plano de contas, clientes, fornecedores, códigos de imposto, produtos), lançamentos do razão geral e documentos de origem como faturas e pagamentos. Por ser uma exportação XML regulada e versionada, obrigatória em Portugal, na Noruega, na Polónia e numa lista crescente de países, o SAF-T dá-lhe o razão geral e os dados mestre num único pacote governado. A Cost and Profitability constrói regularmente um primeiro modelo diretamente a partir do SAF-T, o que permite a um cliente começar sem esperar por uma integração completa do ERP.
Os sistemas operacionais são mais desarrumados e mais valiosos. Sistemas de execução de fabrico, gestão de armazém, transporte e telemática de frota, plataformas de bilhética e CRM contêm todos as quantidades de indutores. Estes raramente partilham chaves com o ERP, o que é precisamente o problema que a camada de transformação existe para resolver.
De razões em bruto a conjuntos de recursos e indutores
Extrair e carregar são os verbos fáceis. Transformar é onde um pipeline de custeio justifica o seu valor, e decompõe-se em quatro tarefas que devem ser construídas e testadas por ordem.
Limpar e reconciliar. Eliminar duplicados, corrigir tipos de dados, uniformizar datas e moedas, e provar que a soma do que carregou é igual ao balancete ao cêntimo. Se o custo extraído não bater com as contas auditadas, nada a jusante é credível. Este ponto de controlo de reconciliação é inegociável e deve ser automatizado, não verificado a olho.
Mapear centros de custo para conjuntos de recursos. Um conjunto de recursos agrupa custos que se comportam da mesma forma e são consumidos pelo mesmo indutor: uma equipa de picking, uma frota, um call center, uma célula CNC. Os centros de custo no ERP foram concebidos para orçamento e responsabilização, não para causalidade, pelo que o mapeamento raramente é um-para-um. Alguns centros dividem-se por vários conjuntos; alguns conjuntos recorrem a vários centros. Esta tabela de mapeamento, o cruzamento da estrutura contabilística para o modelo de custo, é o artefacto mais importante de todo o pipeline e aquele que mais merece controlo de versões e aprovação.
Derivar indutores de atividade. Transformar eventos em bruto nas quantidades de indutores que o modelo consome: contar linhas de encomenda por cliente, somar minutos-máquina por produto, agregar entregas por rota. Num modelo orientado pelo tempo é também aqui que se alimentam as equações de tempo, traduzindo as características das transações em minutos estimados para que o tempo de processamento possa flexibilizar-se com a complexidade real em vez de uma média fixa.
Conformar chaves e hierarquias. Dar a cada produto, cliente e objeto de custo uma chave única e estável, e associá-la às hierarquias pelas quais o negócio reporta: custo de 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 mostrará três margens enganosas.
A caixa de ferramentas de ETL, escolhida para o cliente e não para o consultor
Não existe uma única ferramenta certa, e qualquer consultor que insista no contrário está a vender a sua zona de conforto em vez do seu resultado. O que importa é que o pipeline seja transparente, repetível e mantenível pela sua equipa depois de o trabalho terminar. A Cost and Profitability é deliberadamente agnóstica quanto a ferramentas e construirá dentro daquilo em que a sua equipa de dados já confia.
| Ferramenta | Modelo | Melhor adequação ao trabalho de custeio | Cuidados a ter |
|---|---|---|---|
| Alteryx Designer | Visual, arrastar e largar | Combinação rápida de ficheiros de ERP e operacionais por analistas financeiros; forte com grandes conjuntos de dados locais | Custo de licença; governação de muitos fluxos de trabalho em desktop |
| Power Query | No Excel / Power BI | Baixa barreira quando o cliente já vive no Excel e no Power BI; bom para modelos mais pequenos | Mais fraco com dados muito grandes e orquestração multiorigem |
| KNIME | Visual, código aberto | Preparação gratuita e flexível baseada em nós, com espaço para crescer para análise e aprendizagem automática | Navegação entre nós e uso de memória em fluxos grandes |
| Talend | ETL empresarial (Java) | Centenas de origens, trabalhos agendados de nível empresarial a alimentar um armazém de dados | Construção mais pesada; exige apropriação de engenharia de dados |
| dbt | SQL, com controlo de versões | A norma para transformação nativa em armazém no Snowflake, BigQuery, Redshift ou Databricks; testável e auditável por conceção | Pressupõe que os dados já estão carregados; orientado a SQL, não uma ferramenta visual |
Uma regra prática útil: se os dados do cliente já aterram num armazém na cloud, o dbt dá-lhe transformações testadas e com controlo de versões que um auditor respeitará. Se o trabalho for combinação de exportações e folhas de cálculo conduzida por analistas, o Alteryx ou o Power Query chegam a um modelo mais depressa. Se a integração abranger dezenas de sistemas de origem de forma agendada, o Talend ou um pipeline empresarial comparável é a resposta honesta. A lógica de custeio é idêntica em todos eles; apenas a sintaxe muda.
Armadilhas comuns: lixo à entrada, granularidade excessiva, lógica de indutores quebrada
A maioria dos modelos de custeio que perdem a sala fá-lo por razões de entrada, não por razões de método. Quatro padrões de falha repetem-se com frequência suficiente para merecerem nome.
Lixo à entrada. Extrações não reconciliadas, acréscimos mal lançados e centros de custo a carregar custos que pertencem a outro lado. Se a entrada não bate com o balancete, o modelo herda todos os erros e não acrescenta nenhuma da culpa. Corrija isto no ponto de controlo de reconciliação, nunca mais tarde.
Granularidade excessiva. O instinto de modelar cada micro-atividade produz pipelines frágeis, lentos a atualizar e impossíveis de explicar. Um modelo com 400 atividades é normalmente menos exato do que um com 40, porque as 360 extra são conduzidas por dados adivinhados. A granularidade deve parar onde os dados de indutores deixam de ser fiáveis.
Lógica de indutores quebrada. Um indutor que não causa realmente o custo, uma contagem de encomendas a fazer as vezes do esforço de armazém quando os itens por encomenda variam dez vezes, redistribui silenciosamente o lucro entre clientes. Esta é a armadilha mais perigosa porque o modelo continua a fechar; está simplesmente errado de uma forma que nenhuma reconciliação apanha. A escolha de indutores merece o mesmo escrutínio que o mapeamento de custos.
Pipelines de uma só vez. Uma construção manual heroica que ninguém consegue atualizar no trimestre seguinte é um relatório, não um modelo. Se recarregar os dados leva uma semana da memória de um analista, a perceção degrada-se antes de ser usada. Automatize a extração e a transformação para que uma atualização mensal seja um botão, não um projeto.
Alimentar um modelo limpo no CostCtrl
Quando a camada de ETL é bem feita, a tarefa do motor de custeio torna-se simples. O CostCtrl consome entradas conformadas - conjuntos de recursos com os seus custos, objetos de custo com as suas chaves e quantidades de indutores por período - e executa o cálculo TDABC por cima: taxas de custo de capacidade, consumo por equações de tempo, relato de capacidade não utilizada e as visões de rentabilidade e de curva da baleia sobre as quais a gestão age. Um pipeline limpo é o que permite que esse motor atualize mensalmente em vez de anualmente, e permite a um controller responder a uma pergunta da administração em minutos em vez de semanas.
A divisão de trabalho é deliberada. O ETL é dono da correção e da repetibilidade das entradas; o CostCtrl é dono do método de custeio e dos resultados. Como o motor é alimentado por dados conformados em vez de folhas de cálculo à medida, o mesmo pipeline estende-se naturalmente para a gestão baseada em atividades e para os KPIs de rentabilidade sem uma reconstrução. A Cost and Profitability posiciona-se como o parceiro de implementação em toda essa cadeia: construímos o pipeline nas suas ferramentas, provamo-lo contra as suas contas e devolvemos algo que a sua equipa consegue operar sem nós. O custeio é rigoroso; a canalização é sua para manter.
- Que dados preciso para construir um modelo de rentabilidade?
- No mínimo: um razão geral ou balancete com detalhe de centros de custo, os dados mestre que definem o seu plano de contas e as hierarquias de produtos e clientes, e as quantidades de indutores operacionais (linhas de encomenda, horas-máquina, entregas, FTEs) que explicam quem consumiu o quê. Os dados financeiros sozinhos permitem-lhe distribuir custo; os indutores são o que lhe permite atribuí-lo de forma causal.
- Posso começar um modelo de custeio a partir de um ficheiro SAF-T?
- Muitas vezes sim. A norma SAF-T da OCDE agrupa o razão geral, o plano de contas e os ficheiros mestre de clientes, fornecedores e produtos numa única exportação XML governada, pelo que é frequentemente o ponto de partida único mais limpo. Continuará a precisar de dados de indutores operacionais fora do SAF-T para passar da distribuição de custo à verdadeira atribuição baseada em atividades.
- Qual é a melhor ferramenta de ETL para análise de custos e rentabilidade?
- Aquela que a sua equipa consegue manter. O Alteryx e o Power Query adequam-se à combinação de exportações conduzida por analistas; o dbt é a norma para transformações nativas em armazém e com controlo de versões; o Talend adequa-se à integração multiorigem à escala empresarial; o KNIME é uma forte opção de código aberto. A lógica de custeio é idêntica em todos eles, pelo que a escolha é sobre a sua stack e competências existentes, não sobre o modelo.
- Porque é que o meu modelo de custeio não coincide com o balancete?
- Quase sempre um problema de ETL: uma extração que falhou um razão, uma moeda ou acréscimo tratado de forma inconsistente, ou custos mapeados para o conjunto errado. É por isso que um ponto de controlo de reconciliação rígido, que prove que o custo carregado é igual ao balancete auditado ao cêntimo, pertence ao início de cada pipeline e deve ser automatizado em vez de verificado à mão.
- Quão granular deve ser um modelo de custo?
- Tão granular quanto os seus dados de indutores forem fiáveis, e não mais. Modelar centenas de micro-atividades sobre dados adivinhados produz um pipeline frágil que é menos exato do que um mais enxuto, não mais. Pare de acrescentar detalhe no ponto em que as quantidades de indutores deixam de ser fiáveis, e gaste o esforço poupado em disciplina de atualização.
Kaplan, R. S. & Anderson, S. R., “Time-Driven Activity-Based Costing,” Harvard Business Review (2004) · OCDE, Guidance for the Standard Audit File - Tax (SAF-T), Versão 2.0 · Documentação de produto da Alteryx, Talend, KNIME e dbt sobre preparação e transformação de dados · Literatura do IMA / de profissionais sobre requisitos de dados do custeio baseado em atividades