Taulukkolaskenta, jossa on energiankulutus-, matka- tai hankintadataa, on harvoin päätepiste. Ennen kuin luku ilmestyy kestävyysraportissa, se on kirjoitettu uudelleen, laskettu yhteen, muunnettu, suodatettu ja joskus korjattu käsin. Joka askel on paikka, jossa jokin voi poiketa lähteestä, ja joka askel, jota ei ole dokumentoitu, on askel, jota kukaan ei voi jälkikäteen jäljittää.
Tavanomainen reitti lähteestä raporttiin koostuu tietystä joukosta tunnistettavia käsittelyvaiheita. Data otetaan lähdedokumentista, usein käsin kopioimalla. Sen jälkeen se normalisoidaan: yksiköt yhdenmukaistetaan, merkintätavat mukautetaan, puuttuvat arvot täytetään tai arvioidaan. Sitten seuraa aggregointi, jossa eri sijaintien, ajanjaksojen tai osastojen luvut yhdistetään yhdeksi luvuksi. Väliin mahtuu korjauksia: virheellinen rivi korjataan, poikkeava arvo poistetaan, oletus liitetään tyhjään kenttään. Tämän ketjun päässä on luku, joka ilmestyy raporttiin.
Ongelma ei ole se, että näitä käsittelyvaiheita tapahtuu. Normalisointi ja aggregointi ovat tarpeen, jotta taulukkolaskennan data saadaan käyttökelpoiseksi. Ongelma on se, että näiden vaiheiden tieto on tavallisesti vain yhden työntekijän päässä, tai korkeintaan sähköpostiketjussa, jota kukaan ei enää löydä.
Jos raportin lukua kysytään, on pystyttävä jäljittämään, mistä se on peräisin ja mitä sille on tehty. Ilman tätä jäljitettävyyttä joka kysymys luvusta muuttuu etsinnäksi: kuka on muokannut tätä riviä, minkä perusteella, ja on samaa käsittelyä sovellettu myös edellisenä vuonna. Normalisoinnissa kysymys on esimerkiksi siitä, mitä muuntokerrointa on käytetty ja on tätä kerrointa muutettu sen jälkeen. Aggregoinnissa kysymys on siitä, mitkä lähteet on laskettu yhteen ja on jokin sijainti laskettu vahingossa kahdesti tai päinvastoin jätetty pois.
Taulukkolaskenta, jonka käsittelyvaiheita ei ole dokumentoitu, voi seuraavana vuonna tuottaa samasta lähdedatasta eri luvun, yksinkertaisesti koska joku muu tekee normalisoinnin tai tulkitsee korjauksen eri tavalla. Se ei ole petosta, vaan dokumentoidun prosessin puuttumista. Seuraus on samanlainen: luku ei ole toistettavissa.
Jotkut organisaatiot ajattelevat, että taulukkolaskennan muutosloki riittää. Loki tallentaa, että jotain on muuttunut, mutta ei sitä, miksi, kenen roolissa tehtynä ja minkä säännön perusteella. Ero lokikirjan ja audit trailin välillä on juuri tässä kontekstissa: audit trail tekee käsittelyvaiheesta jäljitettävän, loki vain tallentaa, että jotain on tapahtunut.
Työkalun puuttuminen ei ole tekosyy ohittaa lineage. Myös ilman erikoistunutta ohjelmistoa on mahdollista dokumentoida jokaisesta datapisteestä, mistä lähteestä se on peräisin, mitä käsittelyvaiheita sille on sovellettu ja kuka näitä käsittelyvaiheita on suorittanut. Tämä voidaan tehdä kiinteällä rakenteella taulukkolaskennan rinnalla: rekisterillä, jossa lähde, käsittelyvaihe ja vastuuhenkilö on kirjattu yhteen. Miltä tämä näyttää ilman työkalua, kuvataan sivulla lineagen luomisesta ilman työkalua.
Joka käsittelyvaiheeseen kuuluu omistaja. Ei vain lopullisen datapisteen, vaan itse käsittelyvaiheen: kuka on päättänyt, että tätä normalisointisääntöä sovelletaan, ja kuka saa muuttaa tätä sääntöä. Tämä omistajuus ei usein ole kirjattuna mihinkään. Kaksi kysymystä on syytä erottaa toisistaan: kuka omistaa datapisteen määritelmän, toisin sanoen mitä luku tarkalleen tarkoittaa, ja kuka omistaa sen taustalla olevan prosessin, toisin sanoen kuka on vastuussa siitä reitistä, jonka kautta se syntyy. Ilman että näitä kahta on dokumentoitu, käsittelyvaihe pysyy yksilöllisenä tapana sen sijaan, että se olisi organisaation prosessi.
Data Readiness Scan kartoittaa näitä käsittelyvaiheita: mitkä askelmat tapahtuvat lähteen ja raportin välillä, kuka ne suorittaa ja mitkä säännöt niiden taustalla ovat. Se ei ole raportointityökalu eikä kyselylomake, vaan dokumentaatio siitä prosessista, joka edeltää lukua.
Kun kerran on selvää, mitkä käsittelyvaiheet tapahtuvat taulukkolaskennan ja raportin välillä, syntyy myös näkymä siihen, mitkä näistä askelmista ovat toistuvia ja sääntöohjattuja, ja tulevat siten kysymykseen uudelleenjärjestelyn kannalta. FTE TO AI:n werkscan laskee tehtäväkohtaisesti, mikä osa työstä on siirrettävissä AI:lle, ja liittyy siten juuri niihin käsittelyvaiheisiin, joita tässä on kuvattu: normalisointi, aggregointi ja korjaaminen ovat askelmia, joita voidaan, kunhan ne ensin on dokumentoitu, arvioida tämän kysymyksen valossa.
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.