Realizacja wdrożenia ERP to etap, w którym wszystkie wcześniejsze przygotowania przechodzą test w praktyce. W tym odcinku pokazujemy, jak prowadzić projekt krok po kroku, jakie pułapki najczęściej się pojawiają i dlaczego czasem lepiej rozłożyć wdrożenie na etapy niż ryzykować „big bang”.
Posłuchaj odcinka:
Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Przeczytaj artykuł: „Czas start! Realizacja wdrożenia systemu ERP„
Transkrypcja odcinka 6: „Od planu do działania, czyli co naprawdę liczy się w realizacji wdrożenia ERP”.
Istotną rzeczą jest, że plan prac wdrożeniowych powinien zostać skorelowany i skoordynowany z pracami bieżącymi działów zaangażowanych we wdrożenie systemu ERP. Nawet szef projektu po stronie firmy wdrożeniowej ma przeważnie dwu-, trzykrotnie większe doświadczenie w realizacji tego typu przedsięwzięć.
Witam. Dzisiejszy odcinek podcastu dotyczyć będzie części, która wydaje się być najbardziej intrygująca, czyli samej realizacji wdrożenia systemu ERP. Jest to część najważniejsza, bo od niej zależy sukces całego przedsięwzięcia – czy nasze przygotowania, wybór partnera oraz uzgodnienie zasad współpracy zostaną zwieńczone udanym wdrożeniem ERP.
Prawda jest taka, że trudno jest w tym obszarze wymyśleć coś bardzo nowatorskiego i niesamowitego, odbiegającego od praktyki stosowanej na rynku, dlatego myślę, że nie będzie to długi odcinek.
Kolejnym etapem w sposób naturalny jest sama realizacja wdrożenia ERP, czyli:
- jesteśmy już przygotowani,
- wiemy, po co realizujemy dane przedsięwzięcie,
- wybraliśmy dostawcę,
- wybraliśmy technologię,
- uzgodniliśmy z dostawcą lub dostawcami zasady współpracy.
Uruchamiamy więc samo przedsięwzięcie. Ten etap, ta część jest co prawda najdłuższa, natomiast jest dość jednorodna – mechanizmy się powtarzają.
Co więcej, akurat w realizacji wdrożenia systemu ERP doświadczenie na rynku jest dość powszechne. Po jednej i po drugiej stronie będziemy mieli członków zespołu, którzy mają doświadczenie w tego typu przedsięwzięciach, brali udział w projektach mniejszej lub większej skali. Prawdopodobnie po stronie wykonawcy będą bardziej doświadczone osoby, po stronie firmy wdrażającej trochę mniej, ale jednak ta wiedza jest dość powszechna. Często można pozyskać osoby z takim doświadczeniem i zaprosić je do uczestnictwa w projekcie, nawet w formule czysto projektowej.
Istotna różnica polega na tym, że nacisk, który proponuję, powinien być położony na fazę przygotowawczą, a już w samym wdrożeniu systemu ERP nie będę miał zbyt wielu sugestii. Kilka się znajdzie, ale są to raczej drobne uzupełnienia.
Wybór modelu wdrożeniowego systemu ERP
Dlaczego agile nie zawsze się sprawdza w ERP?
Jednym istotnym punktem jest to, że osobiście nie jestem szczególnym fanem podejścia typu agile do prowadzenia projektów wdrożenia systemu ERP. Nie są to projekty, w których od zera budujemy coś, testujemy, próbujemy, weryfikujemy, przemyśliwujemy i dochodzimy do wniosku, że trzeba przebudować wszystko, co zostało stworzone.
Mówię tu raczej o projektach bazujących na wdrożeniach systemów standardowych, gdzie między 60 a 80% systemu jest już gotowe, my go tylko dostosowujemy do potrzeb firmy. Mamy tutaj elementy modyfikacji czegoś, co już istnieje, a nie budowanie od zera. Powiedzenie, że agile jest szkodliwy byłoby przesadą, natomiast nie rekomenduję go w procesie wdrożenia systemu ERP. Jeśli miałbym opierać się na własnym doświadczeniu, jest ono raczej złe niż dobre.
Jeśli mamy po obu stronach osoby, które rozumieją tę metodykę, i jesteśmy gotowi funkcjonować w środowisku, w którym nie do końca wiemy, jaki budżet będziemy konsumować na wdrożenie i jak długo to wdrożenie ma trwać, to można próbować tego podejścia. Prawdopodobnie większość przedsięwzięć zakończy się sukcesem rozumianym jako dojście do końca procesu wdrożenia systemu ERP. Czy uda się utrzymać i zrealizować założone parametry finansowo-czasowe? Tu przeważnie jest już trochę gorzej.
Koordynacja wdrożenia ERP z bieżącą pracą działów
Znaczenie zaangażowania biznesu, nie tylko IT
Pierwszym istotnym punktem podczas realizacji wdrożenia ERP jest fakt banalny, ale często o nim zapominamy. Plan prac wdrożeniowych powinien zostać skorelowany i skoordynowany z pracami bieżącymi działów zaangażowanych we wdrożenie. Prace codzienne bardzo rzadko, albo wręcz nigdy, nie mogą być przesuwane, więc przygotowując plan projektu wdrożeniowego należy te fakty uwzględnić.
Stąd między innymi sugestia, żeby bardzo mocno w prace koordynacyjne i zarządzanie projektem byli zaangażowani przedstawiciele biznesu, a nie tylko działu IT. Osoby z działów IT czy realizacji projektów nie mają aż tak głębokiej świadomości:
- tego, jakie zadania codzienne i na kiedy muszą być zrealizowane,
- jaki wysiłek jest niezbędny, żeby te zadania były zrealizowane w sposób poprawny,
- co jesteśmy w stanie przesunąć, skrócić, zrobić w wersji uproszczonej, a co musi być zrealizowane w pełnym wymiarze.
W rezultacie na dany okres musimy zaplanować przerwę w pracach projektowych, przynajmniej w zadaniach wymagających aktywnej współpracy ze strony klienta.
Komunikacja fundamentem sukcesu wdrożenia ERP
Drugim istotnym postulatem, również banalnym, ale kluczowym, jest kwestia uczciwego komunikowania przez obie strony statusu prac projektowych. W typowym przedsięwzięciu wdrożenia systemu ERP mamy do czynienia ze 150-200 zadaniami realizowanymi równolegle. To dość krótkie zadania, ale nakładające się na siebie, a kontrola statusów tych prac, podzadań i czynności jest podstawą do tego, aby mieć świadomość, gdzie jesteśmy z projektem.
Jeżeli dostajemy niewłaściwe, nieprawdziwe czy wręcz zakłamane dane w tym zakresie, to monitorowanie statusu i przygotowanie planów awaryjnych, które pozwolą wrócić na ścieżkę krytyczną i dotrzeć do celu w uzgodnionym terminie, jest wręcz niemożliwe.
Jak oceniać postęp realizacji wdrożenia ERP
Drugim zjawiskiem, które pojawia się dość często, jest szukanie wytłumaczeń, dlaczego opóźnienie nie jest „moją winą”. Z punktu widzenia oceniania ma to może jakąś wartość, natomiast z perspektywy projektowej mamy stan taki, że zadanie jest zrealizowane lub nie. Zadanie zostało wykonane w pełni lub częściowo.
Zadanie zostało zrealizowane dobrze i już nie musimy do niego wracać, albo zostało zrealizowane, kolokwialnie mówiąc, „po łebkach” i niestety musimy do niego wrócić. To jest informacja, która nas interesuje z punktu widzenia projektowego.
Jeśli w jakimś obszarze czy zespole powtarza się problem z opóźnieniem, jest to informacja dla struktur zarządczych, że w tym obszarze należy zapewnić wsparcie, zmniejszyć zaangażowanie tego zespołu lub zdjąć z niego zadania związane z projektem wdrożenia ERP. Być może trzeba przełożyć wdrożenie w tym obszarze na późniejszy etap – podjąć decyzję, która pozwoli sprawnie funkcjonować, uwzględniając realne możliwości realizacyjne danego obszaru, zamiast oszukiwać się, że poprzez namowy czy środki dyscyplinujące nagle zwiększymy wydajność.
To się raczej nie wydarzy. Warto zdać sobie sprawę, jakie są realia, i uwzględniając je, planować dalsze działania. Być może uruchomienie systemu ERP, które zakładaliśmy za półtora roku, odbędzie się jednak za dwa lata, ale będziemy mieli możliwość monitorowania tego w sposób zrozumiały i świadomy.
Zacznij od standardu – rozbuduj później
Dlaczego unikać podejścia „big bang”?
Kolejny punkt to jest coś, o czym już mówiłem w tej części, w której opisywałem prace przygotowawcze i kwestie definiowania celu. To jest sprawa próby podejścia wymagającego jak najmniejszej modyfikacji systemu, przynajmniej na pierwsze uruchomienie. To duże zagadnienie, nad którym warto się pochylić – skoro budujemy system na 10 lat i zaplanujemy jego uruchomienie w sposób racjonalny, nie musimy wszystkiego uruchamiać w pierwszej fazie.
Nie musi to być podejście typu „big bang”, gdzie wszystko rusza w jednym momencie – wszystkie modyfikacje, integracje i moduły uruchamiamy przysłowiowego 1 stycznia. Większość funkcji dzisiaj w ogóle nie istnieje w naszym starym systemie. A nawet jeżeli istnieją, mogą funkcjonować w formie uproszczonej, więc wybieramy procesy, które da się obsłużyć. Być może obsługa nie jest bardzo ergonomiczna i da się ją usprawnić, ale to może być zadanie na czas po stabilizacji systemu.
Być może mamy wysepkowe rozwiązania informatyczne, które poprawnie wspierają realizowanie procesów – czy to magazyn wysokiego składowania, budżetowanie czy skonsolidowane raportowanie. Jeśli można cokolwiek wyjąć z podstawowego wdrożenia i uruchomić z pewnym opóźnieniem, to jest to zmniejszanie zakresu prac na pierwszy start, co zawsze zwiększa bezpieczeństwo i zmniejsza ryzyko komplikacji systemu.
Etapowe uruchomienia i stabilizacja systemu
Oczywiście analiza powinna objąć całość, a model docelowy powinien zostać zdefiniowany. Natomiast jestem zwolennikiem etapowego wdrożenia systemu ERP z uzgodnionym okresem stabilizacji. Uruchamiamy system w 66%, dajemy sobie 3 miesiące na stabilizację, usuwamy błędy, uczymy użytkowników jak sprawnie i wydajnie korzystać z systemu o przekazanej parametryzacji.
Użytkownicy uczą się systemu, nabierają doświadczeń, formułują opinie i wyciągają wnioski. Coś, co wydawało im się niezbędne, może okazać się zbędne. To, co wydawało się „nice to have”, okazuje się, że bez tego się żyć nie da. Kolejne trzeba przebudować. Zbieramy te wnioski i w podejściach półrocznych, do-wdrażamy uzgodnione elementy.
Unikamy sytuacji, gdzie mamy bardzo dużo modyfikacji systemu przygotowanych na uruchomienie. Poza wyzwaniami związanymi z:
- migracją danych,
- poprawnością danych,
- tym, że użytkownicy jeszcze nie czują się pewnie w nowym narzędziu,
- tym, że będą trochę zmienione procesy,
- tym, że będą nowe dokumenty,
a my dorzucamy im jeszcze modyfikacje we wszystkich możliwych obszarach. Jeśli da się da tego nie robić, to fajnie jest tego nie robić.
Warto rozłożyć uruchomienie systemu ERP np. na rok czy nawet na półtora roku, gdzie start. Start będzie przysłowiowego 1 stycznia, czyli powiedzmy w połowie lutego. Kolejna paczka funkcjonalności po stabilizacji – gdzieś w marcu/kwietniu, może w maju. Następna paczka funkcjonalności i integracji we wrześniu/październiku, a kolejna w lutym następnego roku.
Rozkładamy realizację wdrożenia ERP w czasie, nie wywieramy dużej presji na użytkowników. Dajemy sobie czas na:
- obserwacje,
- wyciąganie wniosków,
- uspokojenie,
- stabilizację systemu,
- usunięcie błędów.
Zawsze sprzyja to bezpieczeństwu. Nie sprzyja to szybkości działania, natomiast sprzyja to bezpieczeństwu. A ta szybkość też może być uzyskana dzięki temu, że mniejszy fragment systemu uruchamiamy, ale za to szybciej.
To wszystko należy rozważyć na chłodno i podjąć decyzję. Gdybym miał jednym zdaniem coś zasugerować: nie uruchamiajmy pełnego systemu ERP w pełnej komplikacji od pierwszego dnia. Rozłóżmy to w czasie, jeśli to możliwe.
Zaufaj partnerowi wdrożeniowemu systemu ERP
Rola doświadczenia partnera wdrożeniowego
Ostatni punkt dotyczy zagrożenia, które czasami się pojawia – po stronie klienta czasami pojawia się skłonność do podważania metod proponowanych przez firmę wdrażającą. Klienci mają swoje pomysły na podejście do migracji, mają swoje koncepcje budowania ścieżek testowych, swoje wizje dotyczące przygotowania dokumentacji i dlaczego jest ona zbyt skomplikowana albo zbyt ogólna, lub dlaczego dana grupa użytkowników nie powinna być angażowana do definiowania takiego czy innego dokumentu.
Każdy ma prawo do własnej opinii. Natomiast często te pomysły nie są poparte wieloletnim doświadczeniem, tylko intuicją albo chwilową potrzebą zmiany podejścia ze względu na jakieś uwarunkowania wewnętrzne. Nawet mniej doświadczony szef projektu po stronie firmy wdrożeniowej ma przeważnie dwu-, trzykrotnie większe doświadczenie w realizacji tego typu przedsięwzięć.
Dlaczego intuicja klienta nie zawsze wystarcza?
Jeżeli firma zajmuje się wdrożeniami systemów ERP 5, 10, 15 czy 20 lat, można przyjąć założenie, że jeśli chodzi o wypracowaną metodę wdrożenia, która się sprawdza, to raczej te firmy mają to lepiej przemyślane, przygotowane, udokumentowane i zweryfikowane. Byłoby czymś dziwnym, gdyby firma proponowała metodykę wdrożeniową, która za każdym razem kończy się niepowodzeniem. To byłoby podcinanie gałęzi, na której się siedzi.
Te firmy żyją z wdrożeń, zajmują się tylko wdrożeniami, świadczą usługi wdrożeniowe, więc można przyjąć, że mają o tym pojęcie – nawet jeżeli poszczególne osoby w zespole nie są idealne lub część z nich jest młoda i nie ma doświadczenia. Wiedza zgromadzona w firmie powinna dawać nam gwarancję lub przynajmniej skłaniać do zadania pytania: dlaczego oni to tak robią, a nam się wydaje, że to jest nierozsądne?
Wolę czasami dwa dni dyskutować o tym, dlaczego takie, a nie inne podejście do migracji jest zasadne, niż zgodzić się na coś niezbyt rozsądnego i potem cierpieć miesiącami przy pracach w obszarze związanym z decyzją, że „robimy to trochę inaczej niż początkowo proponowaliśmy”. Oczywiście są przypadki, gdy jesteśmy zmuszeni dostosować się do podejścia narzuconego przez klienta. Często jest to dużo bardziej pracochłonne i kosztogenne, ale jakoś dajemy radę.
Jeśli to możliwe, warto zastanowić się, czy zaproponowana metoda pracy przez firmę wdrożeniową lub szefa projektu delegowanego przez tę firmę nie zawiera głębszej mądrości, doświadczenia i wiedzy o tym, co się sprawdza, a co nie w realizacji wdrożenia systemu ERP.
Daje się to modyfikować, natomiast róbmy to świadomie. Jako punkt wyjścia przyjmijmy metodykę, standardy i sposoby pracy, które proponuje firma wdrożeniowa, ponieważ traktujemy ją jako firmę, która się na tym zna. Sami ich wybieraliśmy, weryfikowaliśmy ich doświadczenia i możliwości sukcesu, więc skoro im zaufaliśmy, to zaufajmy im również teraz i ich pomysłu na realizację prac związanych z wdrożeniem systemu ERP.
Podsumowanie i co dalej?
W kwestii realizacji wdrożenia ERP to już chyba wszystko. Jeśli mielibyście jakiekolwiek wątpliwości, pytania czy prośby o poszerzenie przedstawionych tutaj tez, to adres do kontaktu jest w opisie odcinka i zapraszam do kontaktowania się i do komunikacji.
W następnym odcinku porozmawiamy o mitach dotyczących wdrożeń systemów ERP. Opowiemy m.in. o tym, czy samodzielne przeprowadzenie projektu oznacza poniesienie mniejszych kosztów, czy odpowiedzialność za wdrożenie ponosi wyłącznie dostawca oraz czy wybranie najnowszej wersji systemu to zawsze najlepsze rozwiązanie.
Nowe odcinki publikujemy w pierwszy wtorek miesiąca. Tydzień później na naszej stronie pojawia się artykuł z podsumowaniem treści oraz kluczowymi punktami poruszonymi w podcaście. Link do naszego bloga znajdziecie w opisie tego odcinka. Znajdziecie tam także adres e-mail, pod którym możecie się z nami skontaktować.
Jeśli macie jakieś pytania lub sugestie, dajcie nam znać. Do usłyszenia w kolejnym odcinku.
________________________________________________________________________________________________
Nie zapomnij też odsłuchać poprzedniego odcinka, jeśli jeszcze tego nie zrobiłeś.
Odcinek 5, „Sztuka porozumienia czy pole bitwy?”:
Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Artykuł: kliknij tutaj.
Transkrypt: kliknij tutaj.
>