Pojawia się obowiązek raportowania, a pierwszą reakcją jest szukanie narzędzia. Dashboard, platforma, moduł do istniejącego oprogramowania. To wydaje się postępem: pojawia się coś nowego, wydawane są pieniądze, jest dostawca, z którym można się konsultować.
Pytanie, które zostaje pominięte, brzmi: skąd narzędzie bierze swoje dane. Narzędzie liczy, wizualizuje i raportuje, ale niczego nie wymyśla. Dane, które do niego wchodzą, pochodzą z tych samych arkuszy kalkulacyjnych, tych samych e-maili do kierownika administracyjnego, tych samych szacunków, które już istniały. Tyle że te dane teraz znajdują się za interfejsem, który wygląda przejrzyście.
Wybór narzędzia zanim wiadomo, jakie dane są dostępne, kto za nie odpowiada i jak wiarygodne one są, oznacza wybór narzędzia na podstawie założeń. Dostawca pyta, jakiej funkcjonalności potrzeba, a odpowiedź opiera się na tym, co się sądzi, że się posiada — nie na tym, jakie punkty danych, źródła i właściciele faktycznie istnieją. Jakie wymagania funkcjonalne wynikają z własnego procesu to pytanie, na które można odpowiedzieć tylko wtedy, gdy proces już istnieje; bez tego fundamentu narzędzie wybiera się na podstawie listy wymagań, którą ułożył ktoś inny, albo która później okazuje się nie zawierać właśnie tego, co było potrzebne.
Odwrotna kolejność — najpierw uporządkować rejestr punktów danych, lineage i własność danych, a dopiero potem wybrać narzędzie — kosztuje na początku więcej czasu. Nie ma dashboardu, na który można wskazać, nie ma postępu, który można zaprezentować na spotkaniu. Ale pytania, które później stawia się narzędziu, opierają się na tym, co faktycznie dzieje się w firmie, a nie na liście przejętej z demonstracji produktu.
Koszty podejścia najpierw-narzędzie nie da się ująć w jednej pozycji, ale można je rozpoznać.
Jest samo narzędzie, które po roku okazuje się nie zawierać tego, co było potrzebne — połączenia z systemem źródłowym, którego nie ma, struktury raportowania, która nie odpowiada sposobowi działania organizacji, modułu, który robi coś, czego nikt nie potrzebował. Jest czas ludzi, którzy musieli wypełnić narzędzie danymi: jeśli rejestru punktów danych nie było, narzędzie zostało wypełnione tymi samymi pojedynczymi eksportami z Excela jak wcześniej, tylko teraz w systemie, który sugeruje, że jest to kontrolowane.
Jest fałszywe poczucie bezpieczeństwa, które jest najkosztowniejsze. Narzędzie z przekonującym dashboardem daje wrażenie, że dane są w porządku. To wrażenie utrzymuje się do momentu procesu weryfikacji, audytora lub pytania rady nadzorczej o pochodzenie liczby. Wtedy okazuje się, że nikt nie może wskazać, kto dostarczył źródło, jakie założenie zostało w nim zastosowane, czy liczba z tego roku została obliczona w ten sam sposób co w roku poprzednim. Narzędzie tego nie wiedziało, bo narzędzie nigdy nie zadało tego pytania — przyjęło to, co zostało wprowadzone.
I jest wymiana. Narzędzie wybrane bez wglądu w proces, który jest pod nim, po pewnym czasie zostaje zamienione na inne narzędzie, z nadzieją, że to zrobi lepiej. Problem przenosi się, ale nie znika: najpierw kupić narzędzie czy najpierw zorganizować proces to dokładnie ten wybór, który przy każdej wymianie stoi na nowo, i który bez odpowiedzi na stronę procesową ponownie wypada w ten sam niewłaściwy sposób.
Jak ciężko waży niewłaściwa kolejność, zależy od tego, gdzie powstają dane. W firmie budowlanej duża część danych o zrównoważonym rozwoju znajduje się u podwykonawców, na placu budowy i w administracji projektów, która nie została stworzona do raportowania — skąd pochodzą dane o zrównoważonym rozwoju w budownictwie określa, jakich połączeń narzędzie właściwie potrzebuje. W branży instalacyjnej dane są rozproszone po zleceniach serwisowych, rejestracjach materiałów i umowach serwisowych, a gdzie znajdują się dane o zrównoważonym rozwoju w branży instalacyjnej pokazuje, że generyczne narzędzie zbudowane dla organizacji biurowej tutaj szybko okazuje się niewystarczające. Narzędzie, które nie znaje tych różnic, nie może ich też rozwiązać — niezależnie od tego, jak dobry jest interfejs. Kto jednak chce najpierw wybrać narzędzie, dobrze zrobi, czytając jak wybrać narzędzie bez żalu w przyszłości, choć istota pozostaje ta sama: narzędzie nie rozwiązuje procesu, którego nie ma.
Kolejność, która pozostaje, nie jest skomplikowana, ale mniej atrakcyjna do zaproponowania: najpierw ustalić, jakie punkty danych istnieją, skąd pochodzą, kto za nie odpowiada i jakie reguły jakości do nich należą. To praca, dla której powstał Data Readiness Scan od CSRDready.net — rejestr punktów danych, lineage source-to-report dla każdego punktu danych, własność i reguły jakości, bez konieczności posiadania jeszcze narzędzia czy formy raportu. Narzędzie jest w budowie; kto już teraz chce się tym zająć, może zapisać się na listę oczekujących.
Gdy rejestr punktów danych już istnieje, pozostaje jeszcze jedno pytanie, którego nie trzeba zadawać dostawcy oprogramowania: jaka część tej pracy — zbieranie, kontrolowanie i powtarzanie tych samych punktów danych — musi pozostać pracą ludzką, a jaką część można przejąć. Do tego stworzono skan pracy FTE TO AI: oblicza on dla każdego zadania, jaką część pracy można przejąć przez AI, na podstawie zadań tak, jak są faktycznie wykonywane w danej organizacji.
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.