Wdrożenie systemu HR rzadko kończy się na ustawieniu formularzy, pól i ekranów. W rzeczywistości jest to projekt, który ma wpływ na sposób pracy całej organizacji, dotyka jej procesów, przyzwyczajeń i kultury zarządzania zmianą. W najnowszym odcinku podcastu KPMG ON AIR. Lekko o biznesie eksperci KPMG, Jacek Jarosz i Margaryta Wysocka oraz Michał Strzelec, Senior Solution Sales Executive HCM w SAP omawiają cztery typowe pułapki wdrożeń systemów HR-owych SAP oraz pokazują, jak unikać tych pułapek, zanim zaczną wpływać na harmonogram, budżet i zaufanie użytkowników.
Nowy system, stare przyzwyczajenia
Jedną z najczęstszych pułapek wdrożeń SAP HR jest próba odtworzenia dotychczasowego systemu w nowym środowisku. Jacek Jarosz wskazuje sytuację, w której organizacja deklaruje chęć wdrożenia nowego rozwiązania, ale w praktyce oczekuje zachowania tych samych formularzy, tych samych procesów i tej samej logiki działania. Oznacza to, że zamiast wykorzystać zmianę jako szansę na usprawnienie pracy, firma próbuje przenieść stare rozwiązania jeden do jednego.
Margaryta Wysocka podkreśla, że taka sytuacja pojawia się bardzo często. Jak mówi, już na etapie przygotowywania RFP można zauważyć pierwsze symptomy takiego podejścia, ponieważ jak twierdzi „wymagania są opisywane językiem funkcjonalności, a nie realnych potrzeb biznesowych”.
Zdaniem Michała Strzelca firmy bywają „zakładnikami tego, w czym były do tej pory”. Dlatego przed rozpoczęciem zmiany warto stworzyć warunki do oderwania się od codziennych schematów, np. poprzez warsztaty poza siedzibą firmy, podczas których zespół może na nowo zdefiniować swoje potrzeby i zastanowić się, jak procesy powinny wyglądać w przyszłości.
Próba skopiowania starego systemu do nowego środowiska może prowadzić do nadmiernych kastomizacji. Jacek Jarosz przywołuje doświadczenia z projektów, w których budowano skomplikowane rozwiązania, czasem wykorzystując pola systemowe niezgodnie z ich pierwotnym przeznaczeniem. Gdy dostawca wycofywał wsparcie dla takich elementów, cała konstrukcja wymagała przebudowy.
Fit-to-Standard zamiast długu technologicznego
Wdrożenia systemów chmurowych szczególnie mocno pokazują koszt nadmiernej kastomizacji. Michał Strzelec wyjaśnia, że rozwiązania cloudowe są trudniejsze do głębokiego dostosowywania, ale jednocześnie oferują szeroki standard konfiguracji. Kluczowe staje się więc świadome określenie granicy pomiędzy standardem, konfiguracją i rozbudową, ponieważ każda próba wyjścia poza standard wiąże się z kosztem oraz wpływa na elastyczność rozwiązania.
W rozmowie mocno wybrzmiewa podejście Fit-to-Standard. Michał Strzelec wskazuje, że utrzymywanie się możliwie blisko standardu oraz założeń clean core pozwala łatwiej zarządzać produktem i ograniczać ryzyko długu technologicznego. Dług ten może z czasem blokować rozwój systemu oraz ograniczać możliwość korzystania z kolejnych funkcjonalności.
Przy wdrożeniach systemów SAP HR organizacja musi się przygotować na konieczność zmiany sposobu myślenia. Najpierw należy zidentyfikować, czego firma naprawdę potrzebuje, a dopiero później zastanowić się nad tym, czy istnieje uzasadniony powód, by nie skorzystać z Best Practices. Jacek Jarosz podsumowuje ten wątek, wskazując na potrzebę odwrócenia paradygmatu, czyli uzasadniania odstępstw od standardu, a nie samego korzystania z niego.
Projekt HR nie może być pracą po godzinach
Drugą pułapką omawianą w odcinku jest traktowanie projektu wdrożeniowego jako dodatkowego obowiązku dla już obłożonych zadaniami pracowników firmy. Formalnie członkowie zespołu projektowego zostają oddelegowani do prac, jednak w praktyce nadal wykonują swoje codzienne zadania. Jacek Jarosz wskazuje, że taki model bardzo szybko staje się problematyczny, ponieważ projekty HR bywają absorbujące i wymagają dużej uwagi.
Margaryta Wysocka zwraca uwagę, że konsekwencje takiego podejścia są odczuwalne zarówno w harmonogramie, jak i w atmosferze pracy – „jeśli terminy się przeciągają, decyzje się przeciągają, to jest też ogromna frustracja wśród ludzi”. W skrajnych przypadkach przeciążenie może prowadzić do rotacji, co dodatkowo komplikuje projekt, ponieważ wiedza budowana przez wiele miesięcy nie jest łatwa do szybkiego przekazania.
Michał Strzelec dodaje, że projekt wymaga jasnego ownershipu i czasu. Wdrożenie oraz rozwój systemu informatycznego mogą wydawać się proste, jednak są zadaniem wielowymiarowym i wymagają pełnego zaangażowania. Jak podkreśla, „to nie jest praca na pół etatu”.
Ownership, decyzyjność i rola zarządu
Aby uniknąć problemów z zaangażowaniem zespołu, projekt musi zostać odpowiednio spozycjonowany przez zarząd. Margaryta Wysocka wskazuje, że „jeżeli zarząd nie nada wysokiego priorytetu dla tego projektu, to tak samo będzie traktowany przez osoby zaangażowane w projekt”. Zespół powinien mieć czas, mandat do podejmowania decyzji i realną odpowiedzialność. W przeciwnym razie projekt nie ma właściciela.
W rozmowie pojawia się przykład projektu uznanego przez Margarytę Wysocką za wzorcowy. Klient wynajął osobne pomieszczenia i oddelegował ludzi wyłącznie do prac projektowych lub niemal całkowicie odsunął ich od bieżących obowiązków. Dzięki temu wszyscy mogli skupić się na jednym celu, a prace przebiegały terminowo.
Michał Strzelec zwraca również uwagę na znaczenie lidera. Porównuje projekt do zwiedzania nowego miasta, w którym grupa potrzebuje przewodnika, a nie wielu osób chcących iść własną drogą. Wdrożenie wymaga więc osoby lub zespołu, który bierze odpowiedzialność za kierunek, decyzje i najkrótszą drogę od punktu A do punktu B.
Kiedy wdrożenie technologii przesłania troskę o użytkowników
Trzecia pułapka dotyczy sytuacji, w której projekt koncentruje się prawie wyłącznie na technologii. Zespół pracuje nad konfiguracją, formularzami i ekranami, ale do organizacji nie trafia jasna narracja o sensie nadchodzącej zmiany. Jacek Jarosz opisuje taki projekt jako zamknięcie zespołu w „technicznej kapsule”.
Michał Strzelec potwierdza, że widział sytuacje, w których skupienie na konfiguracji przesłaniało change management. „Pomijano komunikację zmiany, prezentację benefitów oraz wyjaśnienie, co organizacja i pracownicy mają dzięki wdrożeniu uzyskać” – opisuje ekspert. Taki błąd często wynika z postrzegania systemu informatycznego jak aplikacji, którą wystarczy zainstalować, aby zaczęła działać.
W przypadku systemu SAP SuccessFactors takie podejście jest szczególnie ryzykowne, ponieważ nie jest to rozwiązanie wyłącznie dla działu IT. Margaryta Wysocka przypomina, że z systemu będą korzystać pracownicy całej organizacji – „każdy się zaloguje, będzie chciał sprawdzić swoje dane, pasek płacowy, PIT, będzie chciał złożyć wniosek o urlop, a menadżerowie będą chcieli obejrzeć plany urlopowe pracowników”.
Change management jako równoległy tor wdrożenia
Skuteczne wdrożenie wymaga komunikacji celu. Michał Strzelec przywołuje przykład z wizyty prezydenta Kennedy’ego na przylądku Canaveral, podczas której osoba sprzątająca na pytanie o to, co tam robi, miała odpowiedzieć, że „wysyła człowieka na księżyc”. W kontekście projektów HR oznacza to potrzebę zbudowania wspólnego poczucia celu, aby każdy wiedział, po co organizacja przechodzi przez zmianę.
„Jeżeli ludzie nie będą rozumieć po co jest ten system, to choćby on był najlepiej skonfigurowany, to nie będą z niego korzystać” – podsumowuje Margaryta Wysocka. Adopcja technologii wśród użytkowników nie jest bowiem dodatkiem do projektu, ale jednym z warunków powodzenia całego wdrożenia.
Dlatego komunikacja nie powinna pojawiać się dopiero przed samym go-live. Jak wskazują eksperci, należy ją prowadzić równolegle z pracami implementacyjnymi. Michał Strzelec puentuje: „Najlepsza konfiguracja bez change managementu polegnie”.
Big Bang, czyli rozwiązanie nie dla wszystkich
Czwarta pułapka dotyczy wdrożenia typu Big Bang. Jacek Jarosz zaznacza, że nie zawsze jest to błąd, jednak wiąże się z dużym ryzykiem, ponieważ oznacza uruchomienie wszystkich procesów, modułów i spółek jednocześnie, bez etapowego rollout’u.
Margaryta Wysocka wskazuje, że w takim modelu niewielki problem może szybko urosnąć do rangi dużej eskalacji. Błąd od razu staje się widoczny dla wszystkich, „zaczynają się maile, telefony z wszystkich działów czy krajów, nie ma w tym momencie przestrzeni na ciche poprawianie niedociągnięć”.
Ryzyko dotyczy także reputacji projektu. Eksperci podkreślają, że nawet drobny błąd może obniżyć zaufanie użytkowników. Po takim falstarcie odbudowa zaufania jest bardzo trudna. Użytkownicy mogą wracać do starych praktyk, np. Excela i maili, a później sztuką jest przekonanie ich do ponownej próby korzystania z nowego systemu.
Nie oznacza to jednak, że Big Bang zawsze prowadzi do porażki. Michał Strzelec wyjaśnia, że może się sprawdzić w organizacjach dojrzałych procesowo, „które dokładnie wiedzą, czego chcą, mają jasno sprecyzowany zakres projektu oraz kryteria sukcesu”. Warunkiem jest jednak dobra walidacja takiej decyzji.
W organizacjach rozproszonych, z wieloma interesariuszami, specyficznymi procesami, różnymi krajami, reżimami prawnymi i strefami czasowymi, lepszym rozwiązaniem może być pilotaż lub rollout etapowy. Margaryta Wysocka wskazuje, że mniejsza skala pozwala wychwycić błędy, których nie udało się zidentyfikować podczas testów akceptacyjnych, zanim zobaczy je cała organizacja.
Technologia rzadko jest głównym wyzwaniem
Pod koniec rozmowy eksperci wskazują wspólny mianownik omawianych case’ów. Margaryta Wysocka mówi o strachu przed zmianą i braku ownershipu, natomiast Michał Strzelec podkreśla, że za każdą zmianą stoją ludzie. Potrzebne są leadership, ownership, zarządzanie zmianą oraz jasna definicja kryteriów sukcesu.
Na koniec rozmówcy wymieniają pięć zasad, które pomagają ograniczyć ryzyko. Warto zaczynać od Fit-to-Standard, traktować projekt HR jako pełnoprawną inicjatywę, prowadzić komunikację przez cały czas trwania wdrożenia, korzystać z pilotaży i etapowego rollout’u oraz budować partnerską relację między klientem i dostawcą.
Skontaktuj się z nami
Dowiedz się więcej, o tym w jaki sposób wiedza i technologia KPMG mogą pomóc Tobie i Twojej firmie.
Jak możemy pomóc?
Newsletter
Chcesz otrzymywać najświeższe informacje biznesowe?