Jossain prosessissa on luku, jota kukaan ei enää osaa selittää. Toimipisteen scope 2 -kulutus, tyttäryhtiön fte-määrä, tuotantolinjan jätemäärä. Luku on viime vuoden raportissa, mutta kukaan ei enää tiedä, mistä järjestelmästä se tuli, kuka sen syötti, oliko se laskettu yhteen tai arvioitu. Tämä ei ole poikkeus. Se on yksi yleisimmistä havainnoista siinä vaiheessa, kun organisaatio tarkastelee kestävyysdataansa ensimmäistä kertaa järjestelmällisesti.
Kysymys ei ole retorinen. Datapiste, jolla ei ole lähdettä, ei ole määritelmällisesti virheellinen, mutta se on todistamaton. Ja todistamaton data, joka päätyy raporttiin, on riski, joka paljastuu vasta siinä vaiheessa, kun joku — varmennuspalvelun tarjoaja, valvova viranomainen, asiakas, jolla on omat ketjuvelvoitteensa — kysyy tarkemmin.
Datapisterekisteri ei ole raportointityökalu eikä kojelauta. Se on luettelo: jokainen datapiste, joka päätyy kestävyysraporttiin, ja sen perässä joukko kiinteitä kenttiä. Mistä se on peräisin. Kuka on sen omistaja. Mitä käsittelyvaiheita on lähteen ja raportin välissä. Minkä säännön mukaan sen laatu arvioidaan. Milloin se on viimeksi tarkistettu.
Näitä kenttiä vaille datapiste on luku, joka sattuu olemaan jossain. Näiden kenttien kanssa siitä tulee tieto, jonka alkuperä on kirjattu ja joka on siksi toistettavasti tarkistettavissa. Juuri tähän eroon organisaatiot törmäävät: raportti on olemassa, sitä tukeva rakenne ei.
Usein lähde on aikoinaan ollut olemassa. Joku on aikanaan hakenut luvun ERP-järjestelmästä, laittanut sen laskentataulukkoon, ja kollega on ottanut sen käyttöön vuotta myöhemmin kopioimatta mukaan sen alkuperää. Tai luku on laskennan tulos — arvio keskiarvon perusteella, muunnos litroista hiilidioksidikiloiksi — jonka laskentasääntöä ei ole kirjattu ylös. Juuri tämä polku, mitä käsittelyvaiheita on lähteen ja raportin välissä, on se kohta, jossa suurin osa tiedosta katoaa. Luku, jota on käsitelty kolme kertaa ennen kuin se saavuttaa raportin, on saanut kolme tilaisuutta menettää alkuperänsä.
Useamman toimipisteen tai liiketoimintayksikön organisaatioissa on toinenkin syy: sama datapiste on olemassa useassa paikassa, hieman toisistaan poikkeavassa muodossa, ja kukaan ei ole koskaan määrittänyt, mikä versio on lähdedata. Se on eri kysymys kuin puuttuva lähde, mutta ne kohtaavat toisensa: jos haluatte tietää, missä datapiste on jo olemassa useissa liiketoimintayksiköissä, törmäätte usein juuri samaan sokeaan pisteeseen.
Datapiste, jolla ei ole lähdettä, saa rekisterissä statuksen: vahvistamaton. Ei poistettu, ei hiljaisesti oletettu oikeaksi, mutta merkitty. Siitä hetkestä lähtien on tehtävä valinta, ja valinta riippuu siitä, mikä on pelissä. Jos kyse on datapisteestä, joka olennaisuusanalyysissä on arvioitu pieneksi, lähde voidaan jäljittää myöhemmin ilman että raportti odottaa sitä. Jos kyse on datapisteestä, jonka on läpäistävä varmennus, lähde on ehto, ei mukava lisä.
Itse etsintä noudattaa vakiintunutta reittiä: takaisin lähdeasiakirjaan tai lähdejärjestelmään, jokaisen käsittelyvaiheen läpi, kunnes päästään omistajalle, joka voi vahvistaa luvun oikeellisuuden. Juuri tätä source-to-report-kartoitus tarkalleen tarkoittaa: ei luvun tarkistamista, vaan sitä johtaneen polun rekonstruointia. Toisinaan käy ilmi, ettei polkua voi enää rekonstruoida. Silloin johtopäätös ei ole se, että luku on väärä, vaan se, ettei sitä voida todistaa — ja se on eri, mutta raportin kannalta yhtä tärkeä, tulos.
Rekisteri ei ole valmis, kun jokaisella datapisteellä on lähde. Se on valmis, kun jokaisella datapisteellä on omistaja, jonka puoleen voidaan kääntyä, laatusääntö, jota vasten sitä arvioidaan, ja kirjattu käsittelyhistoria, joka on käytävä uudelleen läpi kenenkään tarvitsematta muistaa sitä ulkoa. Mitä tähän tarkalleen kuuluu ja milloin voitte lakata etsimästä lisää yksityiskohtia, on käsitelty kohdassa milloin rekisteri on valmis. Useimmille organisaatioille vastaus on epätyydyttävän konkreettinen: se on valmis, kun uusi kollega pystyy rekonstruoimaan raportin ilman apua.
Datapisteen, jolla ei ole lähdettä, jäljittäminen ja korjaaminen on työtä, joka jakautuu vaiheisiin: lähdeasiakirjojen läpikäynti, käsittelyvaiheiden jäljittäminen, omistajien tavoittaminen, vastausten kirjaaminen. Osa tästä työstä — järjestelmien läpikäynti puuttuvan luvun osalta, saatujen vahvistusten yhdistäminen — on tarpeeksi toistuvaa, jotta voidaan laskea, mitä osan siitä tekoäly voi ottaa hoitaakseen. FTE TO AI:n työskannaus tekee tämän tehtäväkohtaisesti: ei yleisluontoisina väittämiä automaatiosta, vaan konkreettisena arviona siitä, mikä osa tämänkaltaisesta etsintätyöstä voidaan jättää järjestelmän hoidettavaksi ja mikä osa vaatii edelleen omistajuutta ja arviointia.
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.