Kennisbank

Construir lineage antes de acrescentar uma ferramenta

Lineage não é mais do que o percurso que um número percorre: do local onde surge até ao local onde aparece no relatório. Esse percurso existe também sem ferramenta. Cada vez que alguém retira um valor de uma folha de cálculo, o soma com outro valor, o divide por um número de fte's ou o converte para outra unidade, essa pessoa percorre um pedaço de lineage — quer isso seja registado ou não. A questão não é se essa lineage existe, mas se alguém a consegue relatar sem ter de recorrer ao autor original.

As etapas entre a origem e o relatório

Um ponto de dados num relatório de sustentabilidade tem quase sempre uma série de etapas atrás de si. Primeiro há a origem: uma folha de cálculo com o consumo de energia por instalação, uma exportação de um sistema de RH, uma fatura de um fornecedor. Depois segue-se uma operação: somar, calcular médias, converter para equivalente de CO2, associar a um fator de emissão. Frequentemente segue-se uma agregação: valores por instalação tornam-se valores por país, valores por mês tornam-se valores por ano. Por fim, o valor chega ao relatório, muitas vezes através de uma última camada manual de transcrição ou colagem.

Para compreender o que significa o mapeamento de origem a relatório quando a origem é uma folha de cálculo, ajuda não ver estas etapas como um todo único, mas como uma sequência de ações separadas, cada uma com a sua própria probabilidade de erro. Quem apenas conhece o início e o fim do percurso não consegue ver onde, no meio, algo correu mal.

Por que cada etapa deve ser registada

Sem registo, a lineage existe apenas na cabeça de quem criou a folha de cálculo. Assim que essa pessoa está de férias, muda de função ou sai da organização, desaparece o conhecimento sobre o que aconteceu entre a origem e o relatório. Um controller que queira verificar um valor tem então de adivinhar ou perguntar. Uma parte externa que avalia o relatório tem de confiar em vez de se basear em documentação.

As operações que se situam entre a origem e o relatório tornaram-se muitas vezes invisíveis porque estão escondidas em fórmulas de células, macros ou na memória de um colaborador. Para descobrir quais as operações entre a origem e o relatório quando a origem é uma folha de cálculo, é necessário identificar separadamente cada fórmula, cada etapa manual e cada ligação — não como uma caixa negra, mas como uma sequência de ações separadas.

O mesmo se aplica às duas operações mais comuns em dados de sustentabilidade: a agregação e a normalização. A agregação — a soma de valores de várias origens num único total — exige o registo de quais as origens que foram incluídas e quais não foram, e porquê. Quem quiser saber como se regista a agregação quando a origem é uma folha de cálculo, encontra a necessidade de documentar, por cada soma, quais as células que foram incluídas. A normalização — a conversão de valores em bruto para uma unidade comparável — apresenta um problema semelhante: que fator de conversão foi utilizado, de que origem provém esse fator e se esse fator se manteve igual durante todo o ano. Para quem quiser registar isto, existe uma abordagem descrita em como se regista a normalização quando a origem é uma folha de cálculo.

Um registo de alterações não é suficiente

Um erro comum é pensar que um registo de alterações proporciona lineage suficiente. Um registo de alterações mostra quando uma célula foi ajustada e por quem, mas não porquê essa alteração foi necessária ou qual a regra que estava por detrás dela. Uma audit trail que apenas regista o que aconteceu, sem a lógica subjacente, deixa sem resposta as mesmas perguntas que um registo inexistente. Por que uma audit trail deve ser mais do que um registo de alterações quando a origem é uma folha de cálculo, está na diferença entre o registo de uma ação e o registo do motivo subjacente.

O que significa registar sem ferramenta

Sem ferramenta, isto significa, na prática: para cada ponto de dados, um documento fixo ou uma secção fixa onde consta qual a origem utilizada, quais as operações aplicadas e em que ordem, quem executou a operação e com base em que regra. Isto pode ser feito num registo separado, em campos de comentário junto à própria folha de cálculo, ou num resumo separado mantido junto ao processo de relato. É mais trabalho do que não registar nada, e menos trabalho do que implementar uma ferramenta sobre um processo que ainda não conhece estas etapas. É exatamente essa a razão para primeiro percorrer estas etapas: uma ferramenta aplicada a um processo desorganizado produz um resultado mais arrumado sobre os mesmos números não rastreáveis. Para os detalhes desta abordagem, incluindo o formato em que a lineage pode ser mantida por ponto de dados, existe um desenvolvimento sobre como se constrói lineage sem ferramenta quando a origem é uma folha de cálculo.

Quando o trabalho manual atinge limites

O registo manual de cada etapa entre a origem e o relatório é possível com um número limitado de pontos de dados e folhas de cálculo. Com um número maior de instalações, origens ou ciclos de relato, seguir cada operação torna-se uma tarefa que exige muito tempo e é sensível aos mesmos erros que a lineage precisamente pretende revelar. No momento em que esse limite se aproxima, é útil saber que parte deste trabalho de registo se pode repetir segundo uma regra fixa e, por isso, pode ser assumida por IA, e que parte continua a exigir avaliação. A werkscan da FTE TO AI calcula isso por tarefa, tornando claro onde o trabalho manual ainda tem lugar e onde a repetição exige outra coisa.