Dziennik zdarzeń mówi, że coś się wydarzyło: otwarto plik, zmieniono komórkę, wykonano eksport. To użyteczne, ale nie odpowiada na pytanie, które ma znaczenie w chwili, gdy ktoś kwestionuje liczbę w raporcie zrównoważonego rozwoju: jak dokładnie ta liczba powstała ze źródła i czy ta droga wciąż jest poprawna.
Log systemowy rejestruje działania. Audit trail dla punktu danych uzasadnia wynik. Nie chodzi o to, kto w którym momencie i który przycisk nacisnął, lecz o to, jakie operacje przekształciły wartość źródłową w liczbę, która obecnie znajduje się w raporcie. Bez tego uzasadnienia każda liczba jest twierdzeniem, którego nikt nie może szybko potwierdzić, nawet osoba, która ją dostarczyła.
Między źródłem a raportem zazwyczaj nie ma linii prostej, lecz szereg operacji, a każda operacja jest miejscem, w którym coś może się zmienić bez zauważenia przez kogokolwiek. Chodzi na przykład o przeliczanie jednostek, agregację lokalizacji do poziomu koncernu, korygowanie wartości odstającej, zastosowanie współczynnika emisji. To, jakie konkretnie są te operacje, różni się w zależności od punktu danych i zostało opisane w jakie operacje zachodzą między źródłem a raportem. Kto nie zapisuje tych etapów, widzi tylko punkt startowy i punkt końcowy, i musi przy każdym pytaniu o liczbę odtworzyć całą drogę od nowa, często na podstawie czyjejś pamięci.
Dwie operacje zasługują na szczególną uwagę, ponieważ najczęściej prowadzą do odchyleń. Agregacja sumuje wartości z różnych źródeł do sumy całkowitej, i przy każdym takim sumowaniu musi być jasne, które pozycje zostały uwzględnione, a które nie. Jak wygląda taka dokumentacja, gdy źródłem jest arkusz kalkulacyjny, opisano w jak dokumentować agregację, gdy źródłem jest arkusz kalkulacyjny. Normalizacja przeskalowuje wartości do wspólnej jednostki lub okresu, a niewielki błąd w tym przeskalowaniu przenosi się na każdą liczbę, która na nim później opiera się. Dokumentacja tego procesu została opisana w jak dokumentować normalizację, gdy źródłem jest arkusz kalkulacyjny. Obie operacje są niepozorne w arkuszu kalkulacyjnym i niezbędne w uzasadnieniu.
Wiele danych dotyczących zrównoważonego rozwoju nie zaczyna się w systemie ze stałymi polami i stałymi regułami, lecz w arkuszu kalkulacyjnym, który ktoś zbudował według własnego uznania. Formuła może zostać nadpisana, kolumna przesunięta, etap pośredni mógł istnieć tylko w głowie osoby, która go tworzyła. Co oznacza mapowanie source-to-report, gdy źródłem jest arkusz kalkulacyjny, zostało opisane w co oznacza mapowanie source-to-report, gdy źródłem jest arkusz kalkulacyjny. Istota polega na tym, że mapowanie nie może zależeć od przypadku komórki czy zakładki, lecz musi być dokumentowane odrębnie i w sposób powtarzalny, niezależnie od samego pliku arkusza kalkulacyjnego.
Bez zapisanych etapów droga od źródła do raportu istnieje tylko tak długo, jak długo istnieją i pamiętają ją osoby, które ją przeszły. Gdy coś się zmieni w procesie, przyjdzie nowy współpracownik lub zostanie zadane pytanie po zakończeniu roku raportowego, jedyną opcją jest ponowne odtwarzanie wszystkiego od nowa. To nie jest audit trail, lecz improwizacja po fakcie. Narzędzie nie może rozwiązać tego problemu, jeśli leżący u jego podstaw proces nie został udokumentowany; dostarcza wtedy jedynie bardziej uporządkowany log rekonstrukcji, która jest tak samo niepewna jak wcześniej.
Dokumentowanie pochodzenia i operacji nie musi czekać na oprogramowanie. Jak zbudować lineage bez narzędzia, przy użyciu środków, które już są dostępne, opisano w jak zbudować lineage bez narzędzia. Dla arkuszy kalkulacyjnych jako źródła obowiązują te same zasady, co dla audit trail w ogóle: dokumentacja dotyczy tych samych etapów, zastosowanych do źródła bez stałej struktury, jak opisano w dlaczego audit trail to więcej niż dziennik zdarzeń, gdy źródłem jest arkusz kalkulacyjny. Kto raz przeprowadził tę dokumentację dla jednego punktu danych, może ją powtórzyć dla następnego, i w ten sposób buduje rejestr, który nie zależy od narzędzia, lecz od procesu.
Gdy już wiadomo, jakie etapy przeszła liczba i kto wykonuje którą operację, powstaje inny rodzaj pytania: która część tej pracy jest wystarczająco powtarzalna, aby ją zautomatyzować. Agregowanie według ustalonej reguły, normalizowanie wartości do stałej jednostki, sprawdzanie operacji względem udokumentowanej reguły jakości – to zadania, które można ocenić pod względem możliwości automatyzacji tylko wtedy, gdy istnieją jako odrębne etapy. Skan pracy FTE TO AI wylicza dla każdego zadania, jaką część pracy może przejąć AI, i wymaga do tego właśnie takiego poziomu szczegółowości zadań, jaki daje audit trail.
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.