Um auditor que presta assurance sobre dados de sustentabilidade faz uma pergunta simples: de onde vem este número, e quem pode demonstrá-lo. Muitas organizações só percebem durante a preparação para um processo de assurance que essa pergunta não pode ser respondida por ponto de dados. O número está no relatório, mas o caminho até ele não está registado em lugar nenhum.
A assurance não pede um relatório bonito. Pede um rasto: um ponto de dados tem de poder ser reconduzido a uma origem, através de passos registados, com um titular identificável que consiga explicar como o número surgiu. Sem esse rasto, cada verificação é uma reconstrução a posteriori, com os riscos que isso implica: pessoas que já não sabem porque um número foi ajustado, folhas de cálculo que foram substituídas, uma origem que já não é possível encontrar.
A pergunta onde já existe um ponto de dados parece simples, mas é exatamente a pergunta que surge durante a assurance. Se a resposta varia por sistema, ou se ninguém tem certeza, isso não é uma questão de formato de relatório. É uma lacuna na linhagem que um processo de assurance expõe.
Existe a tendência de resolver este problema com software que gera relatórios. Isso nada altera na verificabilidade dos números subjacentes. Uma ferramenta que produz um resultado apresentável sobre um processo sem origens e titularidade registadas entrega um relatório mais convincente sobre os mesmos dados pouco fiáveis. A assurance olha através dessa camada.
A verificabilidade começa com três perguntas por ponto de dados: de onde vem, quem é responsável por ele, e que regra determina se o valor está correto. Não são perguntas que uma ferramenta de relatórios responda. São perguntas que uma organização tem de apurar, registar e manter ela própria.
Um registo de pontos de dados com linhagem source-to-report responde a essas três perguntas, por ponto de dados. Mostra que parte dos dados já tem uma origem e um titular claros, e que parte não tem. Essa distinção é exatamente o que está em causa em quantos dos seus pontos de dados têm uma origem: não uma estimativa, mas uma contagem por ponto de dados, com as lacunas visíveis em vez de diluídas numa média.
O que isto não faz: não produz um parecer de assurance, não avalia materialidade, e não garante a aprovação por um auditor. Um registo com linhagem é trabalho preparatório. Torna visível o que é verificável e o que ainda não é, para que um processo de assurance não tropece em perguntas que já deveriam ter sido feitas há muito. O resultado desse processo continua a caber à parte que presta a assurance.
Um ponto de dados sem titular é um ponto de dados que ninguém pode defender quando surge uma pergunta sobre ele. Na prática, a titularidade muda: as pessoas mudam de função, folhas de cálculo são herdadas por um sucessor que não conhece o histórico. A pergunta quem lê o seu registo de pontos de dados quando já não estiver presente não é, por isso, uma experiência mental. É um teste que verifica se o registo é independente de uma única pessoa, ou se o conhecimento desaparece assim que essa pessoa sai.
Um registo que só existe na cabeça do controller não é um registo. A assurance exige algo que se mantenha quando a composição da equipa muda.
Parte da dificuldade na preparação para a assurance não vem de dados de má qualidade, mas de demasiados dados: pontos de dados recolhidos porque em algum momento pareceram relevantes, sem que ninguém volte a verificar se continuam a ser. A pergunta de que pontos de dados precisa realmente pertence, por isso, ao mesmo exercício da construção da linhagem. Menos pontos de dados com um rasto fechado são mais verificáveis do que uma lista longa em que metade nunca foi utilizada.
As folhas de cálculo são frequentemente responsabilizadas neste contexto, mas o problema raramente está no próprio formato de ficheiro. Por que as folhas de cálculo nem sempre são o problema subjacente é tratado em por que as folhas de cálculo não são o problema: uma folha de cálculo com uma origem registada e um titular designado é tão verificável como um sistema, e um sistema sem esse registo é tão vulnerável como uma folha de cálculo solta.
O efeito de um registo fechado não se sente apenas durante a preparação da assurance, mas no trabalho diário em torno do relatório: menos ida e volta sobre a origem de um número, menos tempo gasto a reconstruir um caminho que já foi apurado uma vez. O que muda concretamente quando essa estrutura está estabelecida encontra-se descrito em o que muda quando a linhagem está estabelecida.
Esta ferramenta está em construção. Quem quiser realizar a análise assim que estiver disponível pode inscrever-se na lista de espera.
Apurar origens, titularidade e regras de qualidade é trabalho que hoje ainda se faz muitas vezes de forma manual, por ponto de dados, por sistema. Parte desse trabalho de apuramento pode ser acelerada com IA, outra parte não, e qual parte é isso varia por organização e por processo. A FTE TO AI oferece uma análise de trabalho que calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, tornando claro onde a automatização devolve tempo e onde o trabalho manual permanece.
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.