Suur osa jätkusuutlikkuse andmetest ei tule süsteemist, kus on kindlaksmääratud väljad ja ühikud, vaid tabelarvutusest, mille on kokku pannud töötaja. Energiakulu kWh-des kütuseliitrite kõrval, jäätmearvud eri üksustes erinevates ühikutes, töötajate arvud, mis on loetud erinevatel seisuandmetel. Enne kui selline arv aruandesse sobib, on see normaliseeritud: teisendatud ühisesse ühikusse, korrigeeritud perioodi järgi, koondatud organisatsiooni tasandile. See normaliseerimine toimub sageli samas tabelarvutuses, valemiga, mida ei tea keegi väljaspool selle koostajat.
Probleem ei ole selles, et normaliseeritakse. Probleem on selles, et see etapp on nähtamatu. Lahtris olev valem näitab tulemust, mitte selle taga olevat eeldust. Kui keegi teine faili avab, näeb ta arvu, mitte põhjendust.
Toore tabelarvutuse ja avaldatud arvu vahel on tavaliselt mitu etappi: ühikute teisendamine, puuduvate väärtuste hindamine või vahele jätmine, mitme üksuse arvude kokku liitmine, korrigeerimisteguri rakendamine teadaoleva erinevuse jaoks. Iga etapp muudab arvu ja iga etapp on valik. Millist teisendustegurit on kasutatud, millise perioodi kohta on liidetud, kas kõrvalekalle on kaasa arvatud või mitte ja miks. Ilma dokumenteerimiseta eksisteerivad need valikud ainult tabelarvutuse koostaja peas. Ülevaade millised toimingud jäävad allika ja aruande vahele näitab, et normaliseerimine on harva üksainus etapp, vaid ahel, mille igat lüli peab saama eraldi kontrollida.
Normaliseerimise dokumenteerimine ei ole samaväärne selgituse kirjutamisega pärast aruande valmimist. Küsimus on hetkes, mil toiming toimub: milline valem, milliste parameetritega, millisele toorväärtusele rakendatuna. See on erinevus auditi jälje ja logi vahel. Logi registreerib, et midagi juhtus; auditi jälg selgitab, mis juhtus ja miks oli see toiming sel hetkel õige. Seda vahet käsitletakse lähemalt artiklis miks on auditi jälg rohkem kui logi, kui allikas on tabelarvutus. Kes normaliseerimist dokumenteerib alles tagantjärele, riskib sellega, et algset valikut ei saa enam taastada, eriti kui tabelarvutuse koostaja on vahepeal teisele ametikohale liikunud või organisatsioonist lahkunud.
Sage eeldus on, et päritoluahel — arvu jälgimine allikast aruandeni — eeldab süsteemi, mis seda automaatselt jälgib. See ei ole tingimata vajalik. Ka tabelarvutuste puhul allikana on võimalik dokumenteerida iga andmepunkti kohta, mis lähteväärtust on kasutatud, mis toimingut sellele rakendati ja kes selle toimingu heaks kiitis. See eeldab distsipliini, mitte tarkvara. Kuidas see praktikas välja näeb, on kirjeldatud artiklis kuidas luua päritoluahel tööriista abita, kui allikas on tabelarvutus. Tuum on kindel struktuur: iga andmepunkti kohta lähtetabel, rakendatud valem ja viide, kes selle valemi kinnitas. See on rohkem vorming kui süsteem ja see on rakendatav enne, kui tööriistale üldse mõeldakse.
Normaliseerimisreegel — näiteks kütuseliigi teisendustegur CO2-ekvivalendiks — on iseenesest andmepunkt, mis vajab omanikku. Mitte lõpparvu omanikku, vaid reegli omanikku: kes otsustab, et see tegur on õige, ja kes seda kohandab, kui norm muutub. Ilma selle määramiseta libiseb vastutus kaudselt selle peale, kes juhtumisi tabelarvutuse koostas. Küsimus kellele kuulub andmepunkti definitsioon käsitleb just seda: definitsioonil ja arvutusreeglil peab olema omanik, kes on eraldiseisev sellest, kes andmeid sisestab. See on üks osa allikast aruandeni kaardistamisest, mida on selgitatud artiklis mis on allikast aruandeni kaardistamine: mitte ainult see, kust arv pärineb, vaid ka kes vastutab igas vahepealses etapis.
On olemas tööriistad, mis automatiseerivad normaliseerimist ja näitavad päritoluahelat. Need tööriistad ei lahenda midagi, kui protsess nende taga ei ole korraldatud: kui keegi ei ole dokumenteerinud, milline reegel kehtib millise andmepunkti kohta, näitab tööriist ainult kiiremini arvu, mille päritolu on ikka ebaselge. Esmalt protsess, siis tööriist. Kes selle korralduse üle otsustab, on küsimus, mis ulatub kaugemale kui ainult normaliseerimine; sellega tegeletakse artiklis kellele kuulub selle taga olev protsess.
Kui on selge, milliseid normaliseerimissamme on, kes need läbi viib ja millise reegli alusel, tekib teine küsimus: milline osa sellest käsitsi tehtud tabelarvutuse töö osast on võimalik üle anda AI-le. FTE TO AI töövoo skaneering arvutab ülesande kaupa välja, milline osa töö on võimalik üle võtta, ja on kasutatav niipea, kui normaliseerimissammud on kirjeldatud eraldiseisvate, äratuntavate ülesannetena, mitte peidetud valemi sisse.
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.