L'ordine consueto è: selezionare uno strumento, configurare lo strumento, e poi sperare che il processo si adegui. Nella pratica questo non funziona, perché uno strumento non porta con sé un processo. Uno strumento porta campi, collegamenti, dashboard — ma non la domanda su chi, nella vostra organizzazione, sia responsabile del consumo energetico dell'edificio tre, o se il facility manager che fornisce quel dato sappia che finirà nel rapporto scope 2.
L'ordine corretto è inverso: prima descrivere il processo, solo poi scegliere uno strumento sulla base di ciò di cui quel processo ha bisogno. Sembra una deviazione, ma è il percorso più breve, perché ogni requisito funzionale che pone a uno strumento deve provenire da qualche parte della vostra stessa organizzazione dei dati. Senza questo punto di partenza, selezionate sulla base di funzionalità che un fornitore considera importanti, non su funzionalità che risolvono il vostro effettivo problema.
I costi dell'ordine sbagliato non sono immediatamente visibili, perché uno strumento che non si adatta funziona inizialmente bene — per la parte del processo che per caso corrisponde a ciò che lo strumento si aspetta. Il resto viene costruito manualmente attorno ad esso: un allegato Excel qui, uno scambio di email là, un collaboratore che sa esattamente quale passaggio esce dal sistema. Funziona, finché quel collaboratore non se ne va o il volume dei dati non cresce.
Quanto costa dipende da quanti punti dati passano fuori dallo strumento e con quale frequenza devono essere raccolti nuovamente a mano per ogni ciclo di rendicontazione. Con un numero limitato di punti, si tratta di una deviazione accettabile. Con un numero crescente — più sedi, più categorie scope 3, più normative che si aggiungono — la deviazione diventa il percorso principale, e si finisce per pagare in modo strutturale il disallineamento tra strumento e processo. È un altro modo di dire ciò che è scritto anche in questa pagina: uno strumento sopra un processo disorganizzato produce report più ordinati sulle stesse cifre non attendibili.
Un requisito funzionale è un requisito solo se nasce da qualcosa. "Lo strumento deve poter mostrare la lineage" non è un requisito finché non sapete che il vostro controller deve ricostruire manualmente tre volte all'anno da dove proviene una cifra. "Lo strumento deve poter registrare la titolarità" non è un requisito finché non avete visto che un punto dato senza un responsabile non finisce nella lista delle azioni di nessuno.
Proprio per questo il registro dei punti dati, la lineage source-to-report per punto dato, e l'assegnazione della titolarità devono esistere prima, indipendentemente dallo strumento che alla fine scegliete. Non appena queste tre cose sono definite su carta — quale punto dato, da dove proviene, chi ne è responsabile — avete un elenco di requisiti che non proviene da un fornitore ma dalla vostra stessa organizzazione. Questo elenco lo usate per confrontare gli strumenti, non per scegliere alla cieca uno di essi. Come affrontare questo confronto senza rimpianti è descritto in questa pagina sulla selezione degli strumenti.
Il luogo in cui si trovano i dati varia molto per settore, e questo determina anche quali requisiti funzionali siano rilevanti. In un'impresa di costruzioni gran parte dei dati di sostenibilità si trova presso i subappaltatori e sul cantiere stesso, come descritto in questa pagina sulle fonti di dati nel settore delle costruzioni; lì un requisito relativo a molteplici fonti esterne per progetto è probabilmente più importante che in altri settori. Nel settore degli impianti i dati sono più spesso distribuiti tra bollettini di servizio e registrazioni di materiali a livello di progetto, come si legge in questa pagina sul settore degli impianti; lì conta soprattutto se uno strumento riesce a unire punti di inserimento separati senza che qualcuno lo faccia manualmente.
La domanda generale — organizzare prima il processo o acquistare prima uno strumento — viene approfondita in questa pagina, e la domanda centrale di questa pagina, quali requisiti derivino esattamente dal vostro stesso processo, è riassunta in questa pagina. Entrambe le pagine partono dallo stesso punto: l'ordine determina se un requisito è un vero requisito o solo un'ipotesi.
La Data Readiness Scan definisce il registro dei punti dati, la lineage e la titolarità prima ancora di parlare di uno strumento. Non è uno strumento di reporting né una soluzione a questionario — è il passaggio che determina cosa uno strumento debba effettivamente saper fare per la vostra organizzazione. Senza questo passaggio, acquistate funzionalità; con questo passaggio, acquistate una soluzione per un problema che potete indicare con precisione.
La scan è in fase di sviluppo. Chi desidera fare mappare il proprio processo in questo modo prima di scegliere uno strumento può iscriversi alla lista d'attesa e verrà informato non appena la scan sarà disponibile.
Una volta stabilito il registro dei punti dati ed è chiaro quale punto dato provenga da quale fonte e chi ne sia responsabile, nasce una seconda domanda, naturale: quale parte del lavoro che ruota attorno a questo — la raccolta, il controllo e il trasferimento delle cifre — è ancora lavoro umano, e quale parte può essere assunta da un sistema senza che l'attendibilità diminuisca. A questa domanda risponde la scan del lavoro di FTE TO AI, che calcola per ogni attività quale parte del lavoro possa essere assunta dall'AI. È una scan diversa dalla Data Readiness Scan, e un suo logico seguito: prima sapere qual è il dato e da dove proviene, solo poi valutare quale parte del lavoro manuale attorno ad esso possa diventare superflua.
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.