Ordinea obișnuită este: se selectează un instrument, se configurează instrumentul, și apoi se speră că procesul se va adapta la el. În practică, acest lucru nu funcționează, pentru că un instrument nu aduce cu sine un proces. Un instrument aduce câmpuri, integrări, tablouri de bord — dar nu și răspunsul la întrebarea cine din organizația dumneavoastră este responsabil pentru consumul de energie al clădirii trei, sau dacă managerul facilitar care furnizează acea cifră știe că aceasta ajunge în raportarea scope 2.
Ordinea corectă este inversă: mai întâi se descrie procesul, abia apoi se alege un instrument pe baza a ceea ce acel proces are nevoie. Sună ca un drum mai lung, dar este de fapt cel mai scurt drum, pentru că fiecare cerință funcțională pe care o formulați pentru un instrument trebuie să provină de undeva din propria dumneavoastră organizare a datelor. Fără acest punct de plecare, alegeți în funcție de funcții pe care un furnizor le consideră importante, nu în funcție de funcții care rezolvă blocajul dumneavoastră.
Costurile ordinii greșite nu sunt vizibile imediat, pentru că un instrument care nu se potrivește funcționează la început perfect — pentru partea din proces care coincide întâmplător cu ceea ce se așteaptă instrumentul. Restul este construit manual în jurul lui: un fișier Excel anexat aici, un schimb de e-mailuri acolo, un angajat care știe exact care pas rămâne în afara sistemului. Acest lucru funcționează, până când angajatul respectiv pleacă sau volumul de date crește.
Ce costă depinde de câte puncte de date circulă în afara instrumentului și cât de des trebuie acestea colectate manual din nou pentru fiecare ciclu de raportare. La un număr mic de puncte, acesta este un ocol acceptabil. La un număr în creștere — mai multe locații, mai multe categorii scope 3, mai multă legislație care se adaugă — ocolul devine ruta principală, iar dumneavoastră plătiți în mod structural pentru discrepanța dintre instrument și proces. Este un alt mod de a spune ceea ce se găsește și pe această pagină: un instrument suprapus peste un proces neorganizat produce rapoarte mai ordonate despre aceleași cifre nesigure.
O cerință funcțională este cu adevărat o cerință doar dacă provine de undeva. „Instrumentul trebuie să poată afișa lineage” nu este o cerință până când nu știți că controlorul dumneavoastră trebuie să caute manual de trei ori pe an de unde provine o cifră. „Instrumentul trebuie să poată înregistra proprietatea” nu este o cerință până când nu ați observat că un punct de date fără proprietar nu se află pe lista de acțiuni a nimănui.
Exact de aceea registrul de puncte de date, lineage-ul source-to-report pentru fiecare punct de date și atribuirea proprietății trebuie să existe mai întâi, independent de instrumentul pe care îl veți alege în final. Odată ce aceste trei elemente sunt consemnate — care punct de date, de unde provine, cine își asumă responsabilitatea pentru el — aveți o listă de cerințe care nu provine de la un furnizor, ci din propria dumneavoastră organizație. Această listă o folosiți pentru a compara instrumente, nu pentru a alege unul la întâmplare. Modul în care puteți realiza această comparație fără regrete este descris pe această pagină despre selecția instrumentelor.
Locul unde se află datele diferă mult de la un sector la altul, iar acest lucru determină și care cerințe funcționale sunt relevante. Într-o companie de construcții, o mare parte din datele de sustenabilitate se află la subcontractanți și pe șantierul propriu-zis, așa cum este descris pe această pagină despre sursele de date în construcții; acolo o cerință legată de mai multe surse externe per proiect este probabil mai importantă decât în alte sectoare. În sectorul instalațiilor, datele sunt mai des dispersate în bonuri de service și înregistrări de materiale la nivel de proiect, așa cum se poate citi pe această pagină despre sectorul instalațiilor; acolo contează mai ales dacă un instrument poate combina puncte de introducere separate fără ca cineva să facă asta manual.
Întrebarea generală — mai întâi se organizează procesul sau mai întâi se cumpără un instrument — este dezvoltată în continuare pe această pagină, iar întrebarea centrală a acestei pagini, care anume cerințe provin exact din propriul dumneavoastră proces, este rezumată pe această pagină. Ambele pagini pornesc de la același punct: ordinea determină dacă o cerință este o cerință reală, sau doar o presupunere.
Data Readiness Scan consemnează registrul de puncte de date, lineage-ul și proprietatea înainte de a se discuta despre vreun instrument. Nu este un instrument de raportare și nici o soluție bazată pe chestionar — este pasul care determină ce anume trebuie să poată face un instrument pentru organizația dumneavoastră. Fără acest pas, cumpărați funcții; cu acest pas, cumpărați o soluție pentru o problemă pe care o puteți indica exact.
Scanul este în curs de dezvoltare. Cei care doresc să își cartografieze procesul în acest mod înainte de a alege un instrument se pot înscrie pe lista de așteptare și vor fi informați imediat ce scanul devine disponibil.
Odată ce registrul de puncte de date este stabilit și este clar din ce sursă provine fiecare punct de date și cine este responsabil pentru el, apare o a doua întrebare, firească: care parte din munca din jurul acestuia — colectarea, verificarea și transferul cifrelor — este încă muncă umană, și care parte poate fi preluată de un sistem fără ca fiabilitatea să scadă. Această întrebare este răspunsă de scanul de muncă al FTE TO AI, care calculează pentru fiecare sarcină ce parte din muncă poate fi preluată de AI. Acesta este un scan diferit de Data Readiness Scan, și o continuare logică a acestuia: mai întâi se stabilește care sunt datele și de unde provin, abia apoi se analizează care parte din munca manuală din jurul lor poate deveni inutilă.
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.