Zredukuj ryzyko w projekcie mySAP HR

Wyobraźmy sobie projekt płacowy, w którym na początku fazy realizacji zmieniają się układy zbiorowe.

Jeśli przykładowo zmiana ta jest związania z przejściem pracowników opłacanych stawką godzinową na ryczałt miesięczny, może to oznaczać, że stopień skomplikowania listy płac zmniejszy się, uproszczeniu ulegną również testy. Zatem ryzyko zmiany układów zbiorowych w trakcie projektu jest tutaj pozytywne.

Ocena, czy ryzyko może mieć pozytywne czy negatywne konsekwencje, należy przede wszystkim do kierownika projektu. Statystyki dowodzą, że w większości wdrożeń systemów informatycznych ryzyko nie jest związane z technologią, ale z zarządzaniem przedsięwzięciem (przykładowe renomowane badania Standish Group – raport CHAOS).

Problemy projektowe wynikają najczęściej ze źle sprecyzowanych i niekompletnych wymagań, braku zaangażowania użytkowników, braku zasobów, nierealistycznych oczekiwań czy braku wsparcia kadry zarządzającej. Dotyczy to jak najbardziej projektów mySAP HR. Jak sobie radzić z tymi wyzwaniami? Oto kilka wskazówek.

Właściwi ludzie

Dobrze dobrani ludzie w strukturze organizacyjnej projektu to warunek konieczny dla sukcesu przedsięwzięcia. Jednak nawet w sytuacji, gdy w zespołach roboczych są wysokiej klasy specjaliści, efekty ich pracy mogą być niezadowalające. Problem najczęściej leży w wyborze liderów zespołów.

Jeśli nie są to bezpośredni przełożeni uczestników wdrożenia, pojawia się szereg zagrożeń:

• właściwi przełożeni członków zespołów roboczych nie dostrzegają potrzeby odciążenia pracowników od części zadań operacyjnych na rzecz prac projektowych;
• liderzy zespołów nie dysponują wystarczającymi mechanizmami motywującymi;
• uczestnictwo w projekcie wdrożenia systemu mySAP HR ma dla członków zespołów niższy priorytet niż rutynowe zadania pozaprojektowe, z których przecież są rozliczani przez przełożonych.

Jakie rozwiązania sprawdzają się w praktyce? Zdroworozsądkowe – przykładowo:

• liderem zespołu płacowego jest kierownik rachuby wynagrodzeń;
• liderem zespołu kadrowego jest kierownik sekcji kadrowej;
• liderem zespołu rozwoju kadr jest kierownik sekcji szkoleń lub dyrektor działu HR.

Podział zadań

Ryzykownym podziałem zadań w projekcie mySAP HR jest ten, w którym najniższy poziom odpowiedzialności stanowi Zespół (jako grupa ludzi). Odpowiedzialność zbiorowa rzadko zdaje egzamin, skuteczniejsza jest tradycyjna metoda rozdziału pracy – macierz przypisań odpowiedzialności (ang. RAM – Responsibility Assignment Matrix).

RAM definiuje zwykle zakres odpowiedzialności poszczególnych członków zespołów roboczych w stosunku do tzw. pakietów roboczych. Pakiety robocze stanowią najniższy poziom struktury podziału pracy – WBS (ang. Work Breakdown Structure – Struktura Podziału Pracy). Więcej na ten temat w kontekście projektów mySAP HR znajdą Państwo w publikacjach SAP Professional Journal (ramka).

Obok pokazano przykładową macierz RAM dla II fazy projektu mySAP HR. Ten rodzaj macierzy nosi nazwę RACI (ang. Responsible, Accountable, Consulted, Informed). Przygotowanie takiej macierzy jest relatywnie prostym zadaniem:

• wylistuj wszystkie wymierne działania (kolumny macierzy);
• wskaż członków zespołu roboczego i/lub innych interesariuszy projektu (wiersze);
• przypisz do osób odpowiednie role:

R – realizujący zadanie;

A – rozliczany z zadania i najczęściej zatwierdzający;

C – osoba, z którą zadanie jest konsultowane;

I – osoba, która powinna być informowana o statusie zadania.

Dla przykładowych (dość zgrubnych dla uproszczenia) pakietów roboczych fazy II wdrożenia mySAP HR:

• 2.1 Struktura organizacyjna
• 2.2 Struktura personalna
• 2.3 Procesy HR
• 2.4 Dane podstawowe HR
• 2.5 Raporty HR
• 2.6 Uprawnienia HR
• 2.7 Migracja danych
• 2.8 Plan szkoleń

…możemy zdefiniować następującą macierz RAM.

Oto zalety tak zdefiniowanej macierzy:

• RAM gwarantuje, że każdy pakiet z WBS ma swojego właściciela;
• RAM identyfikuje kanały komunikacji w projekcie (kto i jakiej potrzebuje informacji);
• RAM jest dobrym narzędziem prezentacji zadań i zakresu odpowiedzialności w projekcie dla interesariuszy przedsięwzięcia.

Lessons learned

Każde nowe wdrożenie mySAP HR nie różni się całkowicie od poprzednich, a co za tym idzie – warto skorzystać z zebranych doświadczeń, by uniknąć raz popełnionych błędów i skorzystać z dobrych praktyk.

Wiedza zdobyta podczas projektu powinna być gromadzona w bazie danych, by pomóc organizacji w radzeniu sobie z zagrożeniami w przyszłych przedsięwzięciach. Dostępnych jest wiele metod przeprowadzania sesji lessons learned (LL), m.in.:

• burza mózgów,
• metoda Crawforda,
• listy kontrolne,
• technika delficka i inne.

Najpopularniejszą jest tradycyjna burza mózgów, której uczestnikami mogą być kierownik projektu i liderzy zespołów roboczych. Sesje LL powinny być organizowane nie tylko po starcie produktywnym systemu, ale również po zakończeniu każdej fazy projektu. Większa częstotliwość spotkań pozwala na unikanie powielania błędów w kolejnych fazach.

Sesje LL mogą obejmować zagadnienia ogólne i szczegółowe, w zakresie komunikacji, technologii, organizacji i procedur. Poniżej przedstawiono kilka przykładowych rezultatów LL.

Lessons learned – przykłady rezultatów

• „Najefektywniejsze zespoły robocze w projektach mySAP HR składają się maksymalnie z 5 osób. Większe grupy, nawet z osobami o wysokich kompetencjach, stają się mniej efektywne.”.
• „Jeśli to możliwe, w organizacjach o strukturze funkcyjnej, menedżer liniowy powinien być liderem zespołu. Delegowanie jego podwładnych do projektu staje się łatwiejsze.”.
• „Ścisłe rozdzielenie roli analityka i programisty ABAP nie jest dobrym rozwiązaniem – programista powinien być także zaangażowany w analizę.”.
• “Metoda ‘fast tracking’ (wykonywanie działań wielowątkowo) służąca kompresji czasu powinna być stosowana jak najrzadziej jako wnosząca duże ryzyko.”.
• „W dużych projektach, w których zidentyfikowano wiele osób zatwierdzających rezultaty II fazy (macierz RACI), koncepcja.".
• “Wdrożenia powinna być dystrybuowana w formie elektronicznej (a nie wydruku).”.

Kierownik projektu powinien być moderatorem sesji LL, starając się je organizować z taką częstotliwością, by wiedza zdobyta przez zespół nie uległa degradacji na skutek upływu czasu. W literaturze z dziedziny zarządzania projektami oraz w internecie dostępnych jest wiele szablonów wspierających gromadzenie wiedzy projektowej.

Ścieżka krytyczna

Nieterminowość to zły sen kierownika projektu.  Aby się nie ziścił, warto skorzystać z kilku metod zarządzania czasem w projekcie. Jedną z nich jest tzw. metoda ścieżki krytycznej  (ang. CPM – Critical Path Metod).

Zainteresowanych szczegółami analizy ścieżki krytycznej odsyłam do wspomnianych publikacji w SAP Professional Journal.

W ogólności, znajomość ścieżek krytycznych w projekcie ułatwia zarządzanie harmonogramem w taki sposób, by zminimalizować ryzyko niedotrzymania założonych terminów. Ścieżka krytyczna jest sekwencją działań projektowych, w której opóźnienie jakiegokolwiek z nich powoduje opóźnienie całego projektu.

Monitorowanie działań na ścieżkach krytycznych ma szczególne znaczenie w fazie przygotowania do startu systemu. W przypadku projektów HR, w których termin uruchomienia systemu przypada na I dzień w miesiącu, po to, by rejestrować zdarzenia czasu pracy i móc rozliczać płace za cały miesiąc, kilkudniowe opóźnienie na ścieżce krytycznej może spowodować opóźnienie projektu o cały miesiąc.

Dlatego kierownik projektu powinien zidentyfikować wszystkie ścieżki krytyczne w tej fazie i na bieżąco śledzić realizację zadań. Elementarną pomocą może być tutaj Microsoft Project, który na wykresie Gantta dla projektu identyfikuje ścieżki krytyczne (znalezienie ścieżek krytycznych nie wymaga zatem obliczeń).

Zarządzanie wymaganiami

Jeśli ktoś jest przekonany, że dysponuje pełnym, precyzyjnym i odpornym na zmiany opisem wymagań na system mySAP HR przed rozpoczęciem przedsięwzięcia, może się szybko rozczarować. Nieodłączną cechą przedsięwzięć wdrożeniowych jest ciągłe doprecyzowanie.

Oczywiście, maksymalne uszczegółowienie zakresu projektu mySAP HR jest konieczne, ale dopiero kolejne fazy wdrożenia będą przybliżać nas do pełnej wiedzy o wymaganiach.

Przykładowo: Klient w zakresie projektu zdefiniował wymaganie na składniki wynagrodzeń do korekty płac wynikających ze zmian wynagrodzeń w przeszłości (zaistniałych już po zamknięciu listy płac).  W trakcie tworzenia koncepcji Klient, poznając system mySAP HR, dowiaduje się, że dostępny jest mechanizm rozliczenia wstecznego, który czyni pierwotnie zdefiniowane wymaganie zbędnym. W tym przypadku zakres może zostać zredukowany.

Precyzując wymagania w fazie koncepcji dość łatwo ulegamy pokusie zapominania o kluczowych sprawach kosztem zagadnień pobocznych. W projekcie powinna obowiązywać zasada Pareto – 20% przyczyn przynosi 80% wyników. Innymi słowy, najistotniejsze są wymagania związane z kluczowymi procesami biznesowymi (20% procesów). Pojawiające się nowe niekrytyczne wymagania (wynikające z ciągłego uszczegółowiania projektu) nie powinny wnosić ryzyka dla całego przedsięwzięcia.

Przykładowo, jeśli w trakcie projektu twórcy koncepcji dostrzegą korzyści z integracji obszaru HR z SD (sprzedaż i dystrybucja), mimo, że takowa nie była przewidziana w planie projektu, warto ją rozważyć, ale jako nowe przedsięwzięcie, tak by nie stwarzać ryzyka przekroczenia założonych kosztów i terminów.

Przed projektem mySAP HR stawia się zwykle konkretne cele biznesowe i ze względu na ich bezpieczeństwo należy unikać zmian zakresu, harmonogramu i budżetu.

Warto pamiętać, że każdy projekt ma przynajmniej trzy ograniczenia: budżet, zakres i czas. Często prezentuje się je jako trójkąt równoboczny. Każda zmiana długości jednego z boków wpływa na pozostałe. Sztuka zarządzania projektem polega na utrzymywaniu wielkości trójkąta w akceptowalnych granicach.