Lineage to nic innego jak droga, jaką przebywa liczba: od miejsca, w którym powstaje, do miejsca, w którym trafia do raportu. Ta droga istnieje także bez narzędzia. Za każdym razem, gdy ktoś przejmuje liczbę z arkusza kalkulacyjnego, dodaje ją do innej liczby, dzieli przez liczbę fte lub przelicza na inną jednostkę, ta osoba pokonuje kawałek lineage — niezależnie od tego, czy zostanie to zapisane, czy nie. Pytanie nie brzmi, czy ta lineage istnieje, lecz czy ktoś potrafi ją odtworzyć bez sięgania po pierwotnego autora.
Punkt danych w raporcie zrównoważonego rozwoju ma niemal zawsze za sobą kilka etapów. Najpierw jest źródło: arkusz kalkulacyjny ze zużyciem energii według lokalizacji, eksport z systemu HR, faktura od dostawcy. Następnie następuje operacja: dodawanie, uśrednianie, przeliczanie na ekwiwalent CO2, powiązanie ze wskaźnikiem emisji. Często następuje agregacja: liczby według lokalizacji stają się liczbami według kraju, liczby miesięczne stają się liczbami rocznymi. Na koniec liczba trafia do raportu, często poprzez jeszcze jedną ostatnią warstwę ręcznego przepisywania lub wklejania.
Aby zrozumieć co oznacza mapowanie source-to-report, gdy źródłem jest arkusz kalkulacyjny, pomocne jest, by nie traktować tych kroków jako jednej całości, lecz jako serię odrębnych czynności, z których każda niesie własne ryzyko błędów. Kto zna tylko początek i koniec podróży, nie może zobaczyć, gdzie po drodze coś poszło nie tak.
Bez zapisu lineage istnieje wyłącznie w głowie osoby, która stworzyła arkusz kalkulacyjny. Gdy ta osoba jest na urlopie, zmienia stanowisko lub odchodzi z organizacji, wiedza o tym, co wydarzyło się między źródłem a raportem, znika. Kontroler, który chce zweryfikować liczbę, musi wtedy zgadywać lub dopytywać. Strona zewnętrzna oceniająca raport musi opierać się na zaufaniu zamiast na dokumentacji.
Operacje znajdujące się między źródłem a raportem stały się często niewidoczne, ponieważ są ukryte w formułach komórek, makrach lub pamięci pracownika. Aby ustalić, jakie operacje znajdują się między źródłem a raportem, gdy źródłem jest arkusz kalkulacyjny, konieczne jest nazwanie osobno każdej formuły, każdego ręcznego kroku i każdego powiązania — nie jako czarnej skrzynki, lecz jako serii odrębnych czynności.
To samo dotyczy dwóch operacji, które najczęściej występują w danych dotyczących zrównoważonego rozwoju: agregacji i normalizacji. Agregacja — sumowanie liczb z wielu źródeł w jeden wynik — wymaga zapisania, które źródła zostały uwzględnione, a które nie, i dlaczego. Kto chce wiedzieć, jak zapisuje się agregację, gdy źródłem jest arkusz kalkulacyjny, natrafia na konieczność udokumentowania dla każdego sumowania, które komórki zostały uwzględnione. Normalizacja — sprowadzanie surowych liczb do porównywalnej jednostki — wiąże się z podobnym problemem: jaki współczynnik przeliczeniowy zastosowano, z jakiego źródła ten współczynnik pochodzi i czy pozostał niezmienny przez cały rok. Dla tych, którzy chcą to zapisać, opisano podejście w jak zapisuje się normalizację, gdy źródłem jest arkusz kalkulacyjny.
Częstym błędem jest myślenie, że dziennik zmian zapewnia wystarczającą lineage. Dziennik pokazuje, kiedy komórka została zmieniona i przez kogo, ale nie dlaczego ta zmiana była potrzebna ani jaka zasada za nią stała. Ślad audytowy, który rejestruje jedynie to, co się wydarzyło, bez leżącej u podstaw logiki, pozostawia te same pytania bez odpowiedzi, co brak dziennika. Dlaczego ślad audytowy musi być czymś więcej niż dziennikiem, gdy źródłem jest arkusz kalkulacyjny, tkwi w różnicy między rejestracją czynności a zapisaniem stojącego za nią powodu.
Bez narzędzia oznacza to w praktyce: dla każdego punktu danych stały dokument lub stała sekcja, w której zapisano, jakie źródło zostało użyte, jakie operacje zastosowano i w jakiej kolejności, kto wykonał daną operację i na podstawie jakiej zasady. Może to być osobny rejestr, pola z komentarzami w samym arkuszu kalkulacyjnym lub odrębny przegląd prowadzony równolegle z procesem raportowania. To więcej pracy niż niezapisywanie niczego i mniej pracy niż wdrażanie narzędzia nad procesem, który tych kroków jeszcze nie zna. Właśnie to jest powodem, by najpierw przejść przez te kroki: narzędzie nałożone na niezorganizowany proces daje jedynie schludniejszy wynik nad tymi samymi nieprzejrzystymi liczbami. Szczegóły tego podejścia, łącznie z formatem, w jakim można prowadzić lineage dla poszczególnych punktów danych, opisano w jak buduje się lineage bez narzędzia, gdy źródłem jest arkusz kalkulacyjny.
Ręczne zapisywanie każdego kroku między źródłem a raportem jest wykonalne przy ograniczonej liczbie punktów danych i arkuszy kalkulacyjnych. Przy większej liczbie lokalizacji, źródeł lub cykli raportowania śledzenie każdej operacji staje się zadaniem, które wymaga dużo czasu i jest podatne na te same błędy, które lineage właśnie ma ujawniać. W momencie, gdy ta granica staje się widoczna, warto wiedzieć, która część tej pracy zapisującej daje się powtarzać według stałej zasady, a więc może zostać przejęta przez AI, a która część nadal wymaga oceny. Skan pracy FTE TO AI wylicza to dla każdego zadania, dzięki czemu jasne staje się, gdzie praca ręczna nadal pasuje, a gdzie powtarzalność wymaga czegoś innego.
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.