Systemom MRP II/ERP coraz częściej towarzyszą rozwiązania analityczne i systemy wspomagania decyzji. Niestety, znów okazuje się, że "pamięć organizacji" nie istnieje. Typowe wdrożenie systemu analitycznego, jak niegdyś systemu MRP II/ERP, zaczyna się od wyboru platformy do budowy rozwiązania, gdy tymczasem prawdziwe problemy tkwią w czym innym.

Wdrożenie systemu wspierającego zarządzanie przedsiębiorstwem ma zwykle na celu podniesienie sprawności operacyjnej firmy - automatyzację procesów, skrócenie cykli, uwolnienie kapitału zamrożonego w zapasach i produkcji w toku. Dodatkową korzyścią jest atmosfera sprzyjająca zmianom i usprawnieniom, pozwalająca przeprowadzić to, co na co dzień zrobić jest trudno.

Zarządy bardzo cenią efekty poprawy efektywności, bo mają co pokazać właścicielom, ale trzeba głośno powiedzieć, że ich potrzeby - jako strategów przedsiębiorstwa - nie są przez wdrożenia MRP II/ERP zaspokajane. Z mrowia danych zarządy muszą wyciągnąć wnioski i podjąć na ich podstawie decyzje strategiczne, decydujące o być albo nie być firmy.

Byłoby idealnie, gdyby dane same były w stanie powiedzieć, jaka jest kondycja przedsiębiorstwa, ewentualnie co zrobić, by tę kondycję poprawić. Najlepiej, aby system po analizie po prostu podpowiadał, wyświetlając zielone, żółte lub czerwone światło, wskazujące aktualną kondycję firmy w poszczególnych obszarach. Samo się jednak nie zrobi - od surowych danych do decyzji droga daleka.

Platforma to nie problem

Zaprojektowanie rzeczywiście użytecznego systemu wspomagania decyzji jest w praktyce bardzo trudne, trzeba bowiem przyjąć pewne założenia co do prawdziwości, a zwłaszcza znaczenia pewnych zdarzeń dla przyszłości firmy. Zarówno zarząd, jak i pracownicy nie bardzo są w stanie określić jakie są dokładnie warunki, które powinny wpływać na wartość takiego czy innego wskaźnika i jaka jego wartość w określonym kontekście jest "dobra" lub "zła". Pojawia się także problem z weryfikacją. O ile wskaźniki określające wydajność pracownika można dobrać i porównać je przed i po wdrożeniu części operacyjnej, to w przypadku rozwiązań BI chyba jedynym sposobem byłoby stworzenie drugiego, równoważnego modelu i porównanie np. prognoz.

Takie podejście zakłada jednak, że w sumie temu drugiemu modelowi bardziej ufamy niż oryginalnemu. Można oczywiście opierać się na danych historycznych i sprawdzać, czy model działa wstecz, ale trzeba mieć świadomość, że to wcale nie znaczy, że zadziała także w przyszłości. Do tego w rozwiązaniach BI czasami stosuje się niedeterministyczne algorytmy, jak chociażby sieci neuronowe czy logikę rozmytą, albo pojęcia wymagające dosyć wyrafinowanego aparatu matematycznego. Tak powstaje dodatkowa "bariera językowa" - klient ma wymagania odnoszące się do efektów, jednak sposobu ich osiągania może zwyczajnie nie rozumieć.

Bariera poznawcza przekłada się na sposób podejmowania decyzji o wdrażaniu rozwiązań. Niestety, w sposób negatywny. Gdy w latach 90. mieliśmy do czynienia z pierwszą falą wdrożeń tych systemów, wybieranie systemu zamiast analizy potrzeb było powszechne, co skutkowało bardzo dużym odsetkiem nieudanych wdrożeń. Dziś, gdy systemy MRP II/ERP spowszedniały, klienci znów ulegają skłonności do wybierania rozwiązań według tabelek funkcjonalności.

To tak jakby pamięć organizacji z wdrożenia systemu MRP II/ERP nie istniała. Typowe wdrożenie BI zaczyna się od wyboru platformy do budowy rozwiązania wspomagającego decyzje, gdy tymczasem informatyk powinien pojawiać się na samym końcu, gdy już dokładnie wiadomo, jakie zadania stoją przed nowym systemem.

O ile transakcyjne serwery baz danych są do siebie funkcjonalnie podobne, to serwery analityczne różnią się niekiedy zasadniczo, ale to jeszcze nie powód, by kupować coś tylko dlatego, że rozwiązanie jest "generalnie dobre". W tym, konkretnym przypadku może bowiem być całkiem niewłaściwe. Jeżeli, dajmy na to, najpierw zostanie zbudowana hurtownia, a potem okaże się, że jej zasilenie "dziennym wkładem" trwa dłużej niż doba, to rozwiązanie analityczne nie może w 100% bazować na hurtowni. Takich sytuacji może być więcej.

Raporty ze wszystkiego

Podstawową funkcjonalnością systemu wspomagającego decyzje są niewątpliwie raporty. Zasadniczym wymaganiem w stosunku do systemu raportowego jest to, by raport powstawał szybko i miał czytelny układ. W przypadku dużego systemu pojawia się problem z zarządzaniem zbiorem raportów, przy czym zarządzanie to nie tylko przechowywanie, czy aktualizowanie wersji.

Dla przykładu, taki Crystal Enterprise ma bardzo ciekawą możliwość śledzenia zależności między raportami i wychwytywania różnic, gdy np. raport o podobnej strukturze bazuje na innym zestawieniu. Microsoft Reporting Services ma co prawda oddzielnie rejestrowane na serwerze źródło danych i definicję raportu, ale nie przechowuje informacji o związkach pomiędzy raportami.

Można zaobserwować tendencję, by po wdrożeniu pozostało w firmie jak najwięcej gotowych raportów. Jednak czasami nikt się nie zastanawia, które z podsumowań są naprawdę potrzebne do podejmowania ważnych dla firmy decyzji. Innymi słowy, nie ma analizy stricte biznesowej, która prowadziłaby do wniosków technicznych.

Zamiast gotowych raportów lepiej wdrożyć mechanizmy automatyzujące proces przygotowywania raportów, a także mechanizmy, które pozwalają użytkownikowi samodzielnie zbudować raport na podstawie udostępnionych struktur danych. Tak też się dzieje, bo coraz więcej producentów oferuje narzędzia do projektowania raportów na bazie przygotowanego innego modelu danych.