Wdrożenie rozwiązania informatycznego w przedsiębiorstwie nigdy nie jest łatwe. Bez względu na wielkość organizacji czy poziom skomplikowania procesów biznesowych, każda zmiana jest pewnego rodzaju rewolucją i zmusza niejako do zmiany dotychczasowych nawyków oraz trybu pracy. Podjęcie się realizacji projektu ERP nakłania również do dokładniejszego przyjrzenia się funkcjonowaniu całej organizacji oraz każdej z jej jednostek z osobna, co nieraz okazuje się trudne, bo bezlitośnie obnaża wszelkie braki i zaniedbania.
Od czego zależy powodzenie projektu ERP?
Nie jest odkrywczym stwierdzenie, że powodzenie projektu wdrożenia systemu ERP nigdy nie jest dziełem przypadku. O jego sukcesie decydują różne czynniki, począwszy od samej motywacji, inicjującej cały proces, i gotowości do zmian, poprzez wszelkie prace w projekcie (programistyczne, wdrożeniowe i inne), na osadzeniu tego projektu w szerszej perspektywie i w strategii biznesowej firmy kończąc.
Większość wdrożeń ERP trwa dłużej, niż planowano, kosztuje więcej niż szacowano i przebiega nieco inaczej, niż zakładano. Niektórym jednak przedsiębiorstwom udaje się sprostać wyzwaniom projektu i zrealizować go bez wykraczania poza ustalone ramy.
Szersza perspektywa biznesowa
Brak umiejscowienia projektu ERP w ogólnej strategii biznesowej firmy jest jedną z najczęstszych przyczyn niepowodzenia wdrożenia, a nawet zaprzestania używania systemu w niedługim czasie po zakończeniu projektu. Strategia i plan wdrożenia powinny wynikać i być dostosowane do ogólnej strategii biznesowej przedsiębiorstwa.
Nierealistyczne oczekiwania wobec ERP
Inną przyczyną niepowodzenia projektu są nierealistyczne oczekiwania, skutkujące podejmowaniem błędnych decyzji i koniecznością poradzenia sobie z tego konsekwencjami. Nierealistyczne oczekiwania wobec projektu w oczywisty sposób zwiększają ryzyko przekroczenia budżetu czy harmonogramu, wobec czego często już od samego początku skazują cały projekt na porażkę.
Optymalizacja procesów biznesowych
Ważne dla powodzenia projektu jest również efektywne zarządzanie procesami biznesowymi i ich optymalizacja. Jednym z najczęstszych błędów jest odraczanie wyboru oprogramowania czy też odsuwanie w czasie lub sztuczne przedłużanie czasu samego z powodu braku pewności, jak te procesy biznesowe będą się kształtowały w przyszłości. Często zapomina się (lub po prostu jest to wynikiem niewiedzy), że dzisiejsze systemy ERP są zdecydowanie bardziej stabilne i elastyczne niż były jeszcze dekadę temu. Stąd też koniecznym elementem wdrożenia jest zdefiniowanie i szczegółowe opisanie procesów, jak również wspomniane już osadzenie projektu ERP w długofalowej strategii biznesowej firmy. Dzięki temu system będzie odpowiadał zarówno bieżącym potrzebom organizacji, jak również będzie gotowy sprostać przyszłym wyzwaniom, związanym z rozwojem jej i rynku, na którym funkcjonuje.
System kontroli i nadzoru
Nie wolno zapominać także o procedurach i mechanizmach kontroli nad projektem, które koniecznie muszą zostać ujęte w karcie projektu. Należy jasno określić role i obowiązki dla kierownika projektu, komitetu wykonawczego i innych kluczowych ról projektowych wewnętrznych i zewnętrznych. Pamiętać też trzeba o tym, że zarządzanie projektem wdrożenia ERP musi być zgodne z unikalnymi potrzebami i dynamiką organizacji, w której to wdrożenie ma być przeprowadzone. Ramy tego zarządzania zaś muszą być kompleksowe i jednocześnie dynamiczne, ale także specyficzne i powtarzalne.
Ponieważ implementacje ERP mogą być złożonymi transformacjami biznesowymi (a nie tylko inicjatywami technologicznymi), ważne jest, aby przed rozpoczęciem projektu wdrożyć odpowiednie osoby, kontrole i zarządzanie.
Ryzyko w projekcie
Każde wdrożenie ERP obarczone jest ryzykiem, związanym zarówno z typowymi błędami ludzkimi, jak również z mniej przewidywalnymi i dającymi się kontrolować czynnikami, jak np. zmianami legislacyjnymi, awariami, opóźnieniami podwykonawców. W niemal każdym projekcie zachodzi konieczność zmierzenia się z tego typu sytuacją i takiego zarządzenia tymże ryzykiem, by zminimalizować możliwe niekorzystne konsekwencje. Nie każde jednak ryzyko da się przewidzieć. Nie oznacza to jednak, że należy się biernie przyglądać nadchodzącej katastrofie. Wręcz przeciwnie – reagować należy jak najszybciej, bo tylko tak można zminimalizować negatywne skutki rodzącego się kryzysu. Zacząć zaś należy od zrozumienia zagrożenia – skąd pochodzi, któremu obszarowi projektu zagraża, czym może skutkować. Taka analiza pozwoli z kolei zidentyfikować możliwe sposoby i obszary radzenia sobie z zagrażającym czynnikiem. Inaczej bowiem będzie wyglądała strategia i zarządzanie ryzykiem, związanym z błędami w zakresie procedur kontrolnych, inaczej z nierealistycznymi wymaganiami co do personalizacji i kastomizacji systemu, a jeszcze inaczej w przypadku choćby zatrzymania przez służby celne sprzętu komputerowego, zakupionego za granicą.
Kiedy już zidentyfikujemy zagrożenia, pora na określenie sposobów poradzenia sobie z ich potencjalnymi skutkami. Można to zrobić, tworząc formalny plan naprawczy lub też zaktualizować harmonogram i strategię wdrożenia.
Plan naprawczy powinien być kompleksowy i obejmować wszystkie aspekty projektu – ludzkie, technologiczne i procesowe. Warto pamiętać, że nie od razu Rzym zbudowano i że często naprawa już niewielkiej rzeczy przynosi poprawę rzutującą na całokształt projektu.
Złote zasady
Nie ma możliwości całkowitego uniknięcia ryzyka, które już występuje. Niemniej należy podjąć podstawowe kroki, by projekt doznał jak najmniejszego uszczerbku.
Utrzymanie projektu bazuje na dogłębnej wiedzy o nim – na jakim etapie realizacji się znajduje, jaki status mają poszczególne prace w tym projekcie, które jego pierwotne założenia uległy zmianie i/lub są zagrożone. Powinien być to możliwie najbardziej obiektywny ogląd zarówno elementów technologicznych, jak i procesów oraz ludzi zaangażowanych w projekt. Warto również dokonać takiej oceny z różnych perspektyw – dostawcy systemu i klienta, zespołu projektowo-wdrożeniowego, testerów oprogramowania, architektów systemowych, itd.
Zawsze jednak lepiej zapobiegać niż leczyć. Rzetelne i drobiazgowe zidentyfikowanie czynników ryzyka we wstępnej fazie projektu umożliwia wczesne ich wykrycie i pozwala uniknąć szeregu problemów.
Autor: Anna Młynarczyk, DPS Software
Nie jest odkrywczym stwierdzenie, że powodzenie projektu wdrożenia systemu ERP nigdy nie jest dziełem przypadku. O jego sukcesie decydują różne czynniki, począwszy od samej motywacji, inicjującej cały proces, i gotowości do zmian, poprzez wszelkie prace w projekcie (programistyczne, wdrożeniowe i inne), na osadzeniu tego projektu w szerszej perspektywie i w strategii biznesowej firmy kończąc.
Większość wdrożeń ERP trwa dłużej, niż planowano, kosztuje więcej niż szacowano i przebiega nieco inaczej, niż zakładano. Niektórym jednak przedsiębiorstwom udaje się sprostać wyzwaniom projektu i zrealizować go bez wykraczania poza ustalone ramy.
Szersza perspektywa biznesowa
Brak umiejscowienia projektu ERP w ogólnej strategii biznesowej firmy jest jedną z najczęstszych przyczyn niepowodzenia wdrożenia, a nawet zaprzestania używania systemu w niedługim czasie po zakończeniu projektu. Strategia i plan wdrożenia powinny wynikać i być dostosowane do ogólnej strategii biznesowej przedsiębiorstwa.
Nierealistyczne oczekiwania wobec ERP
Inną przyczyną niepowodzenia projektu są nierealistyczne oczekiwania, skutkujące podejmowaniem błędnych decyzji i koniecznością poradzenia sobie z tego konsekwencjami. Nierealistyczne oczekiwania wobec projektu w oczywisty sposób zwiększają ryzyko przekroczenia budżetu czy harmonogramu, wobec czego często już od samego początku skazują cały projekt na porażkę.
Optymalizacja procesów biznesowych
Ważne dla powodzenia projektu jest również efektywne zarządzanie procesami biznesowymi i ich optymalizacja. Jednym z najczęstszych błędów jest odraczanie wyboru oprogramowania czy też odsuwanie w czasie lub sztuczne przedłużanie czasu samego z powodu braku pewności, jak te procesy biznesowe będą się kształtowały w przyszłości. Często zapomina się (lub po prostu jest to wynikiem niewiedzy), że dzisiejsze systemy ERP są zdecydowanie bardziej stabilne i elastyczne niż były jeszcze dekadę temu. Stąd też koniecznym elementem wdrożenia jest zdefiniowanie i szczegółowe opisanie procesów, jak również wspomniane już osadzenie projektu ERP w długofalowej strategii biznesowej firmy. Dzięki temu system będzie odpowiadał zarówno bieżącym potrzebom organizacji, jak również będzie gotowy sprostać przyszłym wyzwaniom, związanym z rozwojem jej i rynku, na którym funkcjonuje.
System kontroli i nadzoru
Nie wolno zapominać także o procedurach i mechanizmach kontroli nad projektem, które koniecznie muszą zostać ujęte w karcie projektu. Należy jasno określić role i obowiązki dla kierownika projektu, komitetu wykonawczego i innych kluczowych ról projektowych wewnętrznych i zewnętrznych. Pamiętać też trzeba o tym, że zarządzanie projektem wdrożenia ERP musi być zgodne z unikalnymi potrzebami i dynamiką organizacji, w której to wdrożenie ma być przeprowadzone. Ramy tego zarządzania zaś muszą być kompleksowe i jednocześnie dynamiczne, ale także specyficzne i powtarzalne.
Ponieważ implementacje ERP mogą być złożonymi transformacjami biznesowymi (a nie tylko inicjatywami technologicznymi), ważne jest, aby przed rozpoczęciem projektu wdrożyć odpowiednie osoby, kontrole i zarządzanie.
Ryzyko w projekcie
Każde wdrożenie ERP obarczone jest ryzykiem, związanym zarówno z typowymi błędami ludzkimi, jak również z mniej przewidywalnymi i dającymi się kontrolować czynnikami, jak np. zmianami legislacyjnymi, awariami, opóźnieniami podwykonawców. W niemal każdym projekcie zachodzi konieczność zmierzenia się z tego typu sytuacją i takiego zarządzenia tymże ryzykiem, by zminimalizować możliwe niekorzystne konsekwencje. Nie każde jednak ryzyko da się przewidzieć. Nie oznacza to jednak, że należy się biernie przyglądać nadchodzącej katastrofie. Wręcz przeciwnie – reagować należy jak najszybciej, bo tylko tak można zminimalizować negatywne skutki rodzącego się kryzysu. Zacząć zaś należy od zrozumienia zagrożenia – skąd pochodzi, któremu obszarowi projektu zagraża, czym może skutkować. Taka analiza pozwoli z kolei zidentyfikować możliwe sposoby i obszary radzenia sobie z zagrażającym czynnikiem. Inaczej bowiem będzie wyglądała strategia i zarządzanie ryzykiem, związanym z błędami w zakresie procedur kontrolnych, inaczej z nierealistycznymi wymaganiami co do personalizacji i kastomizacji systemu, a jeszcze inaczej w przypadku choćby zatrzymania przez służby celne sprzętu komputerowego, zakupionego za granicą.
Kiedy już zidentyfikujemy zagrożenia, pora na określenie sposobów poradzenia sobie z ich potencjalnymi skutkami. Można to zrobić, tworząc formalny plan naprawczy lub też zaktualizować harmonogram i strategię wdrożenia.
Plan naprawczy powinien być kompleksowy i obejmować wszystkie aspekty projektu – ludzkie, technologiczne i procesowe. Warto pamiętać, że nie od razu Rzym zbudowano i że często naprawa już niewielkiej rzeczy przynosi poprawę rzutującą na całokształt projektu.
Złote zasady
Nie ma możliwości całkowitego uniknięcia ryzyka, które już występuje. Niemniej należy podjąć podstawowe kroki, by projekt doznał jak najmniejszego uszczerbku.
Utrzymanie projektu bazuje na dogłębnej wiedzy o nim – na jakim etapie realizacji się znajduje, jaki status mają poszczególne prace w tym projekcie, które jego pierwotne założenia uległy zmianie i/lub są zagrożone. Powinien być to możliwie najbardziej obiektywny ogląd zarówno elementów technologicznych, jak i procesów oraz ludzi zaangażowanych w projekt. Warto również dokonać takiej oceny z różnych perspektyw – dostawcy systemu i klienta, zespołu projektowo-wdrożeniowego, testerów oprogramowania, architektów systemowych, itd.
Zawsze jednak lepiej zapobiegać niż leczyć. Rzetelne i drobiazgowe zidentyfikowanie czynników ryzyka we wstępnej fazie projektu umożliwia wczesne ich wykrycie i pozwala uniknąć szeregu problemów.
Autor: Anna Młynarczyk, DPS Software
