Raport nie jest przeciwieństwem Business Intelligence. Może być jednym z jego rezultatów. BI obejmuje szerszy proces: zebranie i przygotowanie danych, ich analizę, prezentację oraz wykorzystanie w decyzjach. Sam fakt, że raport ma filtry i kolorowe wykresy, nie rozstrzyga jeszcze o jakości tego procesu.
Dokumentacja Microsoft opisuje raporty Power BI jako interaktywne widoki oparte na modelu danych. Można w nich przechodzić od podsumowania do szczegółów. To dobry przykład tego, dlaczego podział „statyczny raport albo BI” bywa zbyt prosty. Również arkusz może posłużyć do wartościowej analizy, jeśli pozwala sprawdzić właściwe pytanie.
Najpierw wynik, potem właściwy mianownik
Wyobraźmy sobie fikcyjną firmę dostarczającą paczki. Własny przykład liczbowy: w jednym miesiącu miała 50 opóźnionych dostaw na 500, w kolejnym 80 na 1000. Raport liczby opóźnień pokaże wzrost z 50 do 80. Raport ich udziału pokaże spadek z 10% do 8%. Oba wyniki są poprawne i opisują coś innego.
Jeżeli firma pyta o ryzyko opóźnienia pojedynczej dostawy, istotny jest udział. Jeśli planuje liczbę interwencji zespołu obsługi, ważna może być również liczba przypadków. Analiza zaczyna się od wyjaśnienia, której decyzji służy wskaźnik. Większa liczba opóźnień nie musi oznaczać pogorszenia odsetka terminowych realizacji.
Ogólna poprawa może ukryć konkretny problem
Rozbijmy drugi miesiąc na dwie umowne trasy:
- Trasa A: 700 dostaw, 28 opóźnień — 4%.
- Trasa B: 300 dostaw, 52 opóźnienia — około 17,3%.
Łączny wynik nadal wynosi 80 na 1000, czyli 8%. Dla osoby zarządzającej trasą B wynik całej firmy nie wystarcza. Trzeba sprawdzić między innymi dzień tygodnia, godzinę odbioru lub etap, na którym znika zapas czasu. To kolejne pytania do tego samego zbioru, a nie osobny wykres tworzony wyłącznie dla wyglądu panelu.
Przekroje pomagają znaleźć grupę wymagającą uwagi. Nie wskazują automatycznie przyczyny. Związek opóźnień z konkretnym przewoźnikiem może wynikać również z tego, że obsługuje on trudniejszą trasę. Przed zmianą współpracy trzeba porównać warunki, a nie tylko nazwę firmy w tabeli.
Hipoteza potrzebuje danych, których czasem nie ma
Załóżmy, że zespół podejrzewa zbyt późne przekazywanie paczek na trasę B. Jeżeli system przechowuje tylko planowany termin i datę doręczenia, nie da się na tej podstawie potwierdzić godziny rzeczywistego przekazania. BI nie odtworzy zdarzenia, którego nigdzie nie zarejestrowano.
W tej sytuacji wynikiem analizy jest także wskazanie brakującej informacji. Można ustalić sposób jej zbierania i dopiero później sprawdzać hipotezę. Nie należy zastępować brakujących godzin domyślną wartością i przedstawiać tak powstałego wykresu jako dowodu.
Kiedy pojedyncze zestawienie wystarczy?
Stały raport będzie wystarczający, gdy pytanie jest jednoznaczne, dane pochodzą z uzgodnionego źródła, a odbiorca potrzebuje regularnej odpowiedzi w tym samym układzie. Rozbudowany proces analityczny staje się przydatny, gdy pytania zmieniają się, trzeba łączyć informacje i wracać do szczegółów bez każdorazowego składania plików.
W przykładowej firmie działaniem mogłaby być zmiana organizacji odbioru na trasie B. Potem trzeba porównać rezultat w zbliżonych warunkach i obserwować także liczbę dostaw. Szczegóły wiarygodnego przygotowania danych opisuje poradnik o systemie Business Intelligence. Wybór narzędzia ma sens dopiero wtedy, gdy wiadomo, jakie pytania mają prowadzić do jakich działań.
Firma, trasy i wszystkie liczby w przykładzie są fikcyjne.
