Un numero in un rapporto di sostenibilità ha quasi sempre un percorso alle spalle. Inizia come una riga in una fattura energetica, un contatore in un sistema di produzione, un campo di inserimento in uno strumento HR. Nel momento in cui il numero finisce nel rapporto, è stato conteggiato, convertito, aggregato e talvolta corretto. Questi passaggi intermedi sono raramente visibili nel risultato finale. Chi guarda solo al rapporto vede una cifra. Chi guarda al percorso intermedio vede una serie di scelte.
Tra la fonte e il rapporto c'è di norma una sequenza fissa di elaborazioni, anche se nessuno l'ha mai scritta.
Prima i dati vengono raccolti: esportati da un sistema, ritrascritti da una fattura, copiati da un foglio di calcolo. Poi vengono normalizzati: i litri diventano metri cubi, i chilowattora diventano gigajoule, la valuta locale diventa un'unità di calcolo fissa. Successivamente vengono attribuiti a una categoria o a uno scope, il che è una scelta e non un automatismo. Segue poi l'aggregazione: le cifre di sedi, mesi o reparti vengono unite in un totale annuale. Nel percorso avvengono correzioni, per doppi conteggi, per mesi mancanti, per un'unità errata che qualcuno ha notato un anno fa e ha corretto manualmente.
Ogni passaggio è un punto in cui viene fatta un'assunzione. Viene scelto un fattore di emissione. Una stima sostituisce una misurazione mancante. Viene applicato un arrotondamento. Di per sé nulla di ciò è un problema. Il problema nasce quando nessuno sa più più quale assunzione è stata fatta, da chi, e per quale motivo.
Una cifra di rapporto che non può essere ricondotta alla propria fonte è una cifra dichiarata. Nel momento in cui un controller, un revisore o un'autorità di controllo chiede come è composto un numero, la risposta deve essere più di "è nel sistema". La risposta deve poter mostrare il percorso: questa fonte, questa conversione, questa aggregazione, questa correzione.
Documentare questo percorso ha tre conseguenze immediate. In primo luogo, individuare gli errori diventa un lavoro di minuti invece che di giorni, perché è chiaro dove è stata applicata una conversione e dove non lo è stata. In secondo luogo, diventa possibile il passaggio di consegne: se chi gestisce il foglio di calcolo se ne va, la conoscenza delle elaborazioni non se ne va con lei. In terzo luogo, si crea una base per la verifica, perché una parte esterna può seguire i passaggi senza doverli prima ricostruire.
Senza questa documentazione, ogni ciclo di rendicontazione è una ripetizione di lavoro investigativo. Qualcuno chiama il precedente responsabile, cerca in vecchie email, indovina il motivo dietro un arrotondamento. Questo lavoro è invisibile nel rapporto stesso, ma determina quanta fiducia quel rapporto merita.
Non ogni elaborazione richiede lo stesso approccio. L'aggregazione, in cui cifre da più fonti vengono unite in un unico totale, richiede una documentazione diversa dalla normalizzazione, in cui unità e definizioni vengono uniformate. Chi vuole sapere come documentare esattamente l'aggregazione, lo trova in una spiegazione sulla documentazione dei passaggi di aggregazione, e chi si chiede come gestire la normalizzazione può leggerlo in una descrizione sulla documentazione della normalizzazione. Entrambe fanno parte della stessa catena, ma le domande che solleva sono diverse: l'aggregazione solleva domande sulla completezza, la normalizzazione sulla coerenza.
La situazione cambia anche quando la fonte stessa non è un sistema ma un foglio di calcolo. In quel caso non c'è un'esportazione automatica, nessun log di sistema, nessuna struttura fissa, e la documentazione deve essere costruita in modo diverso. Chi ha a che fare con questa situazione trova indicazioni in un chiarimento sul source-to-report mapping quando la fonte è un foglio di calcolo e in una panoramica delle elaborazioni tra fonte e rapporto specifiche per fonti a foglio di calcolo. Per chi non ha budget per uno strumento e deve costruire la lineage con le risorse già disponibili, c'è un metodo per creare la lineage senza software specializzato.
La documentazione delle elaborazioni viene spesso confusa con un registro: un elenco di chi ha modificato cosa e quando. Questo è una parte della storia, ma non il tutto. Una audit trail che registra solo le modifiche non racconta perché è stata fatta una scelta o quale regola è stata applicata. La differenza tra un registro e una vera struttura di rendicontazione è approfondita in una trattazione sul perché un audit trail deve essere più di un registro.
La Data Readiness Scan mappa questo percorso: quale fonte alimenta quale punto dati, quali elaborazioni si trovano nel mezzo, chi è responsabile di ogni passaggio e quale regola di qualità vi è associata. Non è un rapporto né un questionario, ma la struttura sottostante che rende entrambi affidabili.
Non appena le elaborazioni tra fonte e rapporto sono state descritte, diventa visibile quali passaggi sono in realtà lavoro manuale fisso: ritrascrivere una fattura, applicare un fattore di conversione fisso, unire cifre mensili secondo una regola fissa. È esattamente questo il tipo di lavoro di cui si può calcolare quale parte può essere assunta dall'AI, senza che la documentazione dalla fonte al rapporto perda la sua funzione. FTE TO AI calcola per ciascun compito quale parte di esso è trasferibile, sulla base della scansione del lavoro che rende visibile questa differenza compito per compito.
La Data Readiness Scan è in fase di sviluppo. Chi desidera far documentare le elaborazioni tra fonte e rapporto non appena la scansione sarà disponibile può iscriversi alla lista d'attesa.
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.