Arkusz kalkulacyjny wydaje się prostym źródłem. Komórka z liczbą, zakładka z nazwą, wklejony eksport z innego systemu. Ale między tą komórką a liczbą, która ostatecznie trafia do raportu, znajduje się seria operacji, która zazwyczaj nigdzie nie jest udokumentowana. Mapowanie source-to-report to odwzorowanie tej serii: każdego kroku, który przechodzi liczba od momentu, gdy wchodzi do arkusza, do momentu, gdy trafia do wiersza raportu.
W przypadku systemu ze stałymi polami i stałą strukturą często można jeszcze odtworzyć, z jakiego pola co pochodzi. Arkusz kalkulacyjny nie ma takiej struktury z natury. Ktoś dodaje pomocniczą zakładkę do agregacji. Ktoś inny kopiuje kolumnę do innego pliku, aby wykonać przeliczenie. Trzecia osoba wkleja wynik jako wartość do arkusza raportowego, przez co formuła, a wraz z nią ślad, zanika. Nic w tym nie jest błędem w momencie, gdy się dzieje. Problem powstaje rok później, gdy ktoś musi wyjaśnić, skąd pochodzi liczba, a odpowiedzi nie można już odtworzyć.
Mapowanie source-to-report dla źródła w postaci arkusza kalkulacyjnego składa się z kilku rozpoznawalnych kroków, z których każdy wymaga osobnej uwagi.
Pierwszym krokiem jest pochodzenie surowych danych: który plik, która zakładka, która komórka lub zakres komórek, oraz kto je wprowadza lub dostarcza. Bez tego punktu odniesienia nie ma źródła, do którego można by się odwołać.
Drugim krokiem jest jakie operacje znajdują się między źródłem a raportem, gdy źródłem jest arkusz kalkulacyjny. Mowa o jednostkach, które są przeliczane, o filtrach, które wykluczają pewne wiersze, o formułach, które sumują lub przeskalowują wartości. Każda operacja zmienia liczbę, a każda operacja, która nie została udokumentowana, jest krokiem, którego później nie można już zweryfikować.
Trzecim krokiem jest agregacja: wiele wierszy, zakładek lub plików łączonych w jedną liczbę. W przypadku arkusza kalkulacyjnego dzieje się to często ręcznie, poprzez zastosowanie funkcji sumy do zakresu, który ktoś samodzielnie wyznaczył. Sposób wyboru tego zakresu i jego zawartość determinują liczbę w takim samym stopniu jak dane bazowe. Właśnie z tego powodu trzeba ustalić, jak dokumentować agregację, gdy źródłem jest arkusz kalkulacyjny: nie jako formalność, lecz dlatego, że sam etap agregacji jest źródłem błędów, których nikt inny nie widzi.
Czwartym krokiem jest normalizacja: różne jednostki, różne okresy raportowania lub różne lokalizacje sprowadzane do wspólnej podstawy, zanim staną się porównywalne. Również tutaj obowiązuje zasada, że wybór współczynnika przeliczeniowego lub wartości odniesienia determinuje wynik, i że ten wybór musi być możliwy do odtworzenia. Sposób, w jaki to działa, opisano w jak dokumentować normalizację, gdy źródłem jest arkusz kalkulacyjny.
Ostatnim krokiem jest miejsce, w którym liczba się osiada: wiersz raportu, wskaźnik, roczny wynik. Również to przejście musi mieć swój ślad, a nie tylko odniesienie do dokumentu źródłowego.
Łatwo jest pomyśleć, że lista tego, kto co zmienił, jest wystarczająca. To dziennik zmian, a dziennik zmian rejestruje modyfikacje bez pokazywania logiki, która za nimi stoi. Ścieżka audytu, która ma sens, pokazuje nie tylko to, że komórka została zmieniona, ale też dlaczego, na podstawie jakiej reguły i z jakim wynikiem, w sposób umożliwiający odtworzenie pierwotnego źródła. To rozróżnienie jest dalej wyjaśnione w opisie dlaczego ścieżka audytu jest czymś więcej niż dziennikiem zmian, gdy źródłem jest arkusz kalkulacyjny.
Większość organizacji pracujących z arkuszami kalkulacyjnymi nie posiada systemu, który automatycznie śledzi lineage danych. To nie znaczy, że mapowanie jest niemożliwe, oznacza to, że musi się odbywać ręcznie, z dyscypliną zamiast oprogramowania. Jakie kroki są do tego potrzebne i jak proces oparty na arkuszu kalkulacyjnym może stać się mimo to możliwy do odtworzenia, opisano w jak stworzyć lineage bez narzędzia, gdy źródłem jest arkusz kalkulacyjny. Pokrewnym pytaniem, które często jest pomijane, jest kto jest właścicielem definicji danego punktu danych: bez wyznaczonego właściciela definicji znaczenie punktu danych zmienia się w zależności od tego, kto na niego akurat patrzy, a wtedy nawet najlepsze mapowanie ma niewielką wartość.
Narzędzie, które sprawia, że raporty wyglądają lepiej, nie zmienia niczego w wiarygodności liczb, które do niego wchodzą. Jeśli droga od komórki do raportu nie została udokumentowana, narzędzie produkuje jedynie ładniejsze raporty na podstawie tych samych niepewnych liczb. Mapowanie źródła do raportu nie jest więc krokiem następującym po wdrożeniu narzędzia, lecz krokiem, który musi go poprzedzać.
Gdy kroki między źródłem a raportem zostaną spisane, widać również, które z tych kroków są pracą ludzką, a które podlegają stałej, powtarzalnej operacji. To rozróżnienie stanowi podstawę skanu pracy FTE TO AI, który dla każdego zadania wylicza, jaką część pracy można przekazać AI, na podstawie tego, co zostało już udokumentowane na temat operacji, reguł i pochodzenia danych.
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.