SYSTEM 2001 --------- Praktyczny Business Intelligence
Strona główna
Produkty i usługi
Szkolenia i warsztaty dla firm
Case Studies
Pliki do pobrania
O nas
D jak Dane
E jak Entropia cz.1
E jak Entropia cz.2
Architektura SOA, istota
Architektura SOA, geneza koncepcji

 


Niniejszy tekst jest autorstwa Krzysztofa Rumińskiego. 
Ponieważ jest wynikiem współpracy koncepcyjnej trzech autorów: Wojciecha Gardzińskiego, Krzysztofa Rumińskiego i Jakuba Rumińskiego, jest pisany w imieniu wszystkich. 
Styl wypowiedzi – na odpowiedzialność KR

 
W wersji bardziej "parlamentalnej" ten tekst ukazał się w  numerze z sierpnia 2012 czasopisma "Controlling i Rachunkowość Zarządcza". Muszę przyznać, że został tam znacznie sprofesjonalizowany. Redaktor nieco go przystrzygł, skrócił, niektóre rysunki dał grafikowi do przerobienia. Pełen profesjonalizm!

Serdecznie polecam i pozdrawiam Redaktora Stanisława Woźniaka.
-------------

Wstęp
Kilka lat temu opublikowaliśmy w CiRZ cykl artykułów o architekturze środowiska analiz (kolejne numery między sierpniem 2008 i styczniem 2009).
Po tych publikacjach, dalej, pilnie śledziliśmy trendy w dziedzinie „Business Intelligence”.

Znaliśmy tę praktykę niejako z zewnątrz:
a) Z doświadczeń  zdobytych podczas wdrożeń naszych rozwiązań 
b) Z nadzoru wdrożeń systemów ERP, zawierających funkcjonalności raportujące i moduły BI.

Mieliśmy relacje z doświadczeń naszych klientów z wdrożeniami „zaawansowanych” systemów BI, w których nie dane nam było im pomóc i uchronić ich przed tym, czego się obawialiśmy. A co się potwierdzało z fatalistyczną precyzją.

Mamy również informacje z pierwszej ręki: od uczestników, prowadzonych przez nas od siedmiu lat kursów dla analityków biznesowych, którzy wywodzą się w ogromnej większości z dużych firm i korporacji, notowanych na wszystkich giełdach świata.  Przeszkoliliśmy ich już kilka tysięcy.

Niniejsza publikacja jest skutkiem kilkuletniej pracy nad rozwinięciem, uściśleniem i ogłoszeniem nowego paradygmatu architektury środowiska  analiz biznesowych.

I jest adresowana szczególnie do analityków dużych firm. Do nich zwracam się w imieniu Jakuba Rumińskiego, ich kolegi z branży, pracownika światowej korporacji, znającego te problemy od podszewki.
Jego inicjatywa i pomysł skrzyżowane z naszym doświadczeniem i, wypracowywaną przez lata, koncepcją architektury środowiska analiz dały w wyniku pewien nowy, naszym zdaniem, stan rzeczy.
Przedstawiam go teraz Państwu, w imieniu wszystkich trzech współpracowników, pod rozwagę.


Architektura tradycyjna
Gdy wchodzimy do dużej korporacji, nasze pierwsze wrażenie - to bramki wejściowe, drzwi otwierane zamkami elektronicznymi i… krzątający się ludzie z zawieszonymi na szyi identyfikatorami, które te drzwi otwierają. A przynajmniej niektóre, zgodnie z pozycją w firmie każdego z tych eleganckich pracowników.
Sterowaniem tych drzwi oraz dostarczaniem tym ludziom informacji zajmują się drogie, jak skarby sezamu, systemy informatyczne, obsługiwane przez tabuny informatyków i pewną, niemałą liczbę ich niezwykle kompetentnych szefów.

Systemy informatyczne są zorganizowane w sieć powiązań i „jakoś” ze sobą współdziałają. Serwery szumią cicho i elegancko. Gdy oglądamy to nieco z boku, mamy wrażenie potęgi techniki i pracowitej krzątaniny kompetentnych specjalistów wokół ważnych i trudnych do zrozumienia problemów informatycznych, których nie ogarniamy, ale na które patrzymy z nabożnym szacunkiem.
Pamiętamy na przykład, jak to podczas szkolenia pewien menadżer projektu prezentował taki slajd, opisujący, jak firmowa informatyka jest zorganizowana, aby nam służyć.

Oto ten slajd :
Widok 1.Architektura środowiska analiz

 
 

Trochę to skomplikowane. Budzi szacunek. Co jest na tym schemacie, tak naprawdę?
-Tak naprawdę jest tu przedstawiona architektura funkcji raportowania zarządczego, która chce się „wybić na niepodległość”, czyli, mówiąc wprost, obyć się bez pewnego czynnika „dodatkowego”. Jakiego? Zaraz się okaże.
My, analitycy, mamy wprawdzie swoje przyziemne problemy, ale wreszcie jesteśmy przeszkoleni i wiemy, co to znaczy trójwarstwowa architektura analiz.  Teraz dopiero lepiej rozumiemy taki uproszczony schemat:


Widok 2. Klasyczna, trójwarstwowa, architektura analiz biznesowych.




Włożyliśmy wiele pracy przy wdrożeniu systemu BI. Umiemy uruchomić platformę BI, odświeżyć zawartość hurtowni danych (HD) i wykonać każdy raport zdefiniowany na platformie.

Ale tak się składa, że Szef chce od nas codziennie pewien raport. Nasz system BI, wdrożony wzorowo przez renomowaną firmę, przewidywał ten raport i my umiemy go uzyskać. Ale on nie jest dobry. On jest prawie dobry…. Prawie. Które czyni wielką różnicę.

Wdrożenie platformy BI odbyło się sprawnie,  bo trwało … prawie dwa lata. I odbyło się według wszelkich reguł sztuki. Jesteśmy w końcu wiodącą na światowym rynku korporacją, liderem w swojej branży. 

Żartów nie ma, procedury są surowe, w razie czego lecą głowy. Analitycy zostali przeszkoleni, podpisali protokoły odbioru, raporty zostały odebrane. Dostawca wystawił parę faktur, na parę milionów dolarów.

Ale to musiało potrwać. W międzyczasie zmieniły się warunki biznesu, doszły nowe wymiary analizy. Korporacja od miesiąca stosuje nowe kryteria oceny miary biznesowej ( takich, jak Sprzedaż, Rentowność), ponieważ inżynierowie zaprojektowali nowy produkt o innowacyjnych cechach, a koledzy, odpowiedzialni za marketing, wymyślili nowy sposób promocji produktu.

I kierownictwo chce wiedzieć, jakie cechy produktu są najważniejsze dla zwiększenia sprzedaży i jaki wpływ na jej zwiększenia ma promocja.

Dzisiaj, raport, znajdujący się na platformie BI, „prawie dobry”, jest praktycznie bezwartościowy.

Jest – właśnie! - „prawie dobry”. Jak z pewnej reklamy piwa: „Prawie robi wielką różnicę”.
Różnica jest mianowicie taka, że na platformie BI go NIE MA. A od niego właśnie zależą decyzje, zapadające na kierowniczych gremiach, podczas międzynarodowych telekonferencji. Z udziałem najważniejszych menagerów korporacji.

Szef przykazuje surowo, że naszym psim obowiązkiem jest „wystawienie” tego raportu  codziennie do dziewiątej rano. Na platformie prezentacyjnej, dostępnej tym gremiom. Z aktualnymi na dzień dzisiejszy danymi.

I odpowiadamy przed nim osobiście. Głową.

I tu się zaczyna dopiero właściwa opowieść
Sporządzenie nowego, w Excelu, wymaga kilku godzin pracy -w przypadkach bardziej szczęśliwych. 

Kilkunastu lub kilkudziesięciu, w przypadkach mniej szczęśliwych.
Prawie „dobry raport” trzeba zaimportować do Excela, uzupełnić o dodatkowe dane.
Znajdują się w systemie transakcyjnym, nie w hurtowni, a więc poza platformą BI. Albo poza nim, a więc, tym bardziej, poza BI.
Konkretnie, dane te są zawarte na dziesiątkach plików Excela, przygotowanych według uzgodnionego w ekspresowym tempie szablonu, przez pracowników korporacji, znajdujących się w na kilku kontynentach.

Analityk musi otworzyć kilkadziesiąt plików, pobrać z nich po jednej liczbie, coś podsumować, przeliczyć i stworzyć praktycznie od nowa raport  w Excelu.

Ten raport umieszcza z westchnieniem ulgi o godzinie 8.50 na platformie prezentacyjnej korporacji. Jeśli wszystko poszło bez zakłóceń. A jeśli nie? Lepiej o tym nie myśleć.

Po pewnym czasie sprawny analityk niektóre czynności zautomatyzuje sobie przy pomocy VBA, języka programowania na platformie Excela.  I skróci kilkakrotnie czas jego przetwarzania. Ale to wszystko, co może zrobić.

Czy to jest sytuacja wyjątkowa? Czy ktoś powinien beknąć? A może dostawca systemu BI powinien zwrócić pieniądze?  

Na wszystkie te pytania jest jednobrzmiąca odpowiedź -  nie, nie i jeszcze raz NIE.
To sytuacja typowa, powszechna i powtarzalna, jak powrót zatłoczoną szosą pod koniec upojnego weekendu.

Oczywiście tego nie można było przewidzieć w obwarowanym procedurami przedsięwzięciu. System transakcyjny, który rejestruje biznesowe fakty, często nie jest w stanie tych nowych cech zarejestrować. Nie mówiąc o systemie BI, który, w swojej trójwarstwowej architekturze, żywi się danymi systemu transakcyjnego. I niewiele więcej.

Cóż na to mogą poradzić nasi wspaniali informatycy za szklanymi drzwiami? Czy są to ludzie niekompetentni? A może nasi sprawni, jak kierowcy formuły jeden i pół, menadżerowie nie potrafią nam zorganizować pracy?

Czy też, ubrani w eleganckie garnitury, przedstawiciele renomowanej firmy BI nie dotrzymali słowa i dostarczyli nam jakiś nieprzydatny produkt, który miał być ostatnim krzykiem informatycznej i biznesowej mody a, w rzeczywistości, jest tylko „prawie” rewelacyjny?

Nie, nie i jeszcze raz NIE.

Błąd w założeniu
Problem nie polega na tym, żeby dostarczyć jeszcze nowocześniejszy serwer wyposażony w jeszcze jeden rdzeń. Ani jeszcze bardziej zaawansowane oprogramowanie drążące dane wyposażone w jeszcze jeden algorytm Bayesa – Cohen’a. Przy całym szacunku dla autorów algorytmów drążenia danych, w tym pana Iry Cohena (IL, USA). 

W każdym razie, naszym zdaniem, to nie jest problem kluczowy dla przedmiotu naszych rozważań.
Można by powiedzieć z pewną doza przesady, że postęp w dziedzinie BI skupia się na gadżetach, podobnych do szukania najbardziej wytwornego dźwięku zamykania drzwi w nowych modelach luksusowych samochodów. 

W luksusowych samochodach być może zresztą jest już do rozwiązania tylko ten problem. Ale analizy biznesowe i dziedzina BI bynajmniej nie są na tym etapie, by spocząć na laurach i zająć się głównie tego typu zagadnieniami.

Problem kluczowy bowiem leży w niewłaściwej architekturze środowiska analiz biznesowych.
Oczywiście dobra architektura środowiska analiz nie jest jedynym warunkiem powodzenia wdrożenia przedsięwzięcia informatycznego.

Faktem jest jednak, że znajduje się w centrum tych problemów, gdzieś pomiędzy obowiązkami menadżera projektu i rzecznika użytkownika z jednej strony - i problemami implementacji, administrowania zasobami, aż po problemy struktury danych – z drugiej.

Centrum!

Może warto się na tym skupić?
Zamiast architektury „przedkopernikańskiej”, klasycznej, tradycyjnej - proponujemy architekturę przełomu, architekturę zorientowaną na skoroszyt, po angielsku - Spreedsheet Oriented Architecture (SOA).

Zobaczmy schemat architektury tradycyjnej z punktu widzenia prawdziwego rzecznika użytkownika:

Widok 3. Klasyczna trójwarstwowa architektura analiz biznesowych z punktu widzenia rzecznika użytkownika, czyli analityka biznesowego.



Z tego, co wiemy z prawdopodobieństwem bliskim pewności, architektura analiz, w przytłaczającej liczbie firm, korporacji i agend rządowych, wygląda właśnie w ten sposób.
Co to oznacza? Ma to głębokie konsekwencje w przebiegu analizy. Czyli w tym, jak naprawdę działa system BI w środowisku, w którym został umieszczony.

Realna analiza biznesowa w korporacji
Jak wygląda typowa analiza biznesowa w korporacji? I to w korporacji, posiadającej wzorową architekturę trójwarstwową, oraz wdrożony system BI?

  • Menadżerowie nie są samodzielni. Mogą korzystać tylko z Platformy Raportującej ich systemu BI. Reszta może być uzyskana tylko za pośrednictwem informatyków

  • Analitycy zajmują się powtarzalnymi czynnościami obsługi  istniejących raportów w Excelu. Głównie … obrabiają dane, wepchnięte do skoroszytu z różnych źródeł. 


Czyli: żmudne i frustrujące przeklejanie i przerabianie.
Powstają ogromne straty, wskutek braku czasu na twórczą analizę

Analityk w korporacji pracuje prawie zawsze tak samo, jakby obowiązywało prawo starzejącego się skoroszytu.
  • Uzyskać nowe surowe dane. BI służy również jako źródło surowych danych. Równie często sięga się wprost do systemu transakcyjnego.
  • Czym prędzej wyeksportować do Excela
  • Przekleić dane do skoroszytu (raportu) i odświeżyć
  • Rozesłać/umieścić na platformie prezentacyjnej
  • I tak co dzień, co tydzień, co miesiąc …


Przyczyna tego stanu rzeczy jest prosta: Wszystko można przeanalizować w Excelu i WSZYSCY tak robią

Wszyscy są bohaterami paradoksu Excela.

Zaś sam Excel - to wstydliwe, niemal nielegalne narzędzie dodatkowe „niższego rzędu”, istniejące w cieniu systemów BI. Umieszcza się go w architekturze środowiska analiz w charakterze dodatku, niczym kwiatek do kożucha, a właściwie niczym gumowce do garnituru. Bo, choć chodzimy w garniturach pod nogami mamy… błoto.

Uważny czytelnik zwróci uwagę, że każdy system BI zawiera narzędzia eksportu do Excela.
A, nawet, licencje Excela są dodawane do tych systemów w komplecie, gratis! 

W rzeczywistości jednak, producenci BI doskonale wiedzą, że MUSZĄ tak robić, bo użytkownik MUSI, produkowane przez owe systemy BI, raporty i tak importować do Excela, i tak obrabiać dalej, i tak konsolidować z innymi informacjami spoza BI, i tak… robić dokładnie to samo, co robiłby bez owego BI.

Te licencje Excela to ratunek dla BI, nie gratis.
Racja, zapomnieliśmy. Trzeba oddać sprawiedliwość. Pełny obraz architektury tradycyjnej wygląda tak:

Widok 4. Pełna Architektura Praktyczna



Mamy jeszcze eksport do Excela.

Architektura SOA, czyli zapowiedź przewrotu
Wyjdźmy od prostego założenia.
Niczym warzywa w zupie z dziecięcego wierszyka Jana Brzechwy, kończymy - zawsze w Excelu.
No to może, zamiast dokonywać nadludzkich wysiłków, by Excela zastąpić , a co za tym idzie,  naśladować go i podrabiać, po prostu ... uznać jego kluczową rolę?

Może przezwyciężyć paradoks Excela, przyjmując zasadę:

Skoroszyt Excela - to standardowy format raportu, 
znajdujący się w centrum architektury analiz
?!
W centrum!

Jeśli umieścimy skoroszyt Excela w centrum architektury analiz, a nie, jak to się dzieje dotąd, jako peryferia analizy, oddzielone głębokim, błotnistym bajorem, to konsekwencje mogą być podobne, (toutes proportions gardées, oczywiście), jak umieszczenie Słońca w centrum układu kopernikańskiego.

Wiadomo, jakich cudów dokazywali astronomowie przedkopernikańscy, żeby wyznaczyć przewidywane położenie gwiazd na niebie przy założeniu, że Ziemia jest nieruchoma i jest centrum Wszechświata. Metody obliczeń istniały, ale były o rząd wielkości bardziej skomplikowane, niż te, które zostały opracowane po Koperniku.

Może więc zmiana centrum architektury środowiska analiz wywoła równie zbawienne skutki? Jak sądzicie, Szanowni Czytelnicy?
To na razie tylko przeczucie. Wasze przeczucie, mam nadzieję. Bo my już osiągnęliśmy zbawienne wyniki takiego założenia.
I w następnym odcinku chcemy je przedstawić.

Strona główna
Produkty i usługi
Szkolenia i warsztaty dla firm
Case Studies
Blog Krisa
Pliki do pobrania
O nas