Przejdź do głównej zawartości

Studia specjalistyczne analityków biznesowych. Teoria i praktyka (część 3)

Praktyka, praktyka …

W praktyce - charakteryzuje nas (współautorów Studiów) pewne zacięcie „ewangelizacyjne” wśród „pogan”*, którzy nie tylko uparcie nie chcą się „nawrócić”, ale jeszcze obrzucają nas obelgami.

Ta reakcja z jednej strony nas umacnia. Zawsze to lepsze, niż obojętność. Z drugiej, rodzi potrzebę potwierdzenia, że idziemy słuszną drogą. Myślimy … i korygujemy. Ewentualnie. Na razie tylko korygujemy wykonanie. Nie korygujemy podejścia. Podejście pogłębiamy.

Dlatego teraz opiszę pierwsze doświadczenia z konfrontacji naszych idei w realu, nie w Internecie.
Po kolei.

Uczestnicy

Uczestnikami pierwszej edycji studiów byli w przeważającej części (ponad połowa) pracownicy działów analiz i controllingu dużych, międzynarodowych firm, znanych na całym świecie. A z tej grupy - przeważająca część - to światowe korporacje z kapitałem europejskim, amerykańskim i dalekowschodnim.

Z jednej strony – to trochę smutno, bo zbyt kosmopolitycznie. Prestiżowo, ale – w tym prestiżowym towarzystwie, za mało swojsko. Jak na mój gust. Na pocieszenie - z tych najbardziej ambitnych - nie największa – jedna firma z kapitałem polskim. Jaskółka.

Ale ze strony drugiej – tym lepsza nasza referencja. Właśnie oni, pracownicy międzynarodowych korporacji i ambitnych, nowoczesnych firm walczących o rynki na całym świecie, zlecieli się, niby szpaki na dojrzałe wiśnie – na zajęcia „MS Excel w controllingu, dla zaawansowanych”.

A na pytanie – „kto ma w pracy ten wspaniały system na literę S albo na literę O?” - las rąk.

Na drugie pytanie: „No to czego wy tu szukacie?” – pełen zrozumienia – śmiech. I od razu jesteśmy wśród swoich, wśród analityków i controllerów.

Poziom kultury informatycznej wśród uczestników

Poziom wiedzy o Excelu oraz o metodach analizy biznesowej przy użyciu tego narzędzia, sądząc z naszego, wieloletniego doświadczenia dydaktycznego – solidnie powyżej średniej.

Jakiś uczestnik wydaje się nawet nie potrzebować żadnej nowej wiedzy o funkcjonalności Excela. Ma braki w SQLu i czeka, aż przestaniemy nudzić o Excelu. Kilka osób potrafi  zrobić standardową kwerendę.

Ktoś nawet zna coś więcej niż podstawy SQL-a i okazuje się pomocny w debugowaniu zdania SQL, które prowadzący uparł się, żeby działało. A nie chciało.

Percentyl 5% słuchaczy całej naszej działalności dydaktycznej.
Mimo to, a może właśnie dlatego, błyskawicznie uzyskujemy porozumienie z uczestnikami na gruncie naszego podejścia. Jeden z uczestników już na pierwszej przerwie podchodzi do mnie i mówi właściwie coś szokującego.

„Ja wiem, o co panu chodzi. Pan zmierza do zorganizowania środowiska wokół Excela w optymalną architekturę”.

Dlaczego ta wypowiedź tak mnie zaszokowała? Ponieważ tematem zajęć nie była żadna architektura. Nie puszczałem żadnych slajdów. Nie „teoryzowałem”. Nie użyłem ani razu słowa „architektura”. Po prostu prowadziłem zajęcia tak, żeby uczestnicy sporządzili raport uwzględniając uniwersalne formuły, zasilane danymi. Taki raport, który będzie żył długo. Aż do zmiany jego struktury i funkcjonalności. Aż do zmiany modelu biznesowego, który za nim stoi. 

Nowe dane i nowe wartości raportu – w odległości dwóch kliknięć.

Opinia jednego z uczestników

To wypowiedź nie pierwsza, ani pewnie nie ostatnia…
Mój rozmówca, poproszony o krótką pisemną ocenę zajęć, pisze maila.

Oto obszerne fragmenty:
„(pełnię) funkcję specjalisty ds. controllingu i analiz biznesowych. Wcześniej realizowałem zadania, będąc odpowiedzialny za controlling grupowy. Firma (…) zatrudnia ponad 1000 osób, (… )należy do grupy … – łącznie 10 zakładów na świecie.

(…) Uważam, że zajęcia spełniły (przynajmniej w moim przypadku) jedną bardzo istotną funkcję – uświadomiły mnie, że architektura „bałaganu” nie jest jedyną opcją, choć myślę, że niestety jeszcze przeważa w działach analitycznych. Zacząłem się zastanawiać, jakie są przyczyny tak złego stanu? Nasunęły mi się następujące odpowiedzi:

1)      Brak kształcenia w takiej materii – w większości uczymy się technik (VBA, SQL itp.), niestety sama technika bez funkcjonowania w „optymalnym” środowisku nic nie zmieni;

2)      Dane źródłowe – obserwując swoje „podwórko” dostrzegam, że około 30% danych pochodzi ze źródeł zewnętrznych (raporty o konkurencji, dane z artykułów branżowych, raporty organizacji zrzeszających innych producentów itp.). (…)

3)      Ludzka psychika – Pracując 4 lata w działach analitycznych dostrzegam takie oto zachowanie: pojawiają się dane (…) źródłowe (tzw. INPUT) oraz (…)
oczekiwania (najczęściej przełożonych, bądź standardy grupowe) co do formy wyjściowej (tzw. OUTPUT).
Analityk (ponieważ zwykle walczy z czasem) pragnie jak najprędzej wykonać najgorszą rzecz, która rzuca go w opisane „błoto”:
Tworzy linki, przekleja, ręcznie przerabia. Efekt: straty czasu i moim przypadku moralny kac, że chyba istnieje jakieś wyjście z tego „błota”. Analitykowi brakuje warstwy pośredniej (może nie tak pięknej, ale bogatej w zasoby), nazwanej przez Panów DMA;
Pamiętam moją reakcję po wyjściu z sali w pierwszym dniu zajęć – było mi wstyd, że w tak małym stopniu wykorzystuję sposób postępowania pokazany przez Pana. Myślę, że na dzień dzisiejszy ok. 30% moich analiz jest realizowanych zgodnie z SOA.
Znowu zadałem sobie pytanie  – dlaczego? Przecież znam techniki (dobrze poruszam się w arkuszu, znam elementy VBA i SQL).
Niestety prawda jest okrutna: zwykle wybieramy proste rozwiązania nie wymagające myślenia. Działanie zgodne z SOA wymaga najpierw przemyślenia tematu – efekty są później zdumiewające. Kojarzy mi się to z manewrem wyprzedzania na drodze – jest on ryzykowny, najpierw musimy wykonać szereg czynności – odpowiednio się przygotować, ale w efekcie możemy jechać szybciej, zamiast całe życie „przeklejać” dane.
Zatem perspektywy zastosowania architektury SOA w mojej praktyce zawodowej są ogromne. (Podkreślenie KR)
Muszę tylko potraktować to jako formę inwestycji, której na początku zawsze ponosi się większe koszty, niż przychody. Myślę, że rozpocznę moją przygodę od zbudowania własnych „hurtowni” danych (szczególnie w przypadku danych zewnętrznych). Czas aby słowa: parametr, miara, słownik itd. częściej były wypowiadane przez analityków ...

Chciałbym aby relacja 30 % SOA / 70% „błoto” była w moim przypadku odwrotna. Uważam, że podejście SOA stanowi drogę, po której kroczą najlepsi w branży. Z pewnością warto wkroczyć na taką drogę, zbliżając się powoli do "optimum", o którym każdy analityk pewnie "pod skórą czuje", że istnieje.
Dziękuje Panie Krzysztofie za wywołanie u mnie „niesmaku” do architektury „bałaganu”.

Koniec cytatu mojego słuchacza.

Pierwsze wnioski

Nie jest to jedyna wypowiedź. Dysponuję innymi. Mam np. jedną wypowiedź krytyczną o zajęciach (w duchu konstruktywnym :) ) osoby nie tylko krytycznej, ale bardzo kompetentnej, w której pada jednak zdanie (zapewne na pociechę) o naszym  „nowym podejściu”.

A więc to rozstrzyga! Nasz odcisk palca, to nie pokazywanie nawet najbardziej nieznanych skrótów klawiszowych, funkcji i funkcjonalności. Bez tego daje się żyć. Można przecież to zawsze wyszperać w ogromnej bibliotece excelowej. W księgarniach tradycyjnych, internetowych i w bazach wiedzy.

Nasze pierwsze doświadczenie jest takie, że im wyższy poziom wiedzy i umiejętności analizy prezentował uczestnik, tym szybciej i pełniej doceniał nasze „nowe podejście”.

To, czego brakuje, to wizja procesu informatycznego skonstruowanego w środowisku informatycznym  – z integralnym składnikiem – Excelem. 

To podejście: architektura „optymalna”, której konkretną propozycję sformułowaliśmy i którą ćwiczymy na zajęciach - zostało zgodnie przyjęte, jako "nowe".

Myśmy tak właśnie to widzieli. Jeśli byśmy się zniechęcali wypowiedziami recenzentów *, to nasi uczestnicy nie to, że nas uspokoili. Oni nas zobowiązali, żeby to podejście przedstawiać, rozwijać i doskonalić.

Musimy nauczyć naszych słuchaczy nie – Excela, VBA lub SQLa. Musimy ich nauczyć podejścia, jak organizować te i inne narzędzia i umiejętności - w proces analizy umieszczony w „optymalnej” architekturze środowiska informatycznego. Wiecie jakiej. SOA. :)

Zakończenie: Podejście procesowe


Podejście „procesowe” do analizy w Excelu wymaga wypracowania:

1) koncepcji tego procesu (co się będzie kryło pod „dwoma kliknięciami”),
2) architektury środowiska: (kluczowe składniki i ich wzajemne relacje, z Excelem, integralnym składnikiem środowiska a nie marginalizowanym wyrzutkiem) ,
3) założeń działania na platformie analizy, by ten proces realizować i wykorzystać jego atuty (kompetencje analizy na platformie)

Jeśli uważnie przeanalizujemy te warunki, stanie się oczywiste, że żaden specjalista BI, informatyk ani pyszny z powodu swoich kompetencji ale bezmyślny metodologicznie power – user nie pomoże analitykowi. Analityk musi sam sobie pomóc.

Edycja II studiów trwa. Będziemy raportować.

-------------------------------------------------------------------------------------

* ”Poganie” czyli:
·        tzn. „profesjonaliści” spod znaku BI – czyli:
o   konsultanci,
o   prezenterzy na pokazach perswazyjnych o wyższości BI nad resztą świata,
o   informatycy
·        oraz różne osoby dumne z powodu przebywania w tak wytwornym towarzystwie, zwani w literaturze wdzięcznym terminem „pożyteczni idioci”
a nawet
·        inne trolle z cenzusem i z profesjonalnymi profilami, 
z    z których niektórzy, co bardziej zawzięci przedstawiciele, sprowokowani lub nie, wykazują zadziwiającą agresję posuwając się do szczawiowej frazy(„kłamstwo i pie…!”), okazując pogardę („fałszywy specjalista”) lub lekceważenie („wynalazek koła”). 

Komentarze

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…