Dyskusja o architekturze SOA na portalu GoldenLine

Komunikat:
Tutaj, to jest cicho, jak w Puszczy Białej w ciepłe jesienne popołudnie. Taka internetowa enklawa. Coś pomruczę, jakiś gołąbek pokoju przeleci, ja się za nim popatrzę.

Życie według dzisiejszych, miastowych standardów głównego nurtu toczy się gdzie indziej.
Podaję link do dyskusji o ogłoszonej doktrynie architektury SOA

Dyskusja o architekturze SOA na portalu Golden Line

Dyskusja jest ciekawa.
Najciekawsze jednak jest nie to, że nie uczestniczą w niej analitycy.
Ani to, że bi-ludki zanim cokolwiek zrozumieją, idą w swoją stronę, albo trollują, nie kryjąc pogardy.

Ciekawe jest, że ktoś się zainteresuje i chce się dowiedzieć więcej.
A dla Was?

Ale przy okazji...

w związku z dyskusjami, które teraz tam odbywam, jako debiutant, nasuwają mi się refleksje.
Jak ktoś się odezwie, sprawdzam jego profil, żeby wiedzieć coś więcej o komentatorze. I lepiej go zrozumieć.

Czasem profile komentatorów są dużo bardziej interesujące, niż ich komentarze.
Rzadziej jest odwrotnie.
No cóż. Profil - to marketing. Komentatorstwo - to towar na półce. Normalka.

GoldenLine ma dobry projekt funkcjonalny, lepszy od innych portali.
Skupia się na dwóch ważnych rzeczach, dotyczących człowieka: kim jestem i co mam do powiedzenia .

Kapitalna jest możliwość błyskawicznego prześledzenia wszystkich wypowiedzi dyskutanta i zorientowania się, czy to zwykły troll, czy poważny specjalista.
Dobre jest również to, że każda wypowiedź jest wartościowana przez czytelników.

Wygłoszę teraz kontrowersyjną opinię, w dobie mody na powszechną anonimowość.
Anonimowość rodzi brak odpowiedzialności.

Tutaj dyskusje nigdy nie schodzą poniżej pewnego poziomu (kultury).
Spotkałem się z ostrymi atakami, demagogią, spekulacjami o moich intencjach i mojej przyszłości. Ale to mały pikuś przejawów trollowania, wobec tego, co mogło by mnie spotkać, gdyby wypowiadający się komentator nie musiał trzymać nad głową swojego identyfikatora.

Jestem ostrzegany, że część tożsamości może być fałszywa. Nie wykluczam. Mam nawet jakieś konkretne podejrzenia.

Ale nawet fałszywy "specjalista" od Bardzo Ważnego Produktu nie ucieknie od swojej prawdziwej tożsamości. Nawet, jeśli stoi za nim sztab manipulantów.

Szkoda, że inne portale, nawet te, dopuszczające nicki typu "salamandra120" nie stosują tych funkcjonalności. Mało tego, wycofują się z tego dobrego, co mieli.
Myślałem o tym

Otwierają w ten sposób pole do zaśmiecania Internetu breją chamstwa, agresji i beztreści .

Mam nawet pewną spiskową teorię, dlaczego tak robią. Na wszelki wypadek się z nią nie zgadzam. :)
Portalowcy wolą promować swój portal, niż osobowości, które mogły by wyrosnąć na bazie funkcjonalności, które bez oporów stosuje GL.
A oni chcą sami tworzyć swoje autorytety.

Na razie nie mogę znaleźć sposobu walki z wyrastaniem niezależnych autorytetów na tym portalu. 
Poza prymitywną cenzurą, czyli banem.

Czy wyrastają?
No. Jedna gwiazda już jest. Wiem, ale nie powiem :)

GoldenLine is cool!

Praktyka korporacyjna a postulaty SOA

Ukazał się listopadowy numer czasopisma Controlling i Rachunkowość Zarządcza.

Nie ma tam wielu rysunków, więc nie będzie wielu modyfikacji. Odsyłam do czasopisma. 
Tutaj swobodna trawestacja tekstu. Bez utraty istoty.

W poprzednich dwóch (pierwszy Wprowadzenie do architektury -  i drugi - Istota SOA) odcinkach opisaliśmy excelocentryczna architekturę analiz, określoną skrótem SOA.

Taka architektura zapewnia władzę nad analizą tym, którzy za nią odpowiadają – analitykom. 

Skonfrontujmy teraz te postulaty z praktyką korporacyjną.

Czytelnikom zaś proponujemy potraktować rozważania z dwóch poprzednich odcinków naszego cyklu, jako swoisty klucz interpretacyjny poniższego tekstu.

Sformułujemy wnioski, godne kopernikańskiego przewrotu, jaki postulujemy.

Struktura typowej korporacji

Typowa korporacja podzielona jest zazwyczaj na kilka jednostek funkcjonalnych.

Przykładowo: dział marketingu, dział sprzedaży, dział łańcucha dostaw, dział finansów, dział HR i administracji. Wreszcie dział IT, który zajmuje się zapewnieniem właściwej infrastruktury informatycznej wspierającej wypełnianie wszystkich wyżej wymienionych funkcji.

Zauważmy, że podzielenie wielkiego systemu, jakim jest korporacja, na kilka wyspecjalizowanych jednostek, choć porządkuje pracę i zadania, to jednak powoduje, że każda z tych jednostek staje się, w pewnym sensie, wyspą, połączoną z innymi częściami układu jedynie czymś w rodzaju mostu. 

Łączenie jednostek funkcjonalnych w korporację

Czasem most, łączący dwie jednostki, to autostrada, jak w wypadku połączenia działów marketingu i sprzedaży, które stosunkowo dobrze wzajemnie rozumieją swoje zadania.

Czasem to tylko droga ekspresowa, jak połączenie działów marketingu i łańcucha dostaw. Tam, niestety, często brakuje zrozumienia, że, choć byłoby dobrze wprowadzić do planu produkcyjnego jakiś produkt, to jednak nie da się go wyprodukować lub dostarczyć na czas.

Dział finansów i HR połączony jest z pozostałymi zazwyczaj drogą jeszcze niższej rangi.

Najgorsze połączenie z pozostałymi działami ma jednak zwykle dział IT. Most, łączący ten dział z innymi, to zazwyczaj jednopasmowa droga gminna, nawet nieutwardzona.

Skąd się bierze ten brak komunikacji? 

Problem komunikacji z działem IT

Jednym z najważniejszych źródeł trudności jest przede wszystkim brak fachowej wiedzy na temat technologii informatycznych. Aby zdobyć orientację w zakresie roli łańcucha dostaw, marketingu czy HR, a potem dyskutować, niemal jak równy z równym, z fachowcami tych dziedzin, wystarczy jakieś szkolenie i trochę praktyki. Natomiast, jeśli chodzi o technologie informatyczne, sprawa nie jest już taka prosta. Nawet pobieżne zrozumienie ich działania wymaga minimalnej specjalistycznej wiedzy i ścisłego umysłu. Stąd firmowi informatycy tworzą coś w rodzaju zamkniętego klanu.

Pozycja analityka biznesowego miała ten problem rozwiązać. Miał on być osobą, która jednocześnie rozumie problemy technologii informatycznych i problemy biznesu. Coś w rodzaju pośrednika.

To oczywiście częściowo załatwia sprawę, ale każdy, kto choć raz próbował rozmawiać przez tłumacza, zdaje sobie sprawę z trudności komunikacji. Taki dialog pozbawiony jest płynności i spontaniczności, pojawiają się straty niedokładnego tłumaczenia, nieporozumienia i opóźnienia.

Dochodzą tu jeszcze częste braki w wiedzy informatycznej analityków, które stawiają informatyków w uprzywilejowanej pozycji. Luki wiedzy analityka mogą prowadzić w skrajnym wypadku do sytuacji, że jeśli informatycy powiedzą: „tego nie da się zrobić, to jest niemożliwe etc.”, analityk praktycznie jest bezradny, nie ma możliwości w sposób standardowy tego zweryfikować ani do kogo się odwołać ze swoimi racjami.

Podobne trudności występują zresztą przy zakupie lub tworzeniu nowej aplikacji. W tym wypadku aplikacji „krytycznej dla biznesu” (mission critical application MCA) lub typu BI.

(...)

Porażki wdrożeń systemów BI

Spróbujmy odpowiedzieć sobie na pytanie, co oznacza porażka w przypadku takiego wdrożenia. Jest to ważne o tyle, że najczęściej miarą sukcesu wdrożenia jest fakt, że system działa zgodnie ze specyfikacją.

Rzut oka na codzienność analityka biznesowego

Współczesne korporacje są całkowicie uzależnione od systemów informatycznych. Jakakolwiek awaria systemu informatycznego oznacza zawsze kłopoty i straty biznesowe, niekiedy – zagrożenie płynności sprzedaży, czasem, wręcz, płynności finansowej. A nawet widmo bankructwa. System informatyczny – to system nerwowy organizmu, jakim jest korporacja.

Każdy element procesu znajduje swoje odzwierciedlenie w jakiejś transakcji w systemie. A „system” oznacza właściwie kilka systemów transakcyjnych połączonych ze sobą nawzajem - odpowiedzialnych za proces składania zamówień, produkcję, sprzedaż i inne.

Każdy z tych systemów oferuje jakiś rodzaj eksportu danych, które analitycy korporacyjni wykorzystują do tworzenia raportów dla menadżerów.

Po jakimś czasie analitycy organizują sobie te dane z kolejnych okresów, tworząc na swoich komputerach coś w rodzaju podręcznych hurtowni danych, tak, iż można na ich podstawie robić analizy, sięgające daleko wstecz.

Administrują oni tymi hurtowniami, a właściwie „hurtowniami”, albo - quasi – hurtowniami, czy po prostu (własnymi – lokalnymi) zasobami danych, przy pomocy standardowych narzędzi MS Office. Zazwyczaj, przy minimalnym lub zerowym wsparciu działu IT - jakoś sobie radzą. Przeszkody w rodzaju zróżnicowanych formatów eksportowanych przez systemy danych, brakujących atrybutów danego zjawiska itp. itd. pokonują nad wyraz dzielnie.

Wsparcie działu IT zazwyczaj ogranicza się do okresowych "zrzutów" danych do pliku tekstowego lub do formatu skoroszytu Excela.

Innymi słowy - analitycy spędzają najwięcej czasu (mniej więcej – od 70-ciu do 90-ciu procent swojego czasu pracy) na "obróbce danych". Czyli - na przetworzeniu ich do formy, która może następnie być analizowana za pomocą tabeli przestawnej lub funkcji Excela. Dopiero wówczas można zacząć budować raporty, pulpity menadżerskie, "dashboardy", "scorecardy" etc. 

Dojrzewa decyzja o zakupie technologii BI

Sytuacja taka trwa do momentu, dopóki zarząd nie dojrzeje do zakupu technologii, określanej mianem Business Intelligence (BI). Zgodnie z wypracowaną praktyką, powołany zostaje zespół projektowy, który zajmie się wyborem właściwego dostawcy. Rozpoczyna się ewaluacja ofert.

Paleta ofert jest pozornie różnorodna. Obowiązuje zasada, że rozwiązanie BI musi być „dostosowane do potrzeb klienta”, więc bardzo ważne jest ustalenie, które oprogramowanie będzie mogło sprostać zbudowaniu określonego zestawu raportów. Cały nacisk jest kładziony, pozornie słusznie, bo to wynika z paradygmatu obowiązującego w projektowaniu tradycyjnych systemów informatycznych, na „WYJŚCIU”.

Dostawcy prześcigają się w zapewnieniach, który szybciej i lepiej (ostatnio nawet doszło: „taniej”) wykona wymagane raporty. Prezentowane są eleganckie pulpity menadżerskie, "scorecardy" i "dashboardy", które mają stanowić „deskę rozdzielczą” w "centrum dowodzenia", służącą do monitorowania najważniejszych wskaźników w organizacji. 

Kierownictwo jest zafascynowane. Wszyscy emocjonują się różnicą między wskaźnikiem w postaci wirującego, srebrnego dysku u dostawcy X  symbolizującego płynność finansową i majestatycznie powiększającą się sylwetką głównej siedziby korporacji, symbolizującą  kwotę zysku – u dostawcy Y.

Wreszcie zapada decyzja i dostawca zostaje wybrany. Wybrano zysk.

Proces wdrożenia

Po wyborze dostawcy zaczyna się ciężka, żmudna praca, nad ustaleniem zakresu wdrożenia, wymagań i potrzeb użytkowników.

Uruchomiony zostaje projekt i powołany, tradycyjnie, zespół projektowy, angażujący użytkowników z zainteresowanych działów. Najpierw - wielka konferencja, na której przedstawiane jest wdrażane rozwiązanie. Później - koncert życzeń, co kto by chciał, żeby nowe rozwiązanie posiadało.

Zespół projektowy dzielony jest na podzespoły, które mają się specjalizować w określonych zagadnieniach. Każdy zespół zaczyna pracować nad pewną częścią listy potrzeb i wymagań systemowych, zgłoszonych przez użytkowników. Do każdego zespołu, złożonego ze specjalistów z różnych działów, dokooptowany zostaje analityk biznesowy, który ostateczną listę wymagań ma przetłumaczyć na język IT. Prowadzona jest specyfikacja raportów.

Ma miejsce również dobór miar i sposobów ich wyliczania (np. sprzedaż, wartość sprzedaży, stany magazynowe, marża etc.) oraz wymiarów i ich hierarchii (np. region, kraj, miasto, segment, kategoria, marka, rodzaj opakowania etc.) Typy miar i wymiarów zależne są oczywiście od rodzaju biznesu i samej firmy, każda ma swoją specyfikę. 

Defekt procesu

Cała ta wytężona praca posiada jednak istotny defekt.

Skupia się na raportach, na „WYJŚCIU”, miary i wymiary traktując, jak niezbędny etap pośredni, ale tylko etap.  Wrócimy do tego później.

Proces analizy niezliczonych raportów i projektowanie procedur ich generowania trwa miesiące, po czym następuje ewaluacja i wdrożenie, które też trwają miesiące. Zwykle więc,  najszybciej po roku, a najczęściej po dwóch, firma będzie miała do dyspozycji działający system. System „BI”.

Tu zaczynamy się powoli zbliżać do odpowiedzi na pytanie, dlaczego wdrożenie BI kończy się porażką.

Przyjrzyjmy się sytuacji po wdrożeniu. W momencie rozpoczęcia użytkowania, czasami nawet już pierwszego dnia, okazuje się, że praktycznie wszystkie zdefiniowane raporty odrobinę się zdezaktualizowały. Np. zaszła potrzeba wprowadzenia dodatkowej kategoryzacji (dodatkowego wymiaru, agregacji, atrybutu, cechy, kryterium), która jest niedostępna ani w BI ani nawet w systemie głównym, transakcyjnym. A sposób wyliczania niektórych "KPI " (Key Performance Indicator) zmienił się.

W związku z tym pulpit menadżerski nie pokazuje już dokładnie tego, co byśmy chcieli, lub, co gorsza, pokazuje coś całkowicie błędnego.

Poza tym nasz biznes też się trochę zmienił, pojawiły się nowe promocje, które trudno jest monitorować za pomocą dostępnych, zdefiniowanych dopiero co, raportów. 

Zmieniło się też kilku menadżerów, którzy mają trochę inną koncepcję raportowania niektórych zjawisk, więc zdefiniowane raporty stały się zupełnie niepotrzebne.

Dlaczego tak się stało? Przecież analiza poprzedzająca wdrożenie została tak dokładnie zrobiona, wszyscy ciężko pracowali i mieli przewidzieć takie sytuacje, a mimo to nie udało się!

Wykorzystanie platformy raportującej BI w praktyce, jako efekt defektu

Odpowiedź jest prosta, a jakoś nikt tego nie zauważa: Najwyższy Czas to zauważyć!

Analiza przedwdrożeniowa miała miejsce kilka miesięcy temu. Na jej podstawie nastąpiło dostosowanie systemu do wymagań korporacji. To dalsze miesiące. Tymczasem biznes przecież nie stał w miejscu.

Wszyscy specjaliści od zarządzania zgodnie twierdzą, że jedyną stałą w biznesie jest zmiana.

Dochodzimy do sedna. Wszystkie systemy BI posiadają jedno wspólne ograniczenie, które właściwie od samego początku skazuje projekt ich wdrożenia na porażkę. 

Jest nim system raportujący wykazujący immanentny brak elastyczności, a co za tym idzie brak możliwości szybkiego dostosowywania do zmian zachodzących w organizacji, w tym do zmian w funkcjonalnościach systemu BI.

Ten brak, ten immanentny (sic!) defekt platformy raportowej BI, sprawia, że staje się ona …. jeszcze jednym systemem do eksportowania danych.

(...)

Pamiętacie anegdotę o wozaku z poprzedniego odcinka? Mamy tu wozaka – robota. Przywiózł nam (przywozi nam cyklicznie) węgiel wirtualną furmanką. Ale – tym razem już - żarty na bok!

(...)

Filozofia utrwalania defektu, czyli zasady wpajane na szkoleniach BI

Przytoczone przykłady dobrze obrazują ograniczenia filozofii tworzenia technologii BI i rozdźwięku, pomiędzy założeniami teoretycznymi, a późniejszą praktyką.

Pokazują one także, jaką politykę promocji i sprzedaży swoich rozwiązań prowadzą producenci BI.

Ich sztandarowym założeniem i chwytem propagandowym jest stwierdzenie, że 

robienie raportów w Excelu jest błędem metodologicznym, analitycy powinni wykonywać wszystkie raporty na platformie raportowej, a jeżeli muszą się posiłkować Excelem, to znaczy, że są za słabo przeszkoleni.

Tego typu filozofia prezentowana jest zazwyczaj już na etapie sprzedaży systemu BI, prezentowanego jako cudowne panaceum na wyeliminowanie skomplikowanych, rozbudowanych, poumieszczanych w chaotyczny sposób na dyskach sieciowych, plików Excela. Po zakupie BI tego rodzaju stwierdzenia przedstawiane są pracownikom jako element szkolenia BI.

Kiedy, w trakcie szkolenia, analityk przytoczy podobny do powyższego przykład, związany z nieaktualnością  wbudowanych raportów i trudnością z wprowadzeniem zmian, zazwyczaj od osoby prowadzącej szkolenie usłyszy, że to firma ma problem. Ma zbyt skomplikowane procedury wdrażania zmian (sic!). Może też dostanie ofertę na dodatkowe wsparcie konsultingowe.

Przypomina to nieco strategię likwidowania jednych problemów przez produkowanie kolejnych (zwane „ucieczką do przodu”). Najłatwiej jednak jest zlikwidować problem przez wyeliminowanie możliwości jego powstania.

Co należy wobec tego postulować?

Postulaty do praktyki korporacyjnej

1.      Należy zmienić funkcje systemu BI. 

(1)    Główna funkcją systemu BI powinno być  udostępnianie danych do analizy w Excelu.

(2)    System raportujący powinien mieć wyłącznie znaczenie pomocnicze, dla najbardziej stabilnych, najbardziej popularnych i najprostszych raportów. Ale, również powinien podlegać administracji analityka, nie informatyków.

(3)    Udostępnianie danych Excelowi powinno być nie – łaskawie dodawaną –  „zapasową” funkcjonalnością „exportu”, tylko powinno się odbywać, zgodnie z naszymi postulatami, w architekturze SOA (Architektura excelocentryczna).

(4)    To znaczy z zachowaniem trzech złotych zasad: (1) zasady utrzymywania dwóch specjalnych obiektów danych (DMA i ZD), (2) zasady pompy ssącej (PS) i (3) zasady „bez przeklejek!” (BP).

2.      Należy zmienić podział obowiązków uczestników procesu analizy

(1)    Zespoły projektowe - w okresie wdrożenia oraz analitycy poszczególnych działów korporacji -na co dzień, powinni się skupić na:

a.       poznawaniu struktury firmowych baz danych i

b.      budowaniu widoków biznesowych, zawierających wszystkie istotne miary (i procedury ich wyliczania i zmian) i wymiary biznesowe.

(2)    Analitycy powinni mieć:

a.      wgląd w firmowe hurtownie danych

b.      wpływ na procedury ich tworzenia, aktualizacji i uaktualniania. A nawet tworzenia ich prototypów

c.       Najbardziej kompetentni z nich powinni mieć uprawnienia do ich odczytu standardowymi narzędziami MS Office (MS Query, MS Access, ODBC, OLE DB, ADO) oraz jakąś wersją desktopowej lub serwerowej (realnej lub wirtualnej) bazy danych z prawdziwego zdarzenia (np. MS SQL, Oracle, MySQL).

3.      Zależy zmienić stosunek do firm – dostawców systemów BI - na bardziej asertywny

Podstawowym obowiązkiem firmy, dostarczającej rozwiązania hurtowni danych, zaopatrzonych w systemy raportujące, (oznaczanych marketingowym skrótem „BI”) powinno być zapewnienie profesjonalnego dostępu do tabel – widoków biznesowych oraz dostarczenie szczegółowej dokumentacji bazy danych.

Ważnym zobowiązaniem tych firm powinno być:

(1) wdrożenie procedur pielęgnacji i stałego dokumentowania zmian oraz ich udostępniania w widokach biznesowych

(2)  uzgodnione i zagwarantowane przekazanie obowiązków w tym zakresie firmowym informatykom w zakresie hurtowni firmowej z przeznaczeniem do udostępniania danych w trybie do odczytu –  działowym analitykom i ich działowym obiektom analitycznym DMA.

(3)  Jakiekolwiek zastrzeżenia „wyłączności uprawnień”, „tajemnicy”, „praw autorskich do struktury bazy danych” (sic !) i tym podobne próby uzależnienia od siebie, a często, wręcz, terroryzowania klienta przez firmy informatyczne, powinny być konsekwentnie eliminowane.

Takie założenia, naszym zdaniem, radykalnie poprawiłyby efektywność analizy i wyzwoliło znaczne rezerwy tak finansowe, jak intelektualne w polskiej gospodarce. A jesteśmy w tym pierwsi – na świecie jeszcze systemy Business Intelligence krytyce nie podlegają.

Kultura informatyczna analityków

Na marginesie rozważań nad

Minimum kompetencyjnym na Studium Podyplomowym

Ms Excel w Controllingu dla zaawansowanych

Startujące w październiku Studium o powyższym tytule ma za cel, według sformułowanego przez Gospodarza terminu - „wykształcenie świadomego informatycznie controllera/analityka” (biznesowego - dopisek mój).

„Świadomość informatyczna”, a może raczej, kultura informatyczna – to pewien zestaw wyuczonych, przyswojonych i funkcjonujących już niemal odruchowo, bez wysiłku, umiejętności i wynikających z nich zachowań w codziennej praktyce biznesu.

I tak właśnie jest pomyślana misja autorów Studium: kształtować kulturę informatyczną analityków.

Kształtować, a może raczej przekształcać ją w kierunku, który osobistym zdaniem tychże autorów, zdaniem ukształtowanym w toku biznesowych doświadczeń, zapewnia nie tylko lepsze, efektywne wyniki ich pracy ale może przede wszystkim przywraca poczucie ładu i harmonii w środowisku, w którym działają.

Świat nie jest doskonały. Zdajemy sobie z tego sprawę. Nie twierdzimy, że nasze podejście jest doskonałe. Ale twierdzimy, że ma ono kilka cech, które sprawiają, że to podejście jest lepsze od tych obecnie obowiązujących.

Jest podejściem realistycznym.

Korzystamy z dostępnych zasobów, staramy się złapać właściwy rytm biznesu oraz dotrzymujemy słowa.

1. Wszystkie zasoby, którymi dysponuje organizacja są dla nas do wykorzystania. Możemy je wykorzystać, ale możemy się bez niektórych z nich obejść. Są bowiem czasem przeszkody pozamerytoryczne. Mówi się trudno. I próbuje się inaczej. 

Ale najważniejszym zasobem firmy są umiejętności kluczowych pracowników. Jedną z kluczowych kategorii jest, a właściwie powinien być, analityk biznesowy. I te zasoby – tym razem poprzez to studium będziemy się starali uruchomić.

2. Bierzemy pod uwagę wymagania czasowe biznesu nie tylko w zakresie szybkości procesora, wielkości dysków, albo szerokości pasma łączy. Ale przyznajemy, że te względy załatwiają za nas lepiej firmowi informatycy.

Bierzemy pod uwagę przede wszystkim względy dynamiki zmian w realnym biznesie. Proponujemy podejście, które za tą dynamiką zmian rzeczywiście nadąża. I nie zostawia tego problemu na łaskę rozwiązań awaryjnych.

3.  I wreszcie, nie obiecujemy gruszek na wierzbie. Nie proponujemy ostatecznego rozwiązania idealnego pulpitu. Albo doskonale elastycznego, globalnego generatora idealnych raportów. 

Obiecujemy opisać optymalną architekturę informatyczną analiz i wykształcić specjalistę, który potrafi ją kształtować i użytkować, jako pełnoprawny uczestnik procesu produkowania informacji przydatnej dla zarządzania.

Jak to osiągnąć? O kim marzymy, jako o idealnym uczestniku tych kursów?

Kultura informatyczna,  rozumiana, jako ów „zestaw wyuczonych, przyswojonych i funkcjonujących już niemal odruchowo, bez wysiłku, umiejętności” korzystania z dobrodziejstw informatyki w biznesie  ciągle wzrasta. To widać gołym okiem.

Od dziesięcioleci nie spotkaliśmy na przykład osoby, która nie zna Excela. Od lat nie musimy tłumaczyć, co to jest funkcja, adres, łącze, nawet tabela przestawna. 

Zdarza się coraz częściej, że ktoś podnosi rękę, gdy pytamy na naszych kursach, kto słyszał o kwerendzie, o kwerendzie internetowej, o kluczu, o bazie danych.

Ale zawsze musimy objaśniać to wszystko niejako na nowo. Układać w system. W logiczny ciąg elementów właściwie i celowo poukładanych w całość, mającą znamiona dobrej architektury.

I zawsze spotykamy się z radosnym zdumieniem. To takie logiczne, proste i użyteczne. Tak niewiele trzeba. Dlaczego nikt nam nie powiedział?

No to my powiemy.

To o kim marzymy?

Idealny uczestnik, to ktoś nie tyle znający Excela, co rozumiejący podstawy analizy, problemy, które go uwierają, gdy używa najlepszego na świecie systemu BI, żeby wyeksportować kilka ważnych, „szerokich” tabelek. 

I potem wstydliwie przejść do Excela, żeby zrobić raport, którego jego szef potrzebuje na wczoraj.

Jeżeli ktoś uważa, że BI załatwia wszystko najlepiej, że wystarczy wywołać odpowiedni raport naciskając odpowiednią ikonkę, a w najgorszym wypadku, uruchomić  „generator raportów” i zdefiniować ten raport, jeżeli ktoś dysponuje tak wspaniałym systemem, życzymy mu wszystkiego najlepszego. Nie mamy mu nic do zaproponowania.

Jeśli jednak ktoś nie ma takiego szczęścia, jeśli raporty w jego systemie są „prawie dobre”, ale brak im pewnego elementu i dlatego (ze wstydem) musi on uruchamiać Excela i robić ten raport od nowa, to nasze Studium jest właściwym remedium. 

Leczymy z kompleksu, uczymy informatyki tak, żeby mógł on żądać od informatyków i instalatorów BI uwzględnienia jego potrzeb i żeby umiał kształtować swoje raporty, jako integralną część architektury analiz, a nie pogardzaną i wstydliwą gorszą część - „frond – end”, do której się eksportuje wyniki z tej lepszej części struktury.

No dobrze, ale jaki ma być ten uczestnik?

Właściwie, nie mamy wymagań.  Excela każdy zna i prawie nikt z naszych uczestników nie wie tego, co jest istotne dla celu sformułowanego wyżej: umieć kształtować, jako integralną część architektury analiz.

I tego nauczymy.

Istota koncepcji SOA

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

Wojciech Gardziński
Jakub Rumiński
Krzysztof Rumiński

Ukazał się właśnie, we wrześniowym numerze Controllingu i Rachunkowości Zarządczej II odcinek naszej sagi o architekturze. W październiku będzie przerwa, bo mamy przejściowe trudności twórcze. Na listopad szykujemy bombę. Jeśli zapłon ma opóźniony, to siła wybuchu nie będzie zmniejszona. Co się odwlecze to nie uciecze.

Na razie więc publikuję tu fragmenty części II – giej w swojej interpretacji.

Różnię się z Czcigodnym Redaktorem Stanisławem trochę w rozłożeniu akcentów. No i nie mogę darować redakcyjnemu grafikowi takiego zmasakrowania naszych wypieszczonych schematów.  Tutaj będą rysunki może nie tak profesjonalne ale na pewno lepiej oddają istotę idei, które tu prezentujemy. A są to idee dla nas fundamentalne.

Ten fragment tekstu, to kwintesencja naszych wieloletnich doświadczeń. Prosimy o uwagę. To nasza krwawica.

W poprzednim artykule ostro skrytykowaliśmy obowiązującą obecnie, klasyczną architekturę środowiska analiz i zapowiedzieliśmy przewrót. Pora przedstawić alternatywę.

Zmieniamy optykę na excelocentryczną!

 

Optyka excelocentryczna

Oznacza to, że punkt obserwacyjny znajduje się w Excelu, zaś  wszystkie żmudne, pracochłonne, zautomatyzowane lub ręczne, operacje, decydujące o wykonaniu istniejącego raportu na nowy okres, są oceniane z tego punktu obserwacyjnego. Przyjmujemy więc swego rodzaju excelocentryczny punkt widzenia. Wyraźmy to takim, trzypunktowym manifestem:

1.       Jestem w Excelu, nigdzie się nie ruszam, cokolwiek się dzieje, w Excelu, lub poza Excelem, oceniam z punktu widzenia możliwości i metod Excela.

2.       W szczególności mam świadomość, że metody i obiekty Excela są przystosowane do współpracy ze współczesnymi bazami danych.

3.       I dlatego Excel ma wszelkie dane, przynajmniej przy sporządzaniu raportów, żeby „rządzić”! Czyli to ja, analityk, organizuję przepływ danych dla moich raportów.

Zespół tych metod, obiektów i operacji w Excelu ma swoją logikę, wymagania i specyfikę. Innymi słowy, ma określony state of art, profesjonalny sposób projektowania, sporządzania, pielęgnowania i odświeżania raportów.

Ten state of art jest w dużej części zapoznany. Zwłaszcza w części dotyczącej współpracy z bazami danych, które są źródłem ciągle zmieniających się wartości do raportów, które z kolei mają za zadanie przetworzyć te dane w informacje.

A jaka jest teraz sytuacja w zakresie aktualizacji raportów nowymi danymi, skąd analityk bierze dane? Najczęściej dostarczają mu je informatycy. Oni zaś zachowują się przy tym, jak w starym dowcipie, o umorusanym wozaku w gumowcach, który wparowuje do gabinetu Dyrektora i informuje:

                - Przywiozłem węgiel, gdzie zrucić?

Informatyk myśli o danych, które musi „dostarczyć”, jak ten wozak. Potem… jest wolny. Jest z siebie wyjątkowo dumny, zwłaszcza wtedy, gdy dostarczy je w formacie Excela.

Zaś analityk ma coś w rodzaju węgla na błotnistym podwórku. I musi jakoś wnieść ten węgiel do piwnicy.

Jak zmienić tę sytuację?

Kontynuując naszą analogię z węglem, powinniśmy mieć sposób, żeby nie wychodząc z gabinetu i nie używając ani gumowców, ani rękawic, ani łopaty, ściągnąć węgiel do piwnicy. A nawet, żeby w skrajnym wypadku, ściągnąć węgiel wprost ze składu opałowego do tej piwnicy, eliminując wozaka.

Czyli powinniśmy tak zorganizować przepływ danych wykorzystywanych przez raport w Excelu,  żeby nigdy nie opuszczać Excela.

Informatycy, którzy odpowiadają za informatyczny przepływ informacji, uważają, że to serwery bazodanowe są jej jedynym centrum, a Excel to taki drobny, wręcz nieistotny, dodatek do nich – to „Front-End” systemu – do którego dane się eksportuje.

A raport, żeby mógł przetwarzać na bieżąco dane źródłowe na informację, powinien mieć połączenie z danymi i możliwość błyskawicznego ich odświeżenia i zaktualizowania informacji.

Aktualizacja informacji, zawartych w raporcie oznacza, że analitycy do raportu  informację… ciągną!

Lub ssą, jak kto woli.

I to analitycy powinni zorganizować sobie pracę według tej nowej zasady. Oni wiedzą najlepiej, czego im potrzeba, aby otrzymać kompletny  raport. Definiują zakres danych, ich pochodzenie (sic! – nie zawsze dane, dot. wielkości sprzedaży bierze się z programu sprzedaży, choć to niby takie oczywiste – przykład: niezaksięgowane odbiory towarów), definiują stopień ich agregacji, formę, a często również  zakres uprawnień.

Żaden „gotowy raport BI” nie uwzględni wszystkich potrzeb, jakie pojawią się jutro. Dlatego, po zaistnieniu nowej sytuacji, „kreśli się” raport – tabelę w Excelu, a potem „szuka się” danych: otwiera się aplikacje transakcyjne, zastanawia się, skąd wziąć to, a skąd tamto? 

Ale gdy się je odnajdzie, nie przerabia się danych w Excelu, tylko projektuje się nowe źródło danych dla Excela oraz uruchamia się odpowiednią procedurę zasilania źródła danych – nowymi danymi. Nowe źródło danych może bazować na pliku-eksporcie.

To trwa dotąd, aż profesjonalny, przejrzysty raport będzie miał kompletny zestaw źródeł danych.

Istota SOA (Spreadsheet Oriented Architecture)

Co stanowi o istocie?

Zacznijmy od porównania dwóch rysunków:

Na pierwszym, prezentowanym już w pierwszej części tego artykułu, widzimy pomiędzy naszym skoroszytem, a źródłami danych „błoto”, czyli żmudne czynności przeklejenia i umieszczenia w odpowiednich miejscach nowych danych. Dane, dostarczane są do Excela niejako wózkami inwalidzkimi, pchanymi przez owo arkuszowe „błoto”.

Widok: Praktyczna, obecna, architektura analiz

Widok: Architektura SOA

Drugi rysunek pokazuje dwa nowe elementy:

Pierwszy – to mechanizm podłączania źródeł danych i „wciągania” danych do Excela. Mechanizm ten działa wewnątrz Excela, co zapewnia, że analityk ma pełną kontrolę nad procesem odświeżania, a sam proces staje się łatwy i przyjemny. Reprezentowany jest przez pierwszą pompę ssącą (PS1), tę znajdującą się wewnątrz skoroszytu.

Drugi – to dodatkowa warstwa danych, pełniąca rolę źródła danych bezpośredniego dostępu dla Excela, za pośrednictwem wspomnianej pompy (Data Mart for Analysis).

Ta warstwa danych może zaopatrzona być w szereg procedur ją zasilających. Z kolei, te procedury działają na podobnej zasadzie, jak warstwa pierwsza, dlatego  są symbolizowane przez drugą pompę ssącą (PS2) i, w świecie informatyki, noszą nazwę – Data Transformation Services - DTS).

Ale te procedury nie są nawet konieczne. Ważne jest, że dane znajdują się w źródle DMA, obojętnie, jak się tam znalazły: sposobem ręcznym, czy przy pomocy najbardziej zaawansowanych procedur zasilających, porządkujących, uszlachetniających. Najważniejsze, że pompa PS1 może z nich swobodnie korzystać.

Procedury automatyzujące proces aktualizacji źródła (PS2) mogą być usprawniane i zmieniane bez zakłócania procesu tworzenia raportów oraz procesu końcowej analizy biznesowej. Warunek jest prosty: podczas takich prac nie zmienia się struktura źródła.

A oto istota „Architektury SOA” – wyłożona w trzech złotych zasadach:

1) Wprowadzamy dwa pojęcia – nasze „obiekty analityczne”

a)      warstwa danych bezpośredniego dostępu „Data Mart direct Access for Excel”, czy też, prościej, „Data Mart for Analysis” (DMA), do której Excel ma bezpośredni dostęp

b)      zasoby  danych, które oznaczają każdy przydatny fragment opisu rzeczywistości w postaci elektronicznej, dostępny nie z poziomu Excela, tylko za pośrednictwem DMA (poprzez PS2)

Kluczowym warunkiem jest tu wymóg, że właścicielem DMA jest analityk a nie informatyk. Informatyk jest mile widziany, jako asystent merytoryczny, ale nie posiada „władzy”. Uprawnienia do DMA posiada analityk. Bez tego warunku NIE MA SOA!

2) Przyjmujemy zasadę „pompy ssącej” umieszczonej w Excelu. „Jestem w Excelu, nigdzie się nie ruszam…”, odświeżam dane, umieszczone już w Excelu, myszką lub skrótem klawiszowym (uruchamiając jakieś makro lub program aktualizujący dane) i raport jest już aktualny. Wszystko tak organizuję w skoroszycie, że nowy raport o TEJ SAMEJ STRUKTURZE to: zmiana parametrów i aktualizacja danych przez kliknięcie myszą

3) Jakiekolwiek „przeklejki”, zmiany źródeł, ręczne przełączanie na inny zestaw danych, edycje łączy i tym podobne ”tradycyjne operacje okresowe” w działach analiz, są albo surowo zabronione, albo stanowią smutny, ale konieczny wyjątek w stanie wyższej konieczności, a nie żelazną regułę analizy, jaka obecnie obowiązuje.

Kwestia podziału wysiłków między Excela i DMA jest otwarta. Np. DMA może również być realizowane w standardowych narzędziach Excela (MS Query, Power Pivot, ODBC, OLE DB, VBA, ADO), a może być realizowane w MS Access, MS SQL, MySQL, ORACLE, DB2 i co tam sobie kto wymyśli. Wybór bazy danych zależy od oczekiwań jej stawianych, jej dostępności a nawet … kwalifikacji analityka. Zależy również od tego, czy inżynier-analityk potrafi wykorzystać wiedzę i umiejętności swojego asystenta merytorycznego – informatyka.

Ambitny program? Może i ambitny. Ale naszym zdaniem jedyny możliwy, bo innej drogi nie ma. Kto tego nie zrozumie, będzie za pięć lat za burtą głównego nurtu sztuki analiz biznesowych. Razem z producentami mastodontów, nazywających samych siebie, nomen omen, Business Intelligence.

Istota DMA (Data Mart for Analysis)

DMA to kluczowy punkt architektury. Jej serce.

MY, analitycy, znaleźliśmy się w – centrum analiz, przejęliśmy władzę nad swoim informatycznym środowiskiemanaliz, ale za tym idzie… odpowiedzialność. Już nie tylko za właściwie napisane formuły Excela, odpowiednie adresowanie, parametryzowanie, słowniki parametrów, przejrzystość budowy raportu i przyjazny, czytelny i ładny format raportu - to też. A nie spaghetti, niestrawne po kilku tygodniach nawet dla autora.

Spada na nas odpowiedzialność za jakość danych i za architekturę całości, charakteryzującą się trwałością, użytkowością i pięknem. Takimi cechami bowiem od kilku tysięcy lat legitymuje się dobra architektura.

Kształtowanie takiej architektury, co naturalne, można jednak powierzyć komuś, kto

po pierwsze - posiada głębokie zrozumienie potrzeb analizy, zwłaszcza z uwzględnieniem dynamiki zmian tych potrzeb,

po drugie - posiada odpowiednie kwalifikacje.

Jakość danych wynika z kwalifikacji informatycznych wykonawcy procesów, z jakości algorytmów ich przetwarzania, zastosowania metod informatyki, teorii baz danych, języka SQL, elementów programowania…

Wizja przejęcia odpowiedzialności za całość analizy przez ludzi, nawykłych do sprzątania węgla po wozakach, może przyprawić o zawrót głowy. No cóż - trudno. Kiedyś trzeba będzie przyzwyczaić się do tej myśli – jeżeli chcemy być profesjonalnymi analitykami.

.

Korzyści SOA

Stawiając w centrum analiz  Excela, nadajemy mu prawo obywatelstwa. Paradoksalnie spowoduje to na początku poprawę jakości samych raportów. Większa władza, rola pełnoprawnego członka architektury środowiska analiz zobowiązuje do profesjonalizacji skoroszytu.

Oto złota siódemka zalet architektury SOA

1)       Raporty są uniwersalne, odświeżalne, żywe

2)       DMA jest naszą – podkreślmy: NASZĄ! – własnością, a my najlepiej wiemy, co nam potrzeba,

3)        Jednocześnie DMA jest uniwersalnym źródłem danych i dokumentacją zasobów.

4)       Profesjonalizacja analizy. Zamiast łataniny - procedury, elastyczność i nadążność za rytmem biznesu.

5)       Uruchomienie zasobów intelektualnych działu IT. IT TEŻ będzie miał lepsze poczucie spełnionego obowiązku.

6)       Większa współpraca i integracja załogi wokół celów biznesowych a nie wzajemna spychologia i pretensje, kto winny złej analizie.

7)       Władza nad analizą jest w rękach tych, którzy za nią odpowiadają:  analityków.

Następny odcinek: Praktyka korporacyjna a architektura SOA

Jako współautor koncepcji i programu, zapraszam: Studia podyplomowe we Wrocławiu

MS Excel w controllingu dla zaawansowanych

To co się tu wypisuje, jak się orientuję, niezbyt jest zrozumiałe.

Cierpliwości.
Pomału to wszystko rozplączemy i na tym blogu.

Jeśli ktoś jednak jest bardzo niecierpliwy i chce trochę zainwestować w siebie, to ma szansę.
Uniwersytet Ekonomiczny we Wrocławiu docenił nasze podejście i podjął z nami współpracę.

Będziemy głosić nasze idee obok takich tuzów informatyki ekonomicznej, jak prof. Andrzej Bytniewski oraz controllingu, jak dr Jerzy Mońka.

Zapraszamy!
Przypis 17 września 2012:
Miejsc już prawie nie ma. Ale mozna jeszcze próbować...

MS Excel w controllingu dla zaawansowanych

A oto nasze referencje, publikowane na stronie Uniwersytetu Ekonomicznego we Wrocławiu:

Mgr inż. Wojciech Gardziński - właściciel firmy AFIN (Wrocław), producenta Systemu Analizy Ekonomicznej AFIN.NET (ponad setka wdrożeń), opartego o technologię i środowisko arkusza kalkulacyjnego Microsoft Excel, autor wielu publikacji, referatów, programów szkoleniowych z zakresu Excela, Accessa i jego wykorzystania w zarządzaniu, w szczególności w dziedzinie controllingu finansowego.


Referencje akademickie

• Uniwersytet Ekonomiczny we Wrocławiu – trener na studiach podyplomowych „Controlling wspomagany komputerowo”
• Uniwersytet Ekonomiczny we Wrocławiu - szkolenia dla kadry dydaktycznej i bezpłatne udostępnienie narzędzia dydaktycznego AFIN.NET – dla celów nauczania controllingu na bazie programu MS Excel
• Uniwersytet Ekonomiczny we Wrocławiu - współpracy z Kołem Naukowym Controllingu „Conto”
• Politechnika Opolska – współpraca z Wydziałem Zarządzania i Organizacji Produkcji – prowadzenie zajęć „Laboratorium analiz ekonomiczno-finansowych” na kierunku Rachunkowość i Finanse
• Politechnika Opolska - Koło Naukowe Rachunkowości i Finansów„Arafin” – udostępnienie narzędzia AFIN.NET oraz zajęcia seminaryjne
• Uniwersytet Łódzki i Infor Training – Podyplomowe Studium Finansów i Rachunkowości, prowadzenie zajęć laboratoryjnych „Excel – platforma analiz biznesowych”. Współautor programu.
   

Referencje biznesowe

• Ponad 100 klientów narzędzia controllingowego AFIN.NET, w tym m.in. Agencja Restrukturyzacji i Modernizacji Rolnictwa – 14-letnia współpraca,
• PKP Energetyka S.A. – Projekt, wdrożenie oraz zapewnienie narzędzia (AFIN.NET) dla „Platformy Business Intelligence”, obejmującej centralę i wszystkie oddziały (16) firmy oraz wszystkie dziedziny tematyczne analizy biznesowej, merytoryczny projekt hurtowni danych, w tym serwer OLAP.
• PGE Elektrownia Opole S.A. – informatyzacja raportowania finansowego – współpraca 12-letnia
• CEMEX S.A. – wdrożenia AFIN.NET, szkolenia, wdrożenia systemów „na zamówienie” – współpraca 14-letnia, wielokrotnie przerywana (sic!) ze względu na zmiany właścicielskie oraz wznawiana, dostosowanie narzędzia do 4 różnych systemów ERP
• PGNiG Zakłady Gazownicze w Zabrzu (jeden z największych ZG w Polsce) i Opolu – pełne raportowanie finansowe – współpraca 5-letnia, do momentu odgórnej zmiany systemu ERP i monopolizacji informatyki
• Ponadto: Klientami AFIN.NET jest 7 spółek, notowanych na WGPW, 3 przedsiębiorstwa z branży energetycznej oraz jedna z branży telekomunikacyjnej
• Narzędzie współpracuje z ponad 50 różnymi systemami ERP i wieloma typami baz danych
  AFIN.NET posiada klientów za granicą, m.in. w USA

Mgr inż. Krzysztof Rumiński – z wykształcenia inżynier mechanik. Ukończone studia doktoranckie z zakresu Mechanika Stosowana. Specjalista mechaniki stosowanej i metod numerycznych w projektowaniu. W 1979 roku otrzymał Nagrodę Ministra za zasługi dla Przemysłu (metoda szkoleniowa „Discovery Day”). Posiada kwalifikacje księgowego, analityka i informatyka. Zna języki programowania: Visual Basic for Application, Visual Basic Net, Clipper, Fortran, PL/I. Autor jednego z pierwszych programów księgowych na mikrokomputery, wyposażonego w generator raportów finansowych „Finka 2000”.

Współpracował przy projekcie systemu analiz finansowych AFIN, w którym to systemie są zrealizowane niektóre jego pomysły, jako istotne części systemu.

Realizator wdrożeń Business Intelligence, z zastosowaniem standardowych narzędzi analizy (Excel, Access), oprogramowania specjalizowanego i dodatkowego, na platformie serwerowej (Oracle, MS SQL) z użyciem platformy portalowej SharePoint.

Referencje akademickie:

• Uniwersytet w Białymstoku – zajęcia z Podstaw Informatyki na Podyplomowym Studium Rachunkowości przy według programu swojego autorstwa.
• Uniwersytet Łódzki i Infor Training – zajęcia laboratoryjne „Excel – platforma analiz biznesowych” na Podyplomowym Studium Finansów i Rachunkowości. Współautor programu. Asystent promotora jednej z prac dyplomowych.
• Instytut Lotnictwa – kierowanie zespołem definiującym model obliczeniowy MES i wykonującym obliczenia części silników lotniczych

Referencje w zakresie nadzoru informatycznego i konsultingu – koordynacja wdrożeń zintegrowanych systemów zarządzania i konsultacje:

• Ministerstwo Infrastruktury – wdrożenie systemu Egeria
• Ministerstwo Gospodarki - wdrożenie systemu Egeria oraz systemu Lotus Domino i MIS, koncepcja i nadzór nad wdrożeniem systemu rejestracji wniosków unijnych
• Analiza i ekspertyza informatyzacji Polskiego Radia (współpraca)
• Analizy i ekspertyzy informatyczne w firmach prywatnych, spółdzielniach, instytucjach
• Analizy przedwdrożeniowe oraz wdrożenia systemów Profit, Symfonia, Intact

Referencje biznesowe:

• Około 200 wdrożeń systemu finansowo-księgowego „FINKA 2000” w firmach i instytucjach, m.in. w: Wydawnictwo Infor (instalacja wielostanowiskowa), Zakłady Remontowe Hutnictwa (6 zakladów), ZM Ursus (Instalacja na 40 stanowisk)
  Polskie Zaklady Optyczne (instalacja wielostanowiskowa), Fabryka Kabli Będzin (instalacja wielostanowiskowa)
  Agencja Restrukturyzacji i Modernizacji Rolnictwa (8-letnia współpraca do czasu monopolizacji informatyki przez firmę Oracle)
• Wdrożenia systemu analiz finansowych AFIN, współpracującego z różnymi systemami finansowo-księgowymi
• PKP Energetyka S.A. – Analiza wdrożeniowa, współpraca z autorem oprogramowania dla zapewnienia korporacyjnego charakteru narzędzia, koordynacja wdrożenia dla „Platformy Business Intelligence”
• Agencja Restrukturyzacji i Modernizacji Rolnictwa – instalacja i wdrożenie systemu Systemu Analiz Finansowych AFIN i współpraca przy jego pielęgnacji i eksploatacji, przełączając go na kolejne systemy finansowo-księgowe: Finka, Softman, Oracle Financial. Analiza bazy danych systemu Oracle F. Opracowanie pośredniej warstwy danych (dziedzinowa hurtownia danych), stanowiących źródło danych dla analiz finansowych
  
   

Wspólne dokonania autorów – współpraca w formie nieformalnej spółki autorskiej WG&KR (od 2002)


Referencje szkoleniowe
 

• Projekty i realizacja szkoleń – ok. 200 realizacji, 2000 uczestników z 700 firm
• MS Excel - Platforma Analiz Biznesowych
• VBA dla analityków biznesowych
• SQL dla analityków
• MS Access dla analityków

Referencje naukowo-publicystyczne

• Ponad 100 artykułów w czasopismach specjalistycznych, m.in. Controlling i Rachunkowość Zarządcza – 10 lat współpracy
• Controlling i Rachunkowość Zarządcza - Cykl „Przegląd metod dostępu do danych” 4 artykuły (2001, WG).
• Controlling i Rachunkowość Zarządcza - Artykuł problemowy „Integracja Systemów czy System Zintegrowany” (2002) – pionierskie ujęcie i uznanie Excela za główny składnik środowiska analitycznego firmy, obecnie (od 2009) znane pod nazwą „Microsoft Business Intelligence”
• Controlling i Rachunkowość Zarządcza - Cykl „Dane w Excelu” 3 artykuły (2005)
• Controlling i Rachunkowość Zarządcza - Cykl „Optymalna architektura środowiska analiz” 5 artykułów (2008-2009)
• Controlling i Rachunkowość Zarządcza - Cykl „Problemy” 3 artykuły (2009)
• Controlling i Rachunkowość Zarządcza - Cykl „Excel na poważnie” 2 artykuły (2010)
• Controlling i Rachunkowość Zarządcza - Cykl „MS Query” 5 artykułów (2011)
• Controlling i Rachunkowość Zarządcza - Porady – odpowiedzi na pytania czytelników
• Gazeta Prawna - Cykl „Jestem Excel – znamy się?” 19 pełnostronicowych artykułów (2004)
• Monitor Księgowego, 2 roczne cykle krótkich porad (2 strony) dla księgowych, razem ok. 50 artykułów (2005-2006)
  Wiele przedruków, m.in. na portalu tematycznym BI.PL www.bi.pl oraz w Internetowym Serwisie Controllera www.isc.pl
  Blogi tematyczne nt. wykorzystania Excela w controllingu
• Publicystyka na tematycznych grupach dyskusyjnych
• Kilkanaście publicznych wystąpień na konferencjach i seminariach naukowo-biznesowych, w tym najważniejsze to:
  Ryn, 2008 – Prezentacja autorskiej koncepcji, dot. architektury analiz biznesowych z wykorzystaniem programu Excel
  Infor, redakcja „Controllingu i Rachunkowości Zarządczej” – Prowadzenie trzech specjalistycznych spotkań pod nazwą „Klub Controllera”, „Wykorzystanie arkusza kalkulacyjnego Excel w controllingu” (współprowadzenie z drem Stefanem Olechem, ODiTK), 2004, „Optymalna architektura analiz”, 2010, Excel 2010 – Business Intelligence dla wszystkich”, 2011
• Projekt, organizacja i realizacja dwóch edycji ogólnopolskiego konkursu dla controllerów pod egidą redakcji CiRZ na aplikację biznesową, wykorzystującą Excela (udział w jury, ufundowanie nagród)

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ć.