Kestävyysraportin luku on harvoin suoraan lähteestä peräisin oleva luku. Se on useimmiten tulos yhteenlaskusta, keskiarvoistamisesta, painottamisesta tai uudelleenjaosta toimipaikkojen, ajanjaksojen tai yksiköiden välillä. Tätä vaihetta kutsutaan aggregoinniksi, ja kaikista lähteen ja raportin välisistä toimenpiteistä tämä on usein näkymättömin. Laskentataulukon kaava laskee kaksitoista kuukausilukua yhteen vuosiluvuksi, tai laskentapohja keskiarvoistaa päästökertoimet useiden toimittajien kesken. Kukaan ei tällöin kirjaa ylös, mikä oletus siihen sisältyy.
Raakamittauksen ja julkaistun luvun välillä on useita vaiheita. Ensin data kerätään järjestelmistä tai laskentataulukoista, sitten se muunnetaan yhteiseen yksikköön, ja lopuksi se kootaan yhteen tasolle, joka sopii raporttiin — liiketoimintayksikkö, maa, tai kokonaismäärä. Jokainen vaihe voi sisältää valinnan, joka muuttaa lopullista lukua: lasketteko fuusion mukaan hankintapäivästä alkaen vai koko vuodelta, painotatteko keskiarvoa liikevaihdon vai henkilöstömäärän mukaan, pyöristätteko luvut lähteessä vai vasta kokonaismäärässä. Mitä toimenpiteitä lähteen ja raportin välillä tarkalleen on, riippuu indikaattorista ja organisaation rakenteesta, ja kohdassa mitkä toimenpiteet sijoittuvat lähteen ja raportin väliin, kun lähteellä on useita lähteitä, tästä listasta tulee pidempi kuin useimmat organisaatiot odottavat.
Aggregointi on valinta, ja valinnat, joita ei ole dokumentoitu, tehdään uudelleen seuraavalla raportointikierroksella — usein eri henkilön tekemänä, eri oletuksella. Seurauksena on, että viime vuoden lukua ei voida enää jäljittää samaan logiikkaan, ja controller tai tilintarkastaja ei voi todeta, onko luvun muutos todellinen muutos vai muutos laskentamenetelmässä. Dokumentointi ei tässä tarkoita: prosessin kuvaamista yleisin termein. Se tarkoittaa: kunkin raportointipisteen kohdalla kirjataan, mitkä lähteet on otettu mukaan, millä painotuksella, miltä ajanjaksolta, ja kuka teki tämän valinnan.
Aggregointi sekoitetaan usein normalisointiin, mutta ne ovat kaksi erillistä vaihetta. Normalisointi tekee datasta vertailukelpoisen — esimerkiksi muuntamalla eri energiayksiköt yhdeksi standardiksi. Aggregointi kokoaa sen jälkeen tämän vertailukelpoisen datan yhteen korkeammalle tasolle. Normalisointivirhe vaikuttaa läpi kaikkiin sitä seuraaviin aggregointeihin, mikä tarkoittaa, että näitä kahta vaihetta on tarkastettava erikseen. Miten tämä tehdään, löytyy kohdasta miten normalisointi dokumentoidaan.
Useimmilla organisaatioilla ei ole lähdetietoja, jotka tulevat siististi yhdestä järjestelmästä. Osa kestävyysdatasta on laskuissa, osa laskentataulukossa, jonka energiantoimittaja on lähettänyt sähköpostitse, osa ERP-järjestelmästä tehdyssä viennissä. Aggregointi näiden lähteiden yli tarkoittaa, että teidän täytyy manuaalisesti selvittää, mikä rivi kuuluu mihin ajanjaksoon ja mikä rivi on laskettu kahteen kertaan. Kohdassa mitä on source-to-report-kartoitus, kun lähde on laskentataulukko kerrotaan, miten kartoitatte tämän yhteyden raakalähteen ja raportointipisteen välillä, ja kohdassa miten aggregointi dokumentoidaan, kun lähde on laskentataulukko kerrotaan erityisesti, miten dokumentoitte tämän laskentataulukkovaiheen, jotta itse aggregointi tulee toistettavaksi, myös silloin kun kaavan alun perin rakentanut henkilö ei ole enää käytettävissä.
Aggregoinnin dokumentointi ei vaadi ohjelmistoa. Se vaatii kurinalaisuutta: kunkin laskentavaiheen kohdalla merkitään, mitä siihen syötettiin, mitä sääntöä sovellettiin, ja mitä siitä tuli ulos. Tämä voidaan tehdä rekisterissä olemassa olevien laskentataulukkojen rinnalla, ennen kuin järjestelmää koskaan hankitaan. Miltä tämä näyttää ilman työkalua, löytyy kohdasta miten lineage tehdään ilman työkalua. Se, joka ohittaa tämän vaiheen ja hankkii suoraan ohjelmistopaketin raportointia varten, laittaa siistimmän kerroksen samaan epäselvään aggregointiin — raportti näyttää paremmalta, mutta kysymys siitä, on luku oikein, jää vastaamatta.
Aggregointisääntö, jota ei ole dokumentoitu, on myös puuttuva tarkastuspiste. Ulkoisessa tarkastuksessa tai sisäisessä tarkistuksessa jonkun täytyy pystyä osoittamaan, miksi luku on koottu sellaiseksi kuin se on koottu, ei vain, että luku täsmää laskimen kanssa. Tämä ero — luvun, joka täsmää, ja luvun, joka on selitettävissä, välillä — on juuri se, mitä varten audit trail on tarkoitettu, ja miksi se sisältää enemmän kuin yksinkertaisen muutoslokin, kuten selitetään kohdassa miksi audit trail on enemmän kuin loki.
Kun aggregointisäännöt on kerran dokumentoitu — mitkä lähteet, mikä painotus, mikä ajanjakso, kuka teki valinnan — syntyy perusta sen määrittämiseksi, mikä osa tästä työstä on toistettavaa ja siten sopiva siirrettäväksi järjestelmälle. Tämä on eri kysymys kuin se, ovatko säännöt oikein; kysymys on siitä, kuinka paljon näiden sääntöjen soveltamisesta täytyy edelleen pysyä ihmistyönä. FTE TO AI:n työscan laskee tehtäväkohtaisesti, kuinka suuri osa työstä voidaan siirtää tekoälylle, ja aggregointi — kiinteine yhteenlasku-, painotus- ja yhdistämisvaiheineen — on juuri se tehtävätyyppi, jossa tämä tulos on usein yllättävä.
csrdready.net-sivuston Data Readiness Scan on kehitteillä. Ken haluaa jo nyt tuoda järjestystä datapisterekisteriin ja siihen liittyviin aggregointisääntöihin, voi ilmoittautua jonotuslistalle ja saa tiedon, kun scan on saatavilla.
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.