Laskentataulukko vaikuttaa yksinkertaiselta lähteeltä. Solu, jossa on luku, välilehti, jolla on nimi, toisesta järjestelmästä tehty vienti, joka on liitetty sisään. Mutta sen solun ja raportissa lopulta näkyvän luvun välissä on sarja käsittelyvaiheita, joita ei useimmiten ole kirjattu missään. Source-to-report-kartoitus on tämän sarjan kartoittamista: jokainen vaihe, jonka luku käy läpi siitä hetkestä, kun se tulee laskentataulukkoon, siihen hetkeen, kun se päätyy raporttirivillle.
Järjestelmässä, jossa on kiinteät kentät ja kiinteä rakenne, on usein yhä jäljitettävissä, mistä mikä kenttä on peräisin. Laskentataulukolla ei ole tätä rakennetta automaattisesti. Joku lisää välivälilehden aggregointia varten. Joku toinen kopioi sarakkeen toiseen tiedostoon tehdäkseen muunnoslaskennan. Kolmas liittää tuloksen arvona raportointitaulukkoon, jolloin kaava ja sen mukana jälki katoaa. Mikään tästä ei ole tapahtumahetkellä virhe. Ongelma syntyy vuosi myöhemmin, kun jonkun täytyy selittää, mistä luku on peräisin, ja vastausta ei enää pysty jäljittämään.
Source-to-report-kartoitus laskentataulukkolähteelle koostuu tunnistettavista vaiheista, joista kukin vaatii erikseen huomiota.
Ensimmäinen vaihe on raakadatan alkuperä: mikä tiedosto, mikä välilehti, mikä solu tai solualue, ja kuka sen syöttää tai toimittaa. Ilman tätä kiintopistettä ei ole lähdettä, johon voi viitata takaisin.
Toinen vaihe on mitkä käsittelyvaiheet ovat lähteen ja raportin välissä, kun lähde on laskentataulukko. Ajatellaan yksiköitä, joita muunnetaan, suodattimia, jotka jättävät tietyt rivit pois, kaavoja, jotka laskevat yhteen tai uudelleenskaalaavat arvoja. Jokainen käsittelyvaihe muuttaa lukua, ja jokainen käsittelyvaihe, jota ei ole kirjattu, on vaihe, jota ei myöhemmin voi enää tarkistaa.
Kolmas vaihe on aggregointi: useat rivit, välilehdet tai tiedostot, jotka yhdistetään yhdeksi luvuksi. Laskentataulukossa tämä tapahtuu usein käsin, painamalla summafunktiota alueella, jonka joku on itse rajannut. Se, miten tämä alue on valittu ja mitä siinä on, määrittää luvun yhtä paljon kuin taustalla oleva data. Juuri tästä syystä on kirjattava miten aggregointi kirjataan, kun lähde on laskentataulukko: ei muodollisuutena, vaan koska aggregointivaihe itsessään on virhelähde, jota kukaan muu ei näe.
Neljäs vaihe on normalisointi: eri yksiköt, eri raportointijaksot tai eri sijainnit, jotka tuodaan yhteiselle perustalle ennen kuin ne ovat vertailukelpoisia. Tässäkin pätee, että muuntokertoimen tai vertailuarvon valinta ohjaa tulosta, ja tämän valinnan on oltava jäljitettävissä. Miten tämä toimii, on käsitelty kohdassa miten normalisointi kirjataan, kun lähde on laskentataulukko.
Viimeinen vaihe on paikka, jonne luku laskeutuu: raporttirivi, indikaattori, vuosisumma. Myös tällä siirtymällä on oltava jälki, ei vain viittaus alkuperäiseen lähdeasiakirjaan.
On houkuttelevaa ajatella, että lista siitä, kuka on muuttanut mitä, riittää. Se on loki, ja loki kirjaa muutokset näyttämättä niiden takana olevaa logiikkaa. Merkityksellinen audit trail ei näytä ainoastaan, että solua on muutettu, vaan myös miksi, minkä säännön perusteella ja millä tuloksella jäljitettynä alkuperäiseen lähteeseen. Tätä eroa käsitellään tarkemmin selityksessä siitä, miksi audit trail on enemmän kuin loki, kun lähde on laskentataulukko.
Useimmilla organisaatioilla, jotka työskentelevät laskentataulukoiden kanssa, ei ole järjestelmää, joka pitäisi lineage-tietoa automaattisesti yllä. Se ei tarkoita, että kartoitus olisi mahdotonta, se tarkoittaa, että se on tehtävä käsin, kurinalaisuudella ohjelmiston sijaan. Mitä vaiheita tähän tarvitaan ja miten laskentataulukkovetoinen prosessi tulee siitä huolimatta jäljitettäväksi, on kuvattu kohdassa miten lineage tehdään ilman työkalua, kun lähde on laskentataulukko. Tähän liittyvä kysymys, joka usein jää huomiotta, on kuka omistaa datapisteen määritelmän: ilman nimettyä määritelmän omistajaa datapisteen merkitys muuttuu sen mukaan, kuka sitä milloin katsoo, ja silloin kaikkein kauneimmalla kartoituksella on vain vähän arvoa.
Työkalu, joka tekee raporteista kauniimpia, ei muuta mitään niiden lukujen luotettavuuteen, jotka siihen syötetään. Jos solun ja raportin välinen tie ei ole kirjattu, työkalu tuottaa siistimpiä raportteja samoista epävarmoista luvuista. Lähteen ja raportin välinen kartoitus ei siis ole vaihe, joka tulee työkalun jälkeen, vaan vaihe, joka tulee sitä ennen.
Kun lähteen ja raportin väliset vaiheet on kirjoitettu auki, käy myös näkyväksi, mitkä näistä vaiheista ovat ihmistyötä ja mitkä noudattavat kiinteää, toistettavaa käsittelyä. Tämä ero on perusta FTE TO AI:n työskannaukselle, joka laskee tehtäväkohtaisesti, kuinka suuren osan työstä AI voi ottaa hoitaakseen, sen perusteella, mitä käsittelystä, säännöistä ja datan alkuperästä on jo kirjattu.
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.