Dobrze znamy ten obrazek. Wdrożenie BI skończone, licencje kupione, w katalogu raportów leży kilkadziesiąt dashboardów. A w poniedziałek rano dyrektor dzwoni do analityka z pytaniem, czy może mu "szybko wyciągnąć liczby do Excela".
Narzędzie rzadko jest tu winne. Kłopot zaczyna się od tego, od czego w ogóle zaczęto projektować.
Ile osób naprawdę korzysta z BI
Liczby są mało pocieszające. Badanie BARC i Eckerson Group z 2022 roku, oparte na ankiecie wśród 214 firm, pokazało, że z narzędzi analitycznych i BI korzysta średnio około 25% pracowników. Autorzy zwracali uwagę, że ten wskaźnik prawie się nie ruszył przez siedem lat, w których BARC go śledził. IBM, powołując się na dane Gartnera, podaje 29%.
Trzeba te liczby czytać ostrożnie. Różne badania mierzą co innego (kto ma dostęp, kto zalogował się w miesiącu, kto aktywnie tworzy raporty), a nowszych niż 2022 rok porównywalnych danych nie znaleźliśmy. Ale kierunek jest czytelny: po dwudziestu latach rozwoju BI większość ludzi w firmach nadal nie sięga po te narzędzia w codziennej pracy.
Krążą też efektowne liczby w rodzaju "70% dashboardów jest nieużywanych". Nie znaleźliśmy ich w pierwotnym źródle, więc nie będziemy ich powtarzać. Wystarczy zajrzeć do logów własnego narzędzia. Wynik zwykle mówi sam za siebie.
Dlaczego dashboardy leżą nieużywane
Z naszych projektów i z literatury wychodzi kilka powtarzalnych przyczyn, zwykle kilka naraz.
Dashboard nie odpowiada na żadną decyzję
Najczęstszy grzech. Raport powstaje, bo "dane są dostępne", a nie dlatego, że ktoś musi coś rozstrzygnąć. Taki ekran pokazuje wszystko po trochu i nic konkretnego nie podpowiada. IBM opisuje to wprost: dashboardy dają migawkę sytuacji, ale zwykle nie mówią, co z nią zrobić.
Za dużo wskaźników
Strona z 40 kafelkami wygląda imponująco na prezentacji dla zarządu. Użytkownik w codziennej pracy nie wie, na który spojrzeć najpierw. Jeśli wszystko jest ważne, to nic nie jest.
Brak zaufania do liczb
Ktoś otwiera dashboard, widzi sprzedaż z zeszłego tygodnia i porównuje ją z raportem finansowym. Różnica wynosi 3%. Od tej chwili ufa już tylko własnemu arkuszowi. Jedno takie zdarzenie wystarczy, żeby ludzie przestali zaglądać.
Różne definicje tego samego wskaźnika
To zwykle źródło poprzedniego problemu. Dział handlowy liczy "aktywnego klienta" od ostatniego zamówienia, finanse od ostatniej faktury, a marketing od ostatniego logowania. Każdy ma rację, każdy ma inny wynik. Praktycy opisują to jako dryf metryk: kolejne raporty budowane osobno rozjeżdżają się w szczegółach (inna kolumna daty, wyłączone zwroty), aż nikt nie wie, której liczbie wierzyć.
Nikt za to nie odpowiada
Dashboard bez właściciela starzeje się szybciej niż mleko. Zmienia się proces, zmienia się struktura bazy, a raport nadal pokazuje stare dane albo przestaje się odświeżać. Gdy nikt nie czuje się jego gospodarzem, nikt go też nie naprawi.
Jak to naprawić: od decyzji do dashboardu
Poniżej proces, który stosujemy w takiej kolejności. Pierwsze dwa kroki zajmują więcej czasu niż budowa samego raportu i to jest w porządku.
- Nazwij decyzję. Zapytaj użytkownika: jaką decyzję podejmujesz, kiedy i co się dzieje, gdy podejmiesz złą? Jeśli odpowiedzi nie ma, raportu nie budujemy.
- Wybierz 3-5 wskaźników, które tę decyzję zmieniają. Dla każdego ustal próg: przy jakiej wartości robisz coś innego niż zwykle. Wskaźnik bez progu to ciekawostka.
- Zdefiniuj metryki raz. Każdy wskaźnik dostaje jedną definicję, jednego właściciela biznesowego i jedno miejsce w modelu danych. O tym niżej.
- Zbuduj najprostszą wersję. Jeden ekran, czytelny bez szkolenia. Zbierz uwagi po tygodniu użytkowania, nie po miesiącu przygotowań.
- Zmierz użycie i ustal rytm przeglądu. Raport, którego nikt nie otwiera przez kwartał, kandyduje do archiwum.
Warstwa semantyczna: jedna definicja, wiele miejsc użycia
Warstwa semantyczna to zwykle prosta rzecz: miejsce między surowymi tabelami a narzędziami raportowymi, w którym metryka jest zdefiniowana jeden raz. Dashboard, arkusz i asystent AI pytają o tę samą wartość i dostają tę samą odpowiedź. Definicja przechowywana w kodzie ma jeszcze jedną zaletę: ma historię zmian, więc wiadomo, kto i kiedy ją zmienił.
Sama warstwa semantyczna niczego jeszcze nie leczy. Widzieliśmy firmy, w których każde narzędzie BI miało własną "uniwersalną" warstwę i problem tylko się przeniósł. Najtrudniejsza część to uzgodnienie definicji między działami. Technologia jest tu drugorzędna.
Metryki wiodące i opóźnione
Przychód za zeszły miesiąc mówi, co już się stało. Nie da się na jego podstawie niczego uratować. Dlatego do każdego wskaźnika opóźnionego warto dołożyć wiodący: liczbę otwartych zapytań ofertowych, poziom zapasów w dniach, odsetek zamówień z opóźnionym potwierdzeniem. To one dają szansę zareagować, zanim wynik się pogorszy.
Alerty zamiast ekranów
Większość ludzi nie chce codziennie patrzeć na dashboard. Chce wiedzieć, kiedy coś wymaga ich uwagi. Alert przychodzący na komunikator czy mail w chwili przekroczenia progu robi więcej niż najładniejszy ekran, którego nikt nie otworzy. Dashboard zostaje wtedy miejscem, do którego wchodzi się po wyjaśnienie, a nie po informację, że w ogóle coś się dzieje.
Przykład z operacji: dyrektor logistyki
Weźmy typową sytuację w firmie dystrybucyjnej. Dyrektor logistyki ma w BI raport "Logistyka: przegląd", 35 wizualizacji: koszty transportu, liczba kursów, wykorzystanie floty, terminowość dostaw, zwroty, magazyny. Otwiera go raz na kwartał, przed spotkaniem z zarządem. Na co dzień dzwoni do kierowników magazynów.
Zaczynamy od pytania o decyzje. Okazuje się, że są trzy powtarzalne. Rano: czy któryś magazyn jest zagrożony brakiem towaru w ciągu 48 godzin, żeby przesunąć zapas lub zamówić dostawę awaryjną. W tygodniu: którzy przewoźnicy regularnie spóźniają się z dostawami, żeby rozmawiać o zmianie warunków. W miesiącu: czy koszt transportu na paletę mieści się w budżecie.
Z 35 wizualizacji zostaje jeden ekran z czterema wskaźnikami. Dla pierwszej decyzji nie ma ekranu wcale: jest alert, który przychodzi, gdy zapas dla danego magazynu spada poniżej progu wyrażonego w dniach sprzedaży. Terminowość przewoźników zyskuje jedną definicję (dostawa w oknie czasowym potwierdzonym w zamówieniu), ustaloną wspólnie z działem zakupów, bo wcześniej obie strony liczyły ją inaczej. Właścicielem raportu zostaje konkretna osoba z operacji, a nie "dział BI".
Nie obiecujemy cudów w liczbach, bo zależą od firmy. Zmienia się natomiast zachowanie: dyrektor przestaje prosić o wyciągi do Excela, bo wie, że liczby są te same, które widzi księgowość.
Jedna rzecz zaskoczyła nas w takich projektach najbardziej: największy opór nie dotyczył technologii, tylko rezygnacji z raportów. Każdy kafelek ma swojego obrońcę, który "kiedyś go potrzebował". Pomaga prosta zasada: nowy wskaźnik wchodzi na ekran tylko wtedy, gdy któryś stary z niego wychodzi. Ekran ma ograniczoną pojemność, tak jak uwaga człowieka, który na niego patrzy. Bez tej zasady po roku wracamy do czterdziestu kafelków i do arkusza w mailu.
Sprzątanie i mierzenie użycia
Ostatnia rzecz, o której firmy zapominają: dashboardy trzeba usuwać. Większość platform BI zapisuje, kto i kiedy otwierał dany raport. Wystarczy raz na kwartał zrobić zestawienie i zadać trzy pytania:
- Które raporty nie były otwarte przez ostatnie 90 dni?
- Kto jest ich właścicielem i czy nadal ich potrzebuje?
- Które raporty pokazują to samo, tylko pod inną nazwą?
Niewykorzystane raporty archiwizujemy, a właściciel ma 30 dni na sprzeciw. To zwykle nikogo nie boli. Za to użytkownik, który wchodzi do przestrzeni z dwunastoma sensownymi raportami zamiast stu dwudziestu, szybciej znajduje to, czego szuka, i częściej wraca.
Warto też mierzyć sam efekt, nie tylko wejścia: ile decyzji podjęto na podstawie raportu, jak często użytkownik wraca w tym samym tygodniu, ile próśb o "wyciąg do Excela" dalej trafia do analityków. Ten ostatni wskaźnik jest chyba najuczciwszy.
Co zrobić w poniedziałek rano
Wybierz jeden dashboard, który w Twojej firmie powinien być najczęściej używany. Sprawdź w logach, kto go otworzył w ostatnim miesiącu. Potem zapytaj dwie z tych osób, jaką decyzję on im ułatwia. Jeśli odpowiedź brzmi "nie wiem", masz punkt wyjścia do przeprojektowania.
W projektach, które prowadzimy, najlepiej sprawdza się zaczynanie od takiej rozmowy, a nie od modelu danych. Jeśli chcesz przejrzeć swoje raporty pod tym kątem, chętnie porozmawiamy.
