Blaski i cienie wdrażania BI

Narzędzia Business Intelligence mogą dać firmie mnóstwo korzyści i pomóc w osiąganiu coraz lepszych wyników. Jednak – jak pokazują badania – ponad 50% wdrożeń BI się nie udaje. Dlaczego tak jest? Oto kilka moich obserwacji, zebranych podczas kilkunastu lat wdrażania rozwiązań BI.

1. Niezdefiniowanie na wstępie oczekiwań. Często główny cel projektu to „Chcemy wdrożyć BI/Hurtownię Danych/kokpity menedżerskie”. Tymczasem podstawowe pytanie brzmi: „Dlaczego chcemy to zrobić? Co chcemy dzięki temu usprawnić?”. Jeśli cel sformułujemy np. tak: „Chcemy dać szefowi produkcji codzienną bieżącą i zrozumiałą informację o przyczynach przestojów maszyn i braków produkcyjnych” albo „Chcemy, aby szef sprzedaży/logistyki na bieżąco śledził tzw. sprzedaż utraconą z powodu braku na stanie produktów, o które pytają klienci” – oszczędzamy czas, robotę i pieniądze. Bo zwykle dzięki tak zdefiniowanemu celowi wdrożenia jego efekty stają się szybsze i bardziej mierzalne.
2. Zbyt ogólne zdefiniowanie celu powoduje inny problem: rzucanie się od razu na zbyt głęboką wodę. Wdrożenie BI to przedsięwzięcie, które niezależnie od technologii, w której jest realizowane, daje się dobrze podzielić na mniejsze projekty. Tymczasem za często jest ono od razu realizowane „szeroką ławą”. I cóż z tego, że potem na różnych konferencjach dostawcy chwalą się zbudowaniem kostek OLAP o kilkudziesięciu wymiarach, skoro na co dzień nie daje się z nimi pracować? Sami sobie fundujemy w ten sposób mnóstwo pracy i kłopotów z odwzorowaniem w BI wszystkich naszych danych (a nie tylko tych potrzebnych w analizach), weryfikacją danych, wydajnością przetwarzania informacji potrzebnych i niepotrzebnych itp. To z kolei wiąże się często z kolejnym błędem:
3. Odwzorowanie „na wszelki wypadek” wszystkich informacji z ERP w BI. Widziałem taką firmę (i to niejedną), w której controlling... bał się zarządu. Wobec tego – ponieważ „nigdy nie wiemy, o co nas zapytają”, na wszelki wypadek zażyczył sobie odwzorowania absolutnie wszystkich informacji z systemów ERP w swojej Hurtowni Danych. Bardzo to podniosło koszty projektu, wydłużyło jego realizację, spowodowało koszmarne problemy wydajnościowe i w końcu się nie powiodło. A wystarczyło chwilę porozmawiać o biznesie – patrz punkt 1. Bardzo często przy takim podejściu fundujemy sobie błąd kolejny:
4. Chęć zaprojektowania wszystkiego „z góry”. To bierze się z dwóch przyczyn:
   1. technicznej (w tradycyjnych, „ciężkich” platformach BI tak rzeczywiście było, wszelkie zmiany konfiguracji wymagały przemyślenia skutków „7 kroków do przodu” (chcę zmienić pozycję na raporcie, to muszę przeedytować wymiar, zmienić jego hierarchię, sprawdzić, w których kostkach OLAP występuje, w jakich wyliczeniach, jakie to będzie miało skutki w raportach i analizach, w których występuje, przeprocesować wymiar i całą kostkę, zmienić metadane itd.). W nowoczesnej technologii „self service BI” mamy tzw. metodę NIKE – „just do it”...
   2. mentalnej – bardzo boimy się niepowodzenia projektu, więc na wszelki wypadek na początku robimy porządną dokumentację, żeby nikt nam niczego nie zarzucił. Tego zresztą wymagają tradycyjne metodyki wdrożeniowe oparte na PRINCE 2. Nowoczesne narzędzia wdraża się zwykle w oparciu o „lekkie” czy też „zwinne” metodyki oparte na SCRUM – gdzie więcej uwagi przykłada się do cząstkowych, bieżących, ale działających efektów i bieżącego korygowania tego, co robimy razem z odbiorcą naszych prac. Rzecz jasna, wszystkiego „z góry” – zwłaszcza po uprzednim popełnieniu wcześniejszych błędów – zaprojektować się nie da, niemniej często popełniamy kolejny błąd:
5. Tracimy długie miesiące na opracowanie bardzo obszernej i zupełnie niezrozumiałej dokumentacji, która zdumiewająco szybko przestaje być aktualna. Dzieje się tak dlatego, że dokumentacja powstaje „w kontekście” danego narzędzia informatycznego, z reguły też – co naturalne – uwzględnia jego rozmaite ograniczenia, przewiduje zatem ich obejścia. Użytkownik zwykle nie rozumie dokumentu Projektu Wdrożenia, akceptuje go trochę „w ciemno”, tymczasem to ten dokument staje się potem punktem odniesienia w ewentualnych sporach, aneksach, zmianach itp. Stąd bierze się spora część anegdotycznych sporów odbiorców rozwiązań IT z ich dostawcami, wynikłych z tego, że „przecież sami Państwo tak chcieliście”... Oprócz nieprecyzyjnego zdefiniowania celu projektu na wstępie wynika to często z:
6. Chęci nadrobienia w narzędziu BI „niedomogów” rozwiązania ewidencyjnego (np. systemu ERP, który... nie jest ERP – czy ktoś jeszcze pamięta, co w ogóle oznacza ten skrót?). Często spotykałem klientów, którzy mieli podstawową ewidencję zapasów, wyrobów gotowych, przyjęć i wydań do magazynu, nawet receptur technologicznych. Nie mieli jednak precyzyjnie zebranych danych o długościach cykli zaopatrzeniowych i produkcyjnych, przepustowości linii produkcyjnych, przestojach itp. Próbowali jednak w narzędziu BI odwzorować algorytm MRP... Do pewnego stopnia można próbować, ale często rozbijamy się o kolejny problem...
7. Niska jakość danych wejściowych. Jest takie brzydkie powiedzenie o czymś, co wpadło w wentylator... W przypadku wdrożeń BI można sporym nakładem pracy „wyczyścić”, czy uporządkować dane, ale nie da się znikąd „wyczarować” danych, których nie ma... Wdrożenie BI często pokazuje nam, czego potrzebujemy (i zwykle można to niewielkim kosztem uzupełnić), ale samo w sobie nie zastąpi brakującej ewidencji. Innym błędem jest:
8. Budowanie fabryki raportów. Business Intelligence zawiera w sobie słowo „business”, co wskazuje, dla kogo jest tego typu rozwiązanie. Jest ono dla businessu nie tylko dla analityków czy controllerów. Jeżeli business nie będzie bezpośrednio z takim narzędziem pracował, tylko nadal „zamawiał informacje/analizy/raporty” w controllingu, to nie uzyskamy efektu, o który chodzi. Narzędzie musi być na tyle proste i intuicyjnie zrozumiałe, by jego obsługa nie wymagała fachowej wiedzy informatycznej. Nie przypadkiem Gartner Group w tegorocznym raporcie w tzw. kwadrancie liderów umieścił wyłącznie rozwiązania typu „self service BI”, które spełniają to kryterium, czyli Tableau, Qlick i Microsoft... Tymczasem zbyt często myślimy tylko o tym, jak naszą „Fabrykę Raportów” wyposażyć w lepsze narzędzia. To nie zadziała, bo...
9. Z pracą w dobrym narzędziu BI powinno być jak z jazdą na rowerze. Jadąc na rowerze, nie myślimy o... rowerze, tylko o drodze, jaką mamy pokonać, dokąd jechać, jak omijać przeszkody, kiedy pracować nogami mocniej, a kiedy odpocząć przy zjeździe itp. Pracując z danymi, powinniśmy odczuwać to, co niektórzy nazywają „flow”, czyli... myśleć o danych i o tym, czego chcemy się od nich dowiedzieć, a nie o tym, jak działa samo narzędzie...
10. Ważne jest również na samym początku określenie zasad przyszłej współpracy z dostawcą. Chodzi o to, by nie wpaść w tzw. pułapkę uzależnienia od dostawcy. To częsta przypadłość nawet bardzo dużych firm, zwłaszcza wdrażających tradycyjne, „ciężkie” platformy BI. Po jakimś czasie okazuje się, że ... bez dostawcy to w ogóle nie działa, a tylko dostawca posiada „wiedzę tajemną” na temat funkcjonowania naszych mechanizmów ETL czy naszego modelu danych. Taka utrata kontroli nad istotnym elementem własnej infrastruktury IT może być bardzo groźna dla funkcjonowania firmy. A zazwyczaj rachunki za tego typu „outsourcing” jedynie rosną z czasem...