Suurin osa kestävyysdatasta ei ala järjestelmästä, jossa on audit trail. Se alkaa laskentataulukosta, jota joku kiinteistöosastolla ylläpitää, energiantoimittajan viennistä, joka kirjoitetaan käsin uudelleen, tai välilehdestä, jonka joku toinen kollega täyttää kolme kertaa vuodessa. Se ei ole ongelma, jonka työkalu ratkaisee. Kyse on sen tallentamisesta, mitä tapahtuu tuon laskentataulukon ja raportin luvun välillä, ohjelmiston kanssa tai sitä ilman.
Lineage ei ole muuta kuin vastaus kysymykseen: mistä tämä luku tulee ja mitä sille on tehty matkalla. Automatisoidussa järjestelmässä ohjelmisto tallentaa osan tästä. Laskentataulukossa kukaan ei tee sitä automaattisesti, joten se on tehtävä käsin. Se ei tarkoita, että se olisi monimutkaisempaa, ainoastaan että sen on oltava eksplisiittistä. Sen suhteen, mitä source-to-report-kartoitus tarkalleen tarkoittaa, pätee sama logiikka laskentataulukossa kuin ERP-järjestelmässä: joka askel lähteen ja raportin luvun välillä nimetään, myös silloin, kun se askel koostuu käsin tehdystä laskutoimituksesta solussa.
Raakalaskentataulukon ja raportissa olevan luvun välillä on tavallisesti useita käsittelyvaiheita. Raaka energialasku muunnetaan kulutukseksi ajanjaksoa kohti. Tämä kulutus kerrotaan päästökertoimella. Tulos lasketaan yhteen muiden toimipisteiden lukujen kanssa. Jossain vaiheessa yksikkö muunnetaan, puuttuvalle kuukaudelle täytetään arvio tai tehdään korjaus, koska aiempi syöttö osoittautui virheelliseksi. Kukin näistä vaiheista on käsittely, joka muuttaa lukua, ja mitkä käsittelyt sijaitsevat lähteen ja raportin välillä on juuri se, joka on tallennettava ennen kuin kukaan voi tarkistaa luvun.
Laskentataulukossa riskinä on, että näitä vaiheita on piilotettu kaavoihin, joita kukaan ei enää tarkasta. Solu sisältää laskennan, jonka on laatinut kolme vuotta sitten henkilö, jolla on nykyään eri tehtävä. Kukaan ei enää tiedä, miksi kaava on rakennettu tuolla tavalla, ja kukaan ei uskalla muuttaa sitä. Se ei ole lineage-ongelma, joka häviää sen myötä, kun hankitaan työkalu. Ongelma on siinä, että puuttuu tallennettu kuvaus siitä, mitä kyseinen kaava tekee, riippumatta järjestelmästä, jossa se sijaitsee.
Kaksi käsittelyä esiintyy käytännössä aina ja ansaitsevat erityistä huomiota. Ensimmäinen on aggregointi: useiden toimipisteiden, osastojen tai ajanjaksojen luvut yhdistetään yhdeksi luvuksi. Se, miten aggregointi tallennetaan, määrittää, voiko joku jälkikäteen nähdä, mitkä lähteet on laskettu mukaan ja mitkä ei. Laskentataulukossa aggregointi tapahtuu usein yksinkertaisella SUMMA-kaavalla useiden välilehtien yli, mutta kysymys siitä, mitkä välilehdet siihen sisältyvät ja mitkä on tarkoituksella jätetty pois, on harvoin missään kuvattu.
Toinen on normalisointi: eri lähteiden luvut tehdään vertailukelpoisiksi, esimerkiksi muuntamalla yksiköitä tai yhdistämällä eri raportointikausia toisiinsa. Se, miten normalisointi tallennetaan, on yhtä relevanttia käsin tehtävässä prosessissa kuin automatisoidussa järjestelmässä. Laskentataulukko, jossa on sarakkeita eri yksiköissä ja jossa muunnos on toteutettu jossain kaavan keskellä, on normalisointivaihe, jota kukaan ei tunnista sellaiseksi ennen kuin siitä esitetään kysymys.
Lähteen ja raportin välisten vaiheiden tallentamisella on vähän arvoa, jos kukaan ei tiedä, kuka vastaa jokaisen vaiheen oikeellisuudesta. Kaksi kysymystä kuuluu tähän yhteyteen. Ensimmäinen on, kuka omistaa datapisteen määritelmän: kuka määrittää, mitä tietyllä luvulla tarkalleen tarkoitetaan, ja keneltä kysytään, kun tämä määritelmä muuttuu. Toinen on, kuka omistaa taustalla olevan prosessin: kuka vastaa itse laskentataulukosta, sen ylläpidosta ja sen ilmoittamisesta, kun lähde muuttuu tai häviää.
Näiden kahden vastauksen puuttuessa lineage pysyy tilannekuvana. Joku tallentaa tänään, miten luku lasketaan, mutta kuuden kuukauden kuluttua laskentataulukko muuttuu, vastuullinen työntekijä siirtyy muihin tehtäviin, tai välilehti korvataan uudella viennillä, jossa on eri sarakejärjestys. Jos omistajuutta ei ole osoitettu, kukaan ei huomaa, että lineage ei enää vastaa todellisuutta.
Työkalu, joka asetetaan organisoimattomaan prosessiin, tallentaa samat epäselvyydet, ainoastaan siistimmässä käyttöliittymässä. Jos kukaan ei tiedä, mitkä käsittelyt sijaitsevat lähteen ja raportin välillä, kuka omistaa määritelmän ja kuka hallinnoi taustalla olevaa prosessia, automatisointi tuottaa lähinnä nopeampaa epävarmuutta. Järjestys on: ensin vaiheet, omistajat ja säännöt tallennetaan, ja vasta sitten katsotaan, mikä osa niistä voidaan automatisoida.
Kun tämä tallennus on tehty, käy myös selväksi, mikä osa käsin tehtävästä työstä — laskujen uudelleenkirjoittaminen, välilehtien ylläpito, kaavojen tarkistuslaskenta — on tuettavissa tekoälyllä. Se, kuka haluaa tietää, mikä osa tästä työstä tulee kyseeseen tähän tarkoitukseen, voi käyttää FTE TO AI:n työscania. Se laskee tehtäväkohtaisesti, minkä osan työstä tekoäly voi ottaa hoitaakseen, perustuen tehtäviin sellaisina kuin ne nyt suoritetaan.
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.