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