Uma grande parte dos dados de sustentabilidade não provém de um sistema com campos e unidades fixos, mas de uma folha de cálculo elaborada por um colaborador. Consumo de energia em kWh ao lado de litros de combustível, dados de resíduos por unidade em unidades diferentes, números de colaboradores contados em datas de referência diferentes. Antes de tal número caber num relatório, é normalizado: convertido para uma unidade comum, corrigido por período, agregado a um nível organizacional. Essa normalização acontece frequentemente na mesma folha de cálculo, com uma fórmula que ninguém fora de quem a elaborou conhece.
O problema não é que se normalize. O problema é que o passo é invisível. Uma fórmula numa célula mostra um resultado, não o pressuposto subjacente. Se outra pessoa abrir o ficheiro, vê um número, não um raciocínio.
Entre a folha de cálculo em bruto e o número publicado existem geralmente vários passos: conversão de unidades, estimativa ou omissão de valores em falta, soma de números de várias unidades, aplicação de um fator de correção para um desvio conhecido. Cada passo altera o número, e cada passo é uma escolha. Que fator de conversão foi usado, sobre que período foi feita a soma, porque é que um valor anómalo foi ou não incluído. Sem registo, essas escolhas existem apenas na cabeça de quem elaborou a folha de cálculo. Uma visão geral de quais operações se situam entre a fonte e o relatório mostra que a normalização raramente é um único passo, mas antes uma cadeia em que cada elo deve poder ser verificado separadamente.
Registar a normalização não é o mesmo que escrever um esclarecimento depois de o relatório estar concluído. Trata-se do momento em que a operação ocorre: que fórmula, com que parâmetros, aplicada a que valor bruto. É essa a diferença entre uma trilha de auditoria e um registo. Um registo apenas assinala que algo aconteceu; uma trilha de auditoria esclarece o que aconteceu e porque é que essa operação era a correta naquele momento. Essa distinção é desenvolvida em porque é que uma trilha de auditoria é mais do que um registo quando a fonte é uma folha de cálculo. Quem só documenta a normalização a posteriori arrisca-se a que a escolha original já não possa ser reconstituída, sobretudo se quem elaborou a folha de cálculo tiver entretanto mudado de função ou saído da organização.
Um pressuposto frequente é que a lineage — o rastreio de um número desde a fonte até ao relatório — exige um sistema que o faça automaticamente. Isso não é necessariamente verdade. Também com folhas de cálculo como fonte, é possível registar por ponto de dados qual o valor de origem utilizado, que operação lhe foi aplicada e quem aprovou essa operação. Isso exige disciplina, não software. A forma como isso funciona na prática está descrita em como criar lineage sem ferramenta quando a fonte é uma folha de cálculo. O essencial é uma estrutura fixa: por ponto de dados, a tabela de origem, a fórmula aplicada, e uma referência a quem estabeleceu essa fórmula. É mais um formato do que um sistema, e é aplicável antes de se pensar numa ferramenta.
Uma regra de normalização — por exemplo, o fator de conversão de um tipo de combustível para equivalente de CO2 — é em si mesma um ponto de dados que precisa de um responsável. Não o responsável pelo número final, mas o responsável pela regra: quem decide que esse fator é o correto, e quem o ajusta quando a norma muda. Sem essa atribuição, a responsabilidade desloca-se implicitamente para quem, por acaso, construiu a folha de cálculo. A questão quem detém a definição de um ponto de dados trata precisamente disso: uma definição e uma regra de cálculo precisam de um responsável distinto de quem introduz os dados. Isso é um dos elementos do mapeamento source-to-report, explicado em o que é source-to-report mapping: não apenas de onde vem um número, mas também quem é responsável por cada passo intermédio.
Existem ferramentas que automatizam a normalização e mostram a lineage. Essas ferramentas não resolvem nada se o processo subjacente não estiver organizado: se ninguém tiver registado que regra se aplica a que ponto de dados, a ferramenta apenas mostra mais rapidamente um número cuja origem continua pouco clara. Primeiro o processo, depois a ferramenta. Quem decide sobre essa organização é uma questão que vai além da normalização em si; essa é abordada em quem detém o processo subjacente.
Uma vez esclarecido quais são os passos de normalização, quem os executa e com base em que regra, surge uma segunda questão: que parte desse trabalho manual na folha de cálculo pode ser transferida para a IA. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida, e é utilizável a partir do momento em que os passos de normalização estão descritos como tarefas separadas e reconhecíveis, em vez de escondidos numa fórmula.
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.