Metodyka wdrożeń ERP w praktyce – na przykładzie metodyki ASAP:zaangażowanie użytkowników we wdrożenie systemu ERP

Wakacje się skończyły i trudniejsze stało się pisanie blogu. Postaram się jednak nie rzadziej niż co miesiąc napisać coś z aktualnych spostrzeżeń czy wydarzeń. Teraz chciałbym podzielić się sprawą – jak mi się wydaje – fundamentalną dla projektów wdrożeniowych ERP. Natchnienie do tego znalazłem w analizowanych przypadkach niepowodzeń projektowych. Chodzi o sprawę dużego zaangażowania użytkowników w procesie wdrożenia systemu ERP.

Autor: Waldemar Faliński

Uważam, że zaangażowanie to powinno być bardzo duże – nawet większe niż tego wymagają metodyki wdrożeniowe takie jak ASAP. Uważam, że właściwe było by aby to użytkownicy – oczywiście w formie wybranych spośród szerokiej rzeszy użytkowników kluczowych – wykonywali wszystkie prace projektowe. Brałem udział i w takich projektach i zapewniam, że skutek był wspaniały. Królujące obecnie projekty w formule fix-price powodują niestety, że tendencja bywa odwrotna – zmniejszania tego udziału. Ze szkodą dla użytkowników i dla biznesu. Zostańmy zatem przy typowym wymaganym przez metodyki udziale i zaangażowaniu. Jako ilustrację potrzeby tego zaangażowani przytoczę wspomnienie sprzed kilkunastu lat. W ramach SAP zawsze prowadziliśmy projekty z dużym zaangażowaniem użytkowników tj. najpierw byli szkoleni, potem razem z nimi budowana była koncepcja (czyli inaczej projekt rozwiązania – obecnie nazywany blueprintem), potem w fazie realizacji mieli trochę mniej pracy projektowej by w fazie testowania zaangażować się w testy i w szkolenie wszystkich użytkowników.

Jednak nie wszyscy tak robili – istniał wtedy też inny model wdrożeń praktykowany głównie przez wielkie firmy doradcze wdrażające w wielkich korporacjach w USA i innych krajach „Zachodu”. Model ten polegał na tym, że zaangażowanie użytkowników sprowadzało się do udziału tylko w wywiadach i ankietach prowadzonych przez konsultantów zewnętrznych. Potem konsultanci owi na podstawie tych ankiet i własnej analizy tworzyli koncepcję całego nowego zarządzania biznesem i w tych ramach systemu informatycznego. Często bowiem takie wdrożenie było częścią większego projektu zmiany biznesu nazywanego wtedy „business processes reengineering”. Następnie tworzyli system i na samym końcu szkolili wszystkich użytkownikach w zakresie posiadanych przez nich obowiązków na swoich stanowiskach pracy.

Niewątpliwą zaletą takiego podejścia projektowego było minimalne obciążenie własnych pracowników korporacji, ale za to koszt takich wdrożeń był gigantyczny. Dlatego tak prowadzone projekty niemal zupełnie nie przyjęły się w Polsce.

Takie podejście mogło się udawać kilkanaście lat temu gdyż wtedy pracownicy wielkich korporacji wykonywali rutynowe czynności związane z jakimś niewielkim wycinkiem całości procesów korporacji.

Obecnie w dobie permanentnych zmian, „zwinnego” podejścia do tych zmian czyli robienia ich krokami (inkrementalnie) takie podejście projektowe to anachronizm. Użytkownicy muszą być świadomi większego kontekstu wykonywanych przez nich prac – muszą być współautorami tworzonych rozwiązań, muszą mieć wiedzę jak kształtować system – do tego jedyną słuszną drogą jest ich udział w całym procesie wdrożenia.

Wracajmy zatem do teraźniejszości – tamte czasy minęły i wielkie firmy wdrożeniowe stosujące takie podejście albo wymarły jak dinozaury, albo zrezygnowały z wdrażania ERP albo zmieniły sposób postępowania. Tak mi się przynajmniej wydawało. Otóż ostatnio w ramach prowadzonych badań spotkałem się z dwoma przypadkami projektów, gdzie ta „oldskulowa” metoda – w mocno co prawda okrojonej wersji - została zastosowana. W projektach tych w fazie tworzenia koncepcji zaniechano szkolenia użytkowników kluczowych i dania im możliwości zaznajamiania się z systemem. Otrzymanie tej możliwości dopiero w późniejszej fazie zaowocowało wieloma nieporozumieniami i pretensjami i wprowadziło projekt zupełni niepotrzebnie w obszar znacznego ryzyka związanego z narastającym niezadowoleniem. Żaden nowoczesny system bowiem nie będzie działał tak jak stary, który zastępuje i to na dodatek lepiej. Będzie działał lepiej i … inaczej.

Oba przykłady dotyczą projektów z poważnymi problemami dlatego niejako „wczytały” się one w moje przekonanie, że tak nie da się zrobić w pełni udanego projektu. Kto wie – może ktoś ma dobre doświadczenia z takim sposobem wdrażania ERP?

Nie uda mi się tu omówić wszystkich aspektów aktywnego udziału użytkowników w procesie wdrożenia tu wspomnę dwa (chyba) najważniejsze. Pierwszym jest transfer wiedzy, który się w ten sposób efektywnie dokonuje. Drugim zaś jest zaznajamianie z nowym systemem, poznawanie jego specyfiki i stopniowe „polubianie” go. Otóż zazwyczaj decyzja inwestycji we wdrożenie systemu ERP wynika z radykalnej potrzeby usprawnienia pracy. Jest jednak typowym zjawiskiem, że po podjęciu takiej decyzji w trakcie wdrażania nowy system weryfikowany jest poprzez porównanie ze starym. Zachodzi zatem dosyć zabawne (ale też niezwykle poważne przez wzgląd na możliwe konsekwencje) zjawisko pewnej presji wywieranej przez użytkowników aby nowo wdrażany system jak najbardziej przypominał stary. Jest to działanie naturalne ale też bardzo szkodliwe.

Najgorszą sytuacją jest gdy wymagania na nowy system formułowane są na podstawie funkcjonowania starego rozwiązania. Przeważnie jest to tzw. „look and feel” czyli jak system prezentuje dane i jak przebiega z nim interakcja. Najlepszym sposobem aby „zgubić” taki sposób – jasno to powiem, że zły i szkodliwy sposób postrzegania – jest stopniowo zaznajamiać użytkowników z nowym systemem.

Zaznajamiają się oczywiście tylko użytkownicy kluczowi, ale oni są „agentami zmiany” i na bieżąco często wysyłają pozytywne sygnały do organizacji a ich przykład będzie działał później zaraźliwie na resztę organizacji – zarażając ją dobrym pojmowaniem wprowadzanego nowego systemu.

Mieli też możliwość zgłaszania na bieżąco uwag krytycznych – to też jest bardzo dobre zjawisko bo im wcześniej takie uwagi albo zostaną uwzględnione (jeżeli słuszne) albo zneutralizowane tym dla projektu lepiej. Ten aspekt omówię innym razem.

Jeżeli tego zaznajamiania z nowym systemem od początku wdrożenia zabraknie to tworzy się i narasta naturalna bariera, która może się później okazać trudna do przeskoczenia. Użytkownicy czują, że nie biorą udziału w tworzeniu nowego systemu więc nabierają do niego dodatkowo rezerwy. Ponieważ nie biorą aktywnego udziału nie mają możliwości zgłaszać poprawek, które im szybciej zostały by uwzględnione tym było by lepiej dla projektu.

Generalnie izolowanie użytkowników od prac projektowy prowadzi do sytuacji w której ciągle żywym wzorem i odnośnikiem będzie dla nich stare rozwiązanie, które ma zostać zamienione. Gdy wreszcie wejdą w kontakt – im później się to stanie tym gorzej – będą się koncentrować na tym, jak odbiega on od wcześniej wykorzystywanego rozwiązania i będzie to postrzegane przez nich jako wada.

Trudno jest mi wyobrazić sobie dobrze przeprowadzony projekt wdrożenia systemu ERP bez aktywnego udziału użytkowników. Zresztą – co może być niezwykle ważne przy dochodzeniu należytej staranności w realizacji wdrożenia – udział ten jest integralnie zapisany w metodykach wdrożeniowych systemów ERP jak np. w metodyce ASAP.