Uma folha de cálculo com consumo de energia por unidade não é um problema em si. O problema surge no passo seguinte: como essas linhas são agregadas no número que consta no relatório. Esse passo acontece muitas vezes numa fórmula, numa tabela dinâmica ou, pior, na cabeça de quem atualiza a folha de cálculo anualmente. Mais ninguém sabe exatamente que linhas foram incluídas, quais foram excluídas e porquê.
Agregar parece cálculo, mas é uma série de escolhas. Conta com unidades que estiveram fechadas parte do ano? Inclui localizações arrendadas ou apenas propriedade? Calcula com ano civil ou ano fiscal? Cada escolha altera o número final, e numa folha de cálculo estas escolhas normalmente não estão registadas separadamente. Estão embutidas numa fórmula que remete para células, sem que exista uma linha legível que diga: esta é a regra de agregação, e é esta a razão.
Quando alguém assume a folha de cálculo, ou quando um controller quer reproduzir um número semelhante um ano depois, essa explicação falta. A fórmula ainda funciona, mas já ninguém consegue avaliar se ainda é correta para a situação deste ano.
Entre a linha em bruto na folha de cálculo e o número no relatório existem geralmente vários passos: seleção das linhas relevantes, conversão para uma unidade, soma ou média ponderada, e por vezes uma correção para meses ou localizações em falta. Cada passo pode ter a sua própria regra, e cada regra pode mudar sem que isso seja registado em lado nenhum.
A pergunta que então importa: se um controller perguntar como este número foi construído, consegue apontar os passos um a um? Não reconstruir o resultado trabalhando a fórmula de trás para a frente, mas mostrar as próprias regras.
Uma regra de agregação que existe apenas numa fórmula não é verificável nem transferível. Registar significa: anotar separadamente da folha de cálculo qual agregação foi aplicada, sobre que seleção, com que excepções, e quem determinou essa regra. Isto não é um documento extra ao lado da folha de cálculo, é a explicação que torna a folha de cálculo utilizável como fonte de um ponto de reporte.
Sem essa explicação, uma regra de agregação muda sem se notar. Alguém adiciona uma unidade à lista, ajusta a fórmula, e o número deste ano deixa de ser comparável com o do ano anterior. Não porque os dados subjacentes mudaram, mas porque a forma de somar foi silenciosamente ajustada.
A agregação é um dos locais onde as folhas de cálculo escondem erros de agregação, mas não o único. Perguntas semelhantes aplicam-se a unidades e definições: veja como regista a normalização quando a fonte é uma folha de cálculo para o passo que muitas vezes precede a agregação. E para mapear todo o percurso da linha em bruto ao número do relatório, mesmo sem software especializado, existe como cria lineage sem ferramenta quando a fonte é uma folha de cálculo. Ambos ligam-se à pergunta mais ampla o que é exatamente o mapeamento source-to-report, na qual a agregação é um dos passos documentados.
Uma regra de agregação, tal como um ponto de dados, precisa de alguém responsável pela escolha subjacente. Não quem por acaso escreveu a fórmula, mas quem consegue explicar porque foi escolhida esta seleção e este método de cálculo, e que aprova uma alteração antes de esta ser implementada. Esta questão relaciona-se com quem é proprietário da definição de um ponto de dados: a definição determina o que é medido, a regra de agregação determina como as medições são somadas num número de reporte. Ambas devem pertencer a alguém com nome, não a uma folha de cálculo que passa de mão em mão.
Registar regras de agregação não é um exercício único. É uma questão que volta a surgir sempre que a organização muda: uma nova unidade, uma nova unidade de medida, uma fusão. Por isso não basta documentar desta vez; tem de existir um processo que repita o registo em cada alteração. Quem guarda esse processo e quando uma regra de agregação é revista é uma questão que se relaciona com quem é proprietário do processo subjacente, independentemente de quem fornece os números individuais.
Esta página descreve o que é necessário para tornar a agregação transparente. O Data Readiness Scan é a ferramenta que ajuda a registar isto para os seus pontos de dados: o registo, a lineage fonte-para-relatório por ponto e as regras de propriedade. Essa ferramenta está em construção. Quem já quiser começar com isto pode inscrever-se na lista de espera.
Quando as regras de agregação estão registadas, com um proprietário e uma razão, surge um outro tipo de trabalho: executar e verificar esses mesmos passos, ano após ano. Muito desse trabalho de execução, desde selecionar linhas até somar números segundo uma regra fixa, é o tipo de tarefa em que uma werkscan da FTE TO AI permite calcular que parte pode ser assumida pela IA, por tarefa, com base no que o trabalho exatamente implica.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.