Kestävyysraportin luvulla on lähes aina takanaan matka. Se alkaa rivinä energialaskussa, laskurina tuotantojärjestelmässä, syöttökenttänä HR-työkalussa. Siihen mennessä, kun luku päätyy raporttiin, se on laskettu, muunnettu, yhdistetty ja joskus korjattu. Näitä välivaiheita näkee lopputuloksesta harvoin. Se, joka katsoo vain raporttia, näkee luvun. Se, joka katsoo välissä olevaa reittiä, näkee sarjan valintoja.
Lähteen ja raportin välissä on yleensä vakiintunut järjestys käsittelyvaiheita, vaikka kukaan ei olisi sitä koskaan kirjannut ylös.
Ensin data kerätään: viedään järjestelmästä, kirjoitetaan laskusta, kopioidaan laskentataulukosta. Sen jälkeen se normalisoidaan: litrat muuttuvat kuutioiksi, kilowattitunti gigajouleksi, paikallinen valuutta kiinteäksi laskentayksiköksi. Seuraavaksi se osoitetaan kategoriaan tai scopeen, mikä on valinta ja ei automaatio. Sitten seuraa aggregointi: toimipisteiden, kuukausien tai osastojen luvut yhdistetään vuositotaaliksi. Matkan varrella tehdään korjauksia, kaksinkertaisen laskennan varalta, puuttuvien kuukausien varalta, virheellisen yksikön varalta, jonka joku on huomannut vuosi sitten ja korjannut käsin.
Joka vaihe on paikka, jossa tehdään oletus. Päästökerroin valitaan. Arvio korvaa puuttuvan mittauksen. Pyöristys sovelletaan. Sinänsä mikään näistä ei ole ongelma. Ongelma syntyy, kun kukaan ei enää tiedä, mikä oletus on tehty, kenen tekemänä ja miksi.
Raporttiluku, jota ei voi jäljittää lähteeseensä, on väitetty luku. Kun controller, tilintarkastaja tai valvova viranomainen kysyy, miten luku on muodostettu, vastauksen on oltava enemmän kuin "se on järjestelmässä". Vastauksen on pystyttävä näyttämään reitti: tämä lähde, tämä muunnos, tämä aggregointi, tämä korjaus.
Reitin dokumentoinnilla on kolme suoraa seurausta. Ensiksi virheiden jäljittäminen muuttuu minuuttien työstä päivien työn sijaan, koska on selvää, missä muunnos on sovellettu ja missä ei. Toiseksi tulee mahdolliseksi tiedon siirto: kun laskentataulukon hoitaja lähtee, tieto käsittelyvaiheista ei lähde hänen mukanaan. Kolmanneksi syntyy perusta tarkastukselle, koska ulkopuolinen taho voi seurata vaiheita joutumatta ensin rekonstruoimaan niitä.
Saman dokumentaation puuttuessa joka raportointikierros on toistoa etsintätyötä. Joku soittaa edelliselle vastuuhenkilölle, etsii vanhoista sähköposteista, arvailee pyöristyksen taustalla olevaa syytä. Tämä työ on näkymätöntä itse raportissa, mutta se määrittää sen, kuinka paljon luottamusta raportti ansaitsee.
Joka käsittelyvaihe ei vaadi samaa lähestymistapaa. Aggregointi, jossa useiden lähteiden luvut yhdistetään yhdeksi kokonaisluvuksi, vaatii erilaista dokumentaatiota kuin normalisointi, jossa yksiköt ja määritelmät yhtenäistetään. Se, joka haluaa tietää, miten aggregointi dokumentoidaan tarkalleen, löytää tämän selityksestä aggregointivaiheiden dokumentoinnista, ja se, joka pohtii, miten normalisoinnin kanssa toimitaan, löytää sen kuvauksesta normalisoinnin dokumentoinnista. Molemmat ovat osa samaa ketjua, mutta kysymykset, joita ne herättävät, ovat erilaisia: aggregointi herättää kysymyksiä täydellisyydestä, normalisointi yhtenäisyydestä.
Tilanne muuttuu myös, kun lähde itsessään ei ole järjestelmä vaan laskentataulukko. Tällöin ei ole automaattista vientiä, järjestelmälokia eikä kiinteää rakennetta, ja dokumentaatio on rakennettava eri tavalla. Se, joka kohtaa tämän tilanteen, löytää lähtökohtia selvityksestä source-to-report-kartoituksesta, kun lähde on laskentataulukko ja yleiskatsauksesta lähteen ja raportin väliin sijoittuvista käsittelyvaiheista erityisesti laskentataulukkolähteiden osalta. Sille, jolla ei ole budjettia työkalulle ja jonka on rakennettava lineage olemassa olevilla resursseilla, on olemassa työtapa lineagen tekemiseen ilman erikoistunutta ohjelmistoa.
Käsittelyvaiheiden dokumentointi sekoitetaan usein lokikirjaan: listaan siitä, kuka on muuttanut mitä ja milloin. Se on osa tarinaa, mutta ei koko tarina. Audit trail, joka rekisteröi vain muutokset, ei kerro, miksi valinta on tehty tai mitä sääntöä on sovellettu. Ero lokikirjan ja todellisen vastuurakenteen välillä käsitellään selvityksessä siitä, miksi audit trailin on oltava enemmän kuin lokikirja.
Data Readiness Scan kartoittaa tämän reitin: mikä lähde ruokkii mitä datapistettä, mitä käsittelyvaiheita niiden välissä on, kuka omistaa jokaisen vaiheen ja mikä laatusääntö siihen kuuluu. Se ei ole raportti eikä kyselylomake, vaan taustalla oleva rakenne, joka tekee molemmista luotettavia.
Kun lähteen ja raportin väliset käsittelyvaiheet on kuvattu, tulee näkyväksi, mitkä vaiheet ovat kiinteästi käsityötä: laskun kirjoittaminen, kiinteän muuntokertoimen soveltaminen, kuukausilukujen yhdistäminen kiinteän säännön mukaan. Juuri tällaisesta työstä voi laskea, mikä osa siitä on siirrettävissä AI:lle, menettämättä lähteestä raporttiin ulottuvan dokumentaation toimivuutta. FTE TO AI laskee tehtäväkohtaisesti, mikä osa siitä on siirrettävissä, työskentelyskannauksen perusteella, joka tekee tämän eron näkyväksi tehtäväkohtaisesti.
Data Readiness Scan on kehitteillä. Se, joka haluaa dokumentoida lähteen ja raportin väliset käsittelyvaiheet heti, kun skannaus on saatavilla, voi ilmoittautua odotuslistalle.
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.