Um número num relatório de sustentabilidade quase sempre tem um percurso nas costas. Começa como uma linha numa fatura de energia, um contador num sistema de produção, um campo de entrada numa ferramenta de RH. Quando o número chega ao relatório, já foi contado, convertido, agregado e por vezes corrigido. Esses passos intermédios raramente são visíveis no resultado final. Quem só olha para o relatório vê um número. Quem olha para o percurso intermédio vê uma sequência de escolhas.
Entre a fonte e o relatório existe geralmente uma sequência fixa de processamentos, mesmo que ninguém a tenha alguma vez registado por escrito.
Primeiro, os dados são recolhidos: exportados de um sistema, copiados manualmente de uma fatura, copiados de uma folha de cálculo. Depois são normalizados: litros passam a metros cúbicos, quilowatt-hora passa a gigajoule, a moeda local passa a uma unidade de cálculo fixa. Em seguida, são atribuídos a uma categoria ou âmbito (scope), o que é uma escolha e não um automatismo. Depois segue-se a agregação: números de estabelecimentos, meses ou departamentos são reunidos num total anual. Ao longo do caminho ocorrem correções, para duplicações, para meses em falta, para uma unidade incorreta que alguém detetou há um ano e corrigiu manualmente.
Cada passo é um local onde é feita uma suposição. Um fator de emissão é escolhido. Uma estimativa substitui uma medição em falta. É aplicado um arredondamento. Em si, nada disso é um problema. O problema surge quando já ninguém sabe qual suposição foi feita, por quem, e porquê.
Um número de relatório que não pode ser rastreado até à sua fonte é um número afirmado. No momento em que um controller, auditor ou entidade reguladora pergunta como um número foi construído, a resposta tem de ser mais do que "isso está no sistema". A resposta tem de conseguir mostrar o percurso: esta fonte, esta conversão, esta agregação, esta correção.
Registar esse percurso tem três consequências diretas. Primeiro, detetar erros passa a ser trabalho de minutos em vez de dias, porque fica claro onde uma conversão foi aplicada e onde não foi. Segundo, torna-se possível a transferência de conhecimento: se a pessoa que gere a folha de cálculo saír, o conhecimento sobre os processamentos não desaparece com ela. Terceiro, cria-se uma base para verificação, porque uma parte externa consegue seguir os passos sem primeiro os ter de reconstruir.
Sem esse registo, cada ciclo de reporte é uma repetição de trabalho de investigação. Alguém liga ao gestor anterior, procura em e-mails antigos, adivinha a razão de um arredondamento. Esse trabalho é invisível no próprio relatório, mas determina quanta confiança esse relatório merece.
Nem todos os processamentos exigem a mesma abordagem. A agregação, em que números de várias fontes são reunidos num único total, exige um registo diferente da normalização, em que unidades e definições são uniformizadas. Quem quiser saber como documentar exatamente a agregação encontra isso em uma explicação sobre o registo dos passos de agregação, e quem se questiona sobre como lidar com a normalização pode ler isso em uma descrição sobre o registo da normalização. Ambos fazem parte da mesma cadeia, mas as questões que suscitam são diferentes: a agregação suscita questões sobre completude, a normalização sobre consistência.
A situação também muda quando a própria fonte não é um sistema mas uma folha de cálculo. Nesse caso não há exportação automática, nem registo de sistema, nem estrutura fixa, e o registo tem de ser construído de outra forma. Quem se depara com essa situação encontra pontos de partida em uma explicação sobre o mapeamento de fonte a relatório quando a fonte é uma folha de cálculo e em uma visão geral dos processamentos entre fonte e relatório especificamente em fontes de folha de cálculo. Para quem não tem orçamento para uma ferramenta e tem de construir a linhagem (lineage) com os meios já disponíveis, existe um método para criar linhagem sem software especializado.
O registo de processamentos é frequentemente confundido com um registo de alterações (logboek): uma lista de quem alterou o quê e quando. Isso é parte da história, mas não a totalidade. Uma trilha de auditoria (audit trail) que apenas regista alterações não explica por que razão uma escolha foi feita ou qual regra foi aplicada. A diferença entre um registo de alterações e uma verdadeira estrutura de responsabilização é desenvolvida em uma exposição sobre por que razão uma trilha de auditoria deve ser mais do que um registo de alterações.
O Data Readiness Scan mapeia este percurso: que fonte alimenta que ponto de dados, que processamentos existem entre eles, quem é o responsável por cada passo e que regra de qualidade lhe está associada. Isto não é um relatório nem um questionário, mas a estrutura subjacente que torna ambos fiáveis.
Uma vez descritos os processamentos entre fonte e relatório, torna-se visível quais os passos que são invariavelmente trabalho manual: copiar manualmente uma fatura, aplicar um fator de conversão fixo, agregar números mensais segundo uma regra fixa. É precisamente esse tipo de trabalho que permite calcular que parte pode ser assumida pela IA, sem que o registo de fonte a relatório perca a sua função. A FTE TO AI calcula, por tarefa, que parte é transferível, com base no scan de trabalho que torna essa diferença visível por tarefa.
O Data Readiness Scan está em desenvolvimento. Quem quiser que os processamentos entre fonte e relatório sejam registados assim que o scan estiver disponível pode inscrever-se na lista de espera.
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.