Číslo ve zprávě o udržitelnosti má téměř vždy za sebou určitou cestu. Začíná jako řádek na faktuře za energii, počítadlo ve výrobním systému, vstupní pole v HR nástroji. Než se číslo dostane do výkazu, je spočítáno, přepočítáno, agregováno a někdy opraveno. Tyto mezikroky jsou ve výsledném výstupu málokdy vidět. Kdo se dívá jen na výkaz, vidí číslici. Kdo se dívá na cestu mezi tím, vidí řadu rozhodnutí.
Mezi zdrojem a výkazem se obvykle skrývá pevné pořadí úprav, i když si ho nikdo nikdy nezapsal.
Nejprve se data shromáždí: vyexportují se ze systému, přepíšou se z faktury, zkopírují se z tabulky. Poté se normalizují: litry se převedou na metry krychlové, kilowatthodiny na gigajouly, místní měna na pevnou zúčtovací jednotku. Následně se přiřadí ke kategorii nebo scope, což je rozhodnutí, a ne automatismus. Potom následuje agregace: čísla z poboček, měsíců nebo oddělení se sloučí do ročního součtu. Cestou probíhají opravy – kvůli dvojímu započítání, kvůli chybějícím měsícům, kvůli chybné jednotce, kterou si někdo před rokem všiml a ručně opravil.
Každý krok je místem, kde se dělá nějaký předpoklad. Zvolí se emisní faktor. Chybějící měření nahradí odhad. Použije se zaokrouhlení. Samo o sobě na tom nic nevadí. Problém vzniká, když už nikdo neví, jaký předpoklad byl udělán, kým a proč.
Číslo ve výkazu, které nelze vysledovat k jeho zdroji, je pouze tvrzené číslo. Jakmile se controller, auditor nebo dohledový orgán zeptá, jak je číslo sestaveno, odpověď musí být víc než „to je v systému“. Odpověď musí umět ukázat cestu: tento zdroj, tento přepočet, tato agregace, tato oprava.
Zaznamenání této cesty má tři přímé důsledky. Zaprvé se odhalování chyb zredukuje z práce na dny na práci na minuty, protože je jasné, kde byl přepočet uplatněn a kde ne. Zadruhé se stává možným předání: pokud odejde osoba, která tabulku správuje, znalost o úpravách neodejde s ní. Zatřetí vzniká základ pro prověřování, protože externí strana může kroky sledovat, aniž by je nejprve musela rekonstruovat.
Bez tohoto zaznamenávání je každý reportovací cyklus opakováním pátrání. Někdo volá předchozímu správci, hledá ve starých e-mailech, hádá důvod zaokrouhlení. Tato práce je ve výkazu samotném nevidět, ale právě ona určuje, kolik důvěry si výkaz zaslouží.
Ne každá úprava vyžaduje stejný přístup. Agregace, při které se čísla z více zdrojů slučují do jednoho součtu, vyžaduje jiné zaznamenávání než normalizace, při které se srovnávají jednotky a definice. Kdo chce vědět, jak přesně dokumentovat agregaci, najde to v vysvětlení o zaznamenávání kroků agregace, a kdo se ptá, jak zacházet s normalizací, si to přečte v popisu zaznamenávání normalizace. Obojí je součástí téhož řetězce, ale otázky, které vyvolávají, jsou odlišné: agregace vyvolává otázky o úplnosti, normalizace o konzistenci.
Situace se mění i tehdy, když samotný zdroj není systém, ale tabulka. Pak neexistuje automatický export, žádný systémový log, žádná pevná struktura, a zaznamenávání musí být vystavěno jinak. Kdo se s touto situací potýká, najde vodítka v výkladu o mapování source-to-report, kdy je zdrojem tabulka a v přehledu úprav mezi zdrojem a výkazem konkrétně u zdrojů z tabulek. Pro toho, kdo nemá rozpočet na nástroj a musí vybudovat lineage s prostředky, které už má, je k dispozici postup, jak vytvořit lineage bez specializovaného softwaru.
Zaznamenávání úprav se často zaměňuje s deníkem: seznamem toho, kdo co kdy upravil. To je část příběhu, ale ne celek. Audit trail, který zaznamenává jen změny, nevypovídá o tom, proč bylo rozhodnutí učiněno nebo jaké pravidlo bylo uplatněno. Rozdíl mezi deníkem a skutečnou strukturou pro odpovědnost je rozpracován v pojednání o tom, proč audit trail musí být víc než deník.
Data Readiness Scan mapuje tuto cestu: který zdroj napájí který datový bod, jaké úpravy se mezi nimi odehrávají, kdo je vlastníkem každého kroku a jaké pravidlo kvality k němu patří. Nejde o výkaz ani o dotazník, ale o podkladovou strukturu, díky které jsou oba teprve důvěryhodné.
Jakmile jsou úpravy mezi zdrojem a výkazem popsány, stane se viditelným, které kroky jsou spolehlivě manuální práce: přepisování faktury, uplatňování pevného přepočítacího koeficientu, slučování měsíčních čísel podle pevného pravidla. Právě to je druh práce, u které lze vypočítat, jakou část lze převést na AI, aniž by zaznamenávání od zdroje po výkaz ztratilo svou funkci. FTE TO AI vypočítá pro každou úlohu, jakou její část lze převést, na základě pracovní analýzy, která tento rozdíl u každé úlohy zpřehledňuje.
Data Readiness Scan je ve vývoji. Kdo chce zaznamenat úpravy mezi zdrojem a výkazem, jakmile bude scan k dispozici, se může přihlásit na čekací listinu.
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.