csrdready Inscrever-me na lista de espera

Kennisbank

Da célula da folha de cálculo ao número do relatório: o que existe entre os dois

Uma folha de cálculo parece uma origem simples. Uma célula com um número, uma aba com um nome, uma exportação de outro sistema que foi colada. Mas entre essa célula e o número que acaba por constar num relatório, existe uma sequência de operações que na maioria das vezes não fica registada em lado nenhum. Source-to-report mapping é o mapeamento dessa sequência: cada passo que um número percorre desde o momento em que entra na folha de cálculo até ao momento em que chega a uma linha de relatório.

Por que razão uma folha de cálculo torna isto mais difícil, não mais fácil

Num sistema com campos fixos e uma estrutura fixa, é muitas vezes ainda possível determinar de onde vem cada campo. Uma folha de cálculo não tem essa estrutura por natureza. Alguém adiciona uma aba intermédia para agregar. Outra pessoa copia uma coluna para outro ficheiro para fazer uma conversão. Um terceiro cola o resultado como valor numa folha de relatório, com o que a fórmula, e portanto o rasto, desaparece. Nada disto está errado no momento em que acontece. O problema surge um ano depois, quando alguém tem de explicar de onde vem um número e a resposta já não é reconstituível.

Os passos que precisam de ser registados

O source-to-report mapping para uma origem em folha de cálculo consiste num conjunto de passos reconhecíveis, cada um dos quais requer atenção própria.

O primeiro passo é a origem dos dados brutos: qual o ficheiro, qual a aba, qual a célula ou intervalo de células, e quem os introduz ou fornece. Sem este ponto de ancoragem, não há origem para a qual se possa remeter.

O segundo passo é quais são as operações entre a origem e o relatório quando a origem é uma folha de cálculo. Pense em unidades que são convertidas, em filtros que excluem determinadas linhas, em fórmulas que somam ou reescalam valores. Cada operação altera o número, e cada operação que não fica registada é um passo que mais tarde já não pode ser verificado.

O terceiro passo é a agregação: várias linhas, abas ou ficheiros que são combinados num único número. Numa folha de cálculo, isto acontece muitas vezes de forma manual, com um clique na função de soma sobre um intervalo que alguém delimitou por conta própria. A forma como esse intervalo foi escolhido e o que nele está incluído determina o número tanto quanto os dados subjacentes. É exatamente por isso que é preciso registar como se documenta a agregação quando a origem é uma folha de cálculo: não como formalidade, mas porque o próprio passo de agregação é uma fonte de erros que mais ninguém vê.

O quarto passo é a normalização: diferentes unidades, diferentes períodos de relatório ou diferentes localizações que são trazidas para uma base comum antes de se tornarem comparáveis. Também aqui se verifica que a escolha de um fator de conversão ou valor de referência determina o resultado, e que essa escolha tem de ser rastreável. A forma como isso funciona está desenvolvida em como se documenta a normalização quando a origem é uma folha de cálculo.

O último passo é o local onde o número aterra: a linha do relatório, o indicador, o total anual. Também essa transição precisa de ter um rasto, e não apenas uma referência ao documento de origem.

Por que razão isto é mais do que manter um registo de alterações

É tentador pensar que uma lista de quem alterou o quê é suficiente. Isso é um registo de alterações, e um registo de alterações regista modificações sem mostrar a lógica que está por detrás delas. Uma audit trail que tenha significado não mostra apenas que uma célula foi alterada, mas também porquê, com base em que regra e com que resultado rastreável até à origem original. Essa distinção é aprofundada na explicação sobre por que razão uma audit trail é mais do que um registo de alterações quando a origem é uma folha de cálculo.

Isto é possível sem uma ferramenta que o faça automaticamente

A maioria das organizações que trabalham com folhas de cálculo não tem um sistema que mantenha automaticamente a lineage. Isso não significa que o mapeamento seja impossível, significa que tem de ser feito manualmente, com disciplina em vez de com software. Que passos são necessários para isso e como um processo assente em folhas de cálculo pode ainda assim tornar-se rastreável está descrito em como se cria lineage sem ferramenta quando a origem é uma folha de cálculo. Uma questão relacionada que é frequentemente ignorada é quem detém a definição de um ponto de dados: sem um proprietário designado da definição, o significado de um ponto de dados muda com quem, num dado momento, o está a interpretar, e nesse caso o mapeamento mais bem elaborado vale pouco.

Por que razão isto vem primeiro, antes de se acrescentar uma ferramenta

Uma ferramenta que torna os relatórios mais bonitos não altera em nada a fiabilidade dos números que neles entram. Se o percurso da célula ao relatório não estiver registado, uma ferramenta produz relatórios mais arrumados sobre os mesmos números incertos. O mapeamento de origem para relatório não é, por isso, um passo que vem depois da ferramenta, mas um que vem antes.

Quando isto também é uma questão de quem faz o trabalho

A partir do momento em que os passos entre a origem e o relatório estão descritos, torna-se também visível quais desses passos são trabalho humano e quais seguem uma operação fixa e repetível. Essa distinção é a base do werkscan da FTE TO AI, que calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, com base no que já está registado sobre a operação, as regras e a origem dos dados.

Marvinde assistent van de Data Readiness Scan

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.