Inteligencja Biznesowa – rozdział 1

https://xpil.eu/5mAD3

O wdrożeniach Business Intelligence napisano już tyle makulatury, że pisanie kolejnego poradnika czy też podręcznika mija się z celem. Temat został już dość dobrze udokumentowany i sformalizowany, zarówno od strony procesów jak też metodologii. Powstało też w ciągu ostatnich paru lat mnóstwo technologii wspierających tworzenie rozwiązań BI ("BI" czyli "Business Intelligence" właśnie) i to we wszystkich klasach wielkościowych oraz cenowych. Po cholerę więc jeszcze jedna kropelka w tym oceanie?

Ano po pierwsze primo, ponieważ ocean składa się z kropelek. A po drugie primo, bo mam taki kaprys i na własnym blogu mogę pisać nawet o statystykach awaryjności kultywatorów w Koziej Wólce w latach 1954-1960 i gówno mi kto zrobi 😉

Jak zwykle proszę o punktowanie wszelakich bzdur w komentarzach, będę szczęśliwy mogąc je uważnie zignorować. Trolle również mile widziane - jak już nadmieniałem tu i ówdzie, mój /dev/null jest przeogromny i każdy troll znajdzie w nim wielu przyjaciół.

Ponadto, wpis ten będzie mieszał pojęcia z zakresu BI z pojęciami z zakresu DW (hurtowni danych) jako że w moim codziennym życiu zawodowym te dwa zagadnienia przecinają się w bardzo wielu miejscach. Gwoli ścisłości, hurtowania danych jest narzędziem wspomagającym podejmowanie decyzji biznesowych. Zalicza się ona więc do grona narzędzi klasy BI.

Działka BI jest jedną z najbardziej "brudnych" obszarów IT. Wynika to głównie z faktu, że implementowanie rozwiązań BI opiera się w znacznej mierze na interakcji z użytkownikami końcowymi, którzy - na nasze nieszczęście - mają na ogół blade pojęcie o technicznej stronie przedsięwzięcia i albo żądają rzeczy niemożliwych, albo w drugą stronę - mają w dupie bo oni swój raporcik i tak sobie machną na podorędziu w Excelu, a wydziwianie i nowości wolą spychać na innych.

Złożoność rozwiązań BI na ogół rośnie wraz z przedsiębiorstwem. Trzyosobowa firma, która handluje marchewkami, ma dwa warzywniaki na krzyż plus jedno pole, będzie o wiele prostsza do analizy niż, dajmy na to, firma produkująca części zamienne do AGD.

Niemniej jednak ogólny zarys projektu BI jest na ogół ten sam. Z jednej strony barykady mamy wyspecjalizowane (często dość leciwe, ale wciąż działające) systemy komputerowe do obsługi konkretnej działki biznesu. Z drugiej - użytkownicy końcowi (na ogół szefowie firmy lub wysoko postawiona kadra menadżerska) chcący zrozumieć jak na biznesie zarobić jeszcze więcej pieniędzy albo uniknąć problemów. A najlepiej jedno i drugie. Przyjrzyjmy się temu nieszczęsnemu warzywniakowi i zobaczmy jak - hipotetycznie - mogłoby to wyglądać z perspektywy BI.

Kilka lat temu zainstalowano program włoskiej firmy X do analizy jakości marchwi na polu, sprzężony z zakopanymi w ziemi czujnikami argentyńskiej firmy Y. Zarówno X jak i Y już dawno nie istnieją, bo X kupił chiński holding warzywny Vah Zhi Vah a z kolei Y padła 10 lat temu bo byli za mało konkurencyjni. Niemniej jednak system działa dobrze, nikt go nie rusza (skoro działa), generuje (dla każdej marchewki zasianej na naszym polu) w miarę stały strumień danych w postaci cogodzinnych plików tekstowych, i nic więcej. Ani mniej.

Gdzieś tam po drodze jest jeszcze malutka aplikacja zliczająca ilość marchwi wydobytej każdorazowo z pola - generuje, w formacie XML, dane o masach marchwi zebranych z pola danego dnia. Obsługuje się ją za pomocą ręcznego terminala, który zapisuje dane do lokalnego pliku w pamięci flash, a raz dziennie zawartość jest wypluwana do jakiegoś zasobu sieciowego na serwerze firmy.

Do tego dochodzi jeszcze niewielka aplikacja księgowa obsługiwana przez żonę właściciela biznesu, panią Krystynę. Pani Krystyna pracowicie wklepuje wszystkie dane o zakupach nasion, kosztach utrzymania narzędzi, kosztach zasiewów, wykopek oraz (najważniejsze!) danych o sprzedaży, do aplikacji księgowej. Dane są przechowywane na lokalnym serwerze postgresql. Program jest darmowy, prosty w obsłudze, sam się aktualizuje z internetu, ma wszystko co trzeba.

No i teraz pan Stanisław, szef i właściciel tego interesu, chce sprawdzić czy istnieje zależność między średnią długością marchwi a wynikami sprzedaży, dla odmiany M17.

W klasycznym układzie pan Stanisław policzy sobie średnią długość marchwi (odmiana M17) w kwietniu 2011. Użyje do tego celu danych z programu X; prawdopodobnie (o ile jest w miarę kumaty) zrobi to w Excelu, importując pracowicie wszystkie godzinne pliki tekstowe, konwertując je do postaci tabelarycznej, filtrując parametry żeby znaleźć tylko dane o długości, wreszcie licząc średnią dla M17.

Następnie poprosi żonę żeby mu podała zysk netto za kwiecień. Pani Krystyna w tym celu rzuci okiem w swoją apliację księgową i wyciągnie z niej jakiś raport za kwiecień, dla odmiany "Słodka Karotka" (która jest marketingową nazwą M17). Potem doda, odejmie, przemnoży, przedzieli i dostanie zysk netto. Obarczony pewnym nieuniknionym błędem, ponieważ na tym samym polu rośnie jeszcze odmiana M17Z ("Słodka Karotka Plus") a także odmiana eksperymentalna M18, i koszty obsługi pola rozkładają się między te trzy odmiany, mniej więcej po 45% kosztów na każdą odmianę handlową oraz około 10% na eksperymentalną.

Następnie pan Stanisław powtórzy wszystkie te kroki dla maja 2011. Jeżeli starczy mu zapału (a pani Krystynie cierpliwości), również dla czerwca i lipca. W efekcie dostanie cztery pary liczb: średnią długość marchwi M17 oraz zysk netto za każdy miesiąc. Porównując je, może wywnioskować, że dłuższa marchew daje większy zysk. Albo na odwrót. Może jednak przegapić prosty fakt, że największy zysk otrzyma się przy jednej, konkretnej długości marchwi, i że dalsze wydłużanie marchewki będzie generować wyższe koszty bez wzrostu zysku. Albo może nie zauważyć, że krótkie marchewki świetnie sprzedają się piątki i soboty, średnie w środy i czwartki a długie w poniedziałki i piątki. Albo, że rozrzut długości marchwi jest mniejszy w przypadku nasion od dostawców A i B, a większy od C, D oraz E. I tak dalej. Oczywiście pan Stanisław może wiedzieć to wszystko ponieważ "robi" w marchwi od trzech pokoleń, niemniej jednak to jest tylko przykład obrazujący rodzaje analiz, które przy zwięszaniu ilości danych mogą stać sie naprawdę trudne (lub wręcz niemożliwe) do wykonania "zwykłymi" sposobami, w sensownym czasie.

I tutaj właśnie pojawia się możliwość zastosowania rozwiązań klasy BI. Pierwszym etapem analizy będzie z całą pewnością odwiedzenie każdego kluczowego miejsca w firmie i rozeznanie się w charakterystyce danych generowanych (a także - być może - konsumowanych) przez ten dział. Jeżeli zachodzi taka potrzeba, należy również porozmawiać z kluczowymi użytkownikami każdego działu na temat tego jakie dane produkują / konsumują. A więc, idziemy na pole, w zadumie przyglądamy się przez chwilę dostojnym łanom naci, rzucamy okiem na panel sterujący czujników firmy Y. Zbieramy trochę plików godzinnych z systemu X, przyglądamy im się szczegółowo (może być już bez zadumy). Następnie orientujemy się w tym jak działa aplikacja do zbierania danych o ilości marchwi; na koniec rozmawiamy z żoną szefa i przyglądamy się aplikacji księgowej (oraz wszelkim raportom, które pani Krystyna tworzy za jej pomocą).

Potem uderzamy do pana Stanisława (który jest żywotnie zainteresowany poprawą wyników firmy, jednak nie bardzo wie jak to wszystko sprawnie poskładać do kupy) i prosimy go o przykładowe zestawienia i analizy, które sobie tworzył do tej pory we własnym zakresie, a także próbujemy się dowiedzieć co jeszcze pan Stanisław chciałby móc analizować, ale nie daje rady bo ma za dużo danych albo dane są dla niego trudno dostępne.

Na tym etapie mamy już zgrubną ideę jak powinno wyglądać nasze rozwiązanie BI. Znamy źródła danych, mamy dobre pojęcia o ich wzajemnej kompatybilności oraz wiemy czego spodziewają się konsumenci końcowi. Wszystko jeszcze w powijakach, ale przynajmniej znamy kierunek, w którym chcemy się poruszać.

Kolejnym krokiem, w zasadzie najważniejszym dla większości projektów BI, jest unifikacja wymiarów.

Najpierw jednak kropelka teorii. Wymiar ("dimension") to nic innego jak kontekst, w którym występują dane. Na przykład fakt sprzedaży może mieć następujące wymiary: klient, towar, sklep (jeżeli mamy ich więcej), data sprzedaży. Wymiarów używa się potem do "cięcia" danych na kawałki w trakcie analizy. Na przykład z całej sprzedaży możemy odfiltrować tylko dane konkretnego towaru i z zadanego przedziału czasu.

W naszym przypadku wymiarem będzie z pewnością gatunek marchwi - i tu zaczynają się pierwsze schody, ponieważ "na polu" mamy gatunki oznaczane symbolami "M17", "M17Z", "M18" i tak dalej, a "w sklepie" występują już nazwy marketingowe ("Słodka Karotka", "Słodka Karotka Plus" a M18 jako eksperymentalna jeszcze nie ma nazwy). Trzeba to jakoś pogodzić, aby w efekcie uzyskać wymiar uniwersalny (po angielsku nazywa się to "conformed dimension", nie jestem pewien jaka jest poprawna polska nazwa), którego można używać wszędzie. W końcu "M17" to ta sama marchew co "Słodka Karotka", prawda?

No to pierwsze koty za płoty, przyjmijmy, dużym skokiem, że udało nam się zunifikować wszystkie wymiary w naszym marchwiowym biznesie. W rzeczywistości proces unifikacji wymiarów jest dość czaso- i pracochłonny, a jego złożoność rośnie przy większej ilości działów w firmie. Jeżeli jednak uda nam się wymiary poprawnie poukładać, możemy zabrać się za definiowanie faktów.

Faktem w teorii hurtowni danych nazywamy pojedyncze wydarzenie, mające wartość biznesową, dające się pomierzyć numerycznie oraz skojarzyć z uprzednio zdefiniowanymi wymiarami (wszystkimi bądź tylko niektórymi). To może nie jest definicja encyklopedyczna, ale z grubsza oddaje znaczenie faktu. Przykładem faktu jest, wyżej wymienione już, zdarzenie sprzedaży. Wymiary już znamy (klient, towar itd), ale oprócz tego jest jeszcze oczywiście część mierzalna tego zjawiska, czyli na przykład kwota lub ilość sztuk. Ta część mierzalna nazywa się miarą (ang. "measure"). Miary, w połączeniu z wymiarami, są podstawą analizy danych. Na przykład: ile zarobiliśmy na odmianie M17 w 2011 roku, w rozbiciu na poszczególne miesiące i długości?

W przypadku tego wyimaginowanego biznesu marchwiowego faktem będzie niewątpliwie sprzedaż. Innym faktem będą zamówienia nasion, jeszcze innym zbieranie plonów i tak dalej. Ogólnie rzecz biorąc, fakty w naszej hurtowni danych na ogół odpowiadają z grubsza poszczególnym procesom zachodzącym w przedsiębiorstwie. Fakt ma na ogół jedną wartość mierzalną na każdym poziomie szczegółowości...

Zaraz zaraz, że co proszę? Poziom szczegółowości?
Ano, właśnie. Fakty mogą być mierzalne na różnych poziomach szczegółowości (anglicy mówią o ziarnistości czyli "granularity"). Na przykład, trwające miesiąc czasu zebranie 100 ton marchwi z naszego pola będzie zarejestrowane jako 25 faktów (jeden dziennie) przez system rejestracji plonów, a w systemie kadrowym będzie mu odpowiadać jedna miesięczna pensja dla każdego "żniwiarza" - czyli ziarnistość faktu "plon" dla wymiaru "czas" jest "1 dzień", a ziarnistość faktu "wypłata" dla tego samego wymiaru "czas" jest "1 miesiąc". Tym samym te dwa fakty muszą być trzymane osobno. Dotyczą one tego samego procesu biznesowego (zbieranie plonów i związane z nim wypłaty), ale obejmują swoim zasięgiem dwie różne miary ("ilość marchwi dziennie", "kwota wypłaty miesięcznej"), które różnią się ziarnistością wzdłuż wymiaru "czas".

No dobra. Mamy podefiniowane fakty, wiemy na jakich poziomach szczegółowości będą one zbierane, wiemy które wymiary są "podpięte" do których faktów, możemy zacząć pracować na procesem ładowania danych.

O ile wspomniany wcześniej proces ujednolicania wymiarów był najbardziej upierdliwy z punktu widzenia biznesowego, o tyle ładowanie danych do hurtowni jest najczęściej najbardziej skomplikowanym zagadnieniem z punktu technologii. Mianowicie, po pierwsze mamy do czynienia z wieloma różnymi systemami (oraz technologiami) źródłowymi, po drugie musimy mieć świadomość omylności gatunku Homo Sapiens, w związku z czym dane źródłowe będą zawierać błędy, po trzecie wreszcie systemy źródłowe muszą działać nieprzerwanie (na ogół...), a więc ładowanie danych należy zaprojektować w taki sposób, żeby w jak najmniejszym stopniu wpłynąć na wydajność systemów źródłowych.

Oczywiście w przypadku malutkiej firmy marchwijnej szanse na "przyduszenie" systemu źródłowego są znikome. Wyobraźmy sobie jednak duży system bankowy bądź system obstawiania wyścigów konnych - tam wszystkie transakcje muszą odbywać się w czasie rzeczywistym, i nie mogą być zakłócone przez fakt, że prezes banku chce sprawdzić bieżące statystyki rentowności oddziału.

O ładowaniu danych do hurtowni napiszę jednak innym razem, bo widzę, że mi się ten wpis już wymknął spod kontroli jeśli chodzi o wielkość. A w tym przypadku, "większy" nie oznacza "lepszy".

https://xpil.eu/5mAD3

Leave a Comment

Komentarze mile widziane.

Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]

Jeżeli zrobisz literówkę lub zmienisz zdanie, możesz edytować komentarz po jego zatwierdzeniu.