Tak zwane "operacyjne Business Intelligence" stawia zupełnie nowe wymagania przed architekturą takich systemów. Odbiorcami informacji uzyskiwanych z systemów BI są menedżerowie różnego szczebla, którzy wykorzystują je w procesie podejmowania decyzji. W związku z tym liczba użytkowników (osób, dla których wyniki działania środowiska BI są narzędziem pracy) jest 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, że 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. Zwykle są to cykle dzienne, co oznacza, że 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 wystąpiły w ostatnim czasie. Odbiorcy 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 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. Nie jest to zwykle problem, gdyż użytkownicy tego typu systemów pracują w ściśle określonych godzinach "biurowych" i korzystanie z systemu, np. w środku nocy, nie jest potrzebne. Z drugiej strony chwilowa niedostępność systemu, spowodowana awarią bądź innymi zdarzeniami, nie rodzi dużych konsekwencji dla przedsiębiorstwa. Godzina opóźnienia w przygotowaniu raportu dla dyrektora handlowego to coś 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ą, że użyteczność takich rozwiązań dla procesów operacyjnych może być 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, która umożliwia 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.

Dobrym przykładem jest proces segmentacji klientów. Na podstawie danych zebranych z wielu systemów transakcyjnych (np. dane demograficzne i behawioralne, 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ź określić targetowaną ofertę, pozwalającą na efektywny up-selling lub cross-selling naszej propozycji.

Tak uzyskane wyniki mogą 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 skryptem 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".

Inny przykład jest automatyczna optymalizacja procesów produkcyjnych. Opierając się na analizach 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 dopasowana do nieustannie zmieniających się potrzeb rynku, a nie do przyjętych planów, które mogą 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 nie do przyjęcia, 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 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 nie są opóźnione w stosunku do czasu, gdy pojawiły się u źródła. Dzięki temu możliwe jest prowadzenie złożonych analiz na danych niemal w czasie realnym, bez obciążania systemu źródłowego (co mogłoby źle wpływać na inne procesy, do których obsługi których jest on przeznaczony).

Zasadnicza wada takiego podejścia: kopia danych jest identyczna jak źródło. W większości przypadków model danych systemu transakcyjnego, który zostaje odwzorowany, jest całkowicie nieprzystosowany do przetwarzania analitycznego, co rodzi sporo trudności i ograniczeń. Podobne rozwiązanie nie ułatwia integracji informacji pochodzących z wielu systemów, co jest zwykle kluczowym wymaganiem.

Podejście drugie - Operational Data Store (ODS)

Innym 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ż zwykle nie przechowuje się w tego typu repozytoriach danych historycznych.

Kluczowym problemem przy budowie ODS jest zapewnienie 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 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 spotkać się z podejściem opartym na tzw. mechanizmach federacyjnych. W pewnym uproszczeniu polega to na zapewnieniu platformy, która wirtualizuje bazy danych analitycznych, definiując nowe, optymalne i zintegrowane struktury, bez fizycznego przenoszenia większości danych do nowego repozytorium. Dane pozostają 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 transparentny dla odbiorcy. Poprzez szereg zaawansowanych rozwiązań, obejmujących cache, indeksy, częściową replikację etc., obciążenie systemu źródłowego jest minimalizowane. Niemniej jednak 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 interesujących możliwości, zapewniając aktualność i dostępność danych, a jednocześnie eliminując wiele z problemów związanych z nieprzystosowaniem systemów źródłowych do potrzeb 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 federacja danych, jednakże na razie nie ma rozwiązań idealnych. Dlatego wybór właściwego podejścia musi być poparty szczegółową analizą potrzeb i możliwości.

Autor jest prezesem zarządu BusinessVision.