Przymiarki do analizy

Wdrożenia rozwiązań analitycznych ponosiłyby fiasko znacznie rzadziej, gdyby ich uczestnicy zadali sobie trud udzielenia rzetelnej odpowiedzi na kilka podstawowych pytań.

Wdrożenia rozwiązań analitycznych ponosiłyby fiasko znacznie rzadziej, gdyby ich uczestnicy zadali sobie trud udzielenia rzetelnej odpowiedzi na kilka podstawowych pytań.

Niniejszy artykuł nie jest pełnym opisem metodologii wdrożenia systemu analitycznego, ale raczej próbą zwrócenia uwagi na trudne kwestie nieuchronnie pojawiające się w wszystkich projektach tego typu.

Na początek trzeba odpowiedzieć na pytanie: czy system analityczny jest w firmie w ogóle potrzebny? Pytanie niby proste, jednak znalezienie odpowiedzi i jej uzasadnienie (w sposób zapewniający budżet na projekt) - już nie tak bardzo. Na potrzeby niniejszego artykułu zakładamy, że odpowiedź brzmi TAK, to znaczy - są istotne potrzeby, które mogą zostać zaspokojone poprzez wykorzystanie systemu analitycznego i decyzja o wdrożeniu takiego systemu została podjęta.

Na potrzeby niniejszego artykułu ustalmy: system analityczny to system informatyczny udostępniający w sposób zintegrowany informacje uzyskane z wielu źródeł - systemów komputerowych, wskaźników, danych uzupełniających itd. w sposób pozwalający użytkownikowi efektywnie prowadzić analizy, a więc przeprowadzać symulacje, weryfikować wyciągnięte wnioski.

Definicja być może nieco długa, ale wszystko jest tu ważne. Informacje z wielu źródeł, tzn. będące poza zakresem każdego systemu w firmie rozpatrywanego osobno. Integracja odnosi się do jednolitej formy danych, uwalniającej użytkownika od czynności technicznych zmierzających do ich uprzedniego ujednolicenia i pozwalających mu zająć się wyłącznie ich analizą. Integracja oznacza także kompletność, a więc mówimy o systemie, w którym można znaleźć informacje o każdym aspekcie działalności firmy. Efektywność analiz odnosi się do możliwości uzyskiwania wyników w ciągu minut, a nie dni.

System niestandardowy

Czym tworzenie systemu analitycznego różni się od budowy innego (również dużego) systemu informatycznego? Otóż, dodatkową trudność, aczkolwiek nie jedyną, sprawia fakt, iż odbiorcy systemu analitycznego posługują się językiem biznesu, a wykonawcy - językiem informatyki, a to wywołuje problemy komunikacyjne. W przypadku systemu dziedzinowego o zaplanowanym sposobie wykorzystania, np. księgowość, kadry i płace itd., cel wdrożenia jest znany i należy "tylko" ustalić szczegóły. Aby system analityczny naprawdę wspomagał biznes klienta, a więc spełniał swoją rolę, od wykonawcy jest wymagana szczegółowa znajomość specyfiki tego biznesu u klienta.

Kolejne wyzwanie, jakie niesie budowa systemu analitycznego, to spełnienie oczekiwań użytkowników, którzy nie zawsze są w stanie precyzyjnie opisać je w sposób zrozumiały dla wykonawcy. O ile w systemach transakcyjnych, np. do obsługi sprzedaży, użytkownik musi z systemu korzystać, ponieważ nie ma innego sposobu wykonania konkretnej czynności, o tyle w przypadku systemów analitycznych użytkownik może z nich korzystać, choć nie musi. Robi to tylko wtedy, gdy stwierdza, że odnosi z tego wymierne korzyści, np. znacznie skraca czas wykonywania analiz lub otrzymuje informacje istotnie lepszej jakości niż w przypadku prostych raportów z systemu transakcyjnego. Niebagatelne znaczenie ma wygoda obsługi narzędzi analitycznych.

Ambitnie, ostrożnie, sprytnie

Do budowy systemu analitycznego można podejść na dwa sposoby. Pierwsze podejście (całościowe) polega na tworzeniu systemu analitycznego dla wszystkich obszarów działalności firmy jednocześnie, tak aby w momencie uruchomienia zostały uwzględnione potencjalne potrzeby wszystkich użytkowników. Często najpierw rozrysowuje się model działalności całej firmy, optymalizuje go, wprowadza niezbędne zmiany, następnie dostosowuje strukturę do wykonanych zmian (najlepiej równolegle w różnych obszarach), po czym określa założenia systemu i realizuje go. Wykonania tej ambitnej wizji trwa kilka lat, przy czym porażka jest praktycznie wpisana w założenia projektu.

Do poprowadzenia takiego projektu są niezbędne liczne zespoły odpowiedzialne m.in. za modelowanie, analiz funkcjonalną i techniczną, projektowanie, implementację, integrację i testowanie. Jeśli zespoły te komunikują się ze sobą, porażka może się pojawić nieco później. Pułapka tej metody polega na tym, iż model działalności firmy zmienia się w czasie, w związku z czym przy odpowiednim rozmachu modelowanie i projektowanie może się nigdy nie skończyć (lub nie skończyć się przed zakończeniem projektu). Jeżeli w pewnym momencie zostanie podjęta decyzja o implementacji, to przy tej skali po kilku latach uruchamiany system nie będzie pasował do aktualnego modelu działania firmy. Realizacja projektu wg tej strategii zapewnia pracę na długi czas dużej liczbie osób, jednakże projekt tego rodzaju jest obarczony wysokim ryzykiem porażki.