Architektura analizy z Excelem w roli głównej
Praktyka Dzisiaj
Jaka jest teraz, dzisiaj rola Excela w analizie - to wie dobrze każdy analityk, mający szczęście współpracować z jakimś systemem bi – aj. Opisałem to tutaj. A także jeszcze gdzieś, w formie rozwiniętej, pasjonującej historyjki. Prosto z życia. Tam.
Najpierw musi coś zrobić w swoim bi-aju. A potem?
1) Potem – dostęp tylko w interface’ie
(kontrolce) tabeli przestawnej bi – aja. Własnej
kontrolce bi - aja. (…).
2) Jak analityk koniecznie chce, to może zawsze
użyć innej kontrolki - „Excel”. (czyli „Export do Excela” przyp KR, żeby pewien
czytelnik zrozumiał, że Excel nie jest wprawdzie kontrolką, ale istnieją
kontrolki „Excel” :) ) (…). Wówczas analityk otrzyma w Excelu piękną tabelkę
prostokątną, z nagłówkami, której postać wynika z tego, jak obsłużył
„kontrolkę” TP w (…) bi-aju.
3) Jak wejdziemy w szczegóły, to się okaże, że
musi jeszcze wykonać mnóstwo czynności, które równają się ciągnięciu wózka
inwalidzkiego po błocie. Ale później?
Później może już w
Excelu robić, co chce.
Taka jest powszechna praktyka we wszystkich znanych mi
firmach. Moi polemiści żądają dowodu. Dostarczę go natychmiast, gdy oni dostarczą
mi dowodu, w formie wzoru z całką potrójną, na fakt, że woda jest mokra.
No dobrze. Tak jest dzisiaj. Ale na początku tak nie było.
No dobrze. Tak jest dzisiaj. Ale na początku tak nie było.
Praktyka z wczoraj i co się z nią stało
Opiszmy, jak to widział Microsoft, jeszcze pod wodzą Billa
Gates’a.
Zacytujmy oficjalne opracowanie Microsoftu o hurtowniach
danych z roku 2000:
Microsoft oferuje następujące narzędzia do budowy systemów wspomagania
decyzji: serwer OLAP, usługi PivotTable, OLE DB, DTS, (…), Office 2000 i Microsoft Repository.
(…)
Składniki Office 2000, takie, jak Excel, umożliwiają przeglądanie
danych kostki w arkuszu kalkulacyjnym. Można także napisać kod Visual Basic for
Applications (VBA) i stworzyć moduły programowe dla uzyskania danych i
manipulacji nimi, co umożliwia tworzenie własnych interface’ów dla hurtowni
danych.
W jaki sposób miał się odbywać ten dostęp do hurtowni? Czy to może zupełnie
przebrzmiała sprawa sprzed półtorej dekady i nie ma co do niej wracać?
W tej samej publikacji Microsoft ogłasza:
API OLE DB jest podstawą uniwersalnego dostępu. Interface OLE DB może
być używany przez aplikacje baz danych dla dostępu do każdego typu danych
posiadającego dostawcę OLE DB. (…)
ActiveX Data Objects (ADO) jest narzędziem, które pozwala programistom Visual Basic na dostęp do interface’u OLE DB.
ActiveX Data Objects (ADO) jest narzędziem, które pozwala programistom Visual Basic na dostęp do interface’u OLE DB.
Czy te enuncjacje były jakąś rewelacją w owym czasie? Nawet
wówczas nie. Były konsekwentną realizacją polityki MS w zakresie dostępu do baz
danych dla użytkowników Excela.
Standard OLE DB został ogłoszony przez MS w
roku 1992, wraz z innym standardem – ODBC. Standard ODBC został wprowadzony do
Excela w wersji 5 (rok 1995), wraz z dodatkiem MS Query.
Rewelacją było co innego. W roku wydania omawianej
publikacji standard OLE DB został wprowadzony jednocześnie z serwerem MS SQL 7.0
do Excela 2000. Wraz z procedurą tworzenia offline’owych kostek OLAP!
Microsoft dokonał rewolucji, prawie niezauważonej. W każdym
razie nie było żadnego materiału w tefałenie.
W kilku gabinetach jednak na
pewno odbyły się nerwowe narady. Potwornie drogie systemy analizy
wielowymiarowej, wielkie serwery analityczne i elitarne procesy OLAP zyskały
niemal darmowego konkurenta.
Każdy użytkownik Excela mógł podłączyć się do
kostki OLAP wystawionej na stosunkowo niedrogim serwerze MS SQL. Ba, mógł sobie
sam wyprodukować kostkę OLAP na swoim PC-ie dysponując programem MS Excel 2000
wartości 500 dolarów. Wydawało się, że Microsoft dokonał kolejnego wyłomu w
samozwańczych „świątynnych twierdzach” informatycznych.
Zdemokratyzował
profesjonalną analizę biznesową. Tą drogą szedł jeszcze kilka lat, doskonaląc
analityczne funkcjonalności Excela w wersji 2003. Potem, po odejściu Gates’a ta
konsekwentna linia rozwojowa, załamała się w połowie lat 2000 –nych. Jednym z
sygnałów odwrotu było wyłączenie kreatora kostek w wersji Excela 2007 a także
regres w istotnych dla dostępu do danych funkcjach serwera MS SQL 2008.
Jaka może być hipoteza wyjaśniająca, dlaczego ta linia
rozwojowa się załamała?
Może to, że Microsoft poważnie zagroził interesom biznesu
analiz? Wówczas właśnie nastąpiła „odpowiedź” w postaci systemów Bi Aj? A w
Microsofcie nastąpiła akurat, pechowo, zmiana warty?
Wracamy do dnia dzisiejszego
Dzisiaj, zamiast napisać
„Składniki Office 2013, takie, jak Excel, umożliwiają przeglądanie
danych kostki w arkuszu kalkulacyjnym”.
Musimy napisać: Najpierw
musisz użyć bi-aja!
A potem?
Jak analityk koniecznie chce, to może zawsze użyć ( w bi-aju) innej
kontrolki - „Excel”. (…). Wówczas
analityk otrzyma w Excelu piękną tabelkę prostokątną, z nagłówkami, której
postać wynika z tego, jak obsłużył „kontrolkę” TP w (…) bi-aju.
Konsekwencje dziwnego rozwoju analizy
Tak właśnie prawidłowa, (albo, jak kto woli, genialna w swej prostocie i konsekwencji) koncepcja Microsoft’a, koncepcja architektury profesjonalnej analizy, w której Excel jest pełnoprawnym elementem, zintegrowanym ze środowiskiem przez standardy informatyczne, takie jak OLE DB, została sprowadzona do prymitywnej, tępej i egoistycznej koncepcji bi-ajków.
„Bądź naszym użytkownikiem, chcesz, czy nie. Ostatecznie możesz sobie
wypluć coś do Excela”.
Kontrolka „Excel”, czyli miłościwie panujący klawisz „Export
do Excela” zabiła „architekturę służebną” która udostępniała dane dla Excela
„raz na zawsze” i zastąpiła ją „architekturą ochłapu”, rzucającą te dane, jak
ochłap. I utrzymująca stan „karmienia”, czyli stałego uzależnienia.
W wyniku otrzymujemy podział świata analizy na dwie części, odcięcie analityków od głównego nurtu informatyki, skazanie ich na rolę
outsiderów, obciachowych „użytkowników excelka”.
Konsekwencje tej sytuacji są negatywne i wielorakie.
Zamiast promowania efektywnych,
profesjonalnych standardów, procesów i architektury wśród analityków, oferuje
się im (za pośrednictwem ich zdezorientowanych szefów, omamionych przez
specjalistów od sprzedaży) fałszywą alternatywę: albo – bi-aj albo pozostanie w
zatęchłym „informatycznym slumsie exceliozy”.
Analitycy się nie buntują. Robią swoje i
biorą swoje. Jak im wdrożą bi-aja, dopiero się okaże, jak są potrzebni z tym
swoim obciachowym excelkiem.
„Rządzą” tam - biegli w swoim
rzemiośle „guru”, power-userzy, specjaliści od negocjacji z „bi – ludkami”, aby
uzyskać jakiś „raport”, z którego „jakoś” się skorzysta w analizie. Im
pozostają exporty, przeklejki i excelioza, czyli analityczne getto na obrzeżach
bi-ajów z ich rzekomo jedynie profesjonalnymi raportami.
Ale co za różnica? Życie toczy
się gdzie indziej.
Wnioski
Co wynika z tego opisu założeń architektury procesu analizy
z przełomu wieków oraz jego konfrontacji z dzisiejszym podejściem?
I co mnie tak uderzyło w pełnej poczucia wyższości tyradzie
wygłoszonej przez Pewnego Informatyka, specjalisty BI, do analityka, ciekawego
świata i grzecznie zadającego pytania?
OLAP to technologia. (…) Nie ma możliwości i nie można tego
porównywać bo to zupełnie inne bajki.
Otóż zdałem sobie sprawę, że mam do czynienia ze sceną
symboliczną. Oto rozmawiają ze sobą, jak gęś z prosięciem, dwaj przedstawiciele
tej samej dziedziny biznesu, tyle, że z różnych segmentów procesu, który obaj
realizują. Te różne segmenty procesu zakładają wprawdzie różne kompetencje u
każdego z uczestników, ale powinna występować przynajmniej wspólnota celów i
zrozumienie wzajemnego uzależnienia.
A jaki obraz wyłania się z tej konfrontacji postaw?
Z jednej strony - postawa ciekawości i pokory. Wiadomo –
obciachowy analityk. Nie tylko dobrze wychowany, ale zna swoje miejsce. Jest
„tylko” analitykiem.
Z drugiej strony – pycha, przekonanie o swojej niewątpliwej
kompetencji oraz o niekompetencji ludzi „z innej bajki” i …kompletne zagubienie
celu swojej działalności.
Kompletnie inne bajki? Nie można tego porównywać? Absurd?
Tak, dokładnie tak. Może z wyjątkiem absurdu. Samo życie.
Koniec kłótni. Z mojej strony.
Brak komentarzy:
Prześlij komentarz