Lineage ei ole midagi muud kui tee, mille arv läbib: kohast, kus see tekib, kuni kohani, kus see raportis seisab. See tee eksisteerib ka ilma tööriistata. Iga kord, kui keegi võtab arvu tabelist üle, liidab selle teise arvuga, jagab töötajate arvuga (fte) või teisendab teise ühikusse, läbib see inimene tüki lineage'st — olenemata sellest, kas see jäädvustatakse või mitte. Küsimus ei ole selles, kas see lineage eksisteerib, vaid selles, kas keegi saab selle ümber jutustada ilma algse looja kaasamiseta.
Säästva arengu raportis olev andmepunkt on peaaegu alati läbinud mitu sammu. Kõigepealt on allikas: tabel energiakasutusega asukoha kaupa, eksport HR-süsteemist, tarnija arve. Seejärel järgneb töötlus: liitmine, keskmistamine, teisendamine CO2-ekvivalendiks, seostamine heitekoefitsiendiga. Sageli järgneb agregeerimine: asukoha kaupa arvud muutuvad riigi kaupa arvudeks, kuu kaupa arvud muutuvad aasta kaupa arvudeks. Lõpuks jõuab arv raportisse, tihti veel viimase käsitsi ümberkirjutamise või kopeerimise kihi kaudu.
Mõistmiseks, mida tähendab source-to-report-mapping, kui allikas on tabel, on kasulik neid samme mitte vaadata ühtse tervikuna, vaid rea eraldi tegevustena, millel igaühel on oma vigade tekkimise võimalus. Kes tunneb ainult teekonna algust ja lõppu, ei näe, kus keskel midagi valesti läks.
Ilma jäädvustamiseta eksisteerib lineage ainult selle inimese peas, kes tabeli koostas. Kui see inimene puhkusele läheb, ametikohta vahetab või organisatsioonist lahkub, kaob teadmine sellest, mis allika ja raporti vahel juhtus. Kontroller, kes soovib arvu kontrollida, peab siis arvama või küsima. Väline osapool, kes raportit hindab, peab usaldama, mitte dokumentatsioonile toetuma.
Töötlused, mis allika ja raporti vahel toimuvad, on tihti muutunud nähtamatuks, kuna need on peidetud lahtrite valemitesse, makrodesse või töötaja mällu. Selleks, et selgitada välja, millised töötlused jäävad allika ja raporti vahele, kui allikas on tabel, on vajalik nimetada eraldi iga valem, iga käsitsi samm ja iga seos — mitte black boxina, vaid rea eraldi tegevustena.
Sama kehtib kahe töötluse kohta, mis säästva arengu andmetes kõige sagedamini esinevad: agregeerimine ja normaliseerimine. Agregeerimine — mitmest allikast pärinevate arvude kokku liitmine üheks summaks — nõuab jäädvustamist selle kohta, millised allikad on kaasatud ja millised mitte, ning miks. Kes soovib teada, kuidas jäädvustatakse agregeerimine, kui allikas on tabel, puutub kokku vajadusega dokumenteerida iga liitmise puhul, millised lahtrid on kaasatud. Normaliseerimine — töötlemata arvude taandamine võrreldavale ühikule — kannab sarnast probleemi: millist teisenduskoefitsienti on kasutatud, millisest allikast see koefitsient pärineb, ja kas see koefitsient on olnud kogu aasta samasugune. Neile, kes soovivad seda jäädvustada, on kirjeldatud lähenemine kuidas jäädvustatakse normaliseerimine, kui allikas on tabel.
Sageli tehtav viga on arvata, et muudatuste logiraamat annab piisava lineage. Logiraamat näitab, millal lahtrit muudeti ja kelle poolt, aga mitte, miks see muudatus vajalik oli või mis reegel selle taga oli. Auditijälg, mis registreerib ainult, mis toimus, ilma aluseks oleva loogikata, jätab vastuseta samad küsimused kui puuduv logiraamat. Miks auditijälg peab olema rohkem kui logiraamat, kui allikas on tabel, peitub vahes tegevuse registreerimise ja selle taga oleva põhjuse jäädvustamise vahel.
Ilma tööriistata tähendab see praktikas: iga andmepunkti kohta kindel dokument või kindel sektsioon, milles on kirjas, millist allikat on kasutatud, milliseid töötlusi on rakendatud ja mis järjekorras, kes töötluse teostas ning millise reegli alusel. Selleks võib olla eraldi register, kommentaariväljad tabelis endas, või eraldi ülevaade, mida raporteerimisprotsessi kõrval peetakse. See on rohkem tööd kui mittejäädvustamine ja vähem tööd kui tööriista rakendamine protsessi peale, mis neid samme veel ei tunne. Just see on põhjus, miks tuleks kõigepealt need sammud läbida: tööriist, mida rakendatakse korrastamata protsessile, annab korrektsema väljundi samade jälgimatute arvude kohta. Selle lähenemise üksikasjade jaoks, sealhulgas vormingu jaoks, mille alusel lineage'i andmepunkti kaupa hoida, on olemas põhjalikum käsitlus kuidas ülesehitatakse lineage ilma tööriistata, kui allikas on tabel.
Iga sammu käsitsi jäädvustamine allika ja raporti vahel on teostatav piiratud arvu andmepunktide ja tabelite puhul. Suurema arvu asukohtade, allikate või raporteerimistsüklite puhul muutub iga töötluse jälgimine ülesandeks, mis nõuab palju aega ja on tundlik samade vigade suhtes, mida lineage peaks just paljastama. Sellel hetkel, kui see piir silmapiirile ilmub, on kasulik teada, milline osa sellest jäädvustavast töö saab korduda kindla reegli järgi ja on seega AI poolt üle võetav, ning milline osa jääb nõudma hinnangut. FTE TO AI töö-skaneering arvutab selle ülesande kaupa välja, nii et selgub, kus käsitsi töö veel sobib ja kus kordumine nõuab midagi teistsugust.
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.