Operacyjne Business Intelligence
Rozwiązania Business Intelligence, tradycyjnie kojarzone są ze wsparciem strategicznego zarządzania. Najprostszy model tego typu systemów składa się z hurtowni danych, cyklicznie zasilanej informacjami, pochodzącymi z wielu transakcyjnych systemów źródłowych. Dane te są czyszczone, integrowane, agregowane a następnie udostępniane użytkownikom, którzy uzbrojeni w różnego rodzaju narzędzia, tworzą mniej lub bardziej zaawansowane raporty i analizy.
Spis Treści
- Krok pierwszy – podejście tradycyjne
- Krok drugi – pętla zwrotna
- Krok trzeci – operacyjny BI
- Podsumowanie
Kolejnym krokiem w rozwoju BI jest rozszerzenie grupy odbiorców informacji analitycznych o osoby, wykorzystujące je na potrzeby działań operacyjnych, wpisanych w konkretne procesy biznesowe, realizowane w przedsiębiorstwie. Tak zwane „operacyjne Business Intelligence” stawia zupełnie nowe wymagania przed architekturą takich systemów.
Krok pierwszy – podejście tradycyjne
Odbiorcami informacji, uzyskiwanych z systemów BI są managerowie różnego szczebla, którzy wykorzystują je w procesie podejmowania decyzji. W związku z tym liczba użytkowników (rozumianych jako osoby, dla których wyniki działania środowiska BI są de facto ich narzędziem pracy), jest stosunkowo ograniczona. W samym procesie pozyskiwania informacji może oczywiście uczestniczyć większa liczba osób, takich jak choćby analitycy biznesowi, jednakże pełnią oni rolę w znaczniej mierze pomocniczą, ograniczoną do przetworzenia danych do postaci wymaganej przez kadrę zarządzającą.
Drugą istotną cechą „tradycyjnych” rozwiązań Business Intelligence, jest naturalne opóźnienie w dostępie do informacji. Bierze się to z faktu, iż dane źródłowe, pochodzące z systemów transakcyjnych, pobierane są do analitycznych baz danych (hurtownie danych, data marty) w ściśle zdefiniowanych cyklach. Częstotliwość takiego ładowania, zależy zarówno od istniejących wymagań biznesowych, jak i od uwarunkowań związanych z systemami źródłowymi, oraz ograniczeń wykorzystywanej technologii. Typowo są to cykle dzienne, co oznacza, iż dane opisujące zdarzenia, które zaszły danego dnia, dostępne będą w raportach i analizach najwcześniej w dniu kolejnym. W zdecydowanej większości przypadków nie stanowi to problemu, ponieważ strategiczne zarządzanie firmą nie wymaga szczegółowej wiedzy o wszystkich transakcjach, które miały miejsce w ostatnim czasie. Odbiorcy informacji oczekują informacji zagregowanej, przedstawionej w postaci syntetycznych wskaźników, trendów i prognoz.
Kolejną rzeczą na którą warto zwrócić uwagę, jest wymagany poziom dostępności systemów Business Intelligence, rozumiany jako oczekiwane parametry SLA (Service Level Agreement) dla poszczególnych komponentów środowiska. Typowe rozwiązania BI z założenia nie są udostępniane użytkownikom w modelu 24/7. Jest to związane ze wspomnianymi wcześniej cyklami ładowania i przetwarzania danych, które mogą wymagać, aby w określonych godzinach system był wyłączony z użycia. Ponownie – nie jest to zwykle żadnym problemem, gdyż użytkownicy tego typu systemów pracują w ściśle określonych godzinach „biurowych” i korzystanie z systemu na przykład w środku nocy, nie jest nikomu potrzebne. Z drugiej strony chwilowa niedostępność systemu, spowodowana awarią, bądź innymi zdarzeniami, nie rodzi zbyt dużych konsekwencji dla przedsiębiorstwa. Godzina opóźnienia w przygotowaniu raportu dla dyrektora handlowego, oznacza coś nieco innego niż godzina, bez możliwości obsługiwania klientów w całej sieci sprzedaży.
Krok drugi – pętla zwrotna
Ostatnie dwie cechy, czyli opóźnienie w dostępie do informacji, oraz limitowana dostępność systemów Business Intelligence, powodują, iż użyteczność takich rozwiązań dla procesów operacyjnych może być stosunkowo ograniczona.
Nie oznacza to jednak, że są one w tym aspekcie całkowicie bezużyteczne. Ważnym krokiem, pozwalającym na zwiększenie wykorzystania potencjału jaki daje środowisko BI, jest zapewnienie „pętli zwrotnej”, pozwalającej na przekazywanie wyników przetwarzania danych z powrotem do systemów źródłowych. Różnego rodzaju informacje wyliczone z wykorzystaniem całego zaplecza analitycznego (modelowanie, prognozowanie, data mining) wracają tam, gdzie mogą być wykorzystywane do automatycznego sterowania i optymalizowania procesów operacyjnych.
Bardzo dobrym przykładem może być proces segmentacji klientów. Na podstawie danych, zebranych z wielu systemów transakcyjnych (np. dane demograficzne i behawioralne, dane finansowe, historia kontaktów, etc.) możemy na różne sposoby skategoryzować naszych klientów, czyli przypisać ich do określonych grup, charakteryzujących się wspólnymi cechami w jakimś obszarze. Możemy również wyliczyć szereg złożonych wskaźników (np. LTV – Life Time Value, churn probability, etc.), bądź też określić targetowaną ofertę, pozwalającą na efektywny up-selling, bądź cross-selling naszej oferty.
Tak uzyskane wyniki, mogą teraz cyklicznie trafiać do systemów transakcyjnych, gdzie wykorzystywane będą w codziennej pracy na poziomie operacyjnym. Na przykład w call center, konsultant uzyska dostęp nie tylko do danych identyfikacyjnych dzwoniącego klienta, ale będzie w stanie natychmiast określić segment do którego ta osoba została przypisana, lub też będzie automatycznie wspierany w zakresie skryptu rozmowy, który powinien w danej sytuacji zastosować (tzw. NBA – Next Best Action). Idąc dalej tym tropem, system zarządzający kolejką połączeń oczekujących, będzie w stanie zapewnić, że klienci w jakimś sensie „lepsi” będą krócej oczekiwać na połączenie niż, klienci „gorsi”.
Innym przykładem może być automatyczna optymalizacja procesów produkcyjnych. Na podstawie analizy posiadanych zamówień i stanów magazynowych, ale również biorąc pod uwagę wyliczone na podstawie danych historycznych prognozy, jak również wiedzę na temat sezonowości popytu, można skutecznie sterować produkcją. Dzięki temu liczba wytwarzanych przez naszą fabrykę butów w kolorze czerwonym lub niebieskim, będzie faktycznie dopasowana do nieustannie zmieniających się potrzeb rynku, a nie do arbitralnie przyjętych planów, które dawno już mogły się zdezaktualizować.
Krok trzeci – operacyjny BI
Zapewnienie opisanej powyżej pętli zwrotnej, daje możliwość wykorzystywania wyników działania rozwiązań Business Intelligence w procesach biznesowych, jednakże nadal trudno to nazwać operacyjnym BI.
Dopiero znacząca zmiana podejścia do sposobu pozyskiwania i udostępniania danych analitycznych, pozwala na faktyczne wykorzystanie ich przez użytkowników oczekujących informacji, której aktualność zbliżona jest do czasu rzeczywistego. Tutaj jednodniowe opóźnienie w pozyskaniu danych źródłowych jest całkowicie nieakceptowane, a wymagania co do poziomu SLA dla systemów BI znacząco wzrastają, zbliżając się do tych, które stawiane są systemom transakcyjnym.
Możemy zastosować kilka różnych wariantów, jednakże każdy z nich – przynajmniej na obecnym etapie rozwoju technologii – ma swoje ograniczenia. Dlatego wybrane podejście musi być poparte szczegółową analizą zarówno wymagań jak i istniejących uwarunkowań.
Podejście pierwsze – replikacja danych
Stosując mechanizmy dostępne w większości współczesnych systemów bazodanowych, możemy stworzyć odrębną, ale identyczną kopię danych źródłowych. Jest ona przeznaczona do raportowania opartego na informacjach, które praktycznie w ogóle nie są opóźnione w stosunku do czasu w którym się pojawiły u źródła. Dzięki temu, możliwe jest prowadzenie dość złożonych analiz na danych niemal real-time, bez obciążania systemu źródłowego (co mogłoby bardzo negatywnie wpływać na inne procesy, do obsługi których jest on przeznaczony).
Zasadniczą wadą takiego podejścia jest właśnie fakt, iż kopia danych jest „identyczna” jak źródło. W większości przypadków, model danych systemu transakcyjnego, który zostaje tutaj odwzorowany, jest całkowicie nieprzystosowany do przetwarzania analitycznego, co rodzi szereg trudności i ograniczeń. Dodatkowo takie rozwiązanie w żaden sposób nie ułatwia integracji informacji pochodzących z wielu systemów, co jest zwykle dość kluczowym wymaganiem.
Podejście drugie – Operational Data Store (ODS)
Innym, dość powszechnie stosowanym, rozwiązaniem jest zbudowanie dedykowanego repozytorium danych operacyjnych. Tak zwany ODS, zapewnia częściową integrację danych pochodzących z różnych źródeł, jednakże są to dane przetworzone w minimalnym stopniu, posiadające wysoką granulację, zbliżoną do transakcji, które odwzorowują. Są to również wyłącznie dane bieżące, ponieważ typowo nie przechowuje się w tego typu repozytoriach żadnych danych historycznych.
Kluczowym problemem przy budowie ODS jest zapewnienie właściwej aktualności danych. Zarówno pobranie zmienionych rekordów źródłowych (CDC – Changed Data Capture), jak i integracja danych z wielu źródeł rodzi nieuniknione opóźnienia, oraz stawia bardzo wysokie wymagania wydajnościowe wobec wykorzystywanych technologii. System taki może zostać wpięty w wykorzystywaną w organizacji „szynę integracyjną” w modelu EAI (Enterprise Application Integration), bądź też może zostać oparty na innych zaawansowanych mechanizmach integracyjnych.
Podejście trzecie – federacja danych
Coraz częściej można również spotkać się z podejściem opartym o tak zwane mechanizmy federacyjne. W pewnym uproszczeniu polega to na zapewnieniu platformy, która wirtualizuje bazy danych analitycznych, definiując nowe, bardziej optymalne i zintegrowane struktury, bez fizycznego przenoszenia większości danych do nowego repozytorium. Dane pozostają de facto w systemach transakcyjnych, a mechanizmy EII (Enterprise Information Integration) przekładają zapytania analityczne na zapytania bezpośrednio do źródeł.
Całe przetwarzanie, związane z integracją i dostosowaniem danych do potrzeb analitycznych odbywa się „w locie”, w sposób przeźroczysty dla odbiorcy. Poprzez szereg zaawansowanych rozwiązań, obejmujących cache, indeksy, częściową replikację, etc., obciążenie systemu źródłowego jest minimalizowane. Tym nie mniej jest ono znaczące i z pewnością musi być brane pod uwagę przy planowaniu tego typu architektury. Z drugiej strony federacja danych daje szereg bardzo interesujących możliwości, zapewniając bardzo wysoką aktualność i dostępność danych, a jednocześnie eliminując wiele z problemów związanych z nieprzystosowaniem systemów źródłowych do potrzeba analitycznych.
Podsumowanie
Rozwiązania Business Intelligence coraz powszechniej wykorzystywane są w procesach operacyjnych. Wymaga to jednak znaczącej zmiany podejścia do ich architektury, ze względu na istotne ograniczenia „tradycyjnych” rozwiązań w tym zakresie. Rozwój technologii pozwala na wykorzystywanie nowych, ciekawych mechanizmów, takich jak na przykład federacja danych, jednakże póki co, nie ma rozwiązań idealnych. Dlatego wybór właściwego podejścia musi być poparty szczegółową analizą potrzeb i możliwości.
