Kennisbank

Audit trail ei ole lokikirja, kun lähteenä on taulukkolaskenta

Lokikirja tallentaa, kuka avasi tiedoston ja milloin. Se on hyödyllistä, mutta se ei vastaa kysymykseen, jota kestävyysdatasta kysytään useimmin: miten tämä luku on syntynyt. Kun lähteenä on taulukkolaskenta, tämä ero on suurempi kuin järjestelmän kohdalla, koska taulukkolaskenta ei pakota kiinteää rakennetta. Kuka tahansa voi muuttaa kaavaa, lisätä rivin tai vaihtaa yksikön jättämättä jälkeä, joka ylittäisi tiedostonimen ja siihen liitetyn päivämäärän.

Mitä lokikirja tallentaa ja mitä ei

Lokikirja kertoo, että tiedosto "Scope1_2023_v4.xlsx" tallennettiin tiettynä päivänä. Se ei kerro, mikä solu muuttui, mistä syystä, ja oliko muutos korjaus vai uusi olettamus. Kestävyysdatan kohdalla tämä ero on merkityksellinen, koska luku kulkee usein useiden käsien läpi ennen kuin se päätyy raporttiin. Se, joka voi osoittaa, mitä lähteen ja raportin välillä on tapahtunut, voi myös osoittaa, miksi luku on sellainen kuin se on. Se, joka ei voi tätä osoittaa, on jäljellä vain lopputulos, ei tie sen taakse.

Vaiheet lähteen ja raportin välillä

Taulukkolaskennan raakadatan ja raportin luvun välillä on tavallisesti useita käsittelyvaiheita: yksikkö muunnetaan, ajanjakso yhdistetään, poikkeama korjataan, yhden välilehden tulos lasketaan yhteen toisen välilehden tuloksen kanssa. Joka vaihe on hetki, jolloin tehdään olettamus. Mitkä käsittelyvaiheet lähteen ja raportin välillä tarkalleen tapahtuvat, vaihtelee datapisteen ja organisaation mukaan, mutta vaiheet itsessään ovat harvoin ainutlaatuisia. Ne toistuvat käytännössä jokaisessa luvussa, joka koostetaan useista lähteistä.

Audit trail, joka näyttää vain lopputuloksen ja viimeisimmän muutospäivämäärän, jättää nämä välivaiheet kokonaan huomiotta. Jotta lukua voidaan jäljittää, on tallennettava, mikä käsittely tehtiin milloin, millä syötteellä ja kenen toimesta. Se on eri tallennustapa kuin lokikirja tarjoaa: se on source-to-report-mappaus, jossa lähtökohtana ei ole tiedosto vaan datapiste.

Aggregointi omana vaiheenaan

Yksi käsittelyvaiheista, joka jää useimmin huomiotta, on aggregointi: eri lähteiden, osastojen tai ajanjaksojen lukujen laskeminen yhteen yhdeksi luvuksi. Aggregointi vaikuttaa tekniseltä vaiheelta, mutta se sisältää usein sisällöllisiä valintoja: mitkä yksiköt yhtenäistetään, mitkä ajanjaksot lasketaan mukaan, mitkä poikkeukset pidetään erillään. Se, miten aggregointi tallennetaan, määrittää, voiko joku jälkikäteen jäljittää, miksi kokonaisluku on sellainen kuin se on, tai jääkö kokonaisluku mustaksi laatikoksi, jonka vain sen tekijä pystyy selittämään - ja se selitys ei kestä, kun kyseinen henkilö ei ole enää käytettävissä.

Miksi omistajuus kuuluu tallentamiseen

Audit trail ilman omistajuutta tallentaa, mitä tapahtui, mutta ei sitä, kuka on siitä vastuussa. Taulukkolaskennan kohdalla tämä on riski, koska tiedostoa voivat muokata useat henkilöt ilman, että on selvää, kuka teki sisällöllisen valinnan. Sen tallentaminen, kuka suoritti käsittelyn, on eri asia kuin sen tallentaminen, kuka omistaa datapisteen määritelmän: toinen tallentaa toimenpiteen, toinen tallentaa, kuka pystyy selittämään, miksi datapiste on määritelty sellaiseksi kuin se on. Molempia tarvitaan, jotta audit trail on käyttökelpoinen henkilölle, joka ei ollut prosessissa mukana.

Lisäksi on merkityksellistä erottaa toisistaan se, kuka suorittaa käsittelyn, ja se, kuka omistaa taustalla olevan prosessin. Työntekijä voi olla vastuussa taulukkolaskennan täyttämisestä, kun joku toinen on vastuussa prosessista, jossa kyseistä taulukkolaskentaa käytetään. Audit trail, joka ei tee tätä erottelua, osoittaa kysymyksen tullen viimeiseen henkilöön, joka kosketti jotain, ei siihen, kuka tosiasiassa voi selittää, miksi prosessi on järjestetty sillä tavalla.

Tallentaminen ilman työkaluja

Tämän tallentamisen voi aloittaa hankkimatta siihen järjestelmää. Se alkaa nimeämällä datapisteeseen sovellettavat käsittelyvaiheet, kirjaamalla, kuka suorittaa mitä vaihetta, ja kuvaamalla korjauksen taustalla olevan syyn sillä hetkellä, kun korjaus tehdään. Se, miten lineage rakennetaan ilman työkalua, kun lähteenä on taulukkolaskenta, on ennen kaikkea kurinalaisuuskysymys tallentamisessa, ei ohjelmistokysymys. Työkalu voi tukea tätä prosessia sen jälkeen, mutta työkalu prosessin päällä, joka ei tallenna mitään, tuottaa vain siistimmän taulukkolaskennan, jossa on samat näkymättömät olettamukset.

Kun lähteen ja raportin väliset vaiheet on nimetty ja tallennettu, syntyy toinen kysymys: kuka näitä vaiheita tosiasiassa suorittaa, ja mikä osa niistä on tarpeeksi toistettavaa siirrettäväksi eteenpäin. Monet tässä kuvatuista käsittelyvaiheista, kuten yksiköiden muuntaminen tai tietojen yhdistäminen kiinteistä lähteistä, ovat tehtäviä, jotka voidaan purkaa vaiheisiin. [FTE TO AI:n työskentelyanalyysi](https://fte-to-ai.com) laskee tehtäväkohtaisesti, kuinka suuren osan tästä työstä AI voi ottaa hoitaakseen, perustuen tehtävän luonteeseen sen sijaan, että lähtökohtana olisi yleinen olettamus siitä, mitä automaatio voi tehdä.