Duża część danych dotyczących zrównoważonego rozwoju nie pochodzi z systemu ze stałymi polami i stałymi jednostkami, lecz z arkusza kalkulacyjnego opracowanego przez pracownika. Zużycie energii w kWh obok litrów paliwa, dane o odpadach dla różnych lokalizacji w różnych jednostkach, liczba pracowników zliczana na różne daty referencyjne. Zanim taka liczba trafi do raportu, jest znormalizowana: przeliczona na wspólną jednostkę, skorygowana pod względem okresu, zagregowana do poziomu organizacji. Ta normalizacja odbywa się często w tym samym arkuszu, za pomocą formuły, którą nikt poza autorem nie zna.
Problemem nie jest to, że normalizacja się odbywa. Problemem jest to, że ten krok jest niewidoczny. Formuła w komórce pokazuje wynik, nie założenie, które za nim stoi. Jeśli ktoś inny otworzy plik, widzi liczbę, nie rozumowanie.
Między surowym arkuszem kalkulacyjnym a opublikowaną liczbą znajduje się zazwyczaj kilka kroków: przeliczanie jednostek, szacowanie lub pomijanie brakujących wartości, sumowanie danych z kilku lokalizacji, zastosowanie współczynnika korekcyjnego dla znanego odchylenia. Każdy krok zmienia liczbę, i każdy krok jest wyborem. Jaki współczynnik przeliczeniowy został użyty, za jaki okres zsumowano dane, dlaczego wartość odstająca została uwzględniona lub nie. Bez rejestracji te wybory istnieją tylko w głowie osoby, która stworzyła arkusz. Przegląd jakie operacje znajdują się między źródłem a raportem pokazuje, że normalizacja rzadko jest jednym krokiem, a raczej łańcuchem, w którym każde ogniwo musi być możliwe do sprawdzenia osobno.
Rejestrowanie normalizacji nie jest tym samym, co napisanie objaśnienia po zakończeniu raportu. Chodzi o moment, w którym operacja się odbywa: jaka formuła, z jakimi parametrami, zastosowana do jakiej surowej wartości. To jest różnica między śladem audytowym a dziennikiem zdarzeń. Dziennik rejestruje, że coś się wydarzyło; ślad audytowy wyjaśnia, co się wydarzyło i dlaczego ta operacja była wtedy właściwa. To rozróżnienie zostało opisane w dlaczego ślad audytowy to więcej niż dziennik zdarzeń, gdy źródłem jest arkusz kalkulacyjny. Kto dokumentuje normalizację tylko po fakcie, ryzykuje, że oryginalny wybór nie da się już zrekonstruować, zwłaszcza jeśli autor arkusza objął inną funkcję lub opuścił organizację.
Często słyszanym założeniem jest, że lineage — śledzenie liczby od źródła do raportu — wymaga systemu, który automatycznie to rejestruje. To nie jest konieczne. Także gdy źródłem są arkusze kalkulacyjne, można dla każdego punktu danych zarejestrować, jaka wartość źródłowa została użyta, jaka operacja została na niej zastosowana i kto tę operację zatwierdził. To wymaga dyscypliny, nie oprogramowania. Jak to wygląda w praktyce, opisano w jak tworzy się lineage bez narzędzia, gdy źródłem jest arkusz kalkulacyjny. Kluczowa jest stała struktura: dla każdego punktu danych tabela źródłowa, zastosowana formuła oraz odniesienie do osoby, która tę formułę ustaliła. To bardziej format niż system, i można go zastosować jeszcze przed rozważaniem jakiegokolwiek narzędzia.
Reguła normalizacji — na przykład współczynnik przeliczeniowy z rodzaju paliwa na ekwiwalent CO2 — jest sama punktem danych, który potrzebuje właściciela. Nie właściciela końcowej liczby, lecz właściciela reguły: kto decyduje, że ten współczynnik jest właściwy, i kto go zmienia, gdy zmienia się norma. Bez tego przypisania odpowiedzialność przesuwa się niejawnie na osobę, która przypadkiem zbudowała arkusz. Pytanie kto jest właścicielem definicji punktu danych dotyka właśnie tego: definicja i reguła obliczeniowa potrzebują właściciela niezależnego od osoby wprowadzającej dane. To jeden z elementów mapowania od źródła do raportu, wyjaśnionego w co to jest source-to-report mapping: nie tylko skąd pochodzi liczba, ale również kto jest odpowiedzialny za każdy krok pomiędzy.
Istnieją narzędzia, które automatyzują normalizację i pokazują lineage. Te narzędzia niczego nie rozwiązują, jeśli proces poniżej nie jest odpowiednio zorganizowany: jeśli nikt nie zapisał, jaka reguła obowiązuje dla jakiego punktu danych, narzędzie tylko szybciej pokazuje liczbę, której pochodzenie wciąż jest niejasne. Najpierw proces, potem narzędzie. Kto decyduje o tej organizacji, to pytanie wykraczające poza samą normalizację; jest ono omawiane w kto jest właścicielem procesu poniżej.
Gdy już jasne jest, jakie kroki normalizacji istnieją, kto je wykonuje i na podstawie jakiej reguły, powstaje drugie pytanie: jaka część tej ręcznej pracy w arkuszu kalkulacyjnym może zostać przekazana AI. Skan pracy FTE TO AI wylicza dla każdego zadania, jaka jego część może zostać przejęta, i jest użyteczny od momentu, w którym kroki normalizacji zostały opisane jako osobne, rozpoznawalne zadania, a nie ukryte w formule.
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.