Kennisbank

Milloin useiden liiketoimintayksiköiden rekisteri lasketaan valmiiksi

Yhden liiketoimintayksikön rekisterin saa jossain vaiheessa valmiiksi. Datapisteet ovat kirjattuna, kullakin lähde ja omistaja, ja määritelmät on tarkistettu. Useamman liiketoimintayksikön kohdalla kysymys muuttuu. Kyse ei ole enää siitä, onko yksi lista täydellinen, vaan siitä, muodostavatko listat yhdessä yhden kuvan organisaatiosta.

Se on eri tyyppinen työ kuin lisärivien syöttäminen. Ansa on ajatella, että rekisteri on valmis heti kun kukin yksikkö on täyttänyt oman taulukkonsa. Neljä täytettyä taulukkoa, joissa on neljä eri määritelmää samasta datapisteestä, ei tuota rekisteriä, vaan neljä rekisteriä, jotka sattuvat olemaan vieretysten.

Mitä rekisterissä on oltava kunkin liiketoimintayksikön osalta

Jokaisen yksikön kohdalla toistuu samaa peruskysymystä: mitä datapisteitä tarvitaan, mistä ne tulevat ja kuka on niistä vastuussa. Se alkaa kysymyksestä mitä datapisteitä todella tarvitsette, sillä yksikkö, joka rekisteröi liikaa datapisteitä, kerää lähinnä ylläpitotaakkaa raportoinnin paranemisen sijaan.

Jokaisen jäljelle jäävän datapisteen kohdalla on kysyttävä samaa asiaa: on tämä jo olemassa jossain järjestelmässä, vai täytyykö se vielä kerätä erikseen. Sivu missä datapiste on jo olemassa kuvaa tämän selvitystyön. Useamman liiketoimintayksikön tapauksessa vastaus vaihtelee usein: yksiköllä A energiankulutus on jo kiinteistöjärjestelmässä, yksikkö B pitää sitä yhä yllä taulukossa, jota hallinnoi yksi controller. Tämän eron pitää näkyä rekisterissä, ei kadota yhtenäisen sarakkeen taakse, jossa kaikkialla lukee 'olemassa'.

Missä useimmiten menee pieleen: sama nimi, eri määritelmä

Suurin riski useamman yksikön kohdalla ei ole se, että datapisteitä puuttuu, vaan se, että ne ovat olemassa saman nimen alla mutta mittaavat eri asiaa. 'Vedenkulutus' voi yhdellä yksiköllä koskea vain pääkonttoria ja toisella myös tuotantohallia. 'Henkilöstömäärä' (fte) on voitu laskea vuokratyövoiman kanssa tai ilman. Niin kauan kuin tätä eroa ei ole nimetty, kukaan ei huomaa ongelmaa ennen kuin luvut täytyy yhdistää konsolidoituun raporttiin.

Rekisteri, joka ratkaisee tämän, kirjaa kunkin datapisteen määritelmän organisaation tasolla ja näyttää sen jälkeen yksikkökohtaisesti, onko tätä määritelmää sovellettu samalla tavalla. Jos ei, se merkitään rekisteriin avoimena kohtana, ei hiljaisena olettamuksena. Tämän rakenteen kokoaminen on kuvattu sivulla miten datapisterekisteri laaditaan, ja se järjestys ei muutu useamman yksikön kohdalla: ensin datapisteet ja niiden määritelmät kirjataan organisaation tasolla, sitten täytetään yksikkökohtaisesti, mitä on jo olemassa ja mitä puuttuu.

Puuttuvia lähteitä on kaikkialla, ei vain pienimmässä yksikössä

Oletus, että vain pienemmillä tai vähemmän kehittyneillä yksiköillä on aukkoja lähteissään, pitää harvoin paikkansa. Suurella yksiköllä, jolla on laaja ERP-järjestelmä, saattaa jonkin ympäristödatan osalta olla yhtä lailla manuaalinen laskenta kuin pienellä toimipisteellä. Se, kuinka suuri osuus datapisteistä on vailla kiinteää lähdettä, riippuu aiheesta ja siitä, kuinka pitkään yksikkö on työskennellyt näiden lukujen kanssa, ei yksikön koosta. Kuinka monella datapisteellänne on lähde on siksi kysymys, joka on vastattava yksikkökohtaisesti, katso kuinka monella datapisteellänne on lähde. Vasta kun se on kartoitettu yksikkökohtaisesti, voidaan sanoa jotain kokonaisuudesta.

Datapisteitä, joilla ei ole lähdettä, ei poisteta rekisteristä siksi, että ne ovat hankalia. Niille annetaan status ja jatkotoimenpide, kuvattuna kohdassa mitä tehdä datapisteelle, jolla ei ole lähdettä. Useamman liiketoimintayksikön tapauksessa on järkevää verrata tätä statusta yksiköiden välillä: jos kolmella neljästä yksiköstä on lähde jollekin datapisteelle ja neljännellä ei, ratkaisu löytyy usein läheltä niiden kolmen yksikön kokemuksesta, sen sijaan että neljännen yksikön pitäisi keksiä pyörä uudelleen.

Milloin rekisteri täsmää

Useiden liiketoimintayksiköiden rekisteri täsmää, ei siksi että se näyttää täydelliseltä, vaan koska kolme asiaa pätee samanaikaisesti. Ensiksi: kullakin datapisteellä on organisaation tasolla yksi määritelmä, ja tätä määritelmää on sovellettu kaikissa yksiköissä samalla tavalla, tai ero on nimenomaisesti kirjattu. Toiseksi: kunkin datapisteen kohdalla on yksikkökohtaisesti selvää, onko lähde olemassa, ja jos ei, mikä on status. Kolmanneksi: omistajuus on osoitettu sille tasolle, jolla tieto todella sijaitsee, ei automaattisesti yksikön ylimmälle johtajalle.

Kuinka kauan tämä työ kestää, riippuu yksiköiden määrästä, aiheiden määrästä ja taustajärjestelmien tilasta; arvio siitä on kuvattu sivulla kuinka pitkään kestää saada aihe kuntoon. Se ei ole kiinteä läpimenoaika, vaan summa työstä, joka on yhä tehtävä kunkin yksikön ja kunkin datapisteen kohdalla.

Näiden rekisterien yhdistäminen, määritelmien jäljittäminen ja lähteiden vertailu yksikköjen välillä on suurelta osin toistettavaa työtä: samat kysymykset, sovellettuna toistuvasti eri osastoon tai eri datapisteeseen. Mikä osa siitä voidaan siirtää AI:n tehtäväksi ja mikä osa pysyy ihmistyönä, on juuri se, mitä varten FTE TO AI:n työscan on tehty: se laskee tehtäväkohtaisesti, kuinka paljon tilaa on tämänkaltaisen rekisterityön nopeuttamiseen, ilman että tulos riippuu oletuksista, joita kukaan ei ole tarkistanut.