Czy ERP (Enterprise Resource Planning) to projekt IT, czy projekt ludzki z komponentem technologicznym? Wiele organizacji zadaje sobie to pytanie. Już sam fakt jego pojawienia, może być zwiastunem problemów. A to dlatego, że coraz więcej przykładów jednoznacznie wskazuje, że to nie powinien w ogóle być dylemat. Praktyka pokazuje bowiem, że sukces projektu ERP to nie tylko działający system, ale przede wszystkim osiągnięcie celów biznesowych.
Dzieje się to poprzez przyswojenie i stosowanie nowych rozwiązań przez ich użytkowników w obszarach objętych wdrożeniem. Niezbyt zręcznie, ale powszechnie nazywane jest ono adopcją (kalka z języka angielskiego), dlatego będę się tym pojęciem posługiwał w dalszej części artykułu.
Czy ERP to zazwyczaj sukces, czy porażka?
Wdrożenia systemów ERP są obecnie realizowane w wielu organizacjach. Według różnych badań (np. Standish Group – Chaos Report, Panorama Consulting – Annual ERP Report, Deloitte – ERP Trends, McKinsey) około 30% wdrożeń ERP można uznać za pełny sukces, kolejne 40–50% to częściowy sukces z poważnymi trudnościami, a reszta to porażki. To pokazuje, że wdrożenie ERP to projekt wysokiego ryzyka – i ogromnego znaczenia dla firm.
Wiele projektów ERP formalnie się kończy, ale nie przynosi realnej wartości, co dla biznesu oznacza porażkę mimo technicznego wdrożenia. Dotknęło to tak znanych organizacji, jak Hersheys, czy Nike (na przełomie XX i XXI wieku). W czasach nam bliższych na skutek porażek wdrożenia ERP ucierpiały takie organizacje, jak Lidl (0,5 miliarda euro straty i powrót do poprzedniego rozwiązania), miasto Birmingham w Anglii (ogłoszenie bankructwa), SPAR Group (zakłócenia w łańcuchu dostaw, skutkujące utratą sprzedaży o wartości ponad 100 milionów USD) czy Zimmer Biomet, producent implantów ortopedycznych, który na skutek nieudanego projektu ERP doświadczył problemów produkcyjnych i opóźnień w dostawach dla klientów, co przełożyło się na spadek przychodów.
Znane mi organizacje, działające w regionie CEE (Europy Środkowo-Wschodniej) również mierzą się z podobnymi trudnościami. Widziałem kilka przykładów projektów ERP, które napotkały znaczące problemy, możliwe do uniknięcia. Były one rzeczywiście nie tylko związane z częścią techniczną wdrożenia (system, dane, przebieg procesów i podział odpowiedzialności), ale także z częścią ludzką (przyswojenie i stosowanie ERP przez użytkowników). I właśnie tym obszarem zajmę się bliżej w niniejszym artykule.
Gdzie jest „pies pogrzebany”?
Warto zacząć od tego, że projekty ERP charakteryzują się pewnymi wspólnymi elementami kontekstu, który towarzyszy większości z nich. Definiują one naturalną skalę wyzwań w tego typu projektach.
- Złożoność organizacyjna i procesowa.
Dlaczego? System ERP ma zintegrować różne obszary działalności (np. finanse, produkcja, logistyka, czy HR), które wcześniej działały w odrębnych systemach lub silosach organizacyjnych. Każdy z tych obszarów ma własne reguły, potrzeby i kulturę pracy. Próba ujednolicenia tych procesów w jednej strukturze ERP wymaga kompromisów, które często są sprzeczne z dotychczasowymi praktykami lub interesami różnych działów i zespołów. - Ścieranie się potrzeby standaryzacji i zachowania lokalnej specyfiki.
Dlaczego? ERP zakłada wprowadzenie standardowych procesów, często zgodnych z dobrymi praktykami producenta systemu (np. SAP Best Practices). Firmy mają często swoje unikalne praktyki, wypracowane lokalnie przez lata. Stanowią one ich przewagę konkurencyjną – lub tak przynajmniej myślą menedżerowie i pracownicy. Próba ich ustandaryzowania w ramach większej organizacji wywołuje opór i może budzić obawy o utratę elastyczności. Konflikt między „dostosuj procesy firmy do systemu” a „dostosuj system do procesów firmy” jest nieunikniony. Zazwyczaj ze wskazaniem na konieczność tego pierwszego, co pociąga za sobą duże zmiany i opór. - Wysoka zależność od użytkowników i potrzeba zmian kulturowych.
Dlaczego? System ERP nie działa automatycznie. Jego skuteczność zależy od przyjęcia przez użytkowników nowych sposobów pracy, nowych procesów – a to wiąże się nie tylko z nową wiedzą i umiejętnościami, ale czasem wręcz z potrzebą wypracowania nowych nawyków i zmiany wieloletnich przyzwyczajeń. Pracownicy są przywiązani do znanych rozwiązań (np. Excela, dotychczasowego systemu), a ERP często narzuca większą dyscyplinę, transparentność i odpowiedzialność. To rodzi opór, powoduje stres i może prowadzić do pasywnego lub aktywnego sabotowania wdrożenia.
Poza tym w takich projektach występuje wiele innych wyzwań. Na przykład trudność w zdefiniowaniu rzeczywistych potrzeb i celów. Oczekiwania wobec ERP są często niedookreślone lub zbyt ogólne („poprawa efektywności”, „lepsze raportowanie”), co utrudnia jasne określenie wymagań, a potem ocenę sukcesu. Dodatkowo wymagania zmieniają się w trakcie projektu wraz z lepszym poznaniem systemu. Utrudnieniem może być także skala i długotrwałość inwestycji. Projekty ERP są kosztowne, wieloetapowe, często trwają wiele miesięcy lub lat i angażują znaczną część organizacji. Długi horyzont czasowy zwiększa ryzyko zmiany warunków zewnętrznych i wewnętrznych, a równoległe prowadzenie działalności operacyjnej (Business As Usuall – BAU) i wdrażanie ERP mocno obciąża ograniczone zasoby.
Dao – stock.adobe.comCo to znaczy dla Project Managera? – Zarządzanie projektami w ERP, to także Zarządzanie Zmianą
Realizacja projektu ERP stawia przed Project Managerami wyjątkowo wysokie wymagania, wykraczające poza standardowe kompetencje zarządzania projektami. W niniejszym artykule skupię się na tych, które dotyczą umiejętności zarządzania zmianą (Change Management). Rozumiemy przez to zarządzanie ludzkimi aspektami ERP, związanymi z przyswojeniem i stosowaniem (adopcją) rozwiązań przez użytkowników, dzięki czemu osiągamy cele biznesowe projektu. PM nie tylko musi rozumieć mechanizmy prowadzenia zmiany w organizacji, ale przede wszystkim potrzebuje wkomponować ustrukturyzowany proces Zarządzania Zmianą w podejście do realizacji projektu (metoda realizacji projektu, governance, plan, RACI, działanie operacyjne w projekcie). Dla wielu PMów oznacza to konieczność pozyskania wiedzy i umiejętności wykraczających poza ich dotychczasowe silne strony.
Co to znaczy „wystarczająco dobry Change Management”? – recepta na sukces dla PM-a
Przyjrzyjmy się konkretnym obszarom Zarzadzania Zmianą, które PM powinien uwzględnić. To one w największym stopniu decydują o sukcesie wdrożenia ERP z punktu widzenia skutecznego przyswojenia zmiany przez użytkowników.
- Jasna wizja wdrożenia ERP i jego celów, podzielana przez całą organizację
Coś, co dla zarządzających jest oczywiste („wiemy, po co wdrażamy ERP”) okazuje się wcale nieoczywiste w większości wdrożeń. Cele biznesowe dla ERP muszą być jasno wyrażone od początku projektu, określone konkretnymi KPI i ich wartościami. Potrzebują być uspójnione między kluczowymi liderami w organizacji, aby odzwierciedlały interes całej firmy, a nie poszczególnych silosów. Osiągnięcie tych celów zazwyczaj wymaga wprowadzenia znaczących zmian w procesach, a czasem także w organizacji. Wiele wdrożeń boryka się z celami, które są wyrażone zbyt ogólnie („poprawa efektywności”, „unifikacja”, „standaryzacja”, „przyspieszenie raportowania”), nie są mierzalne, nie mają określonych wartości docelowych (i bazowych). Albo nie są podzielne przez kluczowych menedżerów – a rozbieżności ujawniają się dopiero podczas wdrożenia. PM powinien zadbać, aby te wszystkie kwestie zostały wyjaśnione, uzgodnione i zatwierdzone na wczesnych etapach projektu. - Silne przywództwo od najwyższego szczebla w organizacji – koalicja Sponsorów
Każdy projekt ERP ma oczywiście Komitet Sterujący lub jego odpowiednik. Są w nim Sponsorzy. Co wcale nie znaczy, że jest to wystarczające z punktu widzenia wdrożenia zmiany. Do osiągnięcia pełnej adopcji ERP potrzeba wsparcia koalicji Sponsorów, czyli WSZYSTKICH kluczowych liderów w organizacji, której zmiana dotyczy. Z reguły jest to grupa dość duża, licząca kilkanaście-kilkadziesiąt osób z grona najwyższej i wyższej kadry zarządzającej obszarami, których dotyczy wdrożenie ERP, od Zarządu do kluczowych Dyrektorów. To ci liderzy powinni być twarzą ERP dla swoich pracowników, to oni powinni zdefiniować i kaskadować cele ERP dla swoich obszarów. Nadawać priorytet. Komunikować potrzebę zmiany i jej wpływ na pracowników. Wspierać w przypadkach oporu i budować zaangażowanie. Choćby w tak punktowy sposób, jak poprzez otwieranie sesji szkoleniowych dla użytkowników. Prezes jest za wysoko w strukturze i za daleko od pracowników, Dyrektor z danego obszaru nie jest autorytetem dla pracowników z innego obszaru, a Dyrektor IT, który czasami bywa Sponsorem projektu, nie ma władzy i realnego przełożenia na inne obszary, poza swoim. To zadanie dla PMa, aby z głównym Sponsorem projektu ERP zdefiniować zakres koalicji Sponsorów, opracować plan jej zbudowania i wspierać jego realizację. - Mierzalność rezultatów na poziomie firmy i na poziomie użytkowników
Z perspektywy Sponsora, czy PMa projektu ERP cele biznesowe na poziomie firmy są wystarczające. Ale z perspektywy użytkowników – już zupełnie nie. Skrócenie jakiegoś cyklu, podniesienie efektywności, minimalizacja strat, zwiększenie parametrów jakościowych w obsłudze klienta, etc. – każdy z tych celów będzie miał inny „odcień” dla różnych Departamentów i zespołów w organizacji. Te cele można mierzyć poprzez wskaźniki adopcji, czyli KPI konkretne, zdefiniowane specyficznie dla każdego obszaru objętego wdrożeniem ERP. Dopiero wówczas użytkownicy z poszczególnych działów będą wiedzieć, czego właściwie się od nich oczekuje, jaki wkład w sukces ERP potrzebny jest z ich strony. W proces definiowania i kaskadowania tych celów i wskaźników potrzebują być zaangażowani odpowiedni członkowie Koalicji Sponsorów, a PM powinien ten proces zaprojektować, moderować i prowadzić do skutecznego końca. - Pozyskanie wsparcia menedżerów liniowych z obszarów wdrożenia ERP
Zmiana dzieje się na poziomie stanowisk pracy, użytkowników – a na poziomie organizacji jest jedynie sumą zmian indywidualnych. Dlatego bez zaangażowania tych, którzy są najbliżej pracowników efektywne wdrożenie ERP nie jest możliwe. Badani pokazują, że jedynie nieco ponad 35% kierowników jest do tej roli odpowiednio przygotowana. A warto sobie uświadomić, że jest to ok. 10% całej populacji użytkowników (z reguły średnio 1 kierownik przypada na 10-12-15 pracowników). Nie da się zastąpić aktywności tej grupy zaangażowaniem ambasadorów czy Key Userów (jeden z podstawowych błędów!). Trzeba ich aktywnie włączyć we wsparcie wdrożenia. Poza tym ERP to „ich temat” z definicji – to kierownicy zespołów dostają do ręki gotowe narzędzia do osiągania operacyjnych KPI. W naturalny sposób powinni więc być zaangażowani i włączeni w cały proces. Wcześnie! – nie tuż przed Go-Live. To w ich interesie jest, żeby pracownicy zdobyli odpowiednio wcześnie praktyczną wiedzę na temat użytkowania nowych narzędzi. Żeby byli odpowiednio wcześnie i dobrze przygotowani do pracy w nowy sposób. I właśnie rolą PMa jest, aby przy pomocy koalicji Sponsorów zaangażować menedżerów na odpowiednim etapie w cyklu życia projektu ERP. Tak, aby kierownicy mieli szansę „kupić” wdrożenie, zanim będą je „sprzedawać” swoim pracownikom. - Edukacja a nie tylko szkolenia
Temat prosty – a jednocześnie temat-rzeka. Niby szkolenia to coś oczywistego, ale pamiętajmy, że uczymy osoby dorosłe w ich środowisku pracy. W czasie pracy, gdy użytkownicy są odrywani od codziennych zadań. Często nie na systemie, tylko na slajdach. W sposób mocno techniczny, czyli „jak wyklikać transakcję” – ale bez pokazania szerszej perspektywy całego procesu, w którym dany użytkownik działa. Bez uświadomienia wpływu ewentualnych błędów i niedociągnięć na cały proces i na końcowy efekt biznesowy. Szkolenia prowadzą czasem eksperci dziedzinowi, którzy nie mają naturalnych umiejętności przekazywania wiedzy. A poza tym wiedza teoretyczna to jedno, a praktyczna umiejętność obsługi nowych narzędzi i procesów, to drugie. Dlatego w ERP konieczne jest zaprojektowanie procesu edukacji (oba słowa są tu ważne), a nie tylko szkoleń. Co na przykład oznacza, że użytkownicy przed szkoleniami potrzebują mieć chęć do samej zmiany, aby w tych szkoleniach aktywnie uczestniczyć. A do tego potrzebne jest zaangażowanie Sponsorów i ich kierowników (patrz p. 2 i 4 powyżej). A po szkoleniach powinno być jasne, czego się w praktyce nauczyli, aby przed Go-Live byli gotowi do pracy w środowisku produkcyjnym. Bo uczestnictwo w szkoleniach potwierdzone na papierze niczego jeszcze nie gwarantuje, jeśli chodzi o realne umiejętności obsługi nowych narzędzi zgodnie z ich biznesowym przeznaczeniem. Zaprojektowanie i dopilnowanie tego procesu, to także praca PMa. - Komunikacja, która mobilizuje i angażuje, a nie tylko informuje
O tym temacie napisano całe tomy. I nadal komunikacja w projektach ERP, to najczęściej iluzja. Bo nie komunikujemy, tylko nadajemy. Jednostronnie, bez wystarczającej interakcji, w sposób niestrawny i nieinteresujący dla użytkowników. Poprzez kanały i nadawców, którzy nie budują ciekawości, poczucia pilności i świadomości potrzeby zmiany, a jedynie podają dalej suche fakty.
Aby taka komunikacja była skuteczna, potrzebuje ona być interaktywna, bezpośrednia, wychodząca od Sponsorów i menedżerów. Skupiona na kontekście, a nie jedynie na kontencie. Zsynchronizowana z innymi działami projektowymi. Nakierowana na budowanie świadomości potrzeby wdrożenia ERP i angażowanie użytkowników, a nie tylko na ich informowanie. Długo by można pisać – po więcej szczegółów odsyłam do artykułu na temat efektywnej komunikacji w zmianie, który został opublikowany w 41 numerze „Strefy PMI” z czerwca 2023. - Przygotowanie użytkowników na równi z przygotowaniem systemu – i dużo wcześniej! Impact, harmonogram
Model zarządzania zmianą ADKAR, opracowany przez Prosci Inc. daje bardzo konkretne wskazówki, jak taki proces może wyglądać. Różne grupy pracowników (kluczowi użytkownicy userzy, menedżerowie, etc.) powinni być gotowi do realizacji nowych zadań w nowy sposób przed go-live. Aby do tego doszło, wcześniej powinni mieć chęć do uczestnictwa w działaniach przygotowawczych (np. analizie As-Is, projektowaniu docelowych rozwiązań, testach UAT, szkoleniach). Zanim przygotujemy użytkowników, należy zaangażować menedżerów. A menedżerów będą angażować Sponsorzy. Cały ten proces powinien być poprzedzony analizą wpływu wdrożenia ERP na różne grupy odbiorców zmiany oraz planem ich zaangażowania do działań przygotowawczych. PM, który taką pracę domową odrobi odpowiednio wcześnie będzie spał dużo spokojniej i skupi się na rozwiązywaniu realnych dylematów, których wdrożenie ERP niesie całe mnóstwo. W przeciwnym wypadku projekt napotka zapewne na opór, którego można było uniknąć, doświadczy niepotrzebnych opóźnień, konieczności powtarzania pewnych działań (szkoleń, komunikacji, testów, etc.). A przede wszystkim nie pojawi się spodziewana poprawa wyników, albo nastąpi ona później, lub w mniejszej skali, niż zakładał Business Case projektu. - Utrzymanie rezultatów wdrożenia po go-live (lub po poszczególnych iteracjach) i szybkie reagowanie na problemy
Zmiana nie kończy się wraz z formalnym zakończeniem projektu. Cykl zmiany powinien trwać do momentu, aż nie stanie się ona integralnym elementem Business as Usual. Gdy użytkownicy efektywnie pracują w nowym środowisku. Pojawiające się na bieżąco problemy są rytunowo rozwiązywane. A konkretne role w organizacji czują właścicielstwo tego, co do niedawna było nowe – a teraz jest już częścią codziennej rutyny. Niestety większość wysiłków na etapie Hypercare/stabilizacji jest skupiona na technicznym wsparciu użytkowników, a nie na wsparciu ich w osiągnięciu pełnej gotowości do pracy w nowych warunkach. Działania te są zbyt ubogie, aby skutecznie utrwalać nowe sposoby pracy nie mówiąc o efektywnym zarządzaniu wiedzą w organizacji, gdy użytkownicy zmieniają swoje role, a nowe osoby przychodzą do organizacji. A poza tym właścicielstwo nowych sposobów pracy powinno być jasno przypisane do osób odpowiedzialnych w strukturze organizacyjnej: Sponsorów, menedżerów. Nie zawsze tak się dzieje. I znowu – istotny obszar do zagospodarowania dla PMa.
Kylan – stock.adobe.comZmiana nie kończy się wraz z formalnym zakończeniem projektu. Cykl zmiany powinien trwać do momentu, aż nie stanie się ona integralnym elementem Business as Usual. Gdy użytkownicy efektywnie pracują w nowym środowisku. Pojawiające się na bieżąco problemy są rytunowo rozwiązywane. A konkretne role w organizacji czują właścicielstwo tego, co do niedawna było nowe – a teraz jest już częścią codziennej rutyny. Niestety większość wysiłków na etapie Hypercare/stabilizacji jest skupiona na technicznym wsparciu użytkowników, a nie na wsparciu ich w osiągnięciu pełnej gotowości do pracy w nowych warunkach. Działania te są zbyt ubogie, aby skutecznie utrwalać nowe sposoby pracy nie mówiąc o efektywnym zarządzaniu wiedzą w organizacji, gdy użytkownicy zmieniają swoje role, a nowe osoby przychodzą do organizacji. A poza tym właścicielstwo nowych sposobów pracy powinno być jasno przypisane do osób odpowiedzialnych w strukturze organizacyjnej: Sponsorów, menedżerów. Nie zawsze tak się dzieje. I znowu – istotny obszar do zagospodarowania dla PMa.
Umiejętne zarządzanie tymi zagadnieniami w ogromnym stopniu zwiększa szansę na sukces biznesowy wdrożenia ERP. Oczywiście PM musi zarządzać także ryzykami operacyjnymi, biznesowymi, finansowymi, prawnymi – ale o tym napisano już wystarczająco dużo. Czas na skuteczną adopcję poprzez efektywne Zarządzanie Zmianą, aby wielomilionowe często inwestycje w ERP naprawdę przynosiły oczekiwany zwrot. Pytanie oczywiście, czy PM powinien sam być w roli Change Managera, czy powinien mieć do tego inne osoby. Wszystko zależy od zakresu zadań, workloadu, kompetencji i dostępności czasowej. Najważniejsze, aby ktoś w zespole projektowym dopilnował realizacji tych zadań. W przeciwnym wypadku nasz projekt ERP ma niestety mniejszą szansę, żeby być dopisany do listy 30% wdrożeń, zakończonych pełnym sukcesem. A pokażcie mi Sponsora, który zadowoli się tylko częściowym ROI…
Prezes Silfra-Consulting. Ekspert w zakresie zarządzania zmianą i projektami. Ma 20 lat doświadczenia we wdrażaniu zmian organizacyjnych, procesowych, digitalizacyjnych, oraz transformacji biznesowej w największych firmach w Polsce i w Europie, m.in. z branży energetycznej, telekomunikacyjnej, finansowej, transportowej oraz usług dla biznesu. Uczestniczył w tworzeniu PMI w Polsce. Jest współzałożycielem ACMP (Association of Change Management Professionals) – globalnej organizacji zrzeszającej praktyków zarządzania zmianą. Jest instruktorem PROSCI w dziedzinie Change Management i pracuje w globalnej sieci ekspertów PROSCI. Od 27 lat jest wykładowcą na Podyplomowych Studiach w SGH oraz na studiach MBA w zakresie wdrażania strategii oraz Project i Change Management.