Un număr dintr-un raport de sustenabilitate a parcurs aproape întotdeauna un drum. Începe ca o linie într-o factură de energie, un contor într-un sistem de producție, un câmp de introducere într-un instrument HR. Până când numărul ajunge în raport, a fost numărat, convertit, agregat și uneori corectat. Acești pași intermediari sunt rareori vizibili în rezultatul final. Cine se uită doar la raport vede o cifră. Cine se uită la drumul dintre ele vede o serie de decizii.
Între sursă și raport există de regulă o ordine fixă de prelucrări, chiar dacă nimeni nu a notat-o vreodată.
Întâi se colectează date: exportate dintr-un sistem, transcrise dintr-o factură, copiate dintr-un spreadsheet. Apoi sunt normalizate: litrii devin metri cubi, kilowatt-ora devine gigajoule, moneda locală devine o unitate de calcul fixă. Ulterior, sunt alocate unei categorii sau unui domeniu (scope), ceea ce este o decizie, nu un automatism. Urmează apoi agregarea: cifrele de la sucursale, luni sau departamente sunt reunite într-un total anual. Pe parcurs au loc corecții, pentru dubluri, pentru luni lipsă, pentru o unitate greșită pe care cineva a observat-o cu un an în urmă și a corectat-o manual.
Fiecare pas este un loc în care se face o presupunere. Se alege un factor de emisie. O estimare înlocuiește o măsurare lipsă. Se aplică o rotunjire. În sine, niciunul dintre acestea nu este o problemă. Problema apare atunci când nimeni mai nu știe ce presupunere s-a făcut, de către cine și de ce.
O cifră din raport care nu poate fi urmărită înapoi la sursa sa este o cifră afirmată. De îndată ce un controller, auditor sau autoritate de supraveghere întreabă cum a fost construit un număr, răspunsul trebuie să fie mai mult decât „așa apare în sistem”. Răspunsul trebuie să poată arăta traseul: această sursă, această conversie, această agregare, această corecție.
Documentarea acestui traseu are trei consecințe directe. În primul rând, detectarea erorilor devine o muncă de minute, nu de zile, pentru că este clar unde s-a aplicat o conversie și unde nu. În al doilea rând, devine posibil transferul: dacă persoana care administrează spreadsheetul părăsește organizația, cunoștințele despre prelucrări nu pleacă odată cu ea. În al treilea rând, se creează o bază pentru verificare, pentru că o parte externă poate urma pașii fără a trebui să îi reconstruiască mai întâi.
Fără această documentare, fiecare ciclu de raportare este o repetare a unei investigații. Cineva sună administratorul anterior, caută în e-mailuri vechi, ghicește motivul din spatele unei rotunjiri. Această muncă este invizibilă în raportul propriu-zis, dar determină totuși cât de multă încredere merită raportul respectiv.
Nu fiecare prelucrare necesită aceeași abordare. Agregarea, în care cifrele din mai multe surse sunt reunite într-un singur total, necesită o documentare diferită de normalizare, în care unitățile și definițiile sunt aliniate. Cine dorește să știe exact cum se documentează agregarea găsește acest lucru în o explicație despre documentarea etapelor de agregare, iar cine se întreabă cum să abordeze normalizarea poate citi despre asta în o descriere a documentării normalizării. Ambele fac parte din același lanț, dar întrebările pe care le generează sunt diferite: agregarea generează întrebări despre exhaustivitate, normalizarea despre consistență.
Situația se schimbă și atunci când sursa în sine nu este un sistem, ci un spreadsheet. Atunci nu există export automat, nu există jurnal de sistem, nu există o structură fixă, iar documentarea trebuie construită altfel. Cine se confruntă cu această situație găsește repere în o explicație despre maparea de la sursă la raport când sursa este un spreadsheet și în o prezentare a prelucrărilor dintre sursă și raport specifice surselor de tip spreadsheet. Pentru cei care nu au buget pentru un instrument și trebuie să construiască lineage-ul cu resursele deja existente, există o metodă de a construi lineage fără software specializat.
Documentarea prelucrărilor este adesea confundată cu un jurnal: o listă cu cine a modificat ce și când. Aceasta este o parte a poveștii, dar nu întregul tablou. Un audit trail care înregistrează doar modificările nu spune de ce a fost făcută o decizie sau ce regulă a fost aplicată. Diferența dintre un jurnal și o structură reală de justificare este dezvoltată în o expunere despre motivul pentru care un audit trail trebuie să fie mai mult decât un jurnal.
Data Readiness Scan cartografiază acest traseu: ce sursă alimentează ce punct de date, ce prelucrări se află între ele, cine este proprietarul fiecărui pas și ce regulă de calitate îi corespunde. Acesta nu este un raport și nici un chestionar, ci structura de bază care face ca ambele să devină în cele din urmă credibile.
De îndată ce prelucrările dintre sursă și raport sunt descrise, devine vizibil care pași reprezintă muncă manuală fixă: transcrierea unei facturi, aplicarea unui factor de conversie fix, reunirea cifrelor lunare conform unei reguli fixe. Acesta este exact tipul de muncă pentru care se poate calcula ce parte poate fi transferată către AI, fără ca documentarea de la sursă la raport să își piardă funcția. FTE TO AI calculează pentru fiecare sarcină ce parte din aceasta poate fi transferată, pe baza scanării muncii care face vizibilă această diferență, sarcină cu sarcină.
Data Readiness Scan este în curs de dezvoltare. Cine dorește ca prelucrările dintre sursă și raport să fie documentate imediat ce scanarea devine disponibilă se poate înscrie pe lista de așteptare.
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.