Há um momento fixo em quase toda conversa sobre dados de sustentabilidade: alguém aponta para a planilha. Muitas abas, muito trabalho manual, muita chance de erros. A conclusão parece óbvia: substituir a planilha por um sistema e o problema está resolvido. Essa conclusão costuma ser tirada precocemente.
Uma planilha é uma superfície. Ela mostra números, os soma, os relaciona entre si. O que ela não faz é explicar de onde vem um número, quem é responsável por ele, ou se ainda corresponde à definição estabelecida há dois anos. Essas perguntas não foram feitas à planilha — nunca foram registradas em lugar nenhum. A planilha recebe a culpa por algo que já deu errado antes: na coleta, na digitação manual, na suposição de que um colega saberia qual número era o pretendido.
Substitua a planilha por um pacote de software e essas perguntas permanecem sem resposta. O sistema então mostra uma visão mais organizada da mesma incerteza. O relatório parece mais profissional; os dados subjacentes não se tornaram mais confiáveis. Essa é a armadilha: comprar uma ferramenta antes de estar claro o que essa ferramenta deve organizar.
Geralmente trata-se de três coisas que cresceram desconectadas umas das outras. Não existe uma visão atualizada de quais pontos de dados uma organização realmente precisa — essa visão foi criada em algum momento para um padrão de relatório antigo e nunca foi atualizada. Não existe uma linha registrada da fonte até o número do relatório, o que faz com que ninguém possa afirmar com certeza se um número vem de um sistema ou de outro, ou de uma estimativa que alguém preencheu porque os dados reais não estavam disponíveis. E não existe um responsável por cada ponto de dado — a pessoa que fornece o número não é automaticamente quem consegue explicar de onde ele vem ou qual é a sua qualidade.
Essas três coisas não têm nada a ver com planilhas. Elas causariam o mesmo problema em qualquer sistema. Uma planilha apenas as torna mais visíveis, porque não há uma camada por cima que esconda a confusão.
Um registro de pontos de dados com linhagem de fonte até relatório (source-to-report lineage) registra de onde vem um ponto de dado, quem é responsável por ele e quais regras de qualidade se aplicam. Isso é útil, e também é limitado. O registro não mostra um julgamento de conteúdo sobre se um número está correto — ele mostra se o caminho até esse número é rastreável. Duas organizações com o mesmo registro ainda podem ter desempenhos diferentes na qualidade dos dados, porque uma tem uma fonte que em si é imprecisa e a outra não. O registro torna essa diferença visível; não a resolve.
Também é importante: nem todo ponto de dado precisa da mesma quantidade de linhagem. Para alguns números, uma fonte simples e bem documentada é suficiente; para outros, é necessário mais detalhe porque há mais etapas entre a fonte e o relatório. Quais pontos de dados uma organização realmente precisa depende da obrigação de relatório e do setor, e isso é diferente de assumir que tudo merece a mesma atenção. Quantos dos pontos de dados existentes já têm uma fonte varia muito entre organizações — em uma isso está registrado numa integração de ERP, em outra está na memória de um único funcionário.
Criar um registro e uma linhagem não é uma questão de ligar um sistema. É verificar, tema por tema, onde um número surge, quem o analisa antes de chegar ao relatório, e o que acontece quando essa pessoa já não está mais presente. Esse trabalho varia de tema para tema: para um tema a fonte já está pronta, para outro ainda precisa ser encontrada ou reconstruída. Quem se pergunta quanto tempo isso leva por tema encontra uma resposta mais realista em a indicação de prazo por tema do que numa demonstração de ferramenta que promete que tudo acontece automaticamente.
Essa abordagem não produz um relatório — isso é feito por outra ferramenta, com esses dados como base. O que ela produz é uma estrutura que permanece de pé mesmo quando a planilha é substituída, mesmo quando o funcionário que sabia tudo sai da organização. O que isso significa na prática para quem futuramente consultar o registro está descrito em quem consulta o seu registro de pontos de dados quando quem o elaborou já não está mais presente, e o que muda uma vez que a linhagem esteja estabelecida está em as consequências de uma linhagem já estabelecida.
As planilhas não são o problema, mas são o primeiro sintoma visível. Quem substitui a planilha sem antes saber quais pontos de dados realmente importam, qual fonte lhes corresponde e quem é responsável por eles, apenas transfere o problema para um sistema mais caro. O que resta então é a pergunta que antecede esse trabalho: quais pontos de dados são realmente necessários para a obrigação de relatório, e se parte deles talvez já exista em algum lugar da organização sem que ninguém saiba, como se pode ler em onde um ponto de dado pode já estar registrado.
Esse é um trabalho que as pessoas hoje fazem em grande parte manualmente: localizar fontes, comparar definições, apurar responsabilidades. Parte desse trabalho de apuração pode ser estruturada e acelerada com IA, parte não — essa diferença é exatamente o que o scan de trabalho da FTE TO AI analisa. O scan de trabalho calcula, por tarefa, qual parte do trabalho pode ser assumida pela IA, oferecendo assim uma visão mais realista do que a suposição de que uma ferramenta resolve o problema por completo.
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.