Laskentataulukko, jossa on energiankulutus toimipaikkakohtaisesti, ei ole ongelma sinänsä. Ongelma syntyy seuraavassa vaiheessa: miten näitä rivejä yhdistetään luvuksi, joka päätyy raporttiin. Tämä vaihe tapahtuu usein kaavassa, pivot-taulukossa tai, pahimmillaan, sen henkilön päässä, joka päivittää laskentataulukkoa vuosittain. Kukaan muu ei tiedä tarkalleen, mitkä rivit on otettu mukaan, mitkä on jätetty pois ja miksi.
Aggregointi kuulostaa laskemiselta, mutta se on sarja valintoja. Lasketteko mukaan toimipaikat, jotka olivat osan vuotta suljettuina? Otatteko mukaan vuokratut toimipaikat vai vain omistuksessa olevat? Lasketteko kalenterivuoden vai tilikauden mukaan? Jokainen valinta muuttaa loppulukua, ja laskentataulukossa näitä valintoja ei tavallisesti dokumentoida erikseen. Ne sisältyvät kaavaan, joka viittaa soluihin, ilman että missään on luettavaa riviä, joka sanoo: tämä on aggregointisääntö, ja tästä syystä.
Heti kun joku ottaa laskentataulukon vastaan, tai kun kontrolleri haluaa vuotta myöhemmin toistaa vertailukelpoisen luvun, tämä selitys puuttuu. Kaava toimii edelleen, mutta kukaan ei enää voi arvioida, onko se yhä oikea tämän vuoden tilanteeseen.
Laskentataulukon raakarivin ja raportin luvun välillä on tavallisesti useita vaiheita: olennaisten rivien valinta, muuntaminen yksikköön, yhteenlasku tai painotettu keskiarvo, ja joskus korjaus puuttuvien kuukausien tai toimipaikkojen varalta. Jokaisella vaiheella voi olla oma sääntönsä, ja jokainen sääntö voi muuttua ilman että sitä kirjataan minnekään.
Ratkaiseva kysymys on tällöin: jos kontrolleri kysyy, miten tämä luku on muodostettu, voitteko osoittaa vaiheet yksitellen? Ei johtaa tulosta takaperin kaavan läpi, vaan näyttää säännöt itsessään.
Aggregointisääntö, joka on olemassa vain kaavassa, ei ole tarkastettavissa eikä siirrettävissä. Dokumentointi tarkoittaa: kirjataan laskentataulukon ulkopuolella, mitä aggregointia on sovellettu, mihin valintaan, millä poikkeuksilla, ja kuka on tämän säännön vahvistanut. Se ei ole ylimääräinen asiakirja laskentataulukon rinnalle, se on selitys, joka tekee laskentataulukosta ylipäätään käyttökelpoisen lähteen raportointipisteelle.
Ilman tätä selitystä aggregointisääntö muuttuu huomaamatta. Joku lisää toimipaikan listaan, muokkaa kaavaa, ja tämän vuoden luku ei ole enää vertailukelpoinen viime vuoden kanssa. Ei siksi, että taustadata olisi muuttunut, vaan siksi, että yhteenlaskutapaa on hiljaisesti muutettu.
Aggregointi on yksi niistä kohdista, joissa laskentataulukot kätkevät aggregointivirheitä, mutta ei ainoa. Vastaavat kysymykset koskevat yksiköitä ja määritelmiä: katso miten dokumentoitte normalisoinnin, kun lähteenä on laskentataulukko siitä vaiheesta, joka usein tulee aggregoinnin edellä. Ja koko matkan kartoittamiseksi raakarivistä raportin lukuun, myös ilman erikoisohjelmistoa, on olemassa miten teette lineagen ilman työkalua, kun lähteenä on laskentataulukko. Molemmat liittyvät laajempaan kysymykseen mitä source-to-report-mapping tarkalleen tarkoittaa, jossa aggregointi on yksi dokumentoitavista vaiheista.
Aggregointisääntö tarvitsee, samoin kuin datapiste, henkilön, joka on vastuussa sen taustalla olevasta valinnasta. Ei sitä, joka sattui kirjoittamaan kaavan, vaan sitä, joka pystyy selittämään, miksi tämä valinta ja tämä laskentatapa on valittu, ja joka hyväksyy muutoksen ennen kuin se toteutetaan. Tämä kysymys liittyy siihen, kuka omistaa datapisteen määritelmän: määritelmä määrittää, mitä mitataan, aggregointisääntö määrittää, miten mittaukset yhdistetään raportointiluvuksi. Molemmat kuuluvat henkilölle, jolla on nimi, ei laskentataulukolle, joka kulkee kädestä käteen.
Aggregointisääntöjen dokumentointi ei ole kertaluonteinen toimenpide. Se on kysymys, joka palaa aina uudelleen, kun organisaatio muuttuu: uusi toimipaikka, uusi yksikkö, fuusio. Sen takia ei riitä, että dokumentoi tämän kerran; tarvitaan prosessi, joka toistaa dokumentoinnin joka muutoksen yhteydessä. Kuka valvoo tätä prosessia ja milloin aggregointisääntö tarkistetaan, on kysymys, joka koskettaa sitä, kuka omistaa taustalla olevan prosessin, erillään siitä, kuka toimittaa yksittäiset luvut.
Tämä sivu kuvaa, mitä tarvitaan aggregoinnin läpinäkyväksi tekemiseksi. Data Readiness Scan on työkalu, joka auttaa dokumentoimaan tämän datapisteillenne: rekisterin, lähteestä raporttiin ulottuvan lineagen pisteittäin ja omistajuussäännöt. Tämä työkalu on kehitteillä. Jos haluatte aloittaa tämän kanssa jo nyt, voitte ilmoittautua odotuslistalle.
Heti kun aggregointisäännöt on dokumentoitu, omistajalla ja perusteella, syntyy toisenlaista työtä: näiden samojen vaiheiden suorittaminen ja tarkistaminen, vuosi vuoden jälkeen. Suuri osa tästä suorittavasta työstä, rivien valinnasta lukujen yhteenlaskemiseen kiinteän säännön mukaan, on sellaista tehtävää, josta FTE TO AI:n työskannauksella voidaan laskea, mikä osa on siirrettävissä tekoälylle, tehtäväkohtaisesti, sen perusteella, mitä työ tarkalleen sisältää.
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.