Wdrożenia ERP – etapy i fazy – przyczyny wydłużenia: rozszerzenie zakresu

No i proszę – miałem pisać o długości wdrożeń ERP posiłkując się raportami (o których pisałem w poprzednich wpisach), a tu właśnie ich autor - firma Panorama Consulting Services - przesłała mi kolejny „newsletter” mail pod tytułem bardzo pasującym do tego zamiaru: „Defining Your ERP Implementation Phasing Strategy”

Autor: Waldemar Faliński

Przychodzi mi o tym pisać w towarzystwie najświeższych znakomitych danych o wynikach branży ERP opisanych pod tytułem:

http://www.computerworld.com/s/article/9229735/Wall_Street_Beat_ERP_mobile_devices_shine_in_mixed_earnings

Które zdają się potwierdzać, że w czasach kryzysu firmy nie oszczędzają na tym, po czym spodziewają się znacznych oszczędności.

Ponieważ usłyszałem, że jestem niepoprawnym optymistą muszę w tym miejscu ponownie podkreślić, że moje przekonanie co do systemów ERP buduję na doświadczeniu ponad 17 lat w tej „branży”. W SAP z racji mojej funkcji miałem do czynienia z projektami, które popadły w tarapaty. Również jako „najemnik” miewałem z takimi projektami do czynienia i stwierdzam z pełnym przekonaniem: nawet te najbardziej kłopotliwe kończyły się powodzeniem. Z racji mojej obecnej działalności byłbym może nawet zainteresowany tym, by rzeczywiście wdrożenia ERP uchodziły za skomplikowane, długotrwałe i ryzykowne. Jednak uważam, że bezpodstawne straszenie jest szkodliwe również dla takich jak ja „niezależnych” doradców. W tym duchu opracowuję te materiały. Niewątpliwie wdrożenia ERP są trudne, ale przestrzeganie kilku zasad związanych z metodyką ich wdrażania sprawia że ich powodzenie jest niemal gwarantowane - jak to napisałem w pierwszym wpisie.

Przechodząc do tematu stwierdzam, że ze sposobem prezentowania danych statystycznych podanym przez firmy badające rynek ERP mam zasadniczy problem związany z tym, jak postrzegają one długość wdrożenia i jak krytycznie się odnoszą do jego przekroczenia. Otóż wyjawię, że tak postrzeganą jego długość, jak i wiele przypadków jej przekroczenia ja z kolei (na podstawie doświadczenia) uważam za podstawę uznania za sukces, a nie porażkę.

Otóż długość wdrożenia definiowana jest w tych badaniach jako jego całość w ramach której poszczególne części funkcjonalnie realizowane są w przesunięciu czasowym wobec siebie jako fazy. Taki sposób uważam za bardzo gmatwający całą sprawę i sprawiający, że wysnuwane na tej podstawie wnioski mogą być obarczone dużym błędem.

Omówienie tej tematyki przekracza formułę blogu zatem postaram się w punktach wskazać o co chodzi. Uważam, że należy jako wdrożenie rozpatrywać jedną fazę – czyli projekt zaczynający się w jednym punkcie, mający ustalony zakres i cele no i oczywiście zakończenie. Tylko tak ujęty projekt i czas jego realizacji jest miarodajny.

Jak już we wcześniejszym wpisie podałem dla systemów ERP przyjąłem 9 miesięcy jako właściwy czas trwania wdrożenia – jako SAP ERP benchmark. Taki czas przyjęty szczególnie dla wdrożenia całej funkcjonalności „core ERP” na raz jest najbardziej właściwy i miarodajny do porównań i wniosków.

Do celów statystycznych obejmowanie jako wdrożenie wszystkich jego faz uważam za metodycznie wadliwe ponieważ:

Tak więc za szeroko i zbyt ogólnie zarysowane są kryteria zarówno samego wdrożenia jak i jego interpretacje. Dlatego uważam, że do celów porównawczych należy używać faz i to najlepiej fazy pierwszej, w której wdrażany jest core ERP.

Najczęściej też plan projektu ustawiony jest tak, by umożliwić rejestrację danych w nowym systemie od początku roku obrotowego, który najczęściej tożsamy jest z rokiem kalendarzowym. Ma to swoje odzwierciedlenie w tym, że zależnie od daty zawarcia umowy wdrożeniowego na realizację fazy pierwszej jest właśnie tyle czasu ile go zostało do końca roku obrotowego.

Raport Clash of the Titans wskazuje, że średni projekt wdrażania SAP ERP planowany jest na 15 miesięcy, a realizowany w 17 miesięcy czyli występuje przekroczenie o 2 miesiące. To w mojej ocenie bardzo dobry wynik. Wskazuje najwyraxniej, że średni projekt składa się z 2 faz funkcjonalnych.

Zaraz przyjrzę się wykazanym na podstawie badań przyczynom przekroczenia terminu. Firmy badające rynek ERP wykorzystują przekroczenie planowanego czasu realizacji projektu jako pretekst do utyskiwania, że firmy zamawiające wdrożenia nie prowadzą właściwych badań i nie zlecają analiz przedwdrożeniowych. Nie jest moją intencją psucie biznesu takim firmom, ale na podstawie statystyk nasuwa się oczywiste pytanie, czy aby „zaoszczędzić” dwa miesiące, o które przedłuża się średnio wdrożenie SAP ERP warto takie analizy zlecać, co przecież też w jakiś sposób spowoduje podniesienie kosztu i wydłużenie terminu.

Z mojego doświadczenia dopiero konkretne narzędzie i konieczność jego stosowania przez organizację w najlepszy sposób weryfikuje stopień jego zastosowania i te dwa miesiące przedłużenia projektu ponad zaplanowany termin to niewielki koszt takiej zmiany. Nie traćmy z oka tych świetnych wyników dotyczących zwrotu z inwestycji we wdrożenie ERP – całkowity zwrot w 2,5 roku od wdrożenia to korzyść wielka nieadekwatnie do 2 miesięcy przekroczenia terminu!

Z tym pojawia się zagadnienie po co te fazy? Z technicznego punktu widzenia najbardziej optymalnie było by wdrożyć wszystko razem gdyż wtedy w szczególności nie będzie konieczności budowania tymczasowych interfejsów i rozwiązań. No ale jest jeszcze czynnik ludzki i organizacyjny – czyli uzasadniona obawa, że ludzie i organizacja tego nie wytrzyma.

Warto tu wspomnieć o prostych zasadach – w tym miejscu nie zgadzam się z poglądem wyrażonym przez firmę Panorama CS że ułożenie projektu w fazy wymaga jakiejś tajemnej wiedzy – najczęściej bowiem powody takiego działania tkwią w organizacji firmy wdrażającej system ERP i to ona sama wychodzi z inicjatywą ukształtowania faz projektu. Najlepiej jest gdy cała funkcjonalność mająca bezpośredni wpływ na kształt i sposób rejestracji danych w bazie danych zostanie wdrożona razem w pierwszej fazie.

Co do przedłużenia to zobaczmy na mechanizm jego występowania. Skoro wdrożenie „core” ERP musi się zagończych by z początkiem nowego roku obrotowego rejestrować zdarzenia gospodarcze w nowym systemie to na czym takie opóźnienie miało by polegać? Najczęściej (a według mnie zawsze) polega na tym, że system jest gotowy i rozpoczęto w nim pracę wraz z początkiem roku natomiast nie są gotowe niektóre z potrzebnych raportów. Co to ma niby być za opóźnienie?!

Popatrzmy na statystyki dotyczące przyczyn opóźnień. W raporcie Clash of the Titans podano, że w 29 procentach przyczyną przekroczenia planowanego terminu zakończenia projektu jest rozszerzenie ustalonego zakresu projektu („Initial Scope was Extended”). Z opisu można się dowiedzieć, że jest to wynikiem pośpiechu i braku właściwego rozpoznania. Osoba zajmująca się publicystycznie rynkiem ERP na pytanie o co może chodzić wyjaśniła mi, że chodzi o sytuacje gdy zapomniano lub przeoczono jakiś ważny zbiór funkcji. I to miało by się zdarzać w 29% przypadków? Zdumiewające! Różne rzeczy widziałem, ale czegoś takiego nigdy! Każdy miał praktyczną styczność z wyborem systemu ERP dla wielkiej organizacji wie, że to proces związany z wielką odpowiedzialnością, w którym „pierwsze skrzypce” grają osoby kluczowe dla biznesu tej organizacji. Systemu ERP nie kupuje się na zasadzie kaprysu. W takich procesach tworzone są listy (mapy) funkcji (procesów) z precyzyjnym opisem jak mają działać. Dostawca składając ofertę musi „zamapować” funkcje systemu i zapewnić, że będą działały w wymagany sposób.

Tak wic przypadek „przegapienia” istotnego zakresu funkcjonalności wykluczam zdecydowanie choć będę dociekał, czy może ktoś z czymś takim się w praktyce spotkał.

Na podstawie analizy własnych doświadczeń i rozmów ze specami z branży ustaliłem następujące scenariusze sytuacji przekroczenia terminu i budżetu przez „Rozszerzenie Zakresu Wdrożenia”:

1. W trakcie wdrożenia Odbiorca (tak go umownie nazwijmy) odkrywając funkcje i możliwości systemu postanawia pogłębić lub poszerzyć sposób wykorzystania systemu w ramach przewidzianych do wdrożenia funkcji ponad stopień i zakres w jakim zamierzał go używać;
2. W trakcie wdrożenia Odbiorca poznając z bliska funkcje systemu szkoleniowego odkrywa, że jednak jakaś ważna funkcjonalność spoza zakresu jaki deklarował, jako wymagany, bardzo by mu się jednak przydała i postanawia go włączyć w zakres;
3. Dostawca zawęził zakres funkcjonalny oferowanego systemu i/lub nie uświadomił wystarczająco trudów wdrożenia czekających Odbiorców;
4. Wymuszenia na Dostawcy – odbiorca systemu z jakiegoś powodu „kontestuje” zakończenie prac chcąc coś w ten sposób na Dostawcy wymusić;
5. Specyfikacja systemu przedstawiona przez Odbiorcę nie była wystarczająco dokładna (drugie dno jakiejś istotnej funkcji, rzadko wykonywany raport…);
6. Dostawca przyjął nierealny dla określonego budżet i zakres wdrożenia.

Ad.1. To jest wydaje się przypadek najczęstszy i nie mam wątpliwości, że świadczy on o powodzeniu wdrożenia – Odbiorca odkrywa nowe możliwości, których nie przewidywał i chce je biznesowo wykorzystać. Profesjonalny kierownik projektu, a za nim Dostawca powinien uświadomić „koszt” takiej zmiany – nie jest on zazwyczaj wielki. Pora wyjaśnić co to takiego jest – najczęściej jest to możliwość znacznie „głębszej” (aniżeli określona przez Odbiorcę w specyfikacji) klasyfikacji – towarów, środków trwałych, obiektów zbierania kosztów i zysków itd. W tym przypadku wystąpić może niebezpieczeństwo przekroczenia wolumenu danych czy przepustu transmisji danych gdyż taki głębszy sposób klasyfikacji oznacza, że ilość danych wynikających z tych samych zjawisk gospodarczych się pomnaża. Dotyczy to szczególnie klasyfikacji towarów w handlu detalicznym. W tym przypadku może się okazać, że przewidziany sprzęt okaże się niewystarczający. Dobrze o tym pomyśleć zawczasu, bo po starcie produktywnym może dojść do zakłóceń biznesu. Dwa przypadki zakłóceń biznesu z jakimi miałem do czynienia w Polsce miały związek właśnie z takim zjawiskiem – postaram się omówić to w innym wpisie. Jeżeli nie liczyć tych zakłóceń (które są ewidentnym przykładem negatywnym na krawędzi z katastrofą) to ewentualne wydłużenie czasu czy przekroczenie budżetu (rozszerzenie sprzętu, więcej pracy przy migracji itd.) nie można traktować jako zjawisko jednoznacznie negatywne. Takie rozszerzenie uważam za zjawisko pozytywne gdzie Odbiorca świadomie ponosi większy niż zakłada wysiłek ale osiąga znaczne korzyści.

Ad 2. Taki przypadek wydaje mi się może wystąpić na mniejszym mniej sformalizowanym wdrożeniu. Duzi Odbiorcy – i mówię to z pełnym przekonaniem – są bardzo świadomi swoich potrzeb i tego typu sytuacja u nich może wystąpić w wariancie, iż już wcześniej interesowali się taką funkcjonalnością (np. Remonty i Utrzymanie, Zarządzanie Nieruchomościami…), ale nie wiedzieli kiedy i w jakim zakresie będą chcieli ją wdrożyć. System szkoleniowy dostępny i sparametryzowany jest w całym zakresie funkcjonalnym zatem korzystają z okazji i poznają te funkcjonalności z bliska. W każdym razie „odkrycie” takiej funkcjonalności i na zasadzie aneksu rozszerzenie o nią projektu (co pociąga naturalnie przekroczenie pierwotnego budżetu, a być może terminu zakończenia poprzez dodanie nowej fazy) nie można kwalifikować jako negatywne – jest to objaw sukcesu projektu.

Ad. 3. W raporcie firmy Panorama CS jako jedną z przyczyn opóźnień tego typu podaje się, że często dostawcy systemów ERP zawężają zakres funkcjonalny oferowanego systemu i nie uświadamiają wystarczającą Odbiorców o trudach, jakie ich czekają. Co do tego drugiego, to tego typu uwagi są powszechne w każdym trwającym dłużej procesie – tak też często mówią ludzie, którzy wybudowali sobie dom, mimo iż o tym co takie przedsięwzięcie znaczy rozpisuje się wiele czasopism. Z własnego doświadczenia wiem jednak, że dostawcy bardzo dobrze informują Odbiorców o tym co ich czeka i jakie zaangażowanie po ich stronie jest konieczne. Jest to często wpisywane do umów – Dostawcy robią to we własnym interesie jako że zaangażowanie odpowiednio kompetentnych osób i to we właściwym wymiarze czasu jest kluczowe dla powodzenia. Zgódźmy się jednak, że po wdrożeniu trwającym rok każdy może powiedzieć, że tego co musiał robić się nie spodziewał zwłaszcza gdy wdrożenie ERP miało miejsce pierwszy raz. Może się też zdarzyć konieczność większego zaangażowania Odbiorcy jako pochodna innych omawianych tu przypadków. Natomiast zawężania zakresu funkcjonalnego przez Dostawców trudno mi sobie wyobrazić – niemal w 100% przypadków we wdrożeniach w dużych firmach Dostawca musi zagwarantować spełnienie funkcji opisanych w specyfikacji zatem jak miałby ten zakres funkcjonalnie celowo zawęzić? Można powiedzieć inaczej, że Dostawcy to co muszą dostarczyć uwzględniają w wycenie, natomiast ani funkcji więcej ponieważ… często kryterium wyboru jest cena wdrożenia!

Ad. 4. Zdarzył mi się przynajmniej jeden przypadek, że system został uruchomiony, funkcjonował całe miesiące, ale Odbiorca pod różnymi pretekstami unikał formalnego odbioru. W tym przypadku należy wskazać, że sytuacja taka jest bardzo niebezpieczna z punktu widzenia odpowiedzialności za ewidencję zdarzeń gospodarczych wyrażoną szczególnie w Ustawie o Rachunkowości, która spoczywa na tzw. „kierowniku jednostki gospodarczej”. No ale to już temat na zupełnie inny wpis.

Częściej zdarza się i to raczej w przypadku mniejszych Odbiorców, że nieco przewlekają formalny odbiór systemu do użytkowania chcąc coś od Dostawcy „wytargować” albo odwlec związaną z tym płatność. Innymi słowy przekładają sposób w jaki prowadzą swój codzienny biznes na wdrożenie. Cóż – w tej sprawie mogę jedynie stwierdzić, że tak bywa ale czy to może być przykład negatywnego przypadku przekroczenia terminu wdrożenia? Trudno z tym polemizować gdyż leży niejako w naturze biznesowej Odbiorcy jest to jednak sytuacja wysoce negatywna i ryzykowna gdyż za cenę stosunkowo niewielkich korzyści jakie chcą doraźnie osiągnąć podkopują i to kluczowym momencie moralnie i merytorycznie skalę powodzenia wielkiego projektu zmieniającego system nerwowy ich firmy.

Ad.5. Specyfikacja systemu przedstawiona przez Odbiorcę nie była wystarczająco dokładna (drugie dno jakiejś istotnej funkcji, rzadko wykonywany raport…) i generalnie rozwiązywane są „negocjacyjnie” bez wpływu na istotne parametry wdrożenia. Jednak często ten rzadko wykonywany raport gotowy jest dużo po starcie produktywnym (gdyż w 99% i tak potrzebny jest na koniec roku) i bywa że przez Odbiorcę gotowość takich raportów uznawana jest za zakończenie wdrożenia – co powoduje przekonanie, że trwało ono dużo dłużej aniżeli to przewidziano. Są to jednak rzeczy mające w skali wdrożenia znaczenie marginalne choć jak widać psujące obraz terminowości wdrożeń ERP.

Ad. 6. Dostawca przyjął nierealny dla określonego budżet i zakres wdrożenia. Takie sytuacje – przypominające znane teraz postępowanie wykonawców autostrad – miały i mają miejsce. Znane mi przykłady charakteryzowały też patologiczne wykorzystanie znanych metodyk np. Księcia Drugiego – Dostawca w pełni tego świadom powołując się nieustannie na metodykę hodował ryzyka i w ten sposób „przygotowywał” Odbiorcę na przekroczenie terminu i jednocześnie konieczne przekroczenie budżetu. No ale skoro jak to wcześniej napisałem z rozpoznania wynikło, że nikogo to nie interesuje to na tym ten wątek zakończę.

W następnym wpisie kontynuacja wątku przyczyn przekraczania budżetu i terminu wdrożeń ERP. Zapraszam do dyskusji!