Tabulkový soubor se zdá jako jednoduchý zdroj. Buňka s číslem, záložka s názvem, export z jiného systému, který byl vložen. Ale mezi touto buňkou a číslem, které se nakonec objeví v reportu, leží řada úprav, které většinou nejsou nikde zaznamenané. Source-to-report mapping je zmapování této řady: každý krok, který číslo prochází od okamžiku, kdy vstoupí do tabulkového souboru, až do okamžiku, kdy skončí v řádku reportu.
U systému s pevnými poli a pevnou strukturou se často ještě dá odvodit, které pole odkud pochází. Tabulkový soubor takovou strukturu sám od sebe nemá. Někdo přidá mezilehlou záložku pro agregaci. Někdo jiný zkopíruje sloupec do jiného souboru, aby provedl přepočet. Třetí osoba vloží výsledek jako hodnotu do reportovacího listu, čímž zmizí vzorec a s ním i stopa. Nic z toho není chybné v okamžiku, kdy se to stane. Problém vzniká o rok později, když někdo musí vysvětlit, odkud číslo pochází, a odpověď už není možné zrekonstruovat.
Source-to-report mapping pro zdroj v podobě tabulkového souboru sestává z několika rozpoznatelných kroků, z nichž každý vyžaduje samostatnou pozornost.
Prvním krokem je původ surových dat: který soubor, která záložka, která buňka nebo rozsah buněk, a kdo je zadává nebo dodává. Bez tohoto kotevního bodu není žádný zdroj, na který by bylo možné se odvolat.
Druhým krokem je jaké úpravy leží mezi zdrojem a reportem, pokud je zdrojem tabulkový soubor. Jde například o přepočty jednotek, filtry, které vylučují určité řádky, nebo vzorce, které hodnoty sčítají nebo přepočítávají na jiné měřítko. Každá úprava změní číslo, a každá úprava, která není zaznamenaná, je krok, který se později nedá ověřit.
Třetím krokem je agregace: více řádků, záložek nebo souborů, které se sloučí do jednoho čísla. U tabulkového souboru se to často provádí manuálně, stisknutím funkce sumy nad rozsahem, který si někdo sám vymezil. Způsob, jakým byl tento rozsah zvolen, a co v něm je, ovlivňuje výsledné číslo stejně tak jako podkladová data. Právě proto je třeba zaznamenat jak zaznamenat agregaci, pokud je zdrojem tabulkový soubor: nikoli jako formalitu, ale protože samotný krok agregace je zdrojem chyb, které jinak nikdo nevidí.
Čtvrtým krokem je normalizace: různé jednotky, různá reportovací období nebo různé lokace, které se převedou na společný základ, než jsou vzájemně srovnatelné. I zde platí, že výběr přepočítacího faktoru nebo referenční hodnoty ovlivňuje výsledek, a tento výběr musí být dohledatelný. Jak to funguje, je rozebráno v jak zaznamenat normalizaci, pokud je zdrojem tabulkový soubor.
Posledním krokem je místo, kam číslo doputuje: řádek reportu, indikátor, roční souhrn. I tento přechod musí mít stopu, nikoli jen odkaz na zdrojový dokument.
Je lákavé si myslet, že seznam toho, kdo co upravil, je dostačující. To je log, a log zaznamenává změny bez toho, aby ukazoval logiku, která za nimi stojí. Audit trail, který má smysl, neukazuje jen to, že se buňka změnila, ale také proč, na základě jakého pravidla a s jakým výsledkem dohledatelným až k původnímu zdroji. Tento rozdíl je dále vysvětlen ve výkladu o tom, proč je audit trail víc než log, pokud je zdrojem tabulkový soubor.
Většina organizací, které pracují s tabulkovými soubory, nemá systém, který by automaticky sledoval lineage. To neznamená, že mapping není možný, znamená to, že se musí provádět manuálně, s disciplínou místo softwaru. Jaké kroky jsou k tomu potřebné a jak se proces řízený tabulkovým souborem přesto stane dohledatelným, je popsáno v jak vytvořit lineage bez nástroje, pokud je zdrojem tabulkový soubor. Související otázka, která se často přehlíží, je kdo vlastní definici datového bodu: bez určeného vlastníka definice se význam datového bodu mění podle toho, kdo se na něj v danou chvíli dívá, a pak má i sebelepší mapping malou hodnotu.
Nástroj, který dělá reporty vizuálně hezčí, nic nemění na spolehlivosti čísel, která do nich vstupují. Pokud cesta od buňky k reportu není zaznamenaná, nástroj jen vyprodukuje upravenější reporty o stejně nejistých číslech. Mapping od zdroje k reportu proto není krok, který přichází po nástroji, ale ten, který mu předchází.
Jakmile jsou kroky mezi zdrojem a reportem rozepsané, ukáže se také, které z těchto kroků jsou lidská práce a které následují pevný, opakovatelný postup. Tento rozdíl je základem pro pracovní scan FTE TO AI, který u jednotlivé úlohy vypočítá, jakou část práce lze převzít pomocí AI, na základě toho, co už je zaznamenáno o úpravě, pravidlech a původu dat.
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.