Egy fenntarthatósági jelentésben szereplő szám csaknem soha nem ugyanaz a szám, mint amely a forrásrendszerben található. Attól a pillanattól, amikor egy munkatárs beír egy energiaszámlát vagy egy szenzor rögzít egy mérőállást, addig a pillanatig, amikor az a szám egy jelentéstáblázatban megjelenik, valami történik. Átszámítás, összeadás, korrekció, más forrásokkal való összevonás. A source-to-report mapping ennek a folyamatnak a rögzítése: minden lépés, amelyen az adat átmegy a forrás és a jelentés között, abban a sorrendben, ahogyan az megtörténik.
Egy számítás eredménye semmit nem mond a megbízhatóságáról, ha senki nem tudja rekonstruálni, hogyan jött létre az eredmény. Egy kibocsátási adat lehet helyes, mert az alapul szolgáló lépések helyesek voltak, vagy csak helyesnek tűnhet, mert egy hiba az egyik lépésben véletlenül kiegyenlített egy másik lépésben lévő hibát. Mapping nélkül ez a különbség nem látható. Mappinggel viszont igen: minden lépés önmagában áll, saját forrással, saját feldolgozással és saját, ellenőrizhető eredménnyel.
Ez a folyamat általában több lépésből áll, mint az emberek gondolnák. A nyers forrásadat és a jelentésben szereplő szám között gyakran több egymást követő feldolgozás is található: mértékegységek átszámítása, értékek összevonása, kivételek kézi korrekciója. Az, hogy milyen feldolgozások vannak a forrás és a jelentés között, adatpontonként eltér, de a felépítés mindig ugyanaz: egymást követő lépések sorozata, amelyek mindegyike hozzáad vagy megváltoztat valamit az adaton, és amelyeket egyenként külön kell rögzíteni, hogy az egész folyamat követhető legyen.
Két típusú feldolgozás érdemel külön figyelmet, mert ezek fordulnak elő a leggyakrabban, és ezek vezetnek be a legkönnyebben észrevétlen hibákat.
Az első az aggregáció: több forrásból vagy több időszakból származó számok összevonása egyetlen számmá. Aki rögzíti, hogy pontosan hogyan zajlik ez az összeadás, mely tételek kerültek bele és melyek nem, az megakadályozza, hogy a jelentésben szereplő szám egy fekete doboz legyen. Az, hogy hogyan rögzíti az aggregációt, meghatározza, hogy valaki utóbb még újra tudja-e követni azt módon, amely visszavezethető marad az alapul szolgáló tételekhez.
A második a normalizálás: a különböző forrásadatok visszavezetése egy közös mértékegységre vagy definícióra, hogy a különböző rendszerekből származó számok összehasonlíthatóvá váljanak. Egy liter gázolaj és egy kilowattóra elektromos áram csak átszámítás után lesz összehasonlítható, és ez az átszámítás feltételezéseket tartalmaz. Az, hogy hogyan rögzíti a normalizálást, azt jelenti, hogy rögzíti, mik ezek a feltételezések, hogy egy másik fél követhesse ugyanazt a feltételezést, vagy vitába szállhasson vele.
Csábító a mappinget összekeverni egy tevékenységnaplóval: egy listával arról, ki mit módosított és mikor. Ez egy alkotórész, de nem az egész. Egy audit trail, amely csak a változásokat rögzíti, nem árulja el, miért alkalmazták az adott feldolgozást, vagy milyen szabály állt mögötte. Az, hogy miért több egy audit trail, mint egy naplókönyv, azzal a kérdéssel függ össze, amelyet minden ellenőr végül feltesz: nem csak azt, mi változott, hanem milyen logika és milyen forrás alapján.
A source-to-report mappinget gyakran összekeverik a szoftverrel. Léteznek eszközök, amelyek automatikusan megmutatják a lineage-t, de ezek az eszközök csak azt rögzítik, ami már strukturáltan lett megadva. Egy szervezet, amely még táblázatokkal és kézi átadásokkal dolgozik, ugyanolyan jól rögzíthetni a folyamatot, csak más eszközökkel: egy állandó dokumentációs formátummal lépésenként, egy állandó hellyel, ahol a forrásfájlokat megőrzik, egy állandó módszerrel a változások feljegyzésére. Az, hogy hogyan lehet ezt eszköz nélkül megszervezni, itt található leírva: hogyan hozható létre lineage eszköz nélkül. A fegyelem nem a szoftverben rejlik, hanem a rögzítés megismételhetőségében.
Ez a fegyelem különösen fontos, amikor a forrás maga is egy táblázat. Egy cella egy munkalapon nem rendelkezik beépített eredettel: senki nem látja automatikusan, ki írt be egy értéket, vagy milyen dokumentum alapján. Az, hogy mit jelent a source-to-report mapping ha a forrás egy táblázat, azt jelenti, hogy ezt az eredetet manuálisan kell megszervezni, ugyanolyan pontossággal, mint egy automatizált rendszer esetében.
A gyakorlatban a mapping egy kérdésre vezethető vissza, amelyet minden egyes adatpontnál meg kell ismételni: honnan származik ez az érték, mi történt vele, mielőtt a jelentésbe került, és ki hajtotta végre vagy hagyta jóvá ezt a lépést. Ezt a kérdést több száz adatpontnál feltenni munkaigényes, és éppen ez teszi kísértővé a kihagyását. De egy jelentés, amely nem visszakövethető alapokon áll, sebezhető marad olyan kérdésekkel szemben, amelyekre senki nem tud választ adni abban a pillanatban, amikor felteszik.
Ezeknek a lépéseknek a feltérképezése, adatpontonként és több forráson keresztül, ismétlődő munka egy állandó struktúrával: forrás azonosítása, feldolgozás leírása, tulajdonos meghatározása, majd ismétlés a következő adatponthoz. Az állandó struktúrával rendelkező munka pontosan az a fajta munka, amelynek egy része AI-val átvehető. Az FTE TO AI munkaszkennere feladatonként kiszámítja, mely rész alkalmas erre, hogy nyilvánvalóvá váljon, hol maradnak szükségesek az emberek az elbírálásra, és hol automatizálható az ismétlődés.
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.