Jak przygotować sukces projektu wdrożeniowego?

Zastanawiasz się, jak zorganizować udany projekt wdrożeniowy SAP? Twojej organizacji zależy na powodzeniu nowego przedsięwzięcia? W takim razie zacznij je przygotowywać, zanim projekt jeszcze się rozpocznie. Odkryj kluczowe czynniki sukcesu dobrze przygotowanego wdrożenia i poznaj doświadczenia z przedsięwzięć realizowanych przez BCC. Jeśli chcesz się dowiedzieć, na co warto zwrócić uwagę, poznaj pytania, na które powinna odpowiedzieć sobie organizacja planująca wdrożenie.



Według najnowszego raportu Project Management Institute (Pulse of Profession, luty 2014) prawie połowa (44%) strategicznych inicjatyw podejmowanych przez organizacje jest oceniana jako nieudana. Wśród przyczyn trudności z realizacją przedsięwzięć wymieniane są m.in. niejasne cele i ich powiązanie ze strategią firmy, niewystarczające wsparcie kierownictwa, niejednoznaczne priorytety czy konflikty związane z dostępnością kluczowych osób. Wszystkie te elementy wymagają usprawnień, które można podsumować jednym słowem: przygotowanie.

Już trzy wieki temu Benjamin Franklin twierdził, że zaniedbanie przygotowania to przygotowanie porażki. Dlatego dobrze przygotowany projekt powinien rozpocząć się na długo przed podpisaniem umowy, ustaleniem harmonogramu i rozpoczęciem pierwszych prac.

Dlaczego, czyli cele i rezultaty

Pierwszym krokiem przygotowania projektu powinno być ustalenie jego celu i oczekiwanych rezultatów biznesowych. Cel przedsięwzięcia powinien być realistyczny, mierzalny i zgodny z celami strategicznymi organizacji. Powinien też jednoznacznie wyjaśniać, dlaczego firma chce zaangażować czas swoich pracowników i środki finansowe w przeprowadzenie projektu. Przykładowy cel mógłby być zdefiniowany następująco: obniżenie kosztów obsługi serwisowej o co najmniej 5% w stosunku do stanu sprzed wdrożenia. Dobrze zdefiniowany cel będzie w przyszłości „prowadził” zespół projektowy przez przedsięwzięcie, determinując kierunki prac i ułatwiając podejmowanie decyzji.

Ustalenie oczekiwanych rezultatów projektu wymaga natomiast głębokiej refleksji nad najważniejszymi problemami, z którymi boryka się organizacja, i potencjałem rozwoju oraz oceną ich faktycznego wpływu na działalność biznesową. Czy wydajność procesów logistycznych kuleje ze względu na brak dodatkowych raportów kontrolnych? Jedno z możliwych rozwiązań to projekt rozwoju tych raportów. A może jednak rzeczywistym problemem są zawiłe i zbyt złożone procesy zakupowo-magazynowe, które sprzyjają popełnianiu błędów i niespójności, więc powinny zostać uproszczone? Wówczas konieczny jest projekt analizy biznesowej, którego rezultatem będą zmiany organizacyjne połączone ze zmianami w systemach zarządzania.

Ocena wagi poszczególnych problemów dla działalności biznesowej także ułatwi podejmowanie decyzji. Kilkanaście dni pracy zespołu projektowego potrzebnych do zaprojektowania i dostarczenia strategii zatwierdzania może zwrócić się po miesiącu od wdrożenia, dzięki uszczelnionemu procesowi zakupów. Kluczowym czynnikiem sukcesu jest prawidłowa identyfikacja najważniejszych problemów i potencjałów, bo w przeciwnym wypadku może się okazać, że projekt rozwiązuje nie te problemy, które mają największy wpływ na organizację. Kontynuując wyżej przytoczony przykład, można stwierdzić, że spodziewanym rezultatem projektu mogłoby byćwdrożenie zmian organizacyjnych oraz udostępnienie narzędzia w SAP ERP pozwalającego na dynamiczną dywersyfikację partnerów biznesowych obsługujących zgłoszenia serwisowe na podstawie analizy szacunkowych kosztów obsługi zgłoszenia.


Definiując cele i rezultaty projektu, łatwo wpaść w pułapkę ogólnikowych stwierdzeń („poprawa wydajności”, „znaczne obniżenie kosztów”), które trudno będzie racjonalnie ocenić na koniec wdrożenia



Definiując cele i rezultaty projektu, łatwo wpaść w pułapkę szybkich i ogólnikowych stwierdzeń („poprawa wydajności”, „znaczne obniżenie kosztów”), które dobrze wyglądają na prezentacji dla zarządu, ale które trudno będzie racjonalnie ocenić na koniec wdrożenia. Inną potencjalną pułapką jest oczekiwanie, że wdrożenie systemu zarządzania będzie jedynym składnikiem wystarczającym do osiągnięcia założonych celów. Pominięcie w tych oczekiwaniach zadań związanych ze zmianami organizacyjnymi znacząco zwiększa ryzyko niepowodzenia projektu.

Jak, czyli strategia

Znane są przesłanki biznesowe uruchomienia projektu. Czas zatem na określenie strategii (zasady realizacji prac projektowych będą uregulowane przez metodykę projektową). Pierwszym krokiem jest określenie priorytetu przedsięwzięcia w kontekście innych inicjatyw prowadzonych przez firmę (np. budowa magazynu wysokiego składowania, wdrożenie rozwiązania SAP HCM). Umieszczenie projektu na mapie wszystkich przedsięwzięć organizacji ułatwi identyfikację czynników ryzyka i usprawni podejmowanie decyzji związanych np. z dostępnością kluczowego personelu dla poszczególnych projektów (np. dla głównego księgowego najważniejsze są prace w projekcie HCM, ze względu na rozliczenia z pracownikami).

Kierownictwo firmy i liderzy planowanego projektu mają teraz czas na refleksję dotyczącą ewentualnych ograniczeń, przy których przyjdzie realizować przedsięwzięcie (np. przekształcenia własnościowe spółki, planowany awans dyrektora finansowego, konieczność likwidacji zakładu produkcyjnego). Ponadto z wyprzedzeniem można ustalić ścieżki decyzyjne usprawniające podejmowanie decyzji w trakcie trwającego przedsięwzięcia.

To także dobry moment, aby zastanowić się, w jaki sposób będą identyfikowane, zarządzane i wprowadzane zmiany organizacyjne związane z wdrożeniem oraz zmiany zakresu. Zarząd może np. powołać dedykowanego menedżera dla tego obszaru, który będzie nadzorował zmiany organizacyjne we wszystkich trwających projektach. Skuteczność rozwiązania można dodatkowo zwiększyć, ustalając ramy czasowe na zgłaszanie i zatwierdzanie zmian, tak aby zostały uwzględnione w ramach projektu. Innym ważnym aspektem jest ustalenie zasad zarządzania czynnikami ryzyka, zanim jeszcze zostaną one zdefiniowane podczas uruchamiania projektu.

Wreszcie to także ważny moment, aby porozmawiać na temat finansowania przedsięwzięcia (CAPEX/OPEX), źródeł finansowania (np. dedykowany budżet korporacyjny czy budżet poszczególnych działów/spółek) oraz zasad szacowania i nadzorowania wydatków projektowych.

Kto, czyli zespół

Kolejnym krokiem jest ustalenie wszystkich interesariuszy projektu, którzy – poprzez aktywny udział lub jako beneficjenci wprowadzanego rozwiązania – powinni zostać uwzględnieni na etapie planowania projektu. Ważne, aby identyfikując interesariuszy, spojrzeć także poza ramy organizacji, uwzględniając np. potencjalnego partnera wdrożeniowego, kooperantów, obecnych dostawców rozwiązań oraz inne podmioty współpracujące z firmą czy też z nią konkurujące.

Pierwsza grupa, którą należy poddać analizie, to osoby decyzyjne (np. zarząd, kierownicy działów biznesowych) oraz kierownik projektu. Jeszcze zanim rozpoczniemy projekt, warto zastanowić się, które z tych osób powinny wejść w skład komitetu sterującego, czy to ze względu na pozycję w firmie (decyzyjność), czy to ze względu na objęcie podlegającego im obszaru przedmiotem wdrożenia (wpływ), czy też konstruktywne podejście do rozwiązywania trudnych sytuacji.

W momencie rozpoczęcia projektu kierownictwo firmy powołuje zespoły projektowe, wyznaczając liderów poszczególnych obszarów funkcjonalnych i technicznych. Aby zapewnić, że wszyscy zaangażują się w przedsięwzięcie już od pierwszego dnia, warto zidentyfikować kluczowych członków zespołu na długo przed jego rozpoczęciem. Można także pomyśleć o zastępstwach, aby zabezpieczyć się przed wydarzeniami losowymi. Identyfikacja członków zespołu z dużym wyprzedzeniem daje możliwość lepszej oceny ich dostępności, posiadanych kompetencji merytorycznych i umiejętności interpersonalnych, istotnych ze względu na nastawienie na współpracę i osiąganie wyznaczonych celów.

Myśląc o zespole, warto ustalić odpowiedni system motywacyjny dla jego uczestników (o ile w danej organizacji nie istnieje gotowy model). Rozwiązanie może zależeć od specyfiki danego projektu, np. od poziomu zaangażowania pracownika w prace projektowe, czy też być uzależnione od osiągnięcia wyznaczonych celów przedsięwzięcia. Niezależnie od ostatecznej formy, jest to ważny element stymulujący zaangażowanie w prace projektowe, zwłaszcza w trudnych i wymagających momentach projektu.


Myśląc o zespole, warto ustalić odpowiedni system motywacyjny dla jego uczestników. Nie można zapominać także o użytkownikach, który jako beneficjenci nowego rozwiązania będą je oceniać



Nie można zapominać także o użytkownikach. Występując w roli głównych beneficjentów wypracowanego rozwiązania, będą je oceniać, zwłaszcza w pierwszych miesiącach od wdrożenia. Ponadto od ich biegłości w posługiwaniu się stworzonymi narzędziami zależeć będzie wydajność i skuteczność codziennych operacji biznesowych. Warto więc zawczasu zadbać o odpowiednią komunikację, która po pierwsze pozytywnie nastawi ich do planowanej zmiany, a po drugie pozwoli miękko i z minimum obaw przejść ze stanu obecnego do stanu po wdrożeniu.

Partner wdrożeniowy to kolejny element zespołowej układanki. Wybór firmy, z którą będziemy wspólnie realizować prace projektowe, to praktycznie osobny podprojekt, któremu należałoby poświęcić osobny artykuł. To, na co z pewnością warto zwrócić uwagę, to zrozumienie dla celów organizacji, oferowany zakres usług (wdrożenia, serwis aplikacyjny, usługi dodatkowe), referencyjne projekty w każdym z wdrażanych obszarów, doświadczenia międzynarodowe, dbałość o rozwój kompetencji konsultantów czy dopasowanie kultury organizacyjnej. Warto zweryfikować poziomy współpracy z producentem systemu, które pozwolą np. zakupić licencje czy uzyskać szybki dostęp do serwisu technicznego producenta.

A skoro o serwisie technicznym mowa, to przygotowując projekt, warto zinwentaryzować obecnie wykorzystywane systemy oraz ustalić lub potwierdzić zakres wsparcia dla nich. Część aplikacji może zostać zastąpiona przez nowe rozwiązanie. Inne będą wykorzystywane jako źródło lub odbiorca informacji z nowego systemu. Konieczne będzie więc utworzenie interfejsów. Wdrożenie stawia często producentów lub opiekunów tych systemów na uprzywilejowanej pozycji. Warto więc zawczasu zatroszczyć się o odpowiednio korzystne warunki współpracy, tak aby nie zderzyć się z nieprzyjemną niespodzianką podczas projektu.

Wreszcie każda organizacja działa w ramach określonego ekosystemu. Partnerzy biznesowi (np. odbiorcy, dostawcy, podwykonawcy), urzędy państwowe czy regulatorzy (np. urząd skarbowy, ZUS, KNF) będą co najmniej pośrednio dotknięci efektami wdrożenia. Przygotowując projekt, należy się upewnić, że odpowiedni interesariusze zostaną poinformowani o wdrożeniu oraz ewentualnym wpływie (lub jego braku) na ich działania operacyjne.

Kiedy, czyli plan i harmonogram

Harmonogram przedsięwzięcia oczami zarządu i kierownika projektu to zadania zaplanowane do realizacji w określonym czasie, potwierdzane osiąganiem zdefiniowanych kamieni milowych. Podczas przygotowania projektu warto spojrzeć na harmonogram z nieco innej perspektywy.

Przede wszystkim określając ramy czasowe przedsięwzięcia, warto uwzględnić sezonowość obecną praktycznie w każdej działalności biznesowej. Jeśli ważne momenty projektu (np. prace koncepcyjne, testy, szkolenia) zostaną zaplanowane w szczytowym momencie produkcji czy sprzedaży, z prawdopodobieństwem graniczącym z pewnością możemy planować także przesunięcie terminu startu produkcyjnego. Zamiast tego warto twórczo wykorzystać te momenty w działalności firmy na realizację działań niewymagających dużego zaangażowania przedstawicieli biznesu (np. prace konfiguracyjno-rozwojowe, przygotowanie materiałów szkoleniowych, testy jednostkowe/wewnętrzne).

Drugi ważny wymiar to nałożony na harmonogram projektu kalendarz. Typowe okresy ograniczonej dostępności (święta, okresy urlopowe, długie weekendy) nawet w przypadku długich przedsięwzięć mogą rozbić precyzyjnie skonstruowany harmonogram. Warto więc zawczasu przeanalizować czas, w którym planowana jest realizacja projektu, i odpowiednio dostosować harmonogram albo… wprowadzić restrykcyjną politykę urlopową dla członków projektu i komitetu sterującego. Szczególne wyzwanie czeka kierowników projektów międzynarodowych, w których konieczna jest synchronizacja harmonogramu projektu z kalendarzem świąt w dwóch, a nierzadko trzech i więcej krajach, z których pochodzą uczestnicy przedsięwzięcia.

Określając ramy czasowe przedsięwzięcia, warto uwzględnić sezonowość obecną praktycznie w każdej działalności biznesowej oraz typowe okresy ograniczonej dostępności (święta, okresy urlopowe, długie weekendy)
Gdzie, czyli struktura i lokalizacja

Nieodzownym elementem przygotowania przedsięwzięcia jest weryfikacja jego zakresu organizacyjnego i geograficznego. Współczesne organizacje to złożone organizmy: grupy kapitałowe, firmy wielooddziałowe czy wielozakładowe, nie wspominając o korporacjach działających na skalę międzynarodową. Struktura organizacyjna oraz geograficzne lokalizacje, w których prowadzone będą prace, będą miały bezpośredni wpływ stopień trudności wdrożenia w zakresie np. potencjalnych wariantów procesów gospodarczych czy złożoności przygotowania i wykonania danych do docelowego środowiska.

Złożoność organizacyjna dotyka ponadto kwestii związanych z użytkownikami końcowymi: ich licznością i indywidualnym doświadczeniem. Elementy te będą miały bezpośredni wpływ na zakres i skalę szkoleń, zakres wsparcia w trakcie przedsięwzięcia i po starcie produkcyjnym. Niebanalnym wyzwaniem może okazać się wypracowanie optymalnego modelu wsparcia użytkowników pracujących w kilkunastu czy kilkudziesięciu lokalizacjach rozproszonych po kraju lub świecie.

Struktura i lokalizacja firmy będą także determinować preferowaną lokalizację prac projektowych (dostępność kluczowych osób, łatwość dojazdu, ograniczenie kosztów logistycznych). Zawczasu warto więc przemyśleć możliwości komunikacji między oddziałami (tele- i wideokonferencje) oraz zasady pracy zdalnej, które będą obowiązywać w trakcie projektu.


Nieodzownym elementem przygotowania przedsięwzięcia jest weryfikacja jego zakresu organizacyjnego i geograficznego



Co, czyli zakres

Definiowanie zakresu wdrożenia to projekt sam w sobie trudny, zajmujący czas i wymagający szczególnej uwagi. Często już na tym etapie ujawnia się dualizm projektów wdrożeniowych, balansujących pomiędzy działalnością operacyjną przedsiębiorstwa a IT. W typowym scenariuszu dział IT, nadzorujący lub przygotowujący dokumentację na potrzeby działu zakupów, oczekuje od biznesu konkretnych wymagań co do wdrożenia. Ścisła, formalna lista wymagań może jednak zaowocować niejednoznacznymi czy niewłaściwie zinterpretowanymi wymaganiami. Z kolei przedstawiciele biznesu postrzegają projekt jako niepowtarzalną okazję do realizacji wymagań, potrzeb i marzeń owocujących szerokim zakresem funkcjonalnym.

Wdrożenie jest wydarzeniem rzadkim i wywołuje naturalną chęć realizacji rozwiązań na zapas, bez właściwego kontekstu i celu biznesowego. W rezultacie często definicja zakresu sprowadza się do utworzenia listy wymagań funkcjonalnych i pozafunkcjonalnych, a następnie do zebrania na ich podstawie informacji od potencjalnych partnerów wdrożeniowych co do wyceny ich realizacji.

Tymczasem dobre przygotowanie zakresu wdrożenia to pierwszy moment wymagający zdecydowanych decyzji biznesowych. To na tym etapie najlepiej ustalić, które procesy wymagają systemowego wsparcia lub usprawnienia, tak aby cała organizacja zyskała najwięcej. Klasyfikując wymagania, najlepiej wykorzystać metodę MoSCoW opisaną w drugim wydaniu Business Analysis Body of Knowledge:

  • Must (krytyczne/obowiązkowe): wymagania, które muszą być spełnione, aby rozwiązanie mogło zostać uznane za sukces.
  • Should (wymagane): wymagania o wysokim priorytecie, które powinny być obecne w rozwiązaniu, jeśli to możliwe. Często są to krytyczne wymagania, które mogą być zrealizowane na różne sposoby (np. zmianą organizacyjną, zamiast rozwiązania w systemie).
  • Could (opcjonalne/dodatkowe): wymagania, które stanowią pewną wartość dla organizacji, ale ich dostarczenie nie jest konieczne do sukcesu projektu. Ich realizacja jest często uzależniona od ograniczeń czasowych i budżetowych.


Won’t (odrzucone): wymagania, które nie zostały objęte zakresem projektu. Mogą obejmować funkcje, które zostaną zrealizowane w ramach innego projektu, w przypadku spełnienia określonych wymagań biznesowych (np. uruchomienie nowej linii produktowej).
Takie podejście ma kilka zalet. Po pierwsze jeszcze przed rozpoczęciem przedsięwzięcia można na zimno, bez emocji związanych z projektem przemyśleć, spełnienie których wymagań jest niezbędne do osiągnięcia sukcesu biznesowego projektu. Po drugie nadanie wymaganiom priorytetów pozwala lepiej zaplanować finansowanie przedsięwzięcia, np. podzielić budżet na poszczególne grupy wymagań, uwzględniając rezerwę na nowe wymagania, które naturalnie pojawią się podczas prac. Po trzecie, dzięki określeniu ważności wymagań już w trakcie prac projektowych członkowie projektu koncentrują 100% uwagi na rzeczywistych potrzebach biznesowych, ograniczając do minimum dyskusje o zagadnieniachniekrytycznych dla biznesu.

W rezultacie zamiast zaangażowania zespołu w projektowanie kilkudziesięciu raportów, które będą wykorzystywane raz w roku i ograniczą straty o kilkaset złotych, prace projektowe mogą skoncentrować się na funkcjach, które przyniosą bardziej wymierną wartość. Na przykład automatyzację komunikacji z partnerami biznesowymi, co pozwoli odciążyć pracowników, zaoszczędzić dziesiątki tysięcy złotych i dodatkowo pozyskać nowych odbiorców.

Jedyną, acz potencjalnie istotną trudnością, na którą warto się przygotować, jest niewystarczające zaangażowanie kluczowych decydentów w przygotowanie przedsięwzięcia jeszcze przed jego powołaniem. Brak formalnie zdefiniowanego projektu może stanowić argument do odkładnia trudnych decyzji na później. W takich sytuacjach warto odwołać się do celów projektu i aspektów finansowych, które stanowią dobrą „mapę drogową” do ich podejmowania.

Definiując zakres planowanego przedsięwzięcia, trudno nie wspomnieć o dwóch ważnych akceleratorach, które mogą znacząco uprościć i przyspieszyć prace projektowe. Pierwszy z nich to lista i opis procesów biznesowych. Często firmy posiadają już taki materiał, np. stworzony na potrzeby wdrożenia systemu zarządzania jakością. Będzie on stanowił doskonałą podstawę do rozmów na etapie koncepcji. Przygotowując się do projektu, jeszcze przed wyborem systemu czy partnera wdrożeniowego właściciele procesów mogą się zastanowić, gdzie procesy można uprościć, ujednolicić (np. w skali grupy spółek) lub gdzie opis procesu nie nadąża za rzeczywistością. Oczywiście zarówno identyfikacja, jak i opis procesów mogą zostać także zrealizowane podczas wdrożenia, w pierwszym etapie koncepcji.


Lista i opis procesów biznesowych oraz przemyślana strategia zarządzania danymi podstawowymi to dwa ważne akceleratory, które mogą uprościć i przyspieszyć prace projektowe



Drugim ważnym akceleratorem jest przemyślana strategia zarządzania danymi podstawowymi. Dane podstawowe, pomimo że są kluczowym elementem sterującym procesami biznesowymi, bywają często niedoceniane, ze względu na koncentrację interesariuszy na aspektach funkcjonalnych rozwiązania. Tymczasem dostępność, jakość i proces zarządzania danymi podstawowymi przed projektem i po nim należą do kluczowych czynników sukcesu przedsięwzięcia. Dlatego tak ważne jest ustalenie zasad i procedur obsługi danych podstawowych, wyznaczenie osób odpowiedzialnych za nadzór nad danymi czy wręcz powołanie komórki, która będzie odpowiadała za ten obszar w organizacji.

Co dalej?

Solidne i wszechstronne przygotowanie projektu to dopiero początek drogi do udanego wdrożenia. Teraz organizacja jest już świadoma czekających na nią wyzwań i wyposażona w wiedzę i narzędzia, aby im sprostać. Nie pozostaje zatem nic innego, jak formalnie powołać przedsięwzięcie i w pełnej gotowości rozpocząć prace projektowe.

Autor: Michał Jasiński, Kierownik Projektów SAP w BCC
Źródło: Grupa BCC

 

PRZECZYTAJ RÓWNIEŻ:


Back to top