Kun kestävyysdataa tulee useammasta kuin yhdestä liiketoimintayksiköstä, ongelma syntyy ennen kuin rekisteri on olemassa. Jokaisella yksiköllä on omat järjestelmänsä, omat laskentataulukkonsa, omat määritelmänsä siitä, mitä datapiste tarkoittaa. Rekisteri, joka ei järjestä tätä, laskee saman virran pian kolmesti tai jättää sen kokonaan pois.
Datapisterekisteri ei ole lista raportointiaiheista, vaan rekisteri yksittäisen datapisteen tasolla: toimipiste A:n scope 2 -päästöt, yksikkö B:n määräaikaisessa työsuhteessa olevien henkilöiden lukumäärä (fte), toimipaikka C:n vedenkulutus. Jokaisesta datapisteestä on kirjattava, mitä se tarkalleen mittaa, missä yksikössä, miltä ajanjaksolta ja mille entiteetille. Näitä neljää elementtiä ilman datapiste ei ole jäljitettävissä ja siten ei ole tarkistettavissa.
Lisäksi rekisteri sisältää jokaiselle datapisteelle lähteen: järjestelmän, tiedoston tai henkilön, josta luku on peräisin. Se ei ole aina niin yksinkertaista kuin se kuulostaa. Useissa liiketoimintayksiköissä käy säännöllisesti niin, että datapiste täytetään ilman että kukaan pystyy osoittamaan, mistä se on peräisin; mitä tehdä datapisteelle, jolla ei ole osoitettavaa lähdettä on siis kysymys, jonka rekisterin itsensä pitää pystyä vastaamaan, ei jotain, joka selvitetään jälkikäteen.
Houkutus useissa liiketoimintayksiköissä on antaa jokaisen yksikön toimittaa lista erikseen ja yhdistää listat sen jälkeen. Se ei toimi, koska yksiköt käyttävät harvoin samoja määritelmiä. Yksi yksikkö raportoi energiankulutuksen toimipisteittäin, toinen tuotantolinjoittain. Yksi laskee vuokratyöntekijät henkilöstömäärään mukaan, toinen ei. Kun näitä listoja yhdistetään ennen kuin määritelmät on yhtenäistetty, syntyy päällekkäisyyksiä, joita ei tunnisteta päällekkäisyyksiksi.
Järjestys, joka toimii: ensin määritetään, mitkä datapisteet ovat organisaatiolle kokonaisuutena todella merkityksellisiä, riippumatta siitä, mikä yksikkö niitä toimittaa. Se on kysymys tarpeesta, ei saatavuudesta — mitä datapisteitä todella tarvitsette on eri kysymys kuin se, mitä datapisteitä on jo jossain laskentataulukossa. Vasta sen jälkeen määritetään jokaiselle datapisteelle, mikä yksikkö, mikä järjestelmä ja mikä henkilö on lähde. Näin syntyy yksi rekisteri, jossa on yksi määritelmä per datapiste, ja jossa useat yksiköt toimittavat syötteen ilman että datapiste itse kaksinkertaistuu.
Päällekkäisyyksien tunnistaminen on tämän jälkeen edelleen tarpeen, sillä myös hyvillä määritelmillä kaksi yksikköä voi tahattomasti kirjata saman perustavan tosiasian eri nimellä. Miten sen huomaa — miten tunnistat päällekkäisen datapisteen liiketoimintayksiköiden välillä — on tarkistus, joka tehdään rekisterille itselleen, ei raportille, joka siitä myöhemmin syntyy.
Yleinen virhe on omistajuuden osoittaminen yksikkötasolla: yksikkö A vastaa kaikesta yksikkö A:n datasta. Se toimii niin kauan kuin yksiköt pysyvät selkeinä, mutta useissa liiketoimintayksiköissä, joilla on päällekkäisiä prosesseja — yhteinen hankintaosasto, keskitetty ajoneuvokanta — tämä osoitus muuttuu nopeasti epäselväksi. Parempi on omistajuus datapisteen mukaan: yksi nimi, joka pystyy selittämään, mistä luku on peräisin, mikä on yksikkö ja milloin se on viimeksi päivitetty. Tämän nimen ei tarvitse olla se, joka syöttää luvun, mutta sen on tunnettava lähde.
Kuinka monella olemassa olevista datapisteistä on jo tällainen osoitettava lähde, on tavallisesti ensimmäinen kysymys, joka nousee esiin, kun tätä käydään järjestelmällisesti läpi. Kuinka monella datapisteistänne on lähde on juuri se kysymys, joka on vastattava erikseen jokaiselle liiketoimintayksikölle, koska vastaus voi vaihdella yksiköiden välillä merkittävästi.
Useissa liiketoimintayksiköissä houkutus on odottaa, kunnes kaikilla yksiköillä on yhtä paljon syvyyttä, ennen kuin rekisteriä pidetään valmiina. Se ei ole realistinen mittapuu. Rekisteri on valmis, kun jokaisesta datapisteestä on selvää, kuka on omistaja, mikä on lähde ja mikä laatusääntö siihen sovelletaan — vaikka vastaus jollekin datapisteelle olisi toistaiseksi "lähde tuntematon, toimenpide yksikölle X". Puutteellisuus, joka on näkyvää ja osoitettua, on hallittavaa; puutteellisuus, joka pysyy piilossa täytetyn luvun takana, ei ole. Mitä tämä mittapuu tarkalleen tarkoittaa, on käyty läpi kohdassa milloin rekisteri on valmis useissa liiketoimintayksiköissä.
Kuinka paljon aikaa tällaisen rekisterin laatiminen vaatii, riippuu liiketoimintayksiköiden lukumäärästä, yksikköä kohden olevien järjestelmien määrästä ja siitä, missä määrin määritelmät ovat jo yhteneväisiä. Organisaatiossa, jossa on muutama yksikkö ja selkeät lähteet, tämä on huomattavasti vähemmän työtä kuin organisaatiossa, jossa on kymmeniä yksiköitä eri ERP-järjestelmissä. Osoitus siitä, mistä tämä työ juontuu, löytyy kohdasta kuinka pitkään kestää saada aihe kuntoon.
Datapisterekisterin laatiminen ja ylläpito useissa liiketoimintayksiköissä koostuu joukosta tunnistettavia tehtäviä: määritelmien kysymisestä, lähteiden selvittämisestä, omistajien osoittamisesta, päällekkäisyyksien havaitsemisesta. Osa tästä työstä on riittävän toistettavaa automatisoitavaksi, toinen osa vaatii arviointia, joka on jätettävä ihmisen tehtäväksi. FTE TO AI:n työskentelyskannaus laskee tehtäväkohtaisesti, kuinka suuri osa tästä työstä voidaan siirtää AI:n tehtäväksi, jotta selviää, missä työtunteja tarvitaan edelleen ja missä 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.