Egy naplófájl rögzíti, ki nyitott meg egy fájlt és mikor. Ez hasznos, de nem válaszolja meg azt a kérdést, amely a fenntarthatósági adatoknál a leggyakrabban felmerül: hogyan jön létre ez a szám. Egy táblázat mint forrás esetén ez a különbség nagyobb, mint egy rendszer esetén, mert egy táblázat nem kényszerít ki egy fix struktúrát. Bárki megváltoztathat egy formulát, hozzáadhat egy sort vagy módosíthat egy mértékegységet, anélkül hogy ennek bármilyen nyoma maradna a fájlnéven és egy dátumon kívül.
Egy naplófájl azt közli, hogy a "Scope1_2023_v4.xlsx" fájl egy adott napon lett elmentve. Nem közli, melyik cella változott meg, milyen okból, és hogy az adott változás egy javítás volt-e vagy egy új feltételezés. A fenntarthatósági adatok esetén ez a megkülönböztetés releváns, mert egy szám gyakran több kézen megy át, mire egy jelentésbe bekerül. Aki tudja igazolni, mi történt a forrás és a jelentés között, az azt is tudja igazolni, miért olyan egy szám, amilyen. Aki ezt nem tudja igazolni, annak csak egy eredménye van, út nélkül odáig.
A táblázatban lévő nyers adat és a jelentésben szereplő szám között általában több feldolgozási lépés található: egy mértékegységet átszámolnak, egy időszakot összevonnak, egy kiugró értéket kijavítanak, egy tab eredményét hozzáadják egy másik tab eredményéhez. Minden lépés egy olyan pillanat, amikor egy feltételezés születik. Hogy pontosan milyen feldolgozási lépések zajlanak a forrás és a jelentés között, adatponttól és szervezettől függően eltér, de a lépések maguk ritkán egyediek. Csaknem minden számnál visszatérnek, amely több forrásból áll össze.
Egy audit trail, amely csak a végeredményt és az utolsó módosítás dátumát mutatja, teljesen kihagyja ezeket a köztes lépéseket. Ahhoz, hogy egy szám utólag rekonstruálható legyen, rögzíteni kell, milyen feldolgozás történt melyik pillanatban, milyen bemenettel, és ki által. Ez másfajta rögzítés, mint amit egy naplófájl kínál: ez a source-to-report mapping, ahol nem a fájl, hanem az adatpont a kiindulópont.
Egyike azoknak a feldolgozási lépéseknek, amelyek a legkevesebb figyelmet kapják, az aggregáció: különböző forrásokból, osztályokból vagy időszakokból származó számok összeadása egyetlen számmá. Az aggregáció technikai lépésnek tűnik, de gyakran tartalmi döntéseket rejt: mely mértékegységeket egységesítik, mely időszakok számítanak bele, mely kivételeket tartanak külön. Az, hogy hogyan rögzíti az aggregációt, meghatározza, hogy valaki utólag rekonstruálhatja-e, miért olyan az összeg, amilyen, vagy hogy az összeg egy fekete doboz marad, amelyet csak a készítője tud megmagyarázni – és ez a magyarázat nem tartható fenn, amint az illető nem elérhető többé.
Egy audit trail felelősségi kör (eigenaarschap) nélkül rögzíti, mi történt, de nem azt, ki felelős érte. Táblázatok esetén ez kockázatot jelent, mert egy fájlt több ember is szerkeszthet, anélkül hogy egyértelmű lenne, ki hozta meg a tartalmi döntést. Az, hogy rögzítjük, ki hajtott végre egy feldolgozási lépést, más, mint az, hogy rögzítjük, ki birtokolja egy adatpont definícióját: az egyik egy cselekvést rögzít, a másik azt rögzíti, ki tudja megmagyarázni, miért van úgy definiálva egy adatpont, ahogy van. Mindkettő szükséges ahhoz, hogy egy audit trail használható legyen olyan személy számára, aki nem volt jelen a folyamatban.
Ezen felül releváns a megkülönböztetés aközött, ki hajt végre egy feldolgozási lépést, és ki birtokolja az alatta lévő folyamatot. Egy munkatárs felelős lehet egy táblázat kitöltéséért, míg egy másik felelős azért a folyamatért, amelyben az adott táblázatot használják. Egy audit trail, amely nem tesz különbséget e között, egy kérdés esetén az utolsó személyre mutat, aki hozzáért valamihez, nem arra, aki valóban meg tudja magyarázni, miért van úgy kialakítva a folyamat.
Lehetséges elkezdeni ezt a rögzítést anélkül, hogy erre egy rendszert vásárolnának. Ez azzal kezdődik, hogy megnevezik azokat a feldolgozási lépéseket, amelyeket egy adatponton végrehajtanak, rögzítik, ki hajt végre melyik lépést, és leírják egy javítás mögötti okot abban a pillanatban, amikor az megtörténik. Az, hogy hogyan épít fel lineage-t eszköz nélkül, ha a forrás egy táblázat, mindenekelőtt fegyelem kérdése a rögzítésben, nem szoftveré. Egy eszköz ezt a folyamatot utána támogathatja, de egy eszköz egy olyan folyamat felett, amely semmit nem rögzít, csak egy rendezettebb táblázatot eredményez, benne ugyanazokkal a láthatatlan feltételezésekkel.
Amint a forrás és a jelentés közötti lépéseket megnevezték és rögzítették, felmerül egy második kérdés: ki hajtja végre valójában ezeket a lépéseket, és melyik részük eléggé ismételhető ahhoz, hogy átadható legyen. Az itt leírt feldolgozási lépések nagy része, mint a mértékegységek átszámolása vagy adatok összevonása fix forrásokból, olyan feladat, amely lépésekre bontható. Az [FTE TO AI munkaszkennere](https://fte-to-ai.com) feladatonként kiszámítja, hogy az adott munka mely része vehető át AI által, a feladat jellege alapján, nem pedig egy általános feltételezés alapján arról, mire képes az automatizálás általánosságban.
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.