Owoce dyskusji o architekturze SOA (1)

Gorąca, a miejscami wręcz brutalna dyskusja przyniosła mi wiele inspiracji.
W dyskusji nie jestem najlepszy. Ale po wyjściu na schody, zaczynam myśleć na nowo. Dlatego powstało wiele wypowiedzi - felietonów. Przyjęte, jak najgorzej, jako "elaboraty", "woda" i określane róznymi innymi złośliwymi określeniami, moim skromnym zdaniem dodają trochę dodatkowych informacji.

Postanowiłem je stopniowo publikować.
Tam - niedocenione, tu - zobaczymy. Tam, nie mogę zbanowac nikogo, nawet ewidentnego trolla ze zdjęciem, tu będę selekcjonował, jeśli będą komentarze. Krytycznych wyglądam z tęsknotą.
Śmiecie wymiatam co jakiś czas.

Zaczynam.

Ogólne rozważania o architekturze analiz 

Tematem wątku była architektura środowiska analiz. SOA.

Jednak przyjęcie, że termin „architektura” jest rozumiany dokładnie tak samo przez wszystkich ewentualnych gości wątku chyba był nadmiernie optymistyczny. 

Wydaje mi się, że tym założeniem przynajmniej częściowo zawiniłem zbyt pochopne odejście niektórych krewkich dyskutantów, którzy mogli by wnieść jakieś cenne uwagi. 

Na przykład pan Robert Woźniak, w końcu inspirator wątku, któremu tą drogą składam podziękowanie za inspirację. Nie mogę odżałować, że złożył taką pochopną deklarację. Że już „wszystko rozumie”, że „tu nic nie ma”. No i potem „prawie” wytrwał w swojej konsekwencji.

Dlatego zacznę od pieca.

Termin 
„architektura” rozumiem, jako „zorganizowanie określonej przestrzeni do życia i działania dla CZŁOWIEKA”.

Z tego wynika, że kształtując architekturę analiz musimy wyjść od podmiotu, który działa - analizuje.

To się wiąże z pytaniem, zadanym przez jednego z dyskutantów:

Jakie konkretne wymagania realizuje owa architektura "SOA" w rozumieniu tego wątku...

Spróbujmy skorzystać z tego punktu wyjścia.

Kształtując architekturę ustalamy hierarchię elementów organizowanej przestrzeni. 

Najpierw centrum architektury. 

Gdzie jest centrum? 
Możliwie blisko punktu ciężkości albo, inaczej to określając, w pobliżu najważniejszego węzła komunikacyjnego, gdzie krzyżują się szlaki komunikacyjne i informacyjne, gromadzą najważniejsze kompetencje i skąd płyną najważniejsze informacje. Informacje, nie meldunki, bo meldunki oczywiście płyną zewsząd.

Następnie, jeżeli pomyślimy o zorganizowaniu środowiska dla tych, którzy są czynnikiem sprawczym analizy, czyli tych, którzy są jej podmiotem, również logiczne wydaje się, że powinniśmy centrum ustalić zgodnie z ich punktem widzenia.

Wreszcie, jeżeli myślimy o wzajemnym usytuowaniu elementów architektury, takich, jak:
- źródła danych i 
- platforma ich analizy 
– to ponieważ przepływ jest 
- od źródła - do platformy, 
postulat, żeby architektura sprzyjała naturalnemu ruchowi w pożądanym kierunku (a nie powodowała opór)

oraz
by to zainteresowany podmiot decydował o przedmiocie swego zainteresowania
wydaje się godny rozważenia.

Czy takie sformułowanie wymagań jest sensowne?

Przypuśćmy, przynajmniej na chwilę, odpowiedź twierdzącą i zobaczmy, co z tego wynika.

Jeśli wiemy, że główny nurt analizy odbywa się w Excelu a całą „profesjonalna informatyka” jest kosztownym, a czasem, w części, zbędnym dodatkiem, to odpowiedź, gdzie powinno znajdować się centrum, sama się narzuca.

Na platformie analitycznej, czyli w skoroszycie. 
Architekturę trzeba organizować wokół skoroszytu. 

Reszta to już tylko technika i konsekwencja tego punktu wyjścia.

Skoroszyt jest wymarzonym celem każdego analityka, który dostał nietrywialne zadanie analizy.
Proszę wybaczyć bezpośredniość. Może to zbyt radykalne, może nawet trochę przesadzone. Być może. Ale, szczerze mówiąc, szczerze wątpię.

Muszę na koniec stwierdzić jeszcze jedno. 
Właściwie przeważająca, przytłaczająca i dominująca część wypowiedzi z całą swą emocjonalną intensywnością, żarliwością i wytrwałością skupia się właśnie na podważeniu tych założeń. 

Dlatego dyskusja goni w piętkę. 
My – autorzy koncepcji - nie damy się przekonać, że jest inaczej. Wiemy swoje.
Dyskutanci – głównie rzecznicy profesjonalnej informatyki i jeden analityk, nie dadzą się przekonać, że to założenie jest słuszne. Ich wypowiedzi skupiają się na dowodzeniu, z różnym skutkiem, czasem wręcz kompromitującym autorów wypowiedzi, jakie straszne rzeczy dzieją się w Excelu, gdy opieramy się na nim, jak na centrum analizy.
Link do mojej polemiki z przykładowym zestawem takich wypowiedzi znajduje się tutaj:
http://www.goldenline.pl/forum/3099900/architektura-sr...

Być może tak jest. A nawet w wielu wypadkach, za wielu wypadkach, na pewno tak jest.
ALE JEST. Excelioza się szerzy. I działa. Na czas, zgodnie z oczekiwaniami. Czasem wręcz pracując na rachunek niesprawnego BI – aja. 

„Wyciągniesz to sobie jakoś z BI – aja”. === „Zrobisz analizę w Excelu, na podstawie przeklejek z BI- aja”

A to jest nasza propozycja, żeby BYŁO lepiej. Jak ktoś jest zainteresowany, zapraszamy.

Ogólne doświadczenia z dyskusji o architekturze SOA

Wątek o architekturze SOA został uhonorowany przyklejeniem na czele wpisów i znajduje się aktualnie na pierwszym miejscu wpisów grupy Business Intelligence.
Dyskusja o architekturze SOA na portalu Golden Line

Jest ponad pięćset komentarzy. Ale ta ilość nie jest najważniejsza, ponieważ poziom wpisów jest bardzo nierówny.

Jawne konta "specjalistów" nie uchroniły mnie od chamskich ataków i namolnego trollowania. Nie jest to wprawdzie trollowanie a la onet, ale poznałem inny rodzaj trolli.

Ludzie, którzy dają swoje twarze dla autora obelg i potwarzy, dyskutują poniżej poziomu i wbrew logice. Ignorując argumenty i nie rozumiejąc, co się do nich mówi.
Czy się cieszyć, że zostało się "gwiazdą" w takim dymie?

Wartością dodaną, oprócz tego dymu, który służy do utwardzania skóry, jest wiele wpisów rzeczowych, rzetelnych i kompetentnych. Krytyka jest ostra ale odnosi się ad meritum, nie ad personam.

Zmusza do myślenia i inspiruje. Pokazuje nowe pola problemowe i ujawnia inne podejście a nawet inną mentalność.

Nie tylko analitycy są na świecie. I trzeba współpracować ze specjalistami z innych dziedzin, żeby osiągnąć pozytywne wyniki.

Spodziewajcie się sprawozdania z podsumowania.
Ale w kawałkach.
"Słonia, jak powiedział generał kwatermistrzostwa armii amerykańskiej, jemy po kawałku".

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)