Wdrożenia ERP – cz. II. Case nr 1: zakres, strategia i planowanie wdrożenia ERP

Wpis gościnny dr hab. inż. Andrzeja Zalewskiego

Kolejny z serii wpisów gościnnych dr hab. inż. Andrzeja Zalewskiego na temat wdrożenia ERP. Wpisy te pierwotnie opublikowane były na grupie FB, dzięki uprzejmości autora prezentujemy je również na łamach Rudej Strony Zarządzania.

Poprzedni wpis był ważny, gdyż na jego podstawie można łatwo zorientować się we własnej sytuacji, w chwili przystępowania do wdrożenia… dostarcza też niezłych ram dla oceny przypadków z przeszłości.

Matka karmiciela (Politechnika Warszawska) wdraża SAP’a

Funkcjonując w danej instytucji od lat często nie zdajemy sobie sprawy z tego, jak złożony mechanizm ona stanowi. Największe uczelnie wyższe to właśnie takie skomplikowane mechanizmy, tonące w setkach egzotycznych dla biznesu regulacji, zatrudniające tysiące ludzi, rozproszone często po całym mieście, a niekiedy nawet po kilku miejscowościach. Słowem każdy doświadczonych ERP’owiec od razu przeczuwa kłopoty…

Początki

Rzecz dzieje się ok. 2007 roku po serii działań rozpoznawczych typu: wizyty studyjne, demonstracje, konferencje (szczęśliwych) użytkowników etc. Cztery wielkie uczelnie podpisują umowę z konsorcjum firm wdrożeniowych i SAP.

Zakres projektu przyjęto „skromnie” – bodaj 12 modułów (standardowe ERP: finanse, HR, controlling, plus obsługa toku studiów, spraw studenckich etc.).

Oczekiwanie na porażkę i porażka

Słysząc o takim zakresie projektu ludzie z doświadczeniem chwytali się za głowę. Doświadczenie uczyło, że w najlepszym razie udaje się wdrożyć na raz „małe” kilka modułów. Rzecz faktycznie zakończyła się porażką, która – jak to porażka – jest zawsze sekwencją błędnych decyzji i zwyczajnego pecha.

W przypadku mojej uczelni niewątpliwie oderwany od realnych możliwości zakres projektu skutkował brakiem wiary w powodzenie zamierzenia po stronie uczestników PW, to z kolei obniżało ich zaangażowanie i skutkowało efektem „oczekiwania na porażkę”.

To jednak samo pewnie nie dobiłoby projektu, gdyby wykonawca swoją systematyczną pracą pokazywał, że sceptycy się mylą, a wdrożenie posuwa się do przodu a wyuzdane potrzeby Uczelni zostaną finalnie zaspokojone.

Ciosem w plecy było odejście doświadczonego zespołu z firmy wdrażającej i prowadzenie wdrożenia przeciążonym zespołem z łapanki. Niestety, ale liczba zespołów znających się na dużych ERP’ach jest ograniczona i najczęściej ich kalendarz jest ustalony na kilka miesięcy przed kolejnym rokiem.

W efekcie powstał diabelski krąg: brak przekonujących działań wykonawcy -> wątpliwości co do osiągalności u zamawiającego -> ograniczenie zaangażowania zamawiającego -> słaba współpraca zamawiający <–> wykonawca -> jeszcze mniej przekonujące działania utrudniające przekonywujące działania wykonawcy.

I na tym pierwsze podejście się zakończyło.

Podejście nr 2

W kolejnym podejściu nie popełniono błędów z poprzedniego, a nawet podjęto decyzje – dziś oczywiste – ale uważam, że w tamtych okolicznościach po prostu genialne.

Otóż podzielono projekt na część analityczną i część wdrożeniową, przy czym firma robiąca analizy nie mogła wdrażać, do tego miała success fee… Firmę wdrożeniową wybrano na podstawie wymagań określonych przez firmę analityczną! Zakres początkowo zawężono do modułów HR, gdyż tu potrzeba wymiana użytkowanego do tej pory systemu była najpilniejsza. W kolejnym kroku w tym samym reżimie zrealizowano wdrożenie modułów finansowych.

Za istotną ciekawostkę należy uznać fakt, że wdrażając moduły HR niezbędne było podjęcie pewnych decyzji odnośnie konfiguracji modułów finansowych, zdefiniowanie struktur organizacyjnych i innych istotnych elementów, które musiały zostać zdefiniowane nim jeszcze doszło do wdrożenia w obszarze finansów.

Projekt realizowany był w obu przypadkach klasycznie – nie agile’owo.

Ciekawą miarą stanu przedsięwzięcia ERPowego i predyktorem jego sukcesu jest liczba członków Komitetu Sterującego – w pierwszym podejściu przekraczała 10 osób, w drugim było już jak nakazuje Prince2: biznes, główny użytkownik i wykonawca (3 osoby), którym towarzyszyli w spotkaniach kierownicy projektu.

Projekt się udał i SAP jest po dziś dzień w użyciu.

Key takeways

1. Nie przesadzaj z zakresem: zakres wdrożenia winien odzwierciedlać zdolność organizacji do dostosowania się do korzystania z nowego narzędzi i ilości czasu, które jest gotowa na to poświęcić…
2. Strategia wdrożenia jest ważna i musi być dostosowana do etapu dojrzałości wdrożeniowej (patrz pierwszy post)
3. Bez dojrzałości wdrożeniowej – wdrożenie ERP to stąpanie po polu minowym. Osiągnięcie dojrzałości wymaga czasu. A swoją drogą to ciekawe zadanie dla coachów / facylitatorów.
4. Optymiści nie mają racji – zawsze będą tacy, którzy uważają, że można „grać” wbrew doświadczeniu, że nie będą nam mówić inni, jak mamy realizować projekt. Doświadczenie jednak daje się pokonać sporadycznie (tak, jak rzadko udaje się dotrzeć do celu istotnie szybciej niż mówi google ).
5. Kompetencje wdrażającego i stan jego zespołu są kluczowe – przypadkowo zbudowane zespół to na pewno duże ryzyko.

O autorze

Andrzej Zalewski, dr hab.

Informatyk pracujący na Politechnice Warszawskiej, gdzie uczy algorytmiki oraz zarządzania projektami informatycznymi w firmach. Udziela się również jako ekspert i biegły w dziedzinie inżynierii oprogramowania. Kieruje Studiami Podyplomowymi Zarządzanie Zasobami IT oraz Zarządzanie projektami.