Useimmissa organisaatioissa, joissa on useita liiketoimintayksiköitä, samaa datapistettä esiintyy useaan kertaan. Scope 2 -päästöt löytyvät yhdessä toimipisteessä energialaskusta, toisessa kiinteistöpäällikön Excel-viennistä, ja kolmannessa ei mistään — sitä arvioidaan. Tämä ei ole yhden osaston virhe. Se on seurausta vuosista, jolloin kukaan ei ole määritellyt datapistettä keskitetysti, puhumattakaan sen lähteestä.
Kysymys "mitä teette tälle" olettaa, että on olemassa yksi vastaus, joka sopii kaikkialle. Näin ei ole. Lähestymistapa riippuu siitä, mitä kussakin liiketoimintayksikössä on jo olemassa, ja se vaihtelee.
Ennen kuin päätätte mitään datapisteestä, jolla ei ole lähdettä, laittakaa rinnakkain se, mitä kullakin liiketoimintayksiköllä tosiasiallisesti on. Joillekin yksiköille on olemassa lähde, jota kukaan ei ole kirjannut ylös — järjestelmä, toimittaja, paikallinen hallinto. Toisille tätä lähdettä ei ole, ja luku täytetään nyt arvion perusteella tai kollegan, joka "tietää sen suunnilleen". Näihin kahteen tilanteeseen tarvitaan erilainen lähestymistapa. Missä datapiste on jo olemassa on kysymys, jonka vastaatte yksikkö kerrallaan, ennen kuin lisäätte tai muutatte mitään rekisterissä.
Vasta kun tämä kokonaiskuva on olemassa, näette missä ongelma todella on: ei datapisteessä käsitteenä, vaan lähteiden hajonnassa, joka on sen ylösalaisin.
Datapisterekisterissä on per datapiste ei yhtä riviä, vaan niin monta riviä kuin lähteitä on. Datapisteelle, joka esiintyy kolmessa liiketoimintayksikössä, on kolme riviä: kullakin oma lähteensä, oma omistajansa ja oma laatusääntönsä. Se vaikuttaa hankalalta, mutta se estää jotain pahempaa — eri alkuperää olevien lukujen yhdistämisen yhdeksi luvuksi, jonka alkuperää kukaan ei enää pysty jäljittämään.
Jokainen rivi sisältää vähintään: datapisteen määritelmän sellaisena kuin se pätee tälle yksikölle, lähdejärjestelmän tai asiakirjan, josta luku on peräisin, kuka on vastuussa toimittamisesta ja tarkistamisesta, ja säännön, jolla tarkistetaan, on arvo uskottava — vaihteluväli, vertailu edelliseen vuoteen, yksikön tarkistus. Ilman viimeksi mainittua sääntöä huomaatte virheen vasta, kun joku sattumalta katsoo asiaa.
Komplikaatio, joka nousee usein esiin tämän prosessin aikana: yksikkö A ja yksikkö B kutsuvat "samaa" datapistettä samalla nimellä, mutta mittaavat eri asiaa. Toinen laskee leasingautot mukaan scope 1:een, toinen ei. Tämä ei ole lähdeongelma vaan määritelmäongelma, ja se on ratkaistava ennen kuin siihen liitetään lähde. Kuinka tällaiset erot tunnistetaan, on kuvattu kohdassa Kuinka tunnistat kaksinkertaisen datapisteen useassa liiketoimintayksikössä. Vasta kun määritelmä on kaikille yksiköille sama, on mielekästä alkaa liittää lähteitä — muuten rekisteröitte kolme kertaa eri asiaa yhden nimen alle.
Jos tämän selvityksen jälkeen käy ilmi, että liiketoimintayksiköllä ei todella ole lähdettä datapisteelle, on kaksi reittiä. Ensimmäinen: on olemassa järjestelmä tai prosessi, josta luku voisi periaatteessa tulla, mutta kukaan ei ole koskaan nimennyt sitä lähteeksi. Silloin nimeätte tämän lähteen ja kirjaatte, kuka sitä hallinnoi. Toinen: mitään ei todella ole, ja luku arvioidaan tai otetaan nyt toiselta yksiköltä. Silloin kirjaatte sen nimenomaisesti arvioksi, mukaan lukien sen taustalla oleva oletus, sen sijaan että annatte sen kulkea mitattuna arvona. Molemmat reitit kuuluvat rekisteriin — arvio, jota ei ole merkitty arvioksi, on riski, joka paljastuu vasta tarkastuksessa.
Ennen kuin käytätte aikaa lähteen etsimiseen kaikille puuttuville datapisteille, kannattaa selvittää, onko datapiste ylipäätään olennainen kyseiselle liiketoimintayksikölle. Pienellä toimistokiinteistöllä, jossa on viisi työntekijää, ei välttämättä tarvita olennaista scope 3 -datapistettä, joka on olennainen tuotantolaitokselle. Mitä datapisteitä todella tarvitsette auttaa tekemään tämän erottelun, jotta ette etsi lähdettä jollekin, jota ei jälkikäteen tarvittukaan.
On taipumus jatkaa lähteiden etsimistä, kunnes kaikki on täysin katettu. Tämä ei ole kriteeri. Rekisteri on valmis, kun kunkin olennaisen datapisteen kohdalla, liiketoimintayksikkö kerrallaan, on selvää, onko lähde olemassa, kuka on omistaja ja mitä tarkistusta siihen sovelletaan — ei silloin, kun jokainen luku on jäljitettävissä sadan prosentin varmuudella. Milloin rekisteri on valmis useassa liiketoimintayksikössä kuvaa tämän päätepisteen konkreettisesti, ja Kuinka moni datapisteistänne on lähde on kysymys, jolla mittaatte edistymistä matkan varrella.
Tämä on työtä, joka tehdään yksikkö kerrallaan, ei kertarysäyksellä koko organisaatiolle. Kuinka paljon aikaa se vie, riippuu liiketoimintayksiköiden määrästä, datapisteiden määrästä ja siitä, kuinka monella niistä on jo lähde. Osa tästä työstä — omistajien kysely, lähteiden kokoaminen, rekisterin täyttäminen — on sellaista tehtävää, joka voidaan jäsentää ja osittain nopeuttaa. FTE TO AI:n työscan laskee tehtäväkohtaisesti, mikä osa siitä voidaan siirtää AI:lle, jotta tiedätte ennen aloittamista, mikä osa pysyy manuaalisena ja mikä ei.
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.