Uma das barreiras mais comuns à implementação de um modelo de custos adequado é a crença de que não tem os dados. Na maioria das vezes, essa crença está parcialmente correta, mas o fosso é menor do que parece.
Compreender de que dados precisa realmente (vs. o que pensa que precisa) é o primeiro passo.
Os Três Requisitos de Dados do TDABC
Um modelo TDABC requer três tipos de dados:
1. Dados financeiros - totais de centros de custo. O custo total de cada centro de recursos (departamento, equipa ou função) num período. Isto vem do seu plano de contas. Quase todas as empresas têm isto, seja do ERP, software de contabilidade ou exportação ERP. Raramente é a restrição.
2. Dados operacionais - volumes e tipos de transações. O número e tipo de transações processadas por cada centro de recursos: quantas encomendas executadas, clientes integrados, faturas processadas, controlos de qualidade realizados, etc. Estes são os dados que muitas empresas não têm com granularidade suficiente.
3. Estimativas de tempo - quanto tempo cada tipo de transação demora. O tempo necessário por tipo de transação em cada centro de recursos. Isto não requer dados históricos extensos: uma combinação de logs de sistema, métricas operacionais e estimativas estruturadas dos responsáveis de processo é suficiente.
O Dataset Mínimo Viável
Não precisa de um data warehouse, uma plataforma de business intelligence ou um ERP completo para construir um modelo TDABC útil. Precisa de:
- Um razão geral ou plano de contas segmentado por departamento (para construir centros de custo)
- Um relatório operacional ou contagem manual dos tipos de transações chave por departamento
- Estimativas de tempo por tipo de transação, validadas com os responsáveis de departamento
O CostCtrl foi concebido para trabalhar exatamente com isto, mais exportações ERP para empresas em PT/ES/BR, que fornecem a camada financeira automaticamente.
As Lacunas de Dados Comuns (e Como as Colmatar)
Lacuna 1: Sem dados operacionais ao nível de transação
Solução: Comece com um exercício de amostragem de atividades de 2 semanas. Os responsáveis de departamento registam as atividades das suas equipas em blocos de 30 minutos. Isto dá-lhe um dataset inicial suficiente para a primeira iteração do modelo.
Lacuna 2: Sem rastreamento de tempo por cliente ou produto
Solução: Use logs de sistema como proxies (número de emails, tickets, encomendas) combinados com estimativas de tempo por tipo de evento. Impreciso? Sim. Melhor do que não ter modelo? Sempre.
Lacuna 3: Sem ERP / plano de contas por departamento
Solução: Mapeie manualmente as suas contas existentes para centros de custo. Um exercício único que demora 1-2 dias para uma empresa de média dimensão. Documente o mapeamento para que os períodos subsequentes sejam automatizados.
Maturidade de Dados como uma Jornada
O objetivo não é alcançar dados perfeitos antes de construir um modelo. O objetivo é construir um modelo com dados imperfeitos, e depois usar o modelo para identificar onde as melhorias de qualidade de dados terão mais impacto na precisão das decisões.
Frequentemente, 80% do valor vem de 20% dos dados. O modelo mostra-lhe quais são esses 20%.
O CostCtrl tem uma avaliação de maturidade de dados integrada que lhe diz exatamente quais as lacunas de dados que limitam a precisão do seu modelo, e prioriza as lacunas que valem a pena colmatar nos próximos 90 dias.
Faça o Diagnóstico de Rentabilidade para ver a sua pontuação atual de Dados e Tecnologia e obter um roteiro de prontidão de dados prático.
Perguntas frequentes
Que dados precisa realmente para construir um modelo de custos?
Três tipos: dados financeiros (totais dos cost pools, do plano de contas), dados de transação (encomendas, faturas, expedições - o que aconteceu e para quem) e dados operacionais (o tempo ou driver por trás de cada atividade). A maioria das empresas já tem os dois primeiros; o terceiro é normalmente a menor lacuna real, não o bloqueio que se receia.
Preciso de dados perfeitos antes de modelar custos?
Não. Dados perfeitos não são pré-requisito. Um modelo TDABC útil começa com os dados que já exporta do ERP e da contabilidade, e as lacunas são mapeadas durante a construção em vez de corrigidas primeiro. Esperar por dados perfeitos é a razão mais comum para as empresas nunca começarem, e é quase sempre desnecessário.
Preciso primeiro de um novo sistema ou data warehouse?
Normalmente não. As exportações que já tem - razão geral, registos de transações, registos operacionais básicos - chegam para construir um primeiro modelo. Um data warehouse dedicado ajuda em escala, mas é uma otimização, não uma pré-condição. O primeiro modelo prova o valor e mostra exatamente em que dados vale a pena investir a seguir.
Como é que o TDABC funciona com dados imperfeitos ou parciais?
O TDABC usa equações de tempo, por isso pode modelar uma atividade a partir de um pequeno número de tempos observados mais os volumes de transações que já regista. Onde faltam dados, usam-se estimativas razoáveis e sinalizadas, depois refinadas à medida que chegam melhores dados. Isto torna o método robusto aos dados parciais que as empresas reais têm de facto.