Przejdź do głównej zawartości

Spreadsheet Oriented Architecture (SOA) Przewrót kopernikański w Business Intelligence (1)



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 wyeksportować 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 exportować 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 odcinkuchcemy je przedstawić.

Komentarze

  1. Ten wpis jest zwiastunem "cyklu architektonicznego" publikacji "papierowej", ciągle mającej wyższą rangę, niż internetowa, trzech autorów:
    Wojciecha Gardzińskiego oraz Jakuba i Krzysztofa Rumińskich.

    To ostatnia litera(A) -
    w czteroliterowcu I-D-E-A.

    Zdaję sobie sprawę, że mam zaległości z wyczerpaniem tematu związanego z zwłaszcza z literą E.

    Bardzo przepraszam. Obiecuję, że nadrobię.

    OdpowiedzUsuń

Prześlij komentarz

Popularne posty z tego bloga

Wstęp. Do czego służy Excel?

Witam wszystkich użytkowników Excela.
Na początek wypada się przedstawić.
Nazywam się Krzysztof Rumiński (http://www.goldenline.pl/krzysztof-ruminski). Postanowiłem, stosownie do najnowszej mody, prowadzić bloga o Excelu.
Jestem inżynierem mechanikiem, informatykiem, specjalistą w dziedzinie, zwanej wdzięcznie „Business Intelligence”, w skrócie BI.

Co to jest Business Intelligence (BI)? Panuje teraz moda na angielszczyznę. Tak, jak na przełomie osiemnastego i dziewiętnastego wieku, panowała wśród szlachty moda na francuszczyznę, zaś w średniowieczu mieliśmy do czynienia z „makaronizmami”. Wyjaśnijmy więc, co ja rozumiem przez ten termin, bo bezrefleksyjne używanie współczesnych makaronizmów jest źródłem wielu nieporozumień.
BI to dziedzina informatyki wspomagająca przygotowanie informacji przydatnej do zarządzania na podstawie danych.
Anglosasi często słowo information zastępują terminem intelligence. Wyjaśnienia encyklopedyczne i słownikowe są tu mylące. Służba Wywiadu, czyli Agencja …

Referencje dla architektury i podejścia SOA

Od 2012 roku prowadziłem na swoim blogu akcję promowania architektury i podejścia SOA, której koncepcję opublikowaliśmy we trzech , współtwórcą tej architektury, Wojciechem Gardzińskim oraz Jakubem Rumińskim(zbieżność nazwisk nie całkiem przypadkowa, ale chyba nie przynosząca mi wstydu), analitykiem i konsultantem międzynarodowych korporacji, który ją weryfikował i uwiarygadniał z punktu widzenia realiów światowego biznesu.

Teraz czas na innego rodzaju uwiarygodnienie.

Architektura i podejście SOA nie jest tylko nową, oryginalną koncepcją.
Jest produktem komercyjnym, posiadającym pierwsze, ale poważne i sprawdzone na przestrzeni co najmniej dwóch lat, referencje biznesowe w dużej instytucji publicznej.
Podaję jednak referencje z trzech kolejnych lat.
Wyłania się z nich w sposób dla nieco zaskakujący, konsekwentna linia rozwojowa podejścia SOA.
To właściwie logiczne: Wzięła się nie z "nagłego olśnienia".
Wyłoniła się, jako logiczny (i nieubłagany) skutek naszych doświadczeń, …

Codd'a 12 zasad zarządzania bazą danych dla OLAPu

(Codd's paper)
Jako glossa do nieudanej ale burzliwej "dyskusji" o tym, czym jest OLAP i czy tabela przestawna i OLAP to inne bajki, zamieszczam podstawowy tekst tego Ojca Założyciela dzisiejszej technologii bazodanowej Edgara Franka "Teda" Codd'a.
W tekście wytłuszczam te fragmenty, które bezpośrednio odnoszą się do przedmiotu sporu. W komentarzach (kursywą) wyjaśniam, jakie wypowiedzi mojego adwersarza i moje mają tu zastosowanie. Dyskusja ta ma charakter nieco abstrakcyjny, ale dla genezy dzisiejszych "problemów z analizą biznesową", ma fundamentalne znaczenie. Moim skromnym zdaniem. Tłumaczenie zasad z angielskiego tekstu - własne.
Zaczynam: W 1985 Edgar F. Codd napisał artykuł, określający zasady dla Systemów Zarządzania Relacyjnymi Bazami Danych (RDBMS systemów zarządzania), które zrewolucjonizowały branżę IT.
Pamiętam, jak czytałem jeszcze wcześniejsze teksty Codda, wówczas pracownika IBM, w materiałach szkoleniowych tej firmy, jeszcze nie z…