Os dados do modelo de custos, campo a campo

Porque é a extração que decide o projeto

Os modelos de custeio raramente falham na contabilidade. Falham porque o desenho prometeu um detalhe que os sistemas de origem não conseguiam alimentar, e ninguém deu por isso enquanto a construção não ia já adiantada. Escrevemos sobre esse fosso em do projeto a um modelo que funciona.

Por isso começamos com um pedido de dados e não com um workshop. Os ficheiros costumam confirmar aquilo em que toda a gente acreditava. Às vezes mostram que as linhas de encomenda estão resumidas ao nível da fatura, ou que as paragens de entrega não ficam registadas contra o cliente, e o desenho do modelo muda na primeira semana em vez de mudar na sexta. É um bom dia, ainda que não pareça.

Esta página é a especificação: o que pedimos, com que detalhe e porquê. Encaminhe-a para quem vai escrever a consulta. Se ainda está a decidir se avança, comece pelo guia de construção do primeiro modelo TDABC, que mostra o que estes ficheiros vão alimentar.

Três regras que contam mais do que a lista de campos

1. Ao nível da linha, nunca resumido. Uma linha por linha de fatura, linha de encomenda, entrega, devolução ou contacto. Uma extração resumida não volta a abrir-se mais tarde, e todas as diferenças interessantes entre dois clientes vivem no detalhe que a média apagou.
2. Chaves que ligam. Todos os ficheiros de transações precisam do código de cliente, do código de artigo e do número de documento, no mesmo formato usado pelos dados mestre. Nomes em vez de códigos custam mais tempo do que todos os outros problemas de dados juntos.
3. O mesmo período, em todo o lado. Os ficheiros de custo e os ficheiros de transações têm de cobrir os mesmos meses. Um modelo que valoriza doze meses de trabalho com nove meses de custo não reconcilia com nada e cai numa reunião.

Os quatro ficheiros que trazem o custo

Os cinco ficheiros que trazem o trabalho

Três ficheiros para dados mestre e capacidade

A extração não é papelada antes do projeto. É a primeira conversa honesta que o projeto tem.

O que pode ficar de fora

Os pedidos de dados incham porque cada pessoa acrescenta aquilo que talvez venha a querer. Quatro coisas que deixamos de fora por rotina, e uma que recusamos.

Salários individuais. Custo por centro de custo e por função chega, e deixar os nomes de fora evita uma conversa de proteção de dados que não ajuda ninguém. Se um ficheiro de pessoal chegar com nomes, pedimo-lo outra vez sem eles.

O balanço. Um modelo de rentabilidade trabalha sobre a base de custos operacionais. O detalhe do balanço conta para a alocação de capital, que é outra pergunta, tratada em alocação de capital e ROIC.

Versões de orçamento e de previsão. Construa o modelo sobre valores reais primeiro. A comparação com o orçamento é uma camada de reporte acrescentada depois, e misturar as duas cedo é como um projeto de custeio se transforma discretamente num projeto de orçamentação.

Dados perfeitos. Campos em falta, códigos inconsistentes e um conjunto de linhas órfãs são normais. Reconciliamos, quantificamos o que não liga e pomos esse valor na página em vez de o esconder. Um modelo que diz quanta receita não conseguiu ligar merece confiança. Um modelo que garante ter ligado tudo não merece.

Tudo o que exigisse uma revisão jurídica para ser enviado. Se um campo é sensível e não sustenta nada, deixe-o cair. Quase nada nesta lista são dados pessoais depois de os custos com pessoal serem agregados.

O teste de reconciliação que decide tudo

CSV ou Excel serve. Parquet é melhor para ficheiros de transações grandes. O que importa é que sejam extrações em bruto e não relatórios formatados: sem células unidas, sem linhas de subtotal, sem separador de milhares dentro dos campos numéricos, uma única linha de cabeçalho, UTF-8, datas em formato ISO.

O volume raramente é o obstáculo que as pessoas esperam. O caso de estudo que publicámos sobre um operador logístico na Arábia Saudita assentou em 525.000 linhas de expedição, usadas na íntegra e sem amostragem. Se o seu ficheiro de linhas de fatura tem algumas centenas de milhares de linhas, é um ficheiro vulgar.

Quanto a histórico, doze meses é o alvo de trabalho, porque cobre um ciclo sazonal completo. Vinte e quatro deixam ver se um padrão é estrutural ou apenas um trimestre mau, e depois de a consulta estar escrita normalmente não custa mais nada. Um trimestre chega para pôr de pé um primeiro modelo a funcionar.

Há um teste que decide se a extração é utilizável, e vale a pena corrê-lo antes de tudo o resto. Some os ficheiros de custo do período e compare o total com o razão para os recursos em âmbito. Some as linhas de fatura e compare com a receita reportada nos mesmos meses. Se algum dos totais se desviar de forma material, a extração está filtrada algures e o modelo herdaria o filtro. Reconciliação primeiro, modelação depois. Tudo o que está em construir o primeiro modelo TDABC pressupõe que este teste passou, e a canalização por trás dele está em ETL para análise de rentabilidade.

Num formato que pode reencaminhar

Copie o bloco abaixo para o email que envia a quem trata dos sistemas. É propositadamente curto, porque um pedido com quatro páginas é lido uma vez e respondido devagar.

Assim que os ficheiros chegam, a decisão seguinte é quais as características de uma transação que se tornam termos numa equação de tempo. Esse é o tema da biblioteca de indutores de custo, e a aritmética por trás dela está nas equações de tempo.

Perguntas justas.

De que dados preciso para construir um modelo de custo de servir ou de rentabilidade?

Doze extrações. Quatro trazem o custo: as linhas de gasto do razão geral por centro de custo e conta, os custos com pessoal e os equivalentes a tempo inteiro, a depreciação por classe de ativo e a hierarquia de centros de custo. Cinco trazem o trabalho: linhas de fatura, linhas de encomenda, entregas, devoluções e notas de crédito, e contactos de apoio ao cliente. Três trazem dados mestre e capacidade: o ficheiro de clientes, o ficheiro de artigos e o calendário de trabalho. Tudo ao nível da linha, a cobrir os mesmos meses e ligável por código de cliente, de artigo e número de documento.

Quanto histórico é preciso?

Doze meses é o alvo de trabalho, porque cobrem um ciclo sazonal completo. Vinte e quatro meses deixam ver se um padrão é estrutural ou apenas um trimestre mau, e depois de a consulta estar escrita normalmente não custa nada estendê-la. Um trimestre chega para pôr de pé um primeiro modelo a funcionar, mas não chega para rever o preço de uma conta, porque um único mês invulgar pode carregar toda a conclusão.

Os ficheiros têm mesmo de estar ao nível da linha?

Têm, e este é o requisito mais importante de todos. Uma extração resumida não volta a abrir-se mais tarde, e todas as diferenças com significado entre dois clientes vivem no detalhe que o resumo apaga: quantas linhas tinha uma encomenda, quantas paragens exigiu uma entrega, quantos contactos gerou uma conta. Se a extração ao nível da linha for mesmo impossível, isso condiciona o desenho do modelo e deve saber-se na primeira semana, não na sexta.

E se não tivermos os dados de entrega ou de apoio ao cliente?

O modelo continua a correr, com uma aproximação documentada no lugar do indutor em falta. O frete pode ser imputado por peso ou por zona, o custo de apoio pode ser espalhado pelas contas, e ambos ficam identificados como espalhados e não como rastreados. O resultado continua a ser muito mais informativo do que uma média da empresa inteira, e as lacunas passam a ser o plano do que começar a registar.

Isto são dados pessoais? Precisamos de uma revisão de proteção de dados?

Quase nada disto o é. Pedimos custos com pessoal agregados por centro de custo e por função, e não por pessoa, e devolvemos qualquer ficheiro que chegue com nomes ou salários individuais. Os registos de clientes são registos de empresa. Se um campo é sensível e não sustenta o modelo, deixe-o de fora.

Em que formato devem vir os ficheiros?

Extrações em bruto e não relatórios formatados. CSV ou Parquet, UTF-8, datas ISO, ponto decimal, sem separador de milhares dentro dos campos numéricos, uma linha de cabeçalho, sem células unidas e sem linhas de subtotal. Depois corra o teste de reconciliação antes de tudo o resto: os ficheiros de custo têm de fechar com o razão para os recursos em âmbito, e as linhas de fatura têm de fechar com a receita reportada nos mesmos meses.