Kto to pisze i dlaczego uważa, że może...

Moje zdjęcie
Doświadczony. Hmmm. Może docenisz tę cechę? Nie wiem, czy warto. Doświadczenie to głównie to, czego bym nie radził Tobie powtarzać. Ale i tak zrobisz, co zechcesz...

poniedziałek, 17 września 2012

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.

niedziela, 16 września 2012

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