Czego nie uwzględniamy we wdrożeniach ERP?

Posłuchaj odcinka:

Spotify: kliknij tutaj.
YouTube: kliknij tutaj.

Przeczytaj artykuł: kliknij tutaj.

Transkrypcja odcinka 9: „Czego zwykle nie uwzględniamy we wdrożeniach ERP?”.

To nie jest tak, że projekty tego typu, tej skali da się zrobić przy okazji, nie uwzględniając tego w obciążeniu naszego zespołu, który dzisiaj pracuje, realizuje swoje zadania. Sama budowa systemu jako taka to jest dwadzieścia, trzydzieści procent pracy wdrożeniowej. 

Dzień dobry. Dzisiaj ostatnia część podsumowania, czyli lista rzeczy, o których warto pamiętać, o których rzadko myślimy, ale branie ich pod uwagę bardzo pomoże nam przy zrealizowaniu projektu z sukcesem, na czas i przy może nie najmniejszym, ale najbardziej racjonalnym zaangażowaniu się w przedsięwzięcie.  

System ERP nie jest wdrażany „na dziś”

Pierwsza, najważniejsza rzecz jest to, żeby pamiętać cały czas, że system nie jest wdrażany na dziś, że to wdrożenie będzie pierwsze i ostatnie. System wdrażamy i będziemy go wykorzystywać przez dziesięć lat. On będzie rozwijany, utrzymywany, rozbudowywany. Część elementów możemy przesunąć w czasie i zrealizować je nieco później. Część funkcji może być realizowana w oparciu o standardowe funkcje systemu, a dopiero potem modyfikowana, dostrajana, doszczegółowiana, poprawiana. Pamiętajmy o tym, definiując zakres wdrożenia, że być może nie musi to być sto procent wszystkiego tego, co potrzebujemy. Nie musimy uruchamiać tego w pierwszym momencie. Natomiast z drugiej strony pamiętajmy o tym też, że jeżeli w trakcie budowy systemu rozwiniemy go, dostosujemy go do naszych potrzeb i będą one świetnie realizowane, świetnie wspierane, świetnie uzupełniane przez narzędzie informatyczne, to potem przez kolejne x lat – dziesięć, dwanaście, a czasami i więcej – będziemy ten system utrzymywać. Więc to nie jest tak, że koszty zbudowania systemu i posiadania go zanikną w momencie zakończenia wdrożenia. One będą kontynuowane i jeśli nasz system będzie skomplikowany, to koszty jego serwisowania, upgrade’owania, zmieniania wersji i rozwijania będą wyższe. Warto o tym pamiętać. Podkreślałem to już w poprzednich odcinkach, ale ponieważ jest to podsumowanie, to, to powtórzę.

Decyzje w kontekście celów projektu informatycznego

Wszystkie decyzje, które podejmujemy w trakcie realizacji, ewentualnie zagrożenia, które identyfikujemy, powinny się odnosić do celów, które sobie postawiliśmy rozpoczynając projekt, a wręcz nawet definiując jego cel, zakres i oczekiwania. Jeśli mamy do wyboru dużo bardziej dostosowane dla nas procesy w wybranym obszarze, których wdrożenie kosztuje nas dodatkowe trzy do sześciu miesięcy, a po drugiej stronie szalki kładziemy sobie korzyści, które wynikają z szybszego uruchomienia całego systemu, to warto się zastanowić, co jest dla nas ważniejsze, co jest dla nas efektywniejsze, co daje nam więcej korzyści. Nie zawsze odpowiedzi na te pytania są proste, ale zawsze warto chociaż spróbować je sobie zadać.  

Zaangażowanie zespołu w projekt wdrożeniowy

Kolejną rzeczą, o której warto pamiętać to to, że realizacja takiego przedsięwzięcia będzie angażowała nasze zespoły. To nie jest tak, że projekty tego typu, tej skali da się zrobić przy okazji, nie uwzględniając tego w obciążeniu naszego zespołu, który dzisiaj pracuje, realizuje swoje zadania, ma swoje terminy do dotrzymania, ma wymagania formalne, ma wymagania zewnętrzne. Także jeżeli dzisiaj mamy zespół, w którym jest x osób i one są obciążone na 85%, to założenie, że zrobią projekt informatyczny i to się nie odbije na ich funkcjonowaniu, jest nierozsądne.

Realistyczne planowanie dostępności zespołu

Także planując uruchomienie projektu warto jest popatrzeć na realną dostępność naszego zespołu. Uwzględnić to, że ta dostępność jest różna w różnych okresach roku. W intensywnym okresie w sezonie będzie inna, przy zamykaniu roku będzie inna, przy zamykaniu kwartału będzie inna. W różnych branżach jest to też różnie, więc to warto uwzględnić.

A jeszcze, żeby sobie uświadomić, o czym tu mówimy – jeśli mówimy o osobach, które są mocno zaangażowane w projekt, takie jak szef projektu, jakaś osoba wiodąca w obszarze, to może być między sześćdziesiąt a osiemdziesiąt procent nawet czasu w wybranych okresach, czy to analizy, czy testów, czy migracji danych, czy przygotowywaniu nowych koncepcji procesów, które będziemy wdrażali przy okazji  uruchomienia systemu informatycznego.

Typowi użytkownicy to będzie zaangażowanie między 20-60%. Różnie to bywa. Rozstrzał jest duży, ale to przede wszystkim wynika z tego, że w okresach, kiedy dostawca będzie pracował samemu, ten procent jest niższy. Ale, znowu – testy, uruchomienie, nie daj Boże jeszcze okres równoległego funkcjonowania w dwóch systemach, bo czasami takie podejście jest niezbędne. Ja go nie lubię, ale czasami, z racji decyzji podjętych przez klienta takie podejście stosujemy. 

To jest czasowo obciążenie w okolicach 40-60%. No i są osoby, które są bardzo punktowo angażowane. Wycinkowi specjaliści, specjaliści od danego modułu, od danego procesu czy od jakiejś specjalnej technologii, którą angażujemy w dany projekt. No to, to będzie obciążenie na poziomie 20%. Tym się przeważnie da zarządzić. Natomiast jeszcze raz podkreślam osoby kluczowe będą miały takie momenty we wdrożeniu, gdzie ich obciążenie będzie sięgało 60%, a czasami dla niektórych nawet 80. I tego się po prostu nie da powiązać z realizacją innych zadań w sposób racjonalny.

Automatyzacja procesów i testów

Trochę wiąże się z tym też kwestia automatyzacji, ponieważ dzisiejsze możliwości narzędziowe pozwalają automatyzować niektóre procesy. Czy to przy migracji danych nie zawsze trzeba budować skomplikowane interfejsy. Część danych można zmigrować przy pomocy narzędzi, które gdyby ich nie było, to trzeba byłoby tą pracę wykonać ręcznie.

Ale jesteśmy w stanie użyć takich automatów, które zastąpią ręczne wprowadzanie danych. A przy jednostkowych przypadkach, gdzie mamy na przykład danego typu danych dwieście czy pięćset do wprowadzenia, szkoda pisać do tego specyficzne narzędzie, specyficzny interfejs. Warto rozważyć, czy nie doprowadzić do automatyzacji procesu ręcznego wprowadzania. Nie zawsze się to sprawdza, nie zawsze jest to dobre rozwiązanie, ale warto przynajmniej wziąć to pod uwagę. To samo tyczy się automatyzacji testów, jest coraz więcej narzędzi do automatyzowania testów, a one są już coraz bardziej wyspecjalizowane w automatyzowaniu testów konkretnego typu narzędzia, konkretnego typu rozwiązania.

Jeśli planujemy na przykład fazowe rozwijanie systemu czy planujemy dużą ilość modyfikacji, to warto jest przygotować taki zestaw narzędzi, które po przygotowaniu pierwszej wersji systemu mogą zostać stworzone, przygotowane i potem w kolejnych turach iteracjach testów będą wykorzystywane po to, żeby odciążyć użytkownika w realizacji tych zadań, które polegają na tym, że mamy ileś ścieżek testowych sto czy sto pięćdziesiąt, czy dwieście i po prostu przy pomocy przygotowanego zestawu danych należy je przejść i zweryfikować, jak system reaguje na nowe komponenty, które zostały dodane w trakcie ostatniej iteracji budowy modyfikacji czy integracji, czy zasilania. Także warto rozważyć te narzędzia są dość sprawne, ich uruchomienie nie trwa długo, nie są drogie. Warto brać pod uwagę ich wykorzystanie.

Faza przygotowania do wdrożenia i zrozumienie logiki systemu

Kolejny punkt to jest sugestia dotycząca fazy przygotowania do wdrożenia. Jak już wiemy, które narzędzia będziemy wdrażali, jak już wiemy, z kim będziemy współpracowali, to jeszcze raz zachęcam do nawiązania bliższej współpracy i zbudowania wiedzy o naszym zespole wewnętrznym, o tym, jaka logika jest wbudowana w narzędzie, żeby nie próbować na siłę budować rozwiązań, które są sprzeczne z logiką wewnętrzną systemu.

Zrozummy tą logikę, zrozummy jak działają procesy standardowe. Zrozummy jakich narzędzi się używa w danym rozwiązaniu do obsługi takiego, czy innego procesu i próbujmy jak najbardziej nasze procesy dostosować czy budować w zgodzie z tą logiką. Jeśli już musimy koniecznie odejść od tej logiki, to ważne, żeby to była świadoma decyzja. Natomiast to zawsze wydłuża, zwiększa ryzyko. Każda duża przebudowa to jest większe ryzyko. Utrudnia potem utrzymanie, utrudnia rozwijanie, utrudnia wdrażanie nowych wersji. Więc trzymanie się tej logiki wewnętrznej jest bardzo cenne.

A im bardziej nasz zespół wewnętrzny będzie rozumiał, dlaczego tak robimy, dlaczego tak jest lepiej, tym prościej nam będzie wspólnie to rozwiązanie wypracować.  

Całkowity wysiłek w projekcie ERP

Kolejne dość prosta konstatacja, ale warto jest o tym pamiętać, to jest to, że sama budowa systemu jako taka to jest 20-30%  prac wdrożeniowych. Cała reszta to są analizy, przygotowanie testów, przygotowanie danych, przygotowanie integracji, przygotowanie samego uruchomienia, przygotowanie dokumentacji. Więc warto jest przy szacowaniu wysiłku, przy przygotowywaniu harmonogramu mieć świadomość tego, że jeśli dostaniemy informację o tym, że dane zadanie będzie konsumowało dwadzieścia dni albo pięć, albo pięćdziesiąt, to, to jest bardzo często informacja, szczególnie jeśli jest przekazana przez konsultanta albo programistę, że ta informacja dotyczy tylko i wyłącznie zakresu pracy, które jest niezbędne do zbudowania samego rozwiązania.

Natomiast cała reszta nie jest tutaj uwzględniona. Więc z punktu widzenia budżetowego tutaj to jest jeszcze prosta sprawa. Natomiast z punktu widzenia harmonogramowego, jeśli mamy do czynienia z niedoszacowaniem wpływu danej zmiany, danej modyfikacji danej czynności na harmonogram, to potem są z tego bardzo duże problemy. Ostatnio mieliśmy takie przedsięwzięcie, w którym do bazowego wdrożenia klient podjął decyzję, że dołoży trzy czy cztery nowe komponenty i one jednostkowo nie były duże. Natomiast po uwzględnieniu tego, że trzeba przebudować całą koncepcję, potwierdzić tą koncepcję, mimo tego, że tam zmian nie było wiele, ale duży zespół osób musiał się wypowiedzieć na ten temat. Musiał to potwierdzić, podpisać, musiała zostać zweryfikowane i zmodyfikowane podejście do migracji, do zasilenia danymi. Musiały zostać dobudowane nowe integracje z systemami zewnętrznymi. To stosunkowo nie, nieskomplikowane zadania, ale w dużej ilości, w znaczący sposób zwiększyły ilość pracy zarówno po stronie zespołu wdrożeniowego, jak i po stronie klienta. I po prostu okazało się, że dotrzymanie terminu harmonogramu jest nierealizowalne ze względu właśnie na dostępność, na możliwości zespołu wewnętrznego, który musiał tą zmianę zaaprobować, najpierw zrozumieć, potem zaaprobować, a potem jeszcze pomóc zespołowi wdrożeniowemu w uwzględnieniu tego w systemie.  

Koszty i odsunięcie korzyści w czasie

Kolejny dość prosty punkt, ale warto o tym pamiętać. Dłuższy projekt to większe koszty i odsunięcie korzyści w czasie. Także na każdym spotkaniu koordynacyjnym, na każdym komitecie sterującym przy aprobowaniu każdego dodatkowego zadania warto pamiętać o tym. Warto brać to pod uwagę, warto to uwzględniać, jeśli dokładamy zadania, jeśli przesuwamy spotkania, jeśli przesuwamy zadania w czasie, to każde takie przesunięcie zwiększa koszty realizacji zarówno po stronie firmy wdrożeniowej, jak i zespołu wewnętrznego, a przede wszystkim odsuwa w czasie korzyści, o których myśleliśmy rozpoczynając czy definiując sam proces wdrożeniowy.  

Zmiany zakresu i potrzeb to norma

Wiąże się z tym kolejny punkt, w którym warto jest nas od samego początku pamiętać o tym, że zmiana zakresu i potrzeb to jest sytuacja standardowa, a nie wyjątek. Więc od samego początku musimy być przygotowani, musimy mieć przemyślane procedury, musimy mieć przemyślany sposób funkcjonowania. W sytuacji, kiedy taka zmiana się pojawi i będziemy zmuszeni mimo wszystko ją zaimplementować. To nie jest wyjątek, to jest norma. Chcemy się bronić przed zmianami. Chcemy jak najbardziej trzymać się tego pierwotnego zakresu i harmonogramu, ale jeśli się zdarzy coś, co musi zostać zaimplementowane, musi zostać uwzględnione w projekcie, to musimy być do tego przygotowani i od strony proceduralnej, i od strony budżetowej, i od strony harmonogramowej. I mieć to przemyślane. Mieć na to jakiś pomysł.

Na przykład, jeśliby się okazało, że musimy zwiększyć o trzy procent czy piętnaście procent zakres wdrożenia, to w razie czego rezygnujemy z wdrożenia modułu X czy Y. Albo pojawiła się nowa potrzeba biznesowa albo prawna, albo jakakolwiek inna, o której nie myśleliśmy na początku. Jesteśmy do tego przygotowani z punktu widzenia budżetowego nie jest to dla nas problem, że mamy budżet na wdrożenie,  sto jednostek i te sto jednostek zostało zaalkowanych do pierwszego wdrożenia, do pierwotnego wdrożenia. Sam potem proces zwiększania budżetu, pozyskiwania tego budżetu, pozyskiwania zgód na rozszerzenie budżetu jest czasochłonny, pracochłonny, bo powoduje emocje. Nie służy to dobrze wdrożeniu. Czyli staramy się nie wprowadzać zmian. Staramy się trzymać standardu. Staramy się trzymać pierwotnego harmonogramu i zakresu. Ale mamy świadomość tego, że zmiana na projekcie to jest raczej norma niż wyjątek i jesteśmy do tego przygotowani. I w ten sposób damy sobie radę.

Co więcej, jest dość taka powszechna wiedza mówiąca o tym, że około osiemdziesiąt procent projektów informatycznych wykracza poza budżet i harmonogram, więc też to uwzględnijmy. Jeżeli chcemy mieć uruchomienie systemu na pierwszego stycznia i mamy szacunki, że projekt potrwa osiemnaście miesięcy, to już w pierwotnym harmonogramie załóżmy sobie trzy, cztery miesiące rezerwy. Skoro osiemdziesiąt procent projektów na świecie się opóźnia, no to weźmy pod uwagę, że może się tak wydarzyć też u nas. Więc jeżeli mamy uzgodniony harmonogram, to załóżmy od razu w nim rezerwę i czasową, i budżetową, żeby mieć pole manewru, mieć możliwości potem reagowania na nieprzewidziane wypadki, na nieprzewidziane zdarzenia.  

Doświadczenie szefa projektu

Ostatni punkt to taka prośba, sugestia. Pamiętajmy o tym, że, przedstawiciele zespołu wdrożeniowego, a w szczególności szef projektu, który prowadzi prace wdrożeniowe, nawet jeżeli jest słaby, nawet gdy byłby najsłabszym szefem projektu ze strony dostawcy, to on przeważnie ma wielokrotnie większe doświadczenie, jeśli chodzi o realizację tego typu zadań niż członkowie zespołu wewnątrz naszej organizacji. Nie mówię tu o wypadkach, kiedy mamy zatrudnionego z zewnątrz takiego szefa projektu, kiedy ktoś przeszedł z firmy wdrożeniowej i dzisiaj jest członkiem naszego zespołu wewnętrznego. Takie przypadki się zdarzają. Nie są częste. Także co najmniej warto posłuchać doświadczeń, sugestii i przemyśleń szefa projektu ze strony firmy wdrożeniowej. On będzie próbował upraszczać pewne zagadnienia. On będzie próbował dojść do postawionego celu jak najszybciej, jak najsprawniej, jak najprościej. Natomiast to nie jest tak, że on działa ze złej woli i ze względu na jego doświadczenie, wiedzę i praktyczne też przypadki, które przeszedł osobiście w swoim życiu zawodowym warto go posłuchać i warto brać pod uwagę to, co on mówi.  

Podsumowanie

No i to chyba wszystko. Dziękuję za ten odcinek. Gdyby były jakiekolwiek pytania, wątpliwości lub potrzeba rozszerzenia, to z przyjemnością się do tego odniosę. Wszelkie namiary kontaktowe są w opisie odcinka. Dziękuję bardzo i do usłyszenia. 

W następnym sezonie… 

I to już wszystko w dzisiejszym odcinku, a jednocześnie finał naszej pierwszej serii poświęconej wdrożeniom systemów ERP. 

Mamy nadzieję, że wszystkie informacje, które przekazaliśmy w ciągu ostatnich dziewięciu odcinków, pomogą Wam osiągnąć główny cel – sukces we wdrożeniu ERP. Pamiętajcie, że każdy z omawianych przez nas elementów – od wyboru systemu i partnera wdrożeniowego, przez przygotowania, współpracę z doradcą, negocjacje, aż po start projektu – to nie tylko teoria, ale sprawdzone w praktyce rozwiązania. 

Wdrożenie systemu ERP to maraton, nie sprint. To przedsięwzięcie, które będzie służyć Waszej organizacji przez kolejne 10-12 lat. Dlatego każda decyzja podjęta dziś ma znaczenie nie tylko na starcie, ale przez całą drogę, którą przejdziecie wraz z nowym systemem. 

Już dziś możemy Wam zdradzić, że pracujemy nad drugą serią naszego podcastu. Szczegóły ogłosimy wkrótce. Dlatego jeśli jeszcze nas nie obserwujesz na LinkedIn, pora to nadrobić! 

Jak zawsze, tydzień po publikacji ostatniego odcinka tej serii na naszym blogu pojawi się artykuł z podsumowaniem najważniejszych punktów – link znajdziecie w opisie odcinka. Jeśli macie pytania, sugestie, a może chcecie podzielić się swoimi doświadczeniami z wdrożeń, piszcie do nas na podcast@dahliamatic.pl.Dajcie nam też znać, o czym chcielibyście usłyszeć w kolejnej serii – Wasze sugestie są dla nas bardzo cenne! 

Dziękujemy Wam za towarzyszenie nam w tej pierwszej serii. Do usłyszenia wkrótce w nowych odcinkach! 

________________________________________________________________________________________________

Nie zapomnij też odsłuchać poprzedniego odcinka, jeśli jeszcze tego nie zrobiłeś.

Odcinek 8, „Błędne oczekiwania, które psują projekty ERP”:

Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Artykuł: kliknij tutaj.
Transkrypt: kliknij tutaj.