Większość danych dotyczących zrównoważonego rozwoju nie zaczyna się w systemie z audit trail. Zaczyna się w arkuszu kalkulacyjnym prowadzonym przez kogoś z działu facility, w eksporcie od dostawcy energii przepisywanym ręcznie, albo w zakładce wypełnianej trzy razy w roku przez innego współpracownika. To nie jest problem, który rozwiązuje narzędzie. To kwestia rejestrowania tego, co dzieje się między tym arkuszem a liczbą w raporcie, z oprogramowaniem lub bez niego.
Lineage to nic innego niż odpowiedź na pytanie: skąd pochodzi ta liczba i co się z nią po drodze zrobiło. W zautomatyzowanym systemie część tego rejestruje oprogramowanie. Przy arkuszu kalkulacyjnym nikt nie robi tego automatycznie, więc musi to nastąpić ręcznie. To nie znaczy, że jest to bardziej skomplikowane, tylko że musi być wyraźne. W przypadku tego, co dokładnie oznacza mapowanie source-to-report obowiązuje ta sama logika przy arkuszu kalkulacyjnym jak przy systemie ERP: każdy krok między źródłem a liczbą w raporcie zostaje nazwany, nawet jeśli ten krok polega na ręcznym obliczeniu w komórce.
Między surowym arkuszem kalkulacyjnym a liczbą podaną w raporcie znajduje się zwykle kilka operacji. Surowa faktura za energię zostaje przeliczona na zużycie w danym okresie. To zużycie zostaje pomnożone przez współczynnik emisji. Wynik zostaje zsumowany z liczbami z innych lokalizacji. Gdzieś przelicza się jednostkę, wpisuje szacunkową wartość za brakujący miesiąc albo wprowadza korektę, bo wcześniejszy wpis okazał się błędny. Każdy z tych kroków jest operacją zmieniającą liczbę, i jakie operacje znajdują się między źródłem a raportem to właśnie to, co musi zostać zarejestrowane, zanim ktoś będzie mógł skontrolować tę liczbę.
Przy arkuszu kalkulacyjnym ryzyko polega na tym, że te kroki są skryte w formułach, których już nikt nie sprawdza. Komórka zawiera obliczenie ustalone trzy lata temu przez kogoś, kto obecnie pełni inną funkcję. Nikt już nie wie, dlaczego formuła jest tak zbudowana, i nikt nie odważy się jej zmienić. To nie jest problem lineage, który zniknie po zakupie narzędzia. Problem tkwi w braku zapisanego opisu tego, co ta formuła robi, niezależnie od systemu, w którym się znajduje.
Dwie operacje występują praktycznie zawsze i zasługują na osobną uwagę. Pierwsza to agregacja: liczby z kilku lokalizacji, działów lub okresów zostają zsumowane w jedną liczbę. To, jak rejestrowana jest agregacja, decyduje o tym, czy ktoś może później sprawdzić, które źródła zostały uwzględnione, a które nie. W arkuszu kalkulacyjnym agregacja odbywa się często za pomocą prostej formuły SUMA obejmującej szereg zakładek, ale pytanie, które zakładki są w niej zawarte i które zostały świadomie wyłączone, rzadko jest gdzieś opisane.
Druga to normalizacja: liczby z różnych źródeł zostają uczynione porównywalnymi, na przykład poprzez przeliczenie jednostek albo dopasowanie różnych okresów raportowania do siebie. To, jak rejestrowana jest normalizacja, jest tak samo istotne przy procesie ręcznym jak przy zautomatyzowanym systemie. Arkusz kalkulacyjny z kolumnami w różnych jednostkach, w którym przeliczenie zostało gdzieś w połowie wkomponowane w formułę, jest krokiem normalizacji, którego nikt jako takiego nie rozpozna, aż zostanie o niego zadane pytanie.
Rejestrowanie kroków między źródłem a raportem ma niewielką wartość, jeśli nikt nie wie, kto jest odpowiedzialny za poprawność każdego kroku. Należą do tego dwa pytania. Pierwsze to kto jest właścicielem definicji danego punktu danych: kto określa, co dokładnie rozumie się przez daną liczbę, i z kim się konsultuje, gdy ta definicja się zmienia. Drugie to kto jest właścicielem leżącego pod nią procesu: kto jest odpowiedzialny za sam arkusz kalkulacyjny, za jego prowadzenie i za zgłaszanie sytuacji, gdy źródło się zmienia lub przestaje istnieć.
Bez tych dwóch odpowiedzi lineage pozostaje jednorazowym zdjęciem sytuacji. Ktoś dziś zapisuje, jak liczba jest obliczana, ale sześć miesięcy później arkusz się zmienia, odpowiedzialny pracownik zmienia stanowisko albo zakładka zostaje zastąpiona nowym eksportem z inną kolejnością kolumn. Jeśli własność nie została przypisana, nikt nie zauważy, że lineage już nie odpowiada rzeczywistości.
Narzędzie nałożone na niezorganizowany proces rejestruje te same niejasności, tylko w bardziej uporządkowanym interfejsie. Jeśli nikt nie wie, jakie operacje znajdują się między źródłem a raportem, kto jest właścicielem definicji i kto zarządza leżącym pod nią procesem, to automatyzacja przynosi przede wszystkim szybszą niepewność. Kolejność jest taka: najpierw zapisać kroki, właścicieli i zasady, a dopiero potem sprawdzić, którą ich część można zautomatyzować.
Gdy taki zapis już istnieje, staje się też jasne, którą część pracy ręcznej — przepisywanie faktur, prowadzenie zakładek, przeliczanie formuł — można wsparć za pomocą AI. Kto chce wiedzieć, która część tej pracy się do tego kwalifikuje, może skorzystać z werkscan FTE TO AI. Ta oblicza dla każdego zadania, jaką część pracy AI może przejąć, na podstawie zadań tak, jak są obecnie wykonywane.
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.