Egy szám egy fenntarthatósági jelentésben csaknem mindig egy útvonalat tett meg. Kezdődik egy sorként egy energiaszámlán, egy számlálóként egy gyártási rendszerben, egy beviteli mezőként egy HR-eszközben. Mire a szám a jelentésbe kerül, megszámolták, átszámították, összesítették, és néha korrigálták is. Ezek a közbenső lépések ritkán láthatók a végeredményben. Aki csak a jelentést nézi, egy számot lát. Aki a köztük lévő utat nézi, egy sor döntést lát.
A forrás és a jelentés között rendszerint egy állandó sorrendben zajlanak a feldolgozási lépések, még ha senki soha nem is írta le azokat.
Először adatokat gyűjtenek: exportálnak egy rendszerből, átírnak egy számláról, kimásolnak egy táblázatból. Ezután normalizálják: literekből köbméter lesz, kilowattórából gigajoule, a helyi valutából egy állandó számítási egység. Majd hozzárendelik egy kategóriához vagy scope-hoz, ami egy döntés, nem pedig automatizmus. Ezt követi az aggregálás: a telephelyek, hónapok vagy osztályok adatait éves összeggé vonják össze. Közben korrekciók történnek, dupla számlálások miatt, hiányzó hónapok miatt, egy hibás mértékegység miatt, amit valaki egy évvel korábban észrevett és kézzel javított.
Minden lépés egy olyan pont, ahol egy feltételezést tesznek. Kiválasztanak egy kibocsátási tényezőt. Egy becslés helyettesít egy hiányzó mérést. Egy kerekítést alkalmaznak. Önmagában semmi ezekből nem probléma. A probléma akkor keletkezik, amikor már senki sem tudja, milyen feltételezést tettek, ki tette, és miért.
Egy jelentésben szereplő szám, amely nem vezethető visszavissza a forrásához, egy állított szám. Amint egy controller, könyvvizsgáló vagy felügyeleti szerv megkérdezi, hogyan épült fel egy szám, a válasznak többnek kell lennie, mint hogy "ez a rendszerben van". A válasznak meg kell tudnia mutatni az útvonalat: ez a forrás, ez az átszámítás, ez az aggregálás, ez a korrekció.
Az útvonal rögzítésének három közvetlen következménye van. Először, a hibák felderítése perceket vesz igénybe helyett napokat, mert nyilvánvaló, hol alkalmaztak átszámítást, és hol nem. Másodszor, lehetővé válik az átadás: ha az, aki a táblázatot kezeli, elmegy, a feldolgozási lépésekről szóló tudás nem megy vele. Harmadszor, alap keletkezik az ellenőrzéshez, mert egy külső fél követheti a lépéseket anélkül, hogy előbb rekonstruálnia kellene azokat.
Ennek a rögzítésnek a hiányában minden jelentési ciklus a kutatás megismétlése. Valaki felhívja az előző kezelőt, régi e-maileket keres, kitalálja egy kerekítés okát. Ez a munka a jelentésben magában nem látható, de mégis meghatározza, mennyi bizalmat érdemel az adott jelentés.
Nem minden feldolgozási lépés igényel ugyanolyan megközelítést. Az aggregálás, amelynél több forrás adatait egy összeggé vonják össze, más rögzítést igényel, mint a normalizálás, amelynél az egységeket és definíciókat egyeztetik. Aki tudni akarja, hogyan kell pontosan dokumentálni az aggregálást, azt megtalálja egy magyarázatban az aggregálási lépések rögzítéséről, és aki azt kérdezi, hogyan kezelje a normalizálást, arról olvashat egy leírásban a normalizálás rögzítéséről. Mindkettő ugyanannak a láncnak a része, de a felmerülő kérdések eltérnek: az aggregálás a teljességgel kapcsolatos kérdéseket vet fel, a normalizálás a konzisztenciával kapcsolatosakat.
A helyzet akkor is megváltozik, ha a forrás maga nem egy rendszer, hanem egy táblázat. Ekkor nincs automatikus export, nincs rendszernapló, nincs állandó struktúra, és a rögzítést másképp kell felépíteni. Aki ezzel a helyzettel találkozik, támpontokat talál egy magyarázatban a source-to-report mappingről, amikor a forrás egy táblázat, és egy áttekintésben a forrás és a jelentés közötti feldolgozási lépésekről kifejezetten táblázatforrások esetén. Aki nem rendelkezik költségvetéssel egy eszközre, és a lineage-t a már meglévő eszközökkel kell felépítenie, annak van egy módszer a lineage elkészítésére speciális szoftver nélkül.
A feldolgozási lépések rögzítését gyakran összekeverik egy naplókönyvvel: egy listával arról, ki mit mikor módosított. Ez a történet egy része, de nem az egésze. Egy audit trail, amely csak a módosításokat regisztrálja, nem mondja meg, miért hoztak egy döntést, vagy melyik szabályt alkalmazták. A naplókönyv és egy valódi elszámolási struktúra közötti különbséget kifejti egy áttekintés arról, miért kell egy audit trailnek többnek lennie egy naplókönyvnél.
A Data Readiness Scan feltérképezi ezt az útvonalat: melyik forrás táplálja melyik adatpontot, milyen feldolgozási lépések vannak közöttük, ki a tulajdonosa minden egyes lépésnek, és milyen minőségi szabály tartozik hozzá. Ez nem egy jelentés és nem egy kérdőív, hanem az alapstruktúra, amely mindkettőt megbízhatóvá teszi.
Amint a forrás és a jelentés közötti feldolgozási lépéseket leírták, láthatóvá válik, mely lépések állandó kézi munkát jelentenek: egy számla átírása, egy állandó átszámítási tényező alkalmazása, a havi adatok összesítése egy állandó szabály szerint. Ez pontosan az a fajta munka, amelynél kiszámítható, mekkora rész vehető át AI által, anélkül hogy a forrástól a jelentésig tartó rögzítés elveszítené a funkcióját. A FTE TO AI feladatonként kiszámítja, mekkora rész adható át, a munkaszkennelés alapján, amely ezt a különbséget feladatonként átláthatóvá teszi.
A Data Readiness Scan fejlesztés alatt áll. Aki azt szeretné, hogy a forrás és a jelentés közötti feldolgozási lépéseket rögzítsék, amint a szkennelés elérhető lesz, feliratkozhat a várólistára.
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.