Uno Strumento Su un Processo Rotto Vi Dà Solo Report Più Ordinati degli Stessi Numeri Inaffidabili

Costruite prima un registro dei datapoint, e poi progettate un processo source-to-report per datapoint con definizioni coerenti tra unità, invece di lasciare che ogni unità sviluppi il proprio approccio di raccolta indipendentemente. Le definizioni incoerenti tra unità sono spesso invisibili finché qualcuno non cerca di sommare i numeri a livello di gruppo, momento in cui il totale risultante combina silenziosamente cifre che non hanno mai misurato davvero la stessa cosa.

Sistemate il processo, proprietà, definizioni, controlli, prima di introdurre qualsiasi strumento; uno strumento su un processo rotto produce solo report inaffidabili più ordinati che sembrano più credibili di quanto siano davvero. I fogli di calcolo non sono davvero il problema; l'assenza di proprietà chiara, definizioni coerenti, e qualsiasi controllo su cosa conta come cifra valida è il problema, e nessun acquisto di software risolve quello da solo.

Progettate ogni processo di raccolta con controlli, aggregazione, normalizzazione, calcolo e standardizzazione, così ogni cifra si può tracciare fino a una fonte invece di arrivare al report finale come un numero non spiegato che nessuno può difendere se richiesto. Un processo verificabile assomiglia molto a come la finanza già gestisce i dati finanziari, semplicemente quella stessa disciplina tradizionalmente non è stata applicata alle cifre di sostenibilità, esattamente la lacuna che questo approccio colma.

Documentare, per datapoint, da dove proviene, quale elaborazione subisce, e dove finisce nel report finale, così l'intero percorso dalla fonte grezza alla cifra pubblicata è esplicito e verificabile invece di qualcosa che solo una persona nell'organizzazione capisce davvero. Senza questa mappatura, una cifra nel report finale è in pratica una scatola nera che nessuno può verificare in modo indipendente né ricostruire se richiesto.

Assegnate un RACI per datapoint e processo, proprietà della definizione in sostenibilità, proprietà del processo e del controllo in finanza, invece di lasciare la proprietà implicita e presumere che qualcuno si assumerà naturalmente la responsabilità. I dati di sostenibilità hanno una specifica tendenza a finire senza proprietario, poiché cadono tra dipartimenti che presumono ciascuno che l'altro sia responsabile, esattamente ciò che un RACI esplicito è progettato per evitare.

Determinate quali datapoint richiedono davvero i vostri temi materiali e lo standard di reporting, e registrate cosa esiste già rispetto a cosa va costruito, invece di cercare di raccogliere ogni datapoint concepibile che lo standard permette teoricamente. Un registro delimitato a ciò che è genuinamente richiesto, basato sui vostri temi materiali specifici, è una frazione delle dimensioni di uno costruito cercando di coprire ogni possibile disclosure senza considerarne la rilevanza.

Standardizzate la definizione nella fase di registro dei datapoint, prima di progettare qualsiasi processo di raccolta, poiché cercare di riconciliare definizioni incoerenti dopo che ogni unità ha già costruito il proprio processo è considerevolmente più dirompente. Raggiungere accordo su una definizione condivisa presto, anche se richiede più tempo all'inizio, evita il costo molto maggiore di smantellare processi incompatibili dopo.

Definite come appare un valore valido per datapoint e quale scostamento scatena un alert, la stessa disciplina che i dati finanziari hanno già, estesa a cifre di sostenibilità storicamente raccolte con molto meno rigore. Un framework di controllo non deve essere elaborato per essere efficace; deve specificare, per ogni datapoint, come appare un intervallo plausibile e cosa succede quando una cifra ne esce.

Assicuratevi che ogni cifra abbia una fonte tracciabile e un proprietario nominato fin dal primo giorno, ricostruire questo a posteriori è molto più costoso, in particolare una volta che la persona che originariamente ha compilato una cifra ha cambiato ruolo o lasciato l'organizzazione del tutto. I fornitori di assurance cercano specificamente questo tipo di tracciabilità, e la sua assenza è una delle ragioni più comuni per cui un report di sostenibilità non ottiene un'opinione di assurance pulita.

Sistemate prima il processo. I requisiti funzionali di uno strumento dovrebbero derivare dal processo progettato, non il contrario, poiché scegliere il software prima che esista il processo significa indovinare i requisiti invece di definirli da un vero flusso di lavoro testato. Gli strumenti scelti così spesso risultano mancare di capacità di cui il processo ha davvero bisogno, o includere una lunga lista di funzioni che il processo non usa mai.

Definite i requisiti funzionali basandovi sul vostro processo di raccolta progettato, e poi fate la selezione, mai prima che esista il processo, perché una demo di un fornitore è molto più persuasiva di una valutazione chiara di ciò di cui la vostra raccolta dati specifica ha davvero bisogno. I requisiti definiti a partire da un vero processo sono di solito più specifici e utili durante la valutazione dei fornitori rispetto a una checklist generica di funzioni copiata da un report di settore.

La proprietà della definizione spetta alla sostenibilità; la proprietà del processo e del controllo spetta alla finanza, che ha già i sistemi e la disciplina per farlo, poiché la finanza ha passato decenni a costruire il rigore che il reporting di sostenibilità ora deve eguagliare. Questa divisione evita l'errore comune per cui la sostenibilità possiede sia le definizioni che il processo, senza i sistemi che la finanza già ha per eseguire quel processo in modo affidabile su scala.

Usate lo stesso registro dei datapoint e design del processo come template, adattato per unità ma mai ridefinito per unità, così l'aggregazione a livello di gruppo continua ad avere senso invece di diventare un mosaico di approcci reinventati localmente. L'adattamento al contesto locale va bene ed è spesso necessario; ridefinire il datapoint sottostante o la sua definizione a livello locale è ciò che rompe la confrontabilità a livello di gruppo.

Settimane per un singolo tema; un dispiegamento completo a livello di gruppo con governance si misura in trimestri, guidato principalmente dal numero di unità e parti coinvolte più che dalla complessità tecnica dei dati stessi. La tempistica scala molto di più con il coordinamento organizzativo che con la difficoltà della misurazione sottostante, quindi un pilot su un singolo tema può avanzare molto più velocemente di un dispiegamento completo.

Mantenete il source-to-report mapping e il framework di controllo come la documentazione stessa, è costruito per essere pronto per l'audit by design, invece di trattare la documentazione come un compito separato da completare quando il processo è già in corso. Aggiungere documentazione a posteriori su un processo già esistente è di solito sia più lento che meno preciso rispetto a costruire la documentazione come sottoprodotto naturale di un buon design del processo fin dall'inizio.