Powszechna kolejność jest taka: wybrać narzędzie, skonfigurować narzędzie, a potem liczyć na to, że proces się do niego dostosuje. To w praktyce nie działa, ponieważ narzędzie nie przynosi ze sobą procesu. Narzędzie przynosi pola, integracje, dashboardy — ale nie odpowiedź na pytanie, kto w Państwa organizacji odpowiada za zużycie energii w budynku trzecim, albo czy kierownik obiektu, który dostarcza tę liczbę, wie, że trafi ona do raportu zakresu 2.
Właściwa kolejność jest odwrotna: najpierw opisać proces, a potem wybrać narzędzie na podstawie tego, czego ten proces wymaga. To brzmi jak objazd, ale to najkrótsza droga, ponieważ każde wymaganie funkcjonalne, które stawiają Państwo narzędziu, musi skądś wynikać — z własnej organizacji danych. Bez tego punktu wyjścia wybierają Państwo na podstawie funkcji, które dostawca uważa za ważne, a nie funkcji, które rozwiązują Państwa problem.
Koszty niewłaściwej kolejności nie są widoczne od razu, ponieważ narzędzie, które nie pasuje, na początku działa całkiem dobrze — dla tej części procesu, która przypadkiem odpowiada temu, czego narzędzie oczekuje. Resztę buduje się ręcznie wokół niego: załącznik w Excelu tutaj, wymiana e-maili tam, pracownik, który dokładnie wie, który krok wypada poza system. To działa, aż ten pracownik odejdzie albo skala danych wzrośnie.
To, co to kosztuje, zależy od tego, ile punktów danych działa poza narzędziem i jak często trzeba je ponownie ręcznie zbierać w każdym cyklu raportowania. Przy niewielkiej liczbie punktów jest to akceptowalny objazd. Przy rosnącej liczbie — więcej lokalizacji, więcej kategorii zakresu 3, więcej regulacji, które się dołączają — objazd staje się główną trasą, a Państwo strukturalnie płacą za niedopasowanie między narzędziem i procesem. To inny sposób powiedzenia tego, co znajduje się również na tej stronie: narzędzie nałożone na niezorganizowany proces produkuje bardziej uporządkowane raporty na podstawie tych samych niewiarygodnych liczb.
Wymaganie funkcjonalne jest wymaganiem tylko wtedy, gdy skądś wynika. „Narzędzie musi umieć wyświetlać lineage” nie jest wymaganiem, dopóki nie wiadomo, że Państwa kontroler trzy razy w roku musi ręcznie ustalać, skąd pochodzi liczba. „Narzędzie musi umieć rejestrować własność danych” nie jest wymaganiem, dopóki nie zauważyli Państwo, że punkt danych bez właściciela nie znajduje się na liście działań nikogo.
Dlatego właśnie rejestr punktów danych, lineage source-to-report dla każdego punktu danych oraz przypisanie własności muszą najpierw istnieć, niezależnie od tego, jakie narzędzie w końcu Państwo wybierzą. Gdy te trzy elementy są już spisane — który punkt danych, skąd pochodzi, kto za niego odpowiada — mają Państwo listę wymagań, która nie pochodzi od dostawcy, ale z własnej organizacji. Tę listę wykorzystują Państwo do porównywania narzędzi, nie do wybierania jednego z nich na oślep. Jak podejść do takiego porównania bez żalu, opisano na tej stronie o wyborze narzędzia.
Miejsce, w którym znajdują się dane, różni się znacznie w zależności od sektora, a to również decyduje o tym, które wymagania funkcjonalne są istotne. W firmie budowlanej duża część danych o zrównoważonym rozwoju znajduje się u podwykonawców i na samym placu budowy, jak opisano na tej stronie o źródłach danych w budownictwie; tam wymaganie dotyczące wielu zewnętrznych źródeł na projekt jest prawdopodobnie ważniejsze niż w innych sektorach. W branży instalacyjnej dane są częściej rozproszone pomiędzy zleceniami serwisowymi i rejestracjami materiałów na poziomie projektu, jak można przeczytać na tej stronie o branży instalacyjnej; tam liczy się przede wszystkim to, czy narzędzie potrafi łączyć rozproszone punkty wprowadzania danych bez ręcznej pracy kogokolwiek.
Ogólne pytanie — najpierw zorganizować proces czy najpierw kupić narzędzie — zostało dalej rozwinięte na tej stronie, a kluczowe pytanie tej strony, jakie wymagania dokładnie wynikają z Państwa własnego procesu, zostało podsumowane na tej stronie. Obie strony wychodzą z tego samego punktu: kolejność decyduje, czy wymaganie jest wymaganiem, czy zgadywaniem.
Data Readiness Scan rejestruje rejestr punktów danych, lineage i własność, zanim mowa jest o jakimkolwiek narzędziu. To nie jest narzędzie do raportowania ani rozwiązanie w postaci kwestionariusza — to krok, który określa, co narzędzie właściwie musi umieć dla Państwa organizacji. Bez tego kroku kupują Państwo funkcje; z tym krokiem kupują Państwo rozwiązanie problemu, który mogą Państwo wskazać.
Skan jest w budowie. Kto chce w ten sposób zmapować swój proces przed podjęciem decyzji o wyborze narzędzia, może zapisać się na listę oczekujących i zostanie poinformowany, gdy skan będzie dostępny.
Gdy rejestr punktów danych już istnieje i jasne jest, który punkt danych pochodzi z jakiego źródła i kto za niego odpowiada, powstaje drugie, naturalne pytanie: jaka część pracy wokół tego — zbieranie, kontrolowanie i przenoszenie liczb — jest wciąż pracą ludzką, a jaką część może przejąć system bez spadku wiarygodności. Na to pytanie odpowiada skan pracy FTE TO AI, który dla każdego zadania oblicza, jaką część pracy może przejąć AI. To inny skan niż Data Readiness Scan, i logiczna jego kontynuacja: najpierw wiedzieć, czym są dane i skąd pochodzą, a potem sprawdzić, jaka część ręcznej pracy wokół nich może stać się zbędna.
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.