Un dato in un rapporto di sostenibilità non è quasi mai lo stesso dato presente nel sistema di origine. Tra il momento in cui un collaboratore inserisce una fattura energetica o un sensore registra una lettura del contatore, e il momento in cui quel numero compare in una tabella del rapporto, succede qualcosa. Si effettuano conversioni, addizioni, correzioni, aggregazioni con altre fonti. Il source-to-report mapping consiste nel documentare quel percorso: ogni fase che i dati attraversano tra la fonte e il rapporto, nell'ordine in cui avviene.
Il risultato di un calcolo non dice nulla sulla sua attendibilità se nessuno può ricostruire come è stato ottenuto. Un dato sulle emissioni può essere corretto perché i passaggi sottostanti erano corretti, oppure può sembrare corretto perché un errore in una fase ha per caso compensato un errore in un'altra. Senza mapping, questa differenza non è visibile. Con il mapping sì: ogni fase è autonoma, con una propria fonte, una propria elaborazione e un proprio risultato che può essere verificato.
Quel percorso è solitamente composto da più fasi di quanto ci si aspetti. Tra i dati grezzi di origine e il dato di rendicontazione si susseguono spesso più elaborazioni: unità che vengono convertite, valori che vengono aggregati, eccezioni che vengono corrette manualmente. Quali elaborazioni si trovano tra la fonte e il rapporto varia in base al singolo dato, ma la struttura è sempre la stessa: una serie di fasi che ciascuna aggiunge o modifica qualcosa ai dati, e che devono essere documentate singolarmente per poter seguire l'insieme.
Due tipi di elaborazioni meritano un'attenzione particolare, perché sono le più frequenti e quelle in cui è più facile che si introducano errori inosservati.
La prima è l'aggregazione: la fusione di dati provenienti da più fonti o più periodi in un unico numero. Chi documenta esattamente come avviene tale somma, quali voci sono state incluse e quali no, evita che un dato di rendicontazione diventi una scatola nera. Come documentare l'aggregazione determina se in seguito qualcuno potrà ancora ricostruire il percorso in un modo che resti riconducibile alle voci sottostanti.
La seconda è la normalizzazione: la riconduzione di dati di origine eterogenei a un'unità o definizione comune, in modo che i dati provenienti da sistemi diversi diventino comparabili. Un litro di gasolio e un kilowattora di elettricità diventano comparabili solo dopo una conversione, e quella conversione contiene ipotesi. Documentare come si documenta la normalizzazione significa registrare quali sono tali ipotesi, in modo che un'altra parte possa seguire la stessa ipotesi o metterla in discussione.
È tentante confondere il mapping con un registro delle attività: un elenco di chi ha modificato cosa e quando. Questo è una componente, ma non l'insieme. Un audit trail che registra solo le modifiche non racconta perché un'elaborazione è stata applicata o quale regola ne era alla base. Perché un audit trail è più di un registro ha a che fare con la domanda che ogni revisore alla fine pone: non solo cosa è cambiato, ma sulla base di quale logica e quale fonte.
Il source-to-report mapping viene spesso confuso con il software. Esistono strumenti che mostrano automaticamente la lineage, ma questi strumenti registrano solo ciò che è già stato fornito in forma strutturata. Un'organizzazione che lavora ancora con fogli di calcolo e trasferimenti manuali può documentare il percorso altrettanto bene, solo con mezzi diversi: un formato di documentazione fisso per ogni fase, un luogo fisso dove conservare i file di origine, un metodo fisso per annotare le modifiche. Come organizzare questo senza uno strumento è descritto in come si crea la lineage senza uno strumento. La disciplina non risiede nel software, ma nella ripetibilità della documentazione.
Questa disciplina è particolarmente importante quando la fonte stessa è già un foglio di calcolo. Una cella in un foglio di lavoro non ha una provenienza incorporata: nessuno vede automaticamente chi ha inserito un valore o sulla base di quale documento. Cosa significa il source-to-report mapping quando la fonte è un foglio di calcolo è che tale provenienza deve essere organizzata manualmente, con la stessa precisione di un sistema automatizzato.
In pratica, il mapping si riduce a una domanda che si ripete per ogni dato: da dove proviene questo valore, cosa ne è stato fatto prima che finisse nel rapporto, e chi ha eseguito o approvato quella fase. Porre questa domanda per centinaia di dati richiede molto lavoro, e proprio per questo risulta tentante saltarla. Ma un rapporto costruito su una base non riconducibile rimane vulnerabile a domande a cui nessuno può rispondere nel momento in cui vengono poste.
Mappare queste fasi, per ogni dato e su più fonti, è un lavoro ripetitivo con una struttura fissa: identificare la fonte, descrivere l'elaborazione, stabilire il responsabile, ripetere per il dato successivo. Un lavoro con una struttura fissa è esattamente il tipo di lavoro di cui una parte può essere svolta dall'AI. La werkscan di FTE TO AI calcola per ogni attività quale parte di questo lavoro si presta a ciò, in modo che diventi chiaro dove le persone restano necessarie per la valutazione e dove la ripetizione può essere automatizzata.
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.