Kennisbank

Mitä on source-to-report mapping

Kestävyysraportin luku on melkein koskaan sama luku kuin lähdejärjestelmässä oleva luku. Sen hetken välillä, jolloin työntekijä syöttää energialaskun tai sensori rekisteröi mittarilukeman, ja sen hetken välillä, jolloin luku ilmestyy raporttitaulukkoon, tapahtuu jotain. Sitä muunnetaan, lasketaan yhteen, korjataan, yhdistetään muihin lähteisiin. Source-to-report mapping tarkoittaa tämän polun tallentamista: jokainen vaihe, jonka data käy läpi lähteen ja raportin välillä, siinä järjestyksessä kuin se tapahtuu.

Miksi polku itsessään on informaatiota

Laskennan tulos ei kerro mitään sen luotettavuudesta, jos kukaan ei pysty jäljittämään, miten tulos syntyi. Päästöluku voi olla oikea, koska sen taustalla olevat vaiheet olivat oikein, tai se voi vaikuttaa oikealta, koska yhden vaiheen virhe sattui kompensoimaan toisen vaiheen virhettä. Ilman mappausta tätä eroa ei näe. Mappauksen kanssa näkee: jokainen vaihe on erillinen kokonaisuus, omalla lähteellään, omalla käsittelyllään ja omalla tuloksellaan, joka on tarkistettavissa.

Tämä polku koostuu useimmiten enemmästä vaiheista kuin ihmiset odottavat. Raakadatan ja raporttiluvun välillä on usein useita peräkkäisiä käsittelyvaiheita: yksiköitä muunnetaan, arvoja yhdistetään, poikkeuksia korjataan käsin. Mitkä käsittelyvaiheet ovat lähteen ja raportin välillä vaihtelee datapisteittäin, mutta rakenne on aina samanlainen: sarja vaiheita, joista jokainen lisää tai muuttaa jotain datassa, ja jotka on kirjattava erikseen, jotta kokonaisuutta voi seurata.

Kaksi käsittelyä, joissa virheitä syntyy useimmin

Kahdenlaiset käsittelyt ansaitsevat erityistä huomiota, koska ne ovat yleisimpiä ja niissä syntyy virheitä huomaamattomimmin.

Ensimmäinen on aggregointi: usean lähteen tai usean ajanjakson lukujen yhdistäminen yhdeksi luvuksi. Se, kuka kirjaa, miten tämä yhteenlasku tarkalleen etenee, mitkä erät sisältyvät mukaan ja mitkä eivät, estää raporttiluvun muuttumisen mustaksi laatikoksi. Se, miten aggregointi kirjataan, ratkaisee, pystyykö joku jälkikäteen jäljittämään miten aggregointi kirjataan tavalla, joka pysyy jäljitettävissä taustalla olevien erien tasolle.

Toinen on normalisointi: erilaisten lähdedatan muuntaminen yhteiseen yksikköön tai määritelmään, jotta eri järjestelmien luvut tulevat vertailukelpoisiksi. Litra dieseliä ja kilowattitunti sähköä tulevat vertailukelpoisiksi vasta muunnoksen jälkeen, ja tämä muunnos sisältää oletuksia. Sen kirjaaminen, miten normalisointi kirjataan, tarkoittaa näiden oletusten kirjaamista, jotta toinen osapuoli voi seurata samaa oletusta tai kyseenalaistaa sen.

Enemmän kuin lokikirja

On houkuttelevaa sekoittaa mappaus toimintalokiin: luetteloon siitä, kuka on muuttanut mitä ja milloin. Se on osa kokonaisuutta, mutta ei koko kokonaisuus. Auditointijälki, joka rekisteröi vain muutokset, ei kerro, miksi käsittely on tehty tai mikä sääntö sen takana oli. Se, miksi auditointijälki on enemmän kuin lokikirja, liittyy kysymykseen, jonka jokainen tarkastaja lopulta esittää: ei vain mitä on muutettu, vaan millä logiikalla ja mistä lähteestä.

Ilman työkalua, samalla kurinalaisuudella

Source-to-report mapping sekoitetaan usein ohjelmistoon. On olemassa työkaluja, jotka näyttävät lineage-tiedot automaattisesti, mutta ne työkalut rekisteröivät vain sen, mikä on jo toimitettu jäsennellyssä muodossa. Organisaatio, joka työskentelee vielä taulukkolaskentaohjelmilla ja manuaalisilla siirroilla, voi tallentaa polun yhtä hyvin, vain eri keinoin: kiinteä dokumentointimuoto per vaihe, kiinteä paikka, jossa lähdetiedostot säilytetään, kiinteä tapa kirjata muutoksia. Se, miten tämä organisoidaan ilman työkalua, on kuvattu kohdassa miten lineage tehdään ilman työkalua. Kurinalaisuus ei ole ohjelmistossa, vaan kirjaamisen toistettavuudessa.

Tämä kurinalaisuus on erityisen tärkeää, kun lähde itse on jo taulukkolaskentatiedosto. Työkirjan solulla ei ole sisäänrakennettua alkuperää: kukaan ei automaattisesti näe, kuka on syöttänyt arvon tai millä asiakirjalla se perustuu. Se, mitä source-to-report mapping tarkoittaa kun lähde on taulukkolaskentatiedosto, on, että tämä alkuperä on järjestettävä käsin mukaan, samalla tarkkuudella kuin automatisoidussa järjestelmässä.

Mitä tämä kirjaaminen käytännössä tarkoittaa

Käytännössä mappaus tiivistyy kysymykseen, joka toistetaan jokaisen datapisteen kohdalla: mistä tämä arvo tulee, mitä sille on tehty ennen kuin se päätyi raporttiin, ja kuka tämän vaiheen suoritti tai hyväksyi. Tämän kysymyksen esittäminen sadoille datapisteille on työvoimavaltaista, ja juuri se tekee siitä houkuttelevaa ohittaa. Mutta raportti, joka perustuu jäljittämättömään pohjaan, pysyy alttiina kysymyksille, joihin kukaan ei osaa vastata sillä hetkellä, kun ne esitetään.

Näiden vaiheiden kartoittaminen, datapisteittäin ja usean lähteen yli, on toistuvaa työtä, jolla on kiinteä rakenne: lähteen tunnistaminen, käsittelyn kuvaaminen, omistajan määrittäminen, toistaminen seuraavalle datapisteelle. Työ, jolla on kiinteä rakenne, on juuri sellaista työtä, josta osan voi siirtää tekoälyn tehtäväksi. FTE TO AI:n työscan laskee tehtäväkohtaisesti, mikä osa tästä työstä soveltuu siihen, jotta selviää, missä ihmisiä tarvitaan edelleen arviointiin ja missä toistoa voidaan automatisoida.