Lineage on yksinkertaisesti se reitti, jonka luku kulkee: paikasta jossa se syntyy, paikkaan jossa se on raportissa. Tämä reitti on olemassa myös ilman työkalua. Joka kerta kun joku ottaa luvun laskentataulukosta, laskee sen yhteen toisen luvun kanssa, jakaa sen fte-määrällä tai muuntaa toiseen yksikköön, kyseinen henkilö kulkee palan lineagea — kirjataanko sitä tai ei. Kysymys ei ole siitä, onko tämä lineage olemassa, vaan siitä, pystyykö joku kertomaan sen uudelleen ilman alkuperäistä tekijää.
Kestävyysraportin datapisteellä on käytännössä aina joukko vaiheita takanaan. Ensin on lähde: laskentataulukko toimipaikkakohtaisesta energiankulutuksesta, HR-järjestelmän vienti, toimittajan lasku. Sen jälkeen tulee muokkaus: yhteenlasku, keskiarvoistaminen, muuntaminen CO2-ekvivalentiksi, yhdistäminen päästökertoimeen. Usein seuraa aggregointi: toimipaikkakohtaiset luvut muuttuvat maakohtaisiksi luvuiksi, kuukausiluvut muuttuvat vuosiluvuiksi. Lopuksi luku päätyy raporttiin, usein vielä viimeisen manuaalisen kopiointi- tai liittämisvaiheen kautta.
Jotta ymmärtäisi mitä source-to-report-mapping tarkoittaa, kun lähde on laskentataulukko, auttaa nähdä nämä vaiheet ei yhtenä kokonaisuutena vaan sarjana erillisiä toimenpiteitä, joista jokaisella on omat virhemahdollisuutensa. Se, joka tuntee vain matkan alun ja lopun, ei näe missä keskellä on mennyt pieleen.
Ilman kirjaamista lineage on olemassa vain sen henkilön päässä, joka laskentataulukon on tehnyt. Kun kyseinen henkilö on lomalla, vaihtaa tehtävää tai lähtee organisaatiosta, tieto siitä mitä lähteen ja raportin välillä on tapahtunut, katoaa. Kontrolleri, joka haluaa varmistaa luvun, joutuu silloin arvailemaan tai kysymään. Ulkopuolinen osapuoli, joka arvioi raporttia, joutuu luottamaan sen sijaan, että voisi tukeutua dokumentaatioon.
Lähteen ja raportin väliin sijoittuvat muokkaukset ovat usein muuttuneet näkymättömiksi, koska ne piilevät solukaavoissa, makroissa tai työntekijän muistissa. Jotta selvittäisi mitkä muokkaukset sijaitsevat lähteen ja raportin välillä, kun lähde on laskentataulukko, on tarpeen nimetä erikseen joka kaava, joka manuaalinen vaihe ja joka yhdistäminen — ei mustana laatikkona vaan sarjana erillisiä toimenpiteitä.
Sama pätee kahteen muokkaukseen, jotka esiintyvät kestävyysdatassa useimmin: aggregointiin ja normalisointiin. Aggregointi — usean lähteen lukujen laskeminen yhteen kokonaissummaan — vaatii kirjaamista siitä, mitkä lähteet on otettu mukaan ja mitkä ei, ja miksi. Se, joka haluaa tietää miten aggregointi kirjataan, kun lähde on laskentataulukko, kohtaa tarpeen dokumentoida yhteenlaskua kohden, mitkä solut on otettu mukaan. Normalisointi — raakojen lukujen palauttaminen vertailukelpoiseksi yksiköksi — sisältää vastaavan ongelman: mitä muuntokerrointa on käytetty, mistä lähteestä kyseinen kerroin on peräisin, ja on kyseinen kerroin pysynyt samana koko vuoden. Sille, joka haluaa kirjata tämän, on kuvattu lähestymistapa artikkelissa miten normalisointi kirjataan, kun lähde on laskentataulukko.
Yleinen virhe on ajatella, että muutoslokikirja tuottaa riittävän lineagen. Lokikirja näyttää milloin solua on muokattu ja kenen toimesta, mutta ei sitä, miksi muokkaus oli tarpeen tai mikä sääntö sen takana oli. Auditointipolku, joka kirjaa vain sen mitä on tapahtunut, ilman taustalla olevaa logiikkaa, jättää samat kysymykset vastaamatta kuin lokikirjan puuttuminen. Miksi auditointipolun on oltava enemmän kuin lokikirja, kun lähde on laskentataulukko, löytyy erosta toimenpiteen rekisteröinnin ja sen taustalla olevan syyn kirjaamisen välillä.
Ilman työkalua tämä tarkoittaa käytännössä: kutakin datapistettä kohden kiinteä asiakirja tai kiinteä osio, jossa kerrotaan mitä lähdettä on käytetty, mitä muokkauksia on sovellettu missä järjestyksessä, kuka muokkauksen on suorittanut ja millä säännöllä. Tämä voidaan tehdä erillisessä rekisterissä, kommenttikentissä itse laskentataulukossa, tai erillisessä yhteenvedossa, jota pidetään yllä raportointiprosessin rinnalla. Se on enemmän työtä kuin ei kirjaamista lainkaan, ja vähemmän työtä kuin työkalun käyttöönotto prosessin päälle, joka ei näitä vaiheita vielä tunne. Juuri tämä on syy käydä ensin läpi näitä vaiheita: työkalu, joka asetetaan järjestäytymättömän prosessin päälle, antaa siistimmän tulosteen samoista jäljittämättömistä luvuista. Tämän lähestymistavan yksityiskohdat, mukaan lukien muoto, jossa lineage voidaan pitää yllä datapistettä kohden, on kuvattu artikkelissa miten lineage rakennetaan ilman työkalua, kun lähde on laskentataulukko.
Joka vaiheen manuaalinen kirjaaminen lähteen ja raportin välillä on tehtävissä rajallisella määrällä datapisteitä ja laskentataulukoita. Suuremmalla määrällä toimipaikkoja, lähteitä tai raportointikiertoja jokaisen muokkauksen seuraamisesta tulee tehtävä, joka vaatii paljon aikaa ja on herkkä samoille virheille, jotka lineagen juuri pitäisi paljastaa. Sillä hetkellä kun tämä raja tulee näkyviin, on hyödyllistä tietää, mikä osa tästä kirjaavasta työstä on toistettavissa kiinteän säännön mukaan ja siten AI:n otettavissa hoidettavaksi, ja mikä osa vaatii edelleen arviointia. FTE TO AI:n työscan laskee tämän tehtäväkohtaisesti, jolloin selviää missä käsityö yhä sopii ja missä toisto vaatii jotain muuta.
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.