Inteligencja Biznesowa – rozdział 3. (ostatni)

Cóż nam się udało na razie wykombinować? W zasadzie prawie wszystko. Mamy procesy ładujące dane z systemów źródłowych do obszaru Staging, mamy czyszczenie danych oraz przekształcenie danych z obszaru Staging do postaci faktów i wymiarów. Pozostało nam jedynie zbudować na ich bazie – raporty. Czyli gwóźdź programu – bowiem dopiero na podstawie raportów możemy stwierdzić, czy to, co pracowicie próbowaliśmy do tej pory uzyskać jest tym, czego tęsknie oczekują użytkownicy końcowi.

W zależności od tego jak bardzo świadomi są użytkownicy końcowi naszego rozwiązania, mamy dwa możliwe podejścia:

1. Tworzymy raporty

2. Nie tworzymy raportów, pozostawiając ten krok użytkownikom.

Aczkolwiek wersja nr 2 wydaje się być nader kusząca, musimy pamiętać, że można z niej skorzystać tylko w przypadku gdy mamy do czynienia z użytkownikami nie tylko dobrze rozumiejącymi dane i procesy w firmie, ale również mającymi solidne przygotowanie techniczne. I nawet wtedy dobrze jest urządzić kilka sesji szkoleniowych żeby mieć pewność, że wszyscy dobrze rozumieją gdzie szukać których danych, które kolumny są najlepsze do używania w roli filtra lub połączenia do innej tabeli i tak dalej.

A jak to wygląda w naszym przypadku?

Pan Stanisław, marchwiolog z dziada pradziada, rozumie bardzo dobrze wszystko co się dzieje w firmie. Jednak nie jest on zbyt lotny w analizie danych komputerowych, co najwyżej umie sobie zrobić prostą tabelkę w Excelu. Pani Krystyna z kolei jest biegła w cyferkach, ale jej wiedza oscyluje bardziej po stronie finansowo-księgowej biznesu. Żadne z nich raczej nie będzie umiało skonstruować sobie raportu. Trzeba zakasać rękawy – i do dzieła.

Pierwsza, podstawowa sprawa: czy potrzebujemy raportów wielowymiarowych?

Raport wielowymiarowy to taki raport, który zaraz po otwarciu pokazuje dane zagregowane do jakiegoś (na ogół najbardziej ogólnego) poziomu – na przykład, całkowita ilość marchwi wydobyta ze wszystkich pól od powstania firmy – a następnie dająca użytkownikowi możliwość dynamicznego „wędrowania” po danych przy użyciu hierarchii wymiarów. Przykład: raport otwiera się i pokazuje, że do tej pory wydobyto 90150 ton marchwi. Użytkownik rozwija wymiar czasu i widzi te same 90150 ton w rozbiciu na lata: 20000 ton w 2008, 30000 ton w 2009 oraz 40150 ton w 2010. Może to sobie następnie porozwijać do poziomu miesięcy i dni. Tak samo, może „zajrzeć” w wymiar Marchew i zobaczyć, że z tych 90150 ton, 88900 ton to były odmiany do sprzedaży, a reszta – eksperymentalne. I może sobie potem sprawdzić ile ton było sprzedanych dla każdej odmiany. Coś jakby tabela przestawna w Excelu.

Oprócz raportów wielowymiarowych możemy jeszcze tworzyć raporty „tradycyjne”, operacyjne, czyli takie, których układ jest niezmienny (tabelka). Są oczywiście i tutaj dostępne filtry, ale nie ma możliwości pokazania użytkownikowi danych zagregowanych na różnych poziomach szczegółowości. Przykład: raport może pokazać wszystkie pozycje z faktu Wykopki, dzięki czemu – po podsumowaniu (na samym dole) – okaże się, że wydobyto 90150 ton – następnie można odfiltrować (zwykle na górze raportu, powyżej nagłówków kolumn) pojedynczy rok – sprawdzić, że w 2008. wydobyto 20000, potem odfiltrować 2009. i sprawdzić, że było 30000 – ale nie ma tu możliwości pokazania równocześnie danych sumarycznych za marzec 2010 i kwiecień 2009 (co jest jak najbardziej możliwe na raporcie wielowymiarowym).

Czy to oznacza, że raport operacyjny jest gorszy? Nie! On jest po prostu do innych zastosowań. Na ogół przy małej skali działalności wystarczają raporty operacyjne, a przy wzroście ilości danych dochodzi potrzeba raportowania wielowymiarowego. Ponadto, raporty operacyjne są na ogół potrzebne na niższych szczeblach hierarchii firmowej, a analityczne – na wyższych.

Spróbujmy teraz skonstruować raport udzielający wyczerpującej odpowiedzi na pytanie, jakie pan Stanisław postawił sobie w pierwszym rozdziale: czy jest jakaś zależność między długością marchwi a zyskiem, dla odmiany M17?

Pierwszym problemem, na jaki się natkniemy, jest to, że marchew nie jest w żaden sposób segregowana wg długości – wykopujemy 2 tony marchwi, pakujemy w torebki, sprzedajemy. A więc nie ma możliwości bezpośredniej analizy „długość X sprzedaje się lepiej niż długość Y”.

Trzeba więc zastosować podejście statystyczne – policzyć średnią długość marchwi z poszczególnych wykopków, a następnie sprawdzić jakie były wartości sprzedaży. I to jest dokładnie to, co – w pierwszym rozdziale – próbował pan Stanisław zrobić „na piechotę”.

Tym razem jednak mamy ciężką artylerię w postaci hurtowni danych. Mamy w hurtowni tabelę faktów MarchewNaPolu, która przechowuje dzienne dane o każdej marchewce, od chwili zasiania do dnia, w którym jest ona wykopana. Potrzebujemy wyłącznie dane z dnia wykopków – na szczęście mamy w tej tabeli atrybut ‚DzisWykopki’ dzięki czemu łatwo odfiltrować długość marchwi w dniu żniw.

Wyciągamy więc wszystkie długości marchwi, ze wszystkich pól, filtrując wg flagi DzisWykopki, oraz wg odmiany M17. Na wyjściu dostajemy trzy kolumny: data, pole, długość. Daty będą tu rozłożone „rzadko”, ponieważ wykopki zdarzają się tylko kilka razy w roku. Uśredniamy po polu i dacie, dzięki czemu mamy dokładnie jedną średnią wartość długości dla każdego pola / daty wykopków.

Następnie, w osobnym raporcie, wyciągamy wszystkie dzienne dane sprzedażowe dla tej samej odmiany. W wyniku dostajemy trzy kolumny: data, pole, wartość sprzedaży. Sumujemy wartość sprzedaży tak, żeby mieć jedną, łączną wartość sprzedaży dla każdej pary (data, pole). Prawdopodobnie będziemy tu mieć dane dla każdego dnia (oprócz niedziel, żeby dzień święty święcić).

W kolejnym kroku, dla każdego pola, sumujemy sprzedaż tak, żeby uzyskać dane dla pojedynczych wykopków. Przykład: jeżeli na polu X wykopki były 15 kwietnia 2009 a potem 15 października 2009, a potem 15 kwietnia 2010, liczymy łączną wartość sprzedaży z pola X dla dwóch przedziałów: 15/04/2009 – 15/10/2009 oraz 15/10/2009 – 15/04/2010. Dzięki temu, z dobrym przybliżeniem, mamy dane sprzedażowe dla poszczególnych wykopków (a co za tym idzie, dla poszczególnych, uśrednionych długości marchwi).

Na koniec zestawiamy te dwa raporty i możemy wywnioskować która marchew sprzedała się lepiej. Niestety, nie będziemy w stanie stwierdzić, czy długie marchewki schodzą lepiej w piątki czy nie – chyba że zaczniemy sprzedawać długie osobno a krótkie osobno (oraz rejestrować ten fakt w tabeli faktów sprzedaży).

Jak widać, długość marchwi jest w naszym przypadku tematem niewdzięcznym, ponieważ wskutek długich przedziałów czasowych między wykopkami, analiza sprzedaży przy naszym podejściu może być obarczona sporym błędem statystycznym. Być może dałoby się uzyskać lepszą odpowiedź po zgromadzeniu odpowiednio dużej ilości danych.

Jednak oprócz długości możemy też analizować sprzedaż wg dnia tygodnia albo wg odmiany albo wg pola. Na przykład (o ile rejestrujemy reklamacje jako osobny fakt), możemy stwierdzić, że z pola X jest najwięcej reklamacji. Albo, że pole Y daje nam najlepszy zysk dla odmiany M32, a najmniejszy dla odmiany M19. Albo, że odmiana M9 zaczęła się lepiej sprzedawać po zmianie nazwy marketingowej z „Dobra Marchew” na „Świetna Marchew”. I tak dalej.

Na ogół jest tak, że jak się już da użytkownikom kilka raportów (oraz udowodni ich skuteczność), chcą więcej. I prędzej czy później któryś z nich nauczy się jak budować własne raporty, jak skutecznie łączyć i agregować dane oraz szukać trendów, punktów szczególnych i tak dalej.

Warto pamiętać o tym, że jeżeli wdrożenie hurtowni danych zakończy się sukcesem (a niestety zaledwie niewielki odsetek tego typu projektów odnosi sukces), nie oznacza to bynajmniej zakończenia pracy. Hurtownia danych bowiem stale ewoluuje, nowe fakty, wymiary bądź atrybuty pojawiają się od czasu do czasu, zawsze potrzeba nowych analiz, przekrojów i kalkulacji.

Na zakończenie powiem jeszcze, że przeczytałem sobie teraz wszystkie trzy rozdziały jeszcze raz, i widzę, że pominąłem kilka ciekawych zagadnień z działu BI.

Po pierwsze, nie napisałem nic o modelowaniu danych. Może kiedyś skupię się na tym w osobnym cyklu.

Po drugie, pisząc o raportach wielowymiarowych nie wspomniałem słowem o kostkach OLAP, które są podstawą analizy wielowymiarowej. Jak ktoś chce, niech sobie poszuka.

Po trzecie, nie omówiłem zagadnienia „Slowly Changing Dimensions” (nie jestem pewien jaki jest polski odpowiednik) – zagadnienie jest niebanalne i dość ciekawe.

Znalazłoby się pewnie jeszcze jakieś „po czwarte” i „po piąte”, ale to już pozostawię Czytelnikom 😉

конец

Autor: xpil

Po czterdziestce. Żonaty. Dzieciaty. Komputerowiec. Krwiodawca. Emigrant. Rusofil. Lemofil. Sarkastyczny. Uparty. Mól książkowy. Ateista. Apolityczny. Nie oglądam TV. Uwielbiam matematykę. Walę prosto z mostu. Gram na paru instrumentach. Lubię planszówki. Słucham bluesa, poezji śpiewanej i kapel a'capella. || Kliknij tutaj po więcej szczegółów ||

Dodaj komentarz

Bądź pierwszy!

Powiadom o
avatar
wpDiscuz