Lokikirja kertoo, että jotain on tapahtunut: tiedosto avattu, solu muutettu, vienti tehty. Se on hyödyllistä, mutta se ei vastaa kysymykseen, joka ratkaisee sillä hetkellä kun joku kyseenalaistaa kestävyysraportin luvun: miten tämä luku on täsmälleen syntynyt lähteestä, ja pitääkö tämä reitti edelleen paikkansa.
Järjestelmäloki rekisteröi toimintoja. Datapisteen audit trail vastaa lopputuloksesta. Kysymys ei ole siitä, kuka painoi mitä nappia milloin, vaan siitä, mitkä käsittelyvaiheet ovat muuttaneet raakaa arvoa siihen lukuun, joka nyt on raportissa. Ilman tätä vastuunalaisuutta jokainen luku on väite, jota kukaan ei pysty nopeasti perustelemaan, ei myöskään henkilö, joka sen on toimittanut.
Lähteen ja raportin välissä ei useimmiten ole suoraa viivaa, vaan sarja käsittelyvaiheita, ja jokainen vaihe on kohta, jossa jotain voi muuttua kenenkään sitä huomaamatta. Ajatelkaa yksiköiden muuntamista, toimipaikkojen yhdistämistä konsernitasolle, poikkeaman korjaamista, päästökertoimen soveltamista. Mitkä käsittelyvaiheet tarkalleen ovat kyseessä, vaihtelee datapisteen mukaan ja on kuvattu kohdassa mitkä käsittelyvaiheet ovat lähteen ja raportin välissä. Se, joka ei tallenna näitä vaiheita, näkee vain lähtöpisteen ja lopputuloksen, ja joutuu luvusta kysyttäessä rakentamaan koko reitin uudelleen, usein jonkun muistin perusteella.
Kaksi käsittelyvaihetta ansaitsee erityistä huomiota, koska ne johtavat useimmin poikkeamiin. Aggregointi laskee yhteen eri lähteiden arvoja kokonaissummaksi, ja jokaisen yhteenlaskun kohdalla on oltava selvää, mitkä erät on otettu mukaan ja mitkä ei. Miltä tämä tallennus näyttää, kun lähde on laskentataulukko, on kuvattu kohdassa miten tallennatte aggregoinnin, kun lähde on laskentataulukko. Normalisointi skaalaa arvot yhteiseen yksikköön tai jaksoon, ja pieni virhe tässä skaalauksessa siirtyy eteenpäin joka lukuun, joka sen jälkeen sen varaan nojaa. Tämän prosessin tallennus on kuvattu kohdassa miten tallennatte normalisoinnin, kun lähde on laskentataulukko. Molemmat käsittelyvaiheet ovat huomaamattomia laskentataulukossa ja välttämättömiä vastuunalaisuuden kannalta.
Moni kestävyysdata ei ala järjestelmästä, jossa on kiinteät kentät ja kiinteät säännöt, vaan laskentataulukosta, jonka joku on rakentanut oman näkemyksensä mukaan. Kaava on voitu korvata, sarake on voitu siirtää, välivaihe on voinut olla olemassa vain laatijan päässä. Mitä source-to-report-kartoitus tarkoittaa, kun lähde on laskentataulukko, on käsitelty kohdassa mitä source-to-report-kartoitus on, kun lähde on laskentataulukko. Olennaista on, että kartoitus ei saa riippua sattumasta, missä solussa tai välilehdellä tieto on, vaan se on tallennettava erillään ja toistettavasti, riippumatta itse laskentataulukkotiedostosta.
Ilman tallennettuja vaiheita reitti lähteestä raporttiin on olemassa vain niin kauan kuin sen kulkeneet ihmiset ovat paikalla ja muistavat sen. Jos prosessiin tulee muutos, työhön tulee uusi kollega, tai kysymys esitetään raportointivuoden päätyttyä, ainoa vaihtoehto on selvittää asia uudelleen. Se ei ole audit trail vaan jälkikäteinen improvisaatio. Työkalu ei ratkaise tätä ongelmaa, jos taustalla olevaa prosessia ei ole tallennettu; se tuottaa silloin vain siistimmän lokin rekonstruktiosta, joka on yhtä epävarma kuin ennenkin.
Alkuperän ja käsittelyvaiheiden tallentaminen ei edellytä ohjelmistoa. Miten lineage rakennetaan ilman työkalua, olemassa olevin keinoin, on kuvattu kohdassa miten rakennatte lineagen ilman työkalua. Laskentataulukkolähteisiin pätevät samat periaatteet kuin audit trailiin yleensä: tallennus koskee samoja vaiheita, sovellettuina lähteeseen, jolla ei ole kiinteää rakennetta, kuten on käsitelty kohdassa miksi audit trail on enemmän kuin lokikirja, kun lähde on laskentataulukko. Se, joka on tehnyt tämän tallennuksen kerran yhdelle datapisteelle, voi toistaa sen seuraavalle, ja rakentaa tällä tavoin rekisterin, joka ei riipu työkalusta vaan prosessista.
Kun on tallennettu, mitkä vaiheet luku on käynyt läpi ja kuka mitä käsittelyvaihetta suorittaa, syntyy toisenlainen kysymys: kuinka suuri osa tästä työstä on riittävän toisteista automatisoitavaksi. Aggregointi kiinteän säännön mukaan, arvojen normalisointi kiinteään yksikköön, käsittelyvaiheen tarkistus tallennettua laatusääntöä vasten, ovat tehtäviä, joiden automatisoitavuutta voidaan arvioida vasta kun ne ovat olemassa erillisinä vaiheina. FTE TO AI:n työscan laskee tehtäväkohtaisesti, kuinka suuri osa työstä voidaan siirtää tekoälylle, ja se tarvitsee juuri sellaisen tehtävätason tarkkuuden, jonka audit trail tuottaa.
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.