Number jätkusuutlikkuse aruandes on peaaegu alati läbinud teekonna. See algab reana energiaarves, loendurina tootmissüsteemis, sisestusväljana personalitöö tarkvaras. Selleks ajaks, kui number jõuab aruandesse, on see loetud, teisendatud, koondatud ja mõnikord parandatud. Need vahesammud on lõpptulemuses harva nähtavad. Kes vaatab ainult aruannet, näeb arvu. Kes vaatab vahepealset teed, näeb hulka valikuid.
Allika ja aruande vahel on tavaliselt kindel järjekord töötlusi, isegi kui keegi ei ole seda kunagi kirja panud.
Esmalt kogutakse andmed: eksporditakse süsteemist, sisestatakse käsitsi arvelt, kopeeritakse tabelist. Seejärel normaliseeritakse need: liitrid muutuvad kuupmeetriteks, kilovatt-tunnid gigadžaulideks, kohalik valuuta fikseeritud arvestusühikuks. Järgmisena määratakse andmed kategooriale või scope'ile, mis on valik, mitte automaatika. Sellele järgneb agregeerimine: filiaalide, kuude või osakondade arvud koondatakse aastasummaks. Vahepeal tehakse parandusi topeltarvestuste, puuduvate kuude ja aasta tagasi märgatud ning käsitsi korrigeeritud vale ühiku pärast.
Iga samm on koht, kus tehakse eeldus. Valitakse emissioonitegur. Puuduva mõõtmise asendab hinnang. Rakendatakse ümardamist. Iseenesest ei ole neist midagi probleem. Probleem tekib siis, kui keegi ei mäleta enam, milline eeldus tehti, kelle poolt ja miks.
Aruande number, mida ei saa jälgida tagasi tema allikani, on väidetud number. Kohe kui kontroller, audiitor või järelevalveasutus küsib, kuidas number on koostatud, peab vastus olema rohkem kui "see on süsteemis". Vastus peab suutma näidata marsruudi: see allikas, see teisendus, see agregeerimine, see parandus.
Selle marsruudi dokumenteerimisel on kolm otsest tagajärge. Esiteks muutub vigade tuvastamine minutite, mitte päevade tööks, sest on selge, kus teisendust rakendati ja kus mitte. Teiseks muutub üleandmine võimalikuks: kui tabelit haldav isik lahkub, ei lahku töötluste teadmine koos temaga. Kolmandaks tekib alus kontrollimiseks, sest väline osapool saab samme jälgida ilma neid enne rekonstrueerima.
Ilma selle dokumenteerimiseta on iga aruandlustsükkel kordav otsingutöö. Keegi helistab eelmisele haldajale, otsib vanadest e-kirjadest, arvab ümardamise põhjust. See töö on aruandes endas nähtamatu, kuid see määrab, kui palju usaldust see aruanne väärib.
Mitte igal töötlusel ei ole vaja sama lähenemist. Agregeerimine, mille käigus koondatakse mitme allika arvud üheks summaks, vajab erinevat dokumenteerimist kui normaliseerimine, mille käigus ühtlustatakse ühikuid ja definitsioone. Kes soovib teada, kuidas agregeerimist täpselt dokumenteerida, leiab selle selgituses agregeerimissammude dokumenteerimise kohta, ja kes mõtleb, kuidas käituda normaliseerimisega, saab sellest lugeda normaliseerimise dokumenteerimise kirjelduses. Mõlemad on osa samast ahelast, kuid küsimused, mida need tekitavad, on erinevad: agregeerimine tõstatab küsimusi täielikkuse kohta, normaliseerimine järjepidevuse kohta.
Olukord muutub ka siis, kui allikas ei ole süsteem, vaid tabel. Sellisel juhul puudub automaatne eksport, süsteemilogi, kindel struktuur, ja dokumenteerimine tuleb üles ehitada teisiti. Kes seisab silmitsi selle olukorraga, leiab lähtepunkte selgitusest source-to-report mapping'u kohta, kui allikas on tabel ja ülevaates allika ja aruande vahelistest töötlustest spetsiaalselt tabeliallikate puhul. Kellel puudub tarkvara jaoks eelarve ja kes peab lineage'i üles ehitama olemasolevate vahenditega, on olemas tööviis lineage'i loomiseks spetsiaalse tarkvarata.
Töötluste dokumenteerimist aetakse sageli segamini logiraamatuga: nimekirjaga sellest, kes mida millal muutis. See on osa loost, kuid mitte kogu lugu. Auditijälg, mis registreerib ainult muudatusi, ei ütle, miks valik tehti või millist reeglit rakendati. Erinevust logiraamatu ja tõelise vastutusstruktuuri vahel käsitletakse käsitluses sellest, miks auditijälg peab olema rohkem kui logiraamat.
Data Readiness Scan kaardistab selle marsruudi: milline allikas toidab millist andmepunkti, millised töötlused on nende vahel, kes on iga sammu omanik ja milline kvaliteedireegel sellega kaasneb. See ei ole aruanne ega küsimustik, vaid aluseks olev struktuur, mis muudab mõlemad usaldusväärseks.
Kui allika ja aruande vahelised töötlused on kirjeldatud, muutub nähtavaks, millised sammud on kindel käsitsitöö: arve käsitsi sisestamine, fikseeritud teisendusteguri rakendamine, kuuandmete koondamine kindla reegli järgi. Just sellise töö puhul on võimalik arvutada, kui suure osa saab üle võtta AI, ilma et allikast aruandeni ulatuv dokumenteerimine kaotaks oma funktsiooni. FTE TO AI arvutab ülesande kaupa, kui suur osa sellest on üleantav, tuginedes töö skaneerimisele, mis muudab selle erinevuse ülesande kaupa läbipaistvaks.
Data Readiness Scan on väljatöötamisel. Kes soovib, et allika ja aruande vahelised töötlused dokumenteeritaks kohe, kui skaneerimine on saadaval, saab liituda ootenimekirjaga.
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.