Dziennik zdarzeń rejestruje, kto otworzył plik i kiedy. Jest to przydatne, ale nie odpowiada na pytanie, które przy danych dotyczących zrównoważonego rozwoju pada najczęściej: jak ta liczba powstała. Przy arkuszu kalkulacyjnym jako źródle różnica ta jest większa niż przy systemie, ponieważ arkusz kalkulacyjny nie wymusza żadnej stałej struktury. Każdy może zmienić formułę, dodać wiersz lub zmienić jednostkę, bez pozostawienia śladu wykraczającego poza nazwę pliku z datą.
Dziennik zdarzeń informuje, że plik "Scope1_2023_v4.xlsx" został zapisany w określonym dniu. Nie informuje, która komórka została zmieniona, z jakiego powodu, i czy ta zmiana była korektą czy nowym założeniem. Przy danych dotyczących zrównoważonego rozwoju to rozróżnienie ma znaczenie, ponieważ liczba często przechodzi przez wiele rąk, zanim znajdzie się w raporcie. Kto może wykazać, co się wydarzyło między źródłem a raportem, może również wykazać, dlaczego liczba jest taka, jaka jest. Kto tego nie może, ma tylko wynik, a nie drogę do niego.
Między surowymi danymi w arkuszu kalkulacyjnym a liczbą w raporcie zwykle znajduje się kilka operacji: jednostka jest przeliczana, okres jest scalany, wartość odstająca jest korygowana, wynik z jednej zakładki jest dodawany do wyniku z innej zakładki. Każdy krok jest momentem, w którym przyjmowane jest jakieś założenie. Które operacje między źródłem a raportem dokładnie mają miejsce, różni się w zależności od punktu danych i organizacji, ale same kroki są rzadko unikalne. Powtarzają się przy praktycznie każdej liczbie, która jest zestawiana z wielu źródeł.
Audit trail, który pokazuje tylko wynik końcowy i ostatnią datę zmiany, całkowicie umyka tym krokom pośrednim. Aby móc odtworzyć historię liczby, musi być zarejestrowane, jaka operacja została zastosowana w jakim momencie, z jakimi danymi wejściowymi i przez kogo. To inna forma rejestrowania niż ta, którą oferuje dziennik zdarzeń: to mapowanie source-to-report, w którym punktem wyjścia nie jest plik, a punkt danych.
Jedną z operacji, która pozostaje najbardziej niedoceniana, jest agregacja: sumowanie liczb z różnych źródeł, działów lub okresów do jednej liczby. Agregacja odczuwana jest jako krok techniczny, ale zawiera często wybory merytoryczne: które jednostki są ujednolicane, które okresy są uwzględniane, które wyjątki są traktowane osobno. Sposób, w jaki rejestrujecie agregację, decyduje o tym, czy ktoś może później odtworzyć, dlaczego suma jest taka, jaka jest, czy suma pozostaje czarną skrzynką, którą wyjaśnić może tylko jej twórca — a wyjaśnienie to nie jest trwałe, gdy ta osoba nie jest już dostępna.
Audit trail bez określonej odpowiedzialności rejestruje, co się wydarzyło, ale nie kto za to odpowiada. Przy arkuszach kalkulacyjnych to ryzyko, ponieważ plik może być edytowany przez wiele osób, bez jasności, kto podjął decyzję merytoryczną. Rejestrowanie, kto wykonał operację, to coś innego niż rejestrowanie, kto jest właścicielem definicji punktu danych: jedno rejestruje czynność, drugie ustala, kto może wyjaśnić, dlaczego punkt danych został zdefiniowany w określony sposób. Obie te rzeczy są potrzebne, aby audit trail był użyteczny dla kogoś, kto nie był obecny przy tym procesie.
Dodatkowo istotne jest rozróżnienie między tym, kto wykonuje operację, a tym, kto jest właścicielem procesu, który za nią stoi. Pracownik może być odpowiedzialny za wypełnianie arkusza kalkulacyjnego, podczas gdy ktoś inny odpowiada za proces, w którym ten arkusz jest wykorzystywany. Audit trail, który nie robi tego rozróżnienia, wskazuje na pytanie o ostatnią osobę, która czegoś dotknęła, a nie o osobę, która rzeczywiście może wyjaśnić, dlaczego proces jest zorganizowany w taki sposób.
Możliwe jest rozpoczęcie tego rejestrowania bez zakupu do tego systemu. Zaczyna się to od nazwania operacji, które są stosowane na punkcie danych, zapisania, kto wykonuje który krok, oraz opisania powodu korekty w momencie, kiedy jest dokonywana. Sposób, w jaki budujecie lineage bez narzędzia, gdy źródłem jest arkusz kalkulacyjny, to przede wszystkim kwestia dyscypliny w rejestrowaniu, nie oprogramowania. Narzędzie może następnie ten proces wspierać, ale narzędzie nałożone na proces, który niczego nie rejestruje, daje tylko bardziej uporządkowany arkusz kalkulacyjny z tymi samymi niewidocznymi założeniami wewnątrz.
Gdy kroki między źródłem a raportem zostały nazwane i zarejestrowane, powstaje drugie pytanie: kto faktycznie wykonuje te kroki i która ich część jest wystarczająco powtarzalna, aby ją przekazać dalej. Wiele z opisanych tu operacji, takich jak przeliczanie jednostek lub scalanie danych z ustalonych źródeł, to zadania, które można rozłożyć na kroki. [Skan pracy FTE TO AI](https://fte-to-ai.com) wylicza dla każdego zadania, jaką część tej pracy można przekazać AI, na podstawie charakteru zadania, a nie założenia o tym, co automatyzacja może w ogólności.
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.