Jedna fabryka waży odpady na wadze pomostowej. Inna fabryka szacuje ich ilość na podstawie objętości kontenera. Obie podają liczbę dla tej samej pozycji w raporcie. Nikt nie skłamał, nikt nie popełnił błędu. Po prostu nigdy nie zapisano, jaka jest dokładna definicja tego punktu danych, więc każda jednostka wybrała najbardziej logiczną interpretację, jaka była w danym momencie dostępna.
To nie jest wyjątek. To normalny stan organizacji, w której ten sam wskaźnik jest dostarczany przez różne zespoły, z różnymi systemami źródłowymi i różną historią. Pytanie nie brzmi, jak usunąć tę różnicę zanim powstanie. Pytanie brzmi, co z nią zrobić, gdy ją zauważycie.
Krok, który najczęściej jest pomijany, to zapisanie samej definicji gdzieś na piśmie. Nie w głowie kontrolera, który robi to tak od lat, ale w rejestrze: ten punkt danych oznacza to, jest mierzony w ten sposób i te jednostki się liczą albo nie. To, co jest wartością prawidłową w tym zakresie i kto to zauważa, gdy dostarczone dane wykraczają poza ten zakres, opisano na stronie o tym, co jest wartością prawidłową i kto to zauważa, gdy wartość wykracza poza ten zakres. Bez tego zapisu każde zsumowanie danych z różnych jednostek jest sumą rzeczy, które nie są całkiem takie same, zapakowaną w jedną liczbę, która wygląda na jednoznaczną.
To zapisywanie jest właśnie zadaniem Data Readiness Scan: nie napisanie raportu na nowo, ale zbudowanie rejestru punktów danych, w którym dla każdego punktu danych zapisano, co to jest, skąd pochodzi i kto za to odpowiada. Ten rejestr jest miejscem, w którym różnica między jednostkami staje się widoczna, zamiast stać się widoczną dopiero po tym, jak liczba już została zsumowana.
Gdy już zauważycie, że jednostka A i jednostka B rozumieją ten sam punkt danych w inny sposób, istnieją z grubsza trzy ścieżki.
Pierwsza to harmonizacja: wprowadzenie jednej definicji dla całej organizacji, wraz z wszystkimi wynikającymi z tego zmianami w systemach. To często właściwa ścieżka w dłuższej perspektywie, ale nie jest to coś, co można zrealizować z dnia na dzień.
Druga to dokumentowanie i korygowanie: pozostawienie odchylenia tam, gdzie się znajduje, ale zapisanie jego wielkości i zapewnienie za pomocą stałego przelicznika, że suma się zgadza. Działa to, gdy różnica jest stabilna i znana — na przykład gdy jedna lokalizacja stale stosuje inną metodę pomiaru, którą można przeliczyć.
Trzecia to sygnalizowanie: nie korygowanie, ale ustawienie flagi, gdy dostarczone dane odchylają się od wzorca, którego zwykle oczekujecie od tej jednostki. Sposób ustawiania takiego odchylenia sygnałowego i kto otrzymuje o nim powiadomienie, opisano na stronie o tym, jak ustawić odchylenie sygnałowe i kto to zauważa, gdy się wydarzy. Ta ścieżka nie ma na celu rozwiązania problemu, ale zapobieżenie temu, by pozostał niezauważony, podczas gdy pracujecie na rozwiązaniem strukturalnym.
Która ścieżka jest odpowiednia, zależy od tego, jak wiele jednostek się odchyla, jak stabilne jest to odchylenie i jak dużo czasu jest zanim liczba wejdzie do okresu raportowania. To ocena, która różni się w zależności od organizacji i której ten rejestr nie dokona za was — ale sprawia, że widać, że tej oceny trzeba dokonać.
Różnica w definicjach jest jednym z najbardziej niezauważalnych błędów, ponieważ każda jednostka z osobna ma rację. Lokalizacja, która szacuje na podstawie objętości kontenera, nie robi niczego niewłaściwego we własnym procesie. Problem powstaje tylko na poziomie, na którym liczby się łączą, i właśnie tam często nikt nie jest wyznaczony do sprawdzenia, czy leżące u podstaw definicje są w ogóle porównywalne.
To powód, dla którego własność każdego punktu danych jest tak samo istotna jak sama definicja. Jakie kontrole należą do punktu danych i kto to zauważa, gdy jedna z tych kontroli zostaje pominięta, opisano na stronie o tym, jakie kontrole należą do punktu danych i kto to zauważa, gdy jedna z nich zostaje pominięta. Bez wyznaczonego właściciela pytanie „a kto to właściwie widzi” pozostaje bez odpowiedzi, nawet gdy definicja jest zapisana na papierze.
Kuszące jest chęć rozwiązania tego problemu za pomocą systemu, który automatycznie normalizuje dostarczone dane. Ale narzędzie postawione nad zbiorem niezdefiniowanych punktów danych niczego nie normalizuje — pakuje te same różnice w bardziej uporządkowany interfejs. Kolejność, która się utrzymuje, to najpierw zapisanie definicji i własności, a dopiero potem sprawdzenie, jaki system do tego pasuje. Dlaczego ta kolejność nie jest przypadkowa, opisano na stronie o tym, czy najpierw kupić narzędzie, czy najpierw ustalić proces.
Gdy dla każdego punktu danych ustalone jest, jaka jest definicja, kto jest właścicielem i jakie odchylenia są sygnalizowane, powstaje inny rodzaj pytania: kto później wykonuje pracę związaną z tymi kontrolami — przeliczanie, dopytywanie jednostki, która się odchyla, prowadzenie samego rejestru. Część tej pracy jest wystarczająco powtarzalna, by przekazać ją do automatycznego kroku, część wymaga oceny, która pozostaje przy człowieku. Skan pracy FTE TO AI wylicza dla każdego zadania, jaka jego część może zostać przejęta przez AI, na podstawie tego samego rodzaju konkretności, co ten rejestr: nie pytania, czy automatyzacja jest możliwa, ale które części którego zadania się do niej kwalifikują.
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.