Typowy scenariusz rozwoju systemu Business Intelligence w przedsiębiorstwach ma swój początek w arkuszu kalkulacyjnym, udoskonalanym i automatyzowanym, aż do momentu migracji do systemu opartego na rozwiązaniach hurtowni danych. Ten kierunek rozwoju systemów analitycznych (ang. bottom-up) choć początkowo naturalny, z czasem może stać się ograniczeniem dla korporacji lub firm posiadających swoje odziały w wielu lokalizacjach.

W takich warunkach systemy charakteryzują się niekontrolowaną redundancją danych oraz istnieniem wielu rozwijanych oddzielnie obszarów raportowych.

Brak ujednoliconego spojrzenia na dane w znacznym stopniu ogranicza możliwości ich porównania i weryfikacji, szczególnie na szczeblu przedsiębiorstwa. Inne konsekwencje braku strategii w budowie korporacyjnych systemów BI to:

  • niekontrolowane przepływy danych i redundancja danych,
  • rozwój wąskich obszarów raportowych,
  • większe koszty,
  • brak jednolitego spojrzenia na dane,
  • ograniczona elastyczność rozbudowy systemu raportowania,
  • mała wiarygodność danych.

W skrajnych przypadkach koszt czasu, jaki należy poświęcić na zebranie, ręczne zestawienie i odpowiednie sformatowanie danych, może przewyższać wartość uzyskanej w ten sposób informacji. W rezultacie braku spójnej platformy raportowania koszty pozyskiwania danych są wysokie, wyniki nie stanowią solidnej podstawy do podejmowania decyzji zarządczych, a możliwości dalszego rozwoju systemu analitycznego bardzo ograniczone.

Zdefiniowanie odpowiedniej strategii korporacyjnej, która określa zasady oraz wytyczne dla architektury systemu analitycznego, to pierwszy krok w budowie korporacyjnego rozwiązania Business Intelligence. Tworzenie strategii powinno być inicjatywą odgórną, zmierzającą do harmonizacji i ujednolicenia lokalnego spojrzenia na dane (ang. top-down).

Wybór platformy informatycznej dla rozwiązań BI obok wyboru systemu ERP jest najbardziej brzemienną w skutki decyzją dotyczącą IT w przedsiębiorstwie. Często jest ona zdeterminowana właśnie przez wykorzystywany w firmie system ERP. Ze względu na spójną architekturę, łatwiejszą integrację oraz niższe koszty utrzymania systemów firmy decydują się na rozwiązania BI i ERP oferowane przez jednego producenta. Nie jest to jednak regułą, a bywa też, choć rzadko, że system Business Intelligence jest jedynym wspólnym w ramach korporacji rozwiązaniem.

Bez względu jednak na wybraną technologię i dostawcę rozwiązania, po podjęciu decyzji o wprowadzeniu korporacyjnego standardu systemu BI należy rozważyć szereg czynników, które określą przyszłą architekturę systemu. Ponieważ każde przedsiębiorstwo jest inne, nie ma jednej gotowej recepty. Zbudowanie optymalnego rozwiązania to złożony proces, w którym należy uwzględniać między innymi:

  • cele i zakres wykorzystania hurtowni danych,
  • systemy źródłowe,
  • wymagania raportowe,
  • zarządzanie, utrzymanie i rozwój systemu,
  • narzędzia raportowe.

Dla kogo hurtownia

Stworzenie repozytorium danych zapewniającego spójne spojrzenie na informacje pochodzące z różnych działów, lokalizacji oraz systemów to jeden z celów budowy korporacyjnego systemu hurtowni danych.

Zakres potrzeb związanych z wykorzystaniem systemu BI może być różny w zależności od przedsiębiorstwa. Jego zdefiniowanie będzie miało wpływ na decyzje dotyczące kompleksowej architektury systemów i zależności między nimi. Czy hurtownia danych będzie wspomagać procesy analityczne tylko na poziomie korporacyjnym, czy będzie także wykorzystywana przez lokalne odziały na szczeblu operacyjnym?

Jeśli planujemy szerokie wykorzystanie narzędzi na wielu poziomach organizacji, warto rozpatrzyć i odpowiednio wcześniej zadbać o możliwości rozwijania typowo lokalnych wymagań raportowych. Te mogą być spełnione na poziomie dostępu do narzędzia lub poprzez rozwój lokalnych hurtowni danych. Jeśli jednym z celów systemu jest dostarczanie danych do innych systemów raportowych lub transakcyjnych w przedsiębiorstwie, elementem rozważań powinna stać się automatyzacja takiego procesu.

Systemy źródłowe

Złożoność procesu integracji danych korporacyjnych zależy od liczby i heterogeniczności systemów transakcyjnych, które stanowią źródło dla hurtowni danych. Jeśli lokalne oddziały korzystają z jednego systemu transakcyjnego, idea wdrożenia wspólnego narzędzia raportowego wydaje się słuszna ze względu na niższe koszty utrzymania i jeden dostęp do wspólnych struktur danych. Czasami, gdy działalność lokalnych spółek jest bardzo różnorodna, korzystniej jest rozwijać lokalne hurtownie danych, zasilane lokalnymi systemami, które będą dostarczać dane do hurtowni korporacyjnej na określonym poziomie jakości oraz szczegółowości, według ustalonych reguł i definicji.

Kierunek przepływu może być również odwrotny – dane najpierw trafiają do korporacyjnego repozytorium, a następnie po ich integracji są przekazywane do innych systemów. Przykładem takiej architektury może być konieczność dostarczania zagregowanych danych do systemu transakcyjnego na zasadzie sprzężenia zwrotnego. Hurtownia korporacyjna może również być punktem dostępowym w celu dystrybucji danych do lokalnych systemów analitycznych, co z jednej strony stanowi realizację zasady „jednej wersji prawdy”, a z drugiej zapewnia często pożądaną niezależność lokalnych rozwiązań BI.

SAP w korporacyjnych systemach BI

W ramach SAP NetWeaver Business Intelligence oraz SAP BusinessObjects dostępne są rozwiązania do kompleksowego zarządzania informacją i obsługi procesów decyzyjnych w firmie:

  • integracja i czyszczenie danych – BO Data Services
  • hurtownia danych – SAP NetWeaver BW
  • sformatowane raportowanie – Crystal Reports
  • elastyczne raportowanie i analizy ad-hoc z Web Intelligence
  • kokpity menedżerskie z Xcelsius

Wymagania na dziś i na potem

W ogólnej ocenie korporacyjnego systemu BI najistotniejszy jest stopień spełnienia oczekiwań użytkowników. Kontekst wymagań powinno się rozważać szerzej, niż tylko sumując liczbę raportów, ich przeznaczenie oraz definicje. Nie mniej ważne są dostępność, częstotliwość odświeżania danych oraz ich bezpieczeństwo i autoryzacje.

Jeszcze inne elementy stają się istotne w określonych sytuacjach, np. w systemach operujących w wielu strefach czasowych. W takim wypadku występowanie krótkich okien czasowych nieaktywności biznesowej lub nawet ich brak wymaga specjalnego podejścia w planowaniu procesów ładowania danych, przy jednoczesnym zapewnieniu ciągłości procesów i dostępu do danych. Tylko wcześniejsze prawidłowe zaplanowanie architektury systemu pomoże sprostać takim wymaganiom.

W projektowaniu rozwiązania równie ważne jak uwzględnienie dzisiejszych potrzeb jest zaplanowanie elastyczności systemu pod kątem przyszłych rosnących wymagań, ewentualnych zmian i rozszerzeń. Korporacyjne oczekiwania raportowe niekoniecznie znajdą zastosowanie na poziomie operacyjnym, dlatego architektura systemu powinna zapewniać elastyczność i swobodę w raportowaniu na niższych szczeblach organizacji.

Ostateczna decyzja o kształcie rozwiązania BI będzie wypadkową wielu czynników, jednak podobnie jak przy projektowaniu innych narzędzi IT, także dla hurtowni danych obowiązuje zasada, że jeśli system nie spełni potrzeb użytkowników, będzie bezużyteczny.

Analiza procesów oraz zmiana definicji raportów nie jest wyłącznym obowiązkiem zespołów BI. Inicjatywa zmian czy rozszerzeń systemu powinna zawsze wychodzić od biznesowych użytkowników.

W przypadku projektu korporacyjnego, angażującego wiele osób, a nawet zespołów z różnych szczebli organizacji, odpowiedzialności za wymagania względem BI powinny być jasno oddelegowane.

Business Objects 4.0

Zgodnie z zapowiedzią producenta systemu, w maju 2011 r. SAP AG udostępni najnowszą wersję narzędzia SAP Business Objects XI 4.0. Nowe narzędzia będą umożliwiały m.in.:

  • integrację z sieciami społecznościowymi oraz aplikacjami mobilnymi
  • lepsze i szybsze przetwarzanie dużej liczby danych
  • przetwarzanie w czasie rzeczywistym zarówno danych, jak i niestrukturyzowanych informacji
  • większą integrację z rozwiązaniami z grupy BI oraz zarządzania informacją w przedsiębiorstwie

Zarządzanie i utrzymanie

Korporacyjna hurtownia danych to rozwiązanie żywe, ewoluujące wraz ze wzrostem świadomości użytkowników czy też zmianami rynków oraz procesów. Dodawanie nowych funkcjonalności czy zmiana dotychczasowego podejścia do analizy powinny być możliwe bez potrzeby zmiany całej istniejącej architektury lub przestojów. Dotyczy to także uruchamiania rozwiązania (ang. roll-in) w nowych oddziałach firmy. Nawet jeśli tworzenie takiej otwartej architektury wydaje się zbędnym obciążeniem w początkowej fazie rozwoju systemu, na pewno wysiłek ten zwróci się w przyszłości.

Innym aspektem związanym z utrzymaniem systemu jest odpowiednio zrównoważona procedura zarządzania zmianą. Zbyt skomplikowana i uciążliwa dla potencjalnych użytkowników ścieżka wprowadzenia zmiany spowoduje zaniechanie prób usprawnień systemu. W efekcie prowadzi to do powstania zbyt dużych rozbieżności pomiędzy wymaganiami a stanem faktycznym i niskiego stopnia wykorzystania rozwiązania BI. Podobny skutek będzie też miało przyzwolenia na pochopne i niekontrolowane zmiany w systemie.

Istotny jest również podział ról i odpowiedzialności pomiędzy zespołem korporacyjnym oraz zespołami BI rozwijającymi system zgodnie z wymaganiami lokalnymi. Jedna z najczęściej stosowanych praktyk zakłada, że model danych oraz wspólne raporty są własnością korporacji i odpowiedzialność za nie ponosi centralny zespół BI, natomiast raporty dla użytkowników są rozwijane przez zespoły lokalne.

Warstwa prezentacji danych

Różni użytkownicy mają inne potrzeby związane z tworzeniem, prezentacją, elastycznością oraz interaktywnością raportów. Architektura nowoczesnych systemów hurtowni danych, do których zaliczają się także narzędzia SAP, pozwala na oddzielenie warstwy danych od warstwy tworzenia i prezentacji raportów (narzędzia OLAP). Dzięki temu narzędzia raportowe mogą być niezależnie udostępnione róż-nym grupom użytkowników zarówno na poziomie korporacji, jak i lokalnie. W ten sposób niektóre oczekiwania mogą być spełnione na poziomie aplikacji, bez potrzeby rozwijania oddzielnych systemów.

Przykładem takiego rozwiązania może być możliwość tworzenia własnych analiz przez pracowników zagranicznego oddziału firmy. Zamiast tworzyć dla oddziału system z oddzielnym repozytorium danych, zostaje udostępnione lokalnie narzędzie BI, które pozwala na tworzenie i prezentację własnych raportów bazujących na danych z hurtowni korporacyjnej. Takie podejście pomaga utrzymać korporacyjne standardy raportowania oraz realizować zasadę „jednej wersji prawdy”.

Narzędzia SAP dla Business Intelligence

Platformy SAP BI oraz SAP BusinessObjects wspierają różne modele oraz konfiguracje korporacyjnych systemów analitycznych. Proponowany przez firmę SAP koncept LSA (ang. Layer Scalable Architecture) jest zbiorem dobrych praktyk w modelowaniu skalowalnej, przejrzystej i kompletnej architektury BI. Idea LSA polega na modelowaniu danych i funkcji systemu według dedykowanych warstw, które są reprezentacją usług dla poszczególnych funkcji systemu, to jest ładowania danych, konsolidacji, propagacji, integracji, raportowania itp.

Podejście to zakłada również przepływ danych od najbardziej szczegółowych i niezintegrowanych do zagregowanych i zgodnych z definicją biznesową oraz logiczny podział pionowy informacji według struktur organizacyjnych, regionów, stref czasowych poprzez wszystkie warstwy semantyczne. LSA sta-nowi referencję do tworzenia elastycznego oraz wydajnego w utrzymaniu korporacyjnego rozwiązania Business Intelligence opartego na hurtowni danych SAP BI.

Możliwość wyboru różnego rodzaju narzędzi do tworzenia, analizy i prezentacji raportów, w tym łatwa integracji narzędzi BusinessObjects pozwala elastycznie zarządzać oczekiwaniami użytkowników i wyborem optymalnej architektury. Platforma SAP BI oferuje szeroką gamę funkcji, które wspierają potrzeby korporacyjnego systemu analitycznego. Jednak wykorzystanie narzędzi i kreowanie nowych potrzeb raportowych muszą służyć nadrzędnemu celowi, jakim jest realizacja strategii korporacyjnej.