Liczba w raporcie zrównoważonego rozwoju prawie zawsze ma za sobą pewną podróż. Zaczyna się jako wiersz na fakturze za energię, licznik w systemie produkcyjnym, pole wprowadzania w narzędziu HR. Zanim ta liczba trafi do raportu, jest zliczona, przeliczona, zagregowana i czasami skorygowana. Te kroki pośrednie są rzadko widoczne w końcowym wyniku. Kto patrzy tylko na raport, widzi cyfrę. Kto patrzy na drogę pomiędzy, widzi szereg wyborów.
Między źródłem a raportem znajduje się zwykle ustalona kolejność operacji, nawet jeśli nikt jej nigdy nie zapisał.
Najpierw dane są zbierane: eksportowane z systemu, przepisywane z faktury, kopiowane z arkusza kalkulacyjnego. Potem są normalizowane: litry stają się metrami sześciennymi, kilowatogodziny stają się gigadżulami, lokalna waluta staje się stałą jednostką rozliczeniową. Następnie są przypisywane do kategorii lub zakresu (scope), co jest wyborem, a nie automatyzmem. Potem następuje agregacja: liczby z lokalizacji, miesięcy lub działów są łączone w roczną sumę. Po drodze zdarzają się korekty, z powodu podwójnego liczenia, brakujących miesięcy, błędnej jednostki, którą ktoś zauważył rok temu i ręcznie poprawił.
Każdy krok jest miejscem, w którym przyjmuje się jakieś założenie. Wybierany jest współczynnik emisji. Szacunek zastępuje brakujący pomiar. Stosowane jest zaokrąglenie. Samo w sobie nic z tego nie jest problemem. Problem powstaje, gdy nikt już nie wie, jakie założenie zostało przyjęte, przez kogo i dlaczego.
Liczba w raporcie, której nie można wyśledzić do jej źródła, jest liczbą jedynie twierdzoną. Gdy tylko kontroler, audytor lub organ nadzorczy zapyta, jak liczba została zbudowana, odpowiedź musi być czymś więcej niż „to jest w systemie”. Odpowiedź musi być w stanie wskazać trasę: to źródło, to przeliczenie, ta agregacja, ta korekta.
Udokumentowanie tej trasy ma trzy bezpośrednie konsekwencje. Po pierwsze, wykrywanie błędów staje się pracą na minuty, a nie na dni, ponieważ jasne jest, gdzie zastosowano przeliczenie, a gdzie nie. Po drugie, możliwe staje się przekazanie: jeśli osoba zarządzająca arkuszem kalkulacyjnym odchodzi, wiedza o operacjach nie odchodzi razem z nią. Po trzecie, powstaje podstawa do weryfikacji, ponieważ strona zewnętrzna może śledzić kroki bez konieczności ich najpierw rekonstruować.
Bez tej dokumentacji każdy cykl raportowania jest powtórką pracy detektywistycznej. Ktoś dzwoni do poprzedniego zarządzającego, szuka w starych e-mailach, zgaduje powód zaokrąglenia. Ta praca jest niewidoczna w samym raporcie, ale to ona decyduje o tym, ile zaufania ten raport zasługuje.
Nie każda operacja wymaga tego samego podejścia. Agregacja, w której liczby z wielu źródeł są łączone w jedną sumę, wymaga innej dokumentacji niż normalizacja, w której jednostki i definicje są ujednolicane. Kto chce wiedzieć, jak precyzyjnie dokumentować agregację, znajdzie to w wyjaśnieniu dotyczącym dokumentowania kroków agregacji, a kto zastanawia się, jak podejść do normalizacji, przeczyta o tym w opisie dokumentowania normalizacji. Obie są częścią tego samego łańcucha, ale pytania, które wywołują, są różne: agregacja wywołuje pytania o kompletność, normalizacja o spójność.
Sytuacja zmienia się również, gdy samo źródło nie jest systemem, a arkuszem kalkulacyjnym. Wtedy nie ma automatycznego eksportu, dziennika systemowego, ustalonej struktury, i dokumentację trzeba zbudować inaczej. Kto ma do czynienia z taką sytuacją, znajdzie punkty odniesienia w wyjaśnieniu dotyczącym mapowania source-to-report, gdy źródłem jest arkusz kalkulacyjny oraz w przeglądzie operacji między źródłem a raportem specyficznie dla źródeł w postaci arkuszy kalkulacyjnych. Dla tych, którzy nie mają budżetu na narzędzie i muszą zbudować lineage przy pomocy środków, które już mają, jest sposób postępowania, by stworzyć lineage bez specjalistycznego oprogramowania.
Dokumentowanie operacji jest często mylone z dziennikiem: listą tego, kto co i kiedy zmienił. To część historii, ale nie całość. Ścieżka audytu, która rejestruje tylko zmiany, nie mówi, dlaczego dokonano wyboru lub jaka reguła została zastosowana. Różnica między dziennikiem a prawdziwą strukturą odpowiedzialności jest wyjaśniona w rozważaniu o tym, dlaczego ścieżka audytu musi być czymś więcej niż dziennikiem.
Data Readiness Scan mapuje tę trasę: które źródło zasila który punkt danych, jakie operacje znajdują się między nimi, kto jest właścicielem każdego kroku i jaka reguła jakości mu odpowiada. To nie jest raport ani kwestionariusz, lecz struktura leżąca u podstaw, która czyni obie te rzeczy wiarygodnymi.
Gdy operacje między źródłem a raportem zostaną opisane, widoczne staje się, które kroki są stałą pracą manualną: przepisywanie faktury, stosowanie stałego współczynnika przeliczeniowego, łączenie miesięcznych liczb według stałej reguły. To właśnie ten rodzaj pracy, dla którego można obliczyć, jaka jej część może zostać przejęta przez AI, bez utraty funkcji dokumentacji od źródła do raportu. FTE TO AI wylicza dla każdego zadania, jaka jego część jest przenośna, na podstawie skanu pracy, który ujawnia tę różnicę dla każdego zadania.
Data Readiness Scan jest w fazie rozwoju. Kto chce, aby operacje między źródłem a raportem zostały udokumentowane, gdy skan będzie już dostępny, może zapisać się na listę oczekujących.
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.