Suuri osa kestävyysdatasta ei tule järjestelmästä, jossa on kiinteät kentät ja kiinteät yksiköt, vaan laskentataulukosta, jonka työntekijä on koostanut. Energiankulutus kWh:ssa rinnakkain polttoainelitrojen kanssa, jätemäärät toimipaikoittain eri yksiköissä, työntekijämäärät, jotka on laskettu eri seurantapäivinä. Ennen kuin tällainen luku sopii raporttiin, se on normalisoitu: muunnettu yhteiseen yksikköön, korjattu jakson mukaan, yhdistetty organisaatiotasolle. Tämä normalisointi tapahtuu usein samassa laskentataulukossa, kaavalla, jota kukaan laatijan ulkopuolella ei tunne.
Ongelma ei ole se, että normalisoidaan. Ongelma on se, että vaihe on näkymätön. Solussa oleva kaava näyttää tuloksen, ei sen takana olevaa olettamusta. Kun joku muu avaa tiedoston, hän näkee luvun, ei päättelyä.
Raakalaskentataulukon ja julkaistun luvun välissä on tavallisesti useita vaiheita: yksiköiden muuntaminen, puuttuvien arvojen arvioiminen tai ohittaminen, useiden toimipaikkojen lukujen yhteenlaskeminen, korjauskertoimen soveltaminen tunnettuun poikkeamaan. Jokainen vaihe muuttaa lukua, ja jokainen vaihe on valinta. Mitä muuntokerrointa on käytetty, miltä jaksolta on laskettu yhteen, miksi poikkeama on otettu mukaan tai jätetty pois. Ellei näitä dokumentoida, valinnat ovat olemassa vain laskentataulukon tekijän päässä. Katsaus mitä toimenpiteitä lähteen ja raportin välillä on osoittaa, että normalisointi on harvoin yksittäinen vaihe, vaan ketju, jonka jokainen lenkki on tarkistettava erikseen.
Normalisoinnin dokumentointi ei ole samaa kuin selityksen kirjoittaminen sen jälkeen, kun raportti on valmis. Kyse on hetkestä, jolloin toimenpide tapahtuu: mikä kaava, millä parametreilla, mihin raakadataan sovellettuna. Se on ero seurantalokin ja auditointiketjun välillä. Loki tallentaa, että jotain on tapahtunut; auditointiketju selventää, mitä on tapahtunut ja miksi tämä toimenpide oli sillä hetkellä oikea. Tämä erottelu käsitellään tarkemmin kohdassa miksi auditointiketju on enemmän kuin loki, kun lähde on laskentataulukko. Se, joka dokumentoi normalisoinnin vasta jälkikäteen, ottaa riskin, että alkuperäistä valintaa ei voida enää rekonstruoida, varsinkin jos laskentataulukon laatija on sillä välin siirtynyt toiseen tehtävään tai lähtenyt organisaatiosta.
Yleinen olettamus on, että lineage — luvun jäljittäminen lähteestä raporttiin — vaatii järjestelmän, joka pitää siitä automaattisesti kirjaa. Se ei ole välttämätöntä. Myös laskentataulukoiden ollessa lähteenä on mahdollista dokumentoida per datapiste, mitä lähdearvoa on käytetty, mitä toimenpidettä siihen on sovellettu ja kuka on hyväksynyt tämän toimenpiteen. Se vaatii kuria enemmän kuin ohjelmistoa. Se, miltä tämä käytännössä näyttää, on kuvattu kohdassa miten teet lineagen ilman työkalua, kun lähde on laskentataulukko. Ytimessä on kiinteä rakenne: per datapiste lähdetaulukko, sovellettu kaava ja viittaus siihen, kuka on vahvistanut tämän kaavan. Se on enemmän formaatti kuin järjestelmä, ja sitä voidaan soveltaa ennen kuin työkalusta on edes puhetta.
Normalisointisääntö — esimerkiksi polttoainetyypin muuntokerroin CO2-ekvivalentiksi — on itsessään datapiste, joka tarvitsee omistajan. Ei loppuluvun omistajaa, vaan säännön omistajaa: kuka päättää, että tämä kerroin on oikea, ja kuka päivittää sen, kun standardi muuttuu. Ilman tätä nimeämistä vastuu siirtyy implisiittisesti sille, joka sattui rakentamaan laskentataulukon. Kysymys kuka omistaa datapisteen määritelmän käsittelee juuri tätä: määritelmä ja laskentasääntö tarvitsevat omistajan, joka on erillinen datan syöttäjästä. Tämä on yksi osa source-to-report-kartoitusta, joka on selitetty kohdassa mitä on source-to-report-kartoitus: ei vain se, mistä luku on peräisin, vaan myös se, kuka on vastuussa kustakin välivaiheesta.
On olemassa työkaluja, jotka automatisoivat normalisoinnin ja näyttävät lineagen. Ne työkalut eivät ratkaise mitään, jos niiden alla oleva prosessi ei ole kunnossa: jos kukaan ei ole dokumentoinut, mikä sääntö pätee mihin datapisteeseen, työkalu vain näyttää nopeammin luvun, jonka alkuperä on edelleen epäselvä. Ensin prosessi, sitten työkalu. Kuka päättää tästä järjestämisestä, on kysymys, joka ulottuu normalisointia laajemmalle; sitä käsitellään kohdassa kuka omistaa sen alla olevan prosessin.
Kun on selvää, mitä normalisointivaiheita on, kuka ne suorittaa ja millä säännön perusteella, syntyy toinen kysymys: mikä osa tästä laskentataulukon manuaalisesta työstä voidaan siirtää AI:lle. FTE TO AI:n työscan laskee tehtäväkohtaisesti, mikä osa työstä on siirrettävissä, ja se on käyttökelpoinen sitten, kun normalisointivaiheet on kuvattu erillisinä, tunnistettavina tehtävinä sen sijaan, että ne olisivat piilossa kaavan sisällä.
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.