Przejdź do głównej zawartości

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


Kompleks Informatyczny - etiologia

Dalszy ciąg refleksji po zakończeniu pierwszej edycji studiów podyplomowego „MS Excel w controllingu dla zaawansowanych” (EXCze szczególnym uwzględnieniem bloku - Informatyczny Warsztat Controllera (IWC).

Sformułowany w pierwszej części niniejszego cyklu cel dydaktyczny Informatycznego Warsztatu Controllera (eliminowanie informatycznego kompleksu u słuchaczy Studiów), wymaga bliższego wyjaśnienia.

Na kompleks ten składają się trzy charakterystyczne cechy często spotykane u przeciętnego analityka/controllera.

1.       Excelioza, czyli zaawansowane, lecz nieoptymalne, a więc nieprofesjonalne i prowadzące do problemów, użytkowanie głównego narzędzia analizy - Excela

2.       Bariera danych, czyli
a.       Braki w wiedzy o strukturze danych oraz o języku ich opisu i manipulacji
b.      Braki w umiejętnościach posługiwania się danymi do analizy i controllingu, ze szczególnym uwzględnieniem współczesnych baz danych
oraz

3.       Bariera informatyki, albo Alienacja informatyczna, czyli
a.       Trudności w porozumieniu się z profesjonalnymi informatykami, a zwłaszcza brak umiejętności stawiania im zadań i rozliczania z ich wykonania
b.      Niski stopień rozumienia natury procesów informatycznych, a zwłaszcza ich składników i struktury, czyli architektury środowiska informatycznego wspierającego analityka.
Skutkuje to:
c.       powstaniem wspomnianej bariery między specjalistami od rozwiązywania merytorycznych zagadnień a wspomagającymi ich informatykami.
d.      trudnościami z włączeniem się analityka/controllera w obieg informacji,
e.      poczuciem obcości wobec infrastruktury informatycznej, teoretycznie stworzonej dla jego potrzeb.

Kompleks informatyczny – diagnoza

Pokonanie opisanego kompleksu, ze szczególnym uwzględnieniem tych dwóch barier,  jest kluczowe dla rozwiązania ważnych problemów analizy/controllingu.
Czy informatycy, jako wspierający analityków "konsultanci",  są w stanie tu coś pomóc? Niestety, niewiele.

Informatyk słabo rozumie zagadnienia merytoryczne controllingu i analizy biznesowej a zwłaszcza praktyczne wymogi ich modelowania i rozwiązywania (np.zmian w modelu rozwiązania w "rytm biznesu").
Naturalną specyfikację problemu w Excelu ("standard przemysłowy"!) rozpatruje wyłącznie pod kątem potrzeb projektu informatycznego. Problemy analityka z profesjonalizacją tej "specyfikacji" nic go nie obchodzą.
Mało tego. Dostrzegane przez niego "naiwności" rozwiązania "exceliotycznego" bierze za ich cechę wrodzoną.
"Excel, excelioza", wiadomo!"
I faktycznie, owa "specyfikacja", obarczona błędem "exceliozy", pozostawia wiele do życzenia.
Ale, paradoksalnie, informatyk słabo zna Excela, więc mimo świadomości niedostatków specyfikacji, sam nie umiałby jej sprofesjonalizować.

Z drugiej strony jest pozbawiony kompleksów, za to pełen zawodowej pychy, poczucia fachowości, a nawet wyższości w stosunku do swoich „klientów”,  którzy nie rozumieją „podstawowych rzeczy”.

Sam zaś rozumie tylko język algorytmów i schematów. W skrajnych wypadkach – wymaga specyfikacji problemu „w narzędziu”, czyli na platformie jakiegoś systemu generowania raportów. Które to narzędzie potrafi później generować  schematy i algorytmy .

Firmy wspierające analizę i controlling wysyłają więc „konsultantów”, którzy pełnią rolę tłumaczy z „controllingowej exceliozy” na „informatyczną grypserę”.
Pierwszej nie rozumieją informatycy, drugiej - controllerzy.
Łańcuszek procesu tradycyjnego rozwiązywania powstających problemów się wydłuża. I podraża.

Skutek jest zawsze ten sam:
Informatycy umacniają się w przekonaniu, że problem muszą rozwiązać „po swojemu” a analityk po „niezdarnym” wytłumaczeniu konsultantowi „o co chodzi”, raczej przeszkadza niż pomaga.
Systemy informatyczne wspierające analizę/controlling słabo korespondują z wymaganiami a w każdym razie niemal zawsze są spóźnione w stosunku do zmieniających się potrzeb.
A analitycy? Ratują się … exceliozą.

Kompleks informatyczny – propozycja terapii

Jakie jest wyjście?  Są dwa.
          a) Niektórzy będą twierdzić, że – wyjściem jest (dalsze) usprawnienie procesu informatycznego
     b)  My twierdzimy, że jedynym wyjściem jest usprawnienie procesu analizy w ExceluZ Excelem w  roli głównej.  
Zaprojektowanie procesu zintegrowanego z danymi i z infrastrukturą informatyczną
Pokazanie analitykom/controllerom drogi do tajemniczego i pozornie nieprzystępnego świata informatyki. Drogi, której szukają trochę po omacku. Którą wreszcie rozpoznają, jako prowadzącą do ICH celu.

Pokazanie im, że – „to takie proste!”

Prawidłowo skonstruowany proces analizy w Excelu, oprócz wartości użytkowej, może być – prototypem znacznie sztywniejszego, ale prostszego w obsłudze i rozpowszechnianiu, rozwiązania na platformie jakiegoś systemu raportującego. Łatwego do prowadzenia „polityki informacyjnej” i „polityki bezpieczeństwa”. Abstrahując od ich złudnej skuteczności i bezalternatywności.

Jesteśmy wprawdzie przekonani, że dobrze skonstruowany proces analizy na platformie Excela, wspomagany oprogramowaniem zintegrowanym z platformą Excela właśnie,  będzie wypierać  tradycyjne rozwiązania informatyczne.

Ale to już inna historia.
To sprawa rozpowszechnienia powszechnej praktyki na przypadki wielkich korporacji, gdzie Excel króluje, ale "jakby" - "nielegalnie".
Ale początek, powinien być zawsze taki: Najpierw prototyp w Excelu. Według reguł sztuki.

I właściwie „prawie” jest. Niestety obarczony brzemieniem kompleksu informatycznego analityków. W exceliozie i przy pomocy przeklejek. W wersji zaawansowanej, zautomatyzowanych. Nie prototyp, tylko prowizorka. Najtrwalsze rozwiązanie we wszechświecie. Wymagające wiele żmudnej, nikomu niepotrzebnej roboty za każdym razem.  
Raz na tydzień, zamiast raz na zawsze.

Wnioski

Diagnoza jest oczywista.
Istnieje poważny problem na styku analityk/ controller jako użytkownik systemów wspierających proces analizy z jednej strony i  „informatyk wspierający” z drugiej. Jedną z jego przyczyn jest kompleks informatyczny aktorów procesu analizy/controllingu.

Pokonanie kompleksu informatycznego jest zadaniem dla analityka/controllera. Nasze doświadczenia w tym zakresie są jednoznaczne. Nikt go tutaj nie wesprze ani nie zastąpi. Nikt nie jest w stanie mu pomóc . Żaden doradca ani konsultant. Tylko on sam. I my go do tego zadania przygotowujemy.

Następne odcinki Refleksji będą dotyczyć składników kompleksu oraz konfrontacji naszych zamierzeń z pierwszymi doświadczeniami dydaktycznymi.

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…