Change management we wdrożeniach projektów SAP

Kiedy wprowadzić change management?

Hanna Dziubińska: Michał, jesteś Change Managerem, więc kładziesz bardzo duży nacisk na wprowadzanie zmian w organizacjach i na gotowość organizacji do tych zmian. Powiedz mi proszę, czy faktycznie możemy mówić, że Change Management jest taką prefazą przed wdrożeniem projektowym?

Michał Sarna: To jest bardzo ciekawe pytanie. Fajnie to w ogóle nazwałaś taką prefazą. Myślę, że zdecydowanie, tak powinniśmy powiedzieć, że zarządzanie zmianą zaczyna się przed projektem, tak, to jest ten moment. Możemy sobie powiedzieć także, że zarządzanie zmianą, żeby zadziałało, zaczyna się przed projektem, ale nie jest to działanie jednorazowe, jest to początek całego procesu, który będzie trwał równolegle do trwającego projektu, czy trwającego wdrożenia i będzie trwał także po jego zakończeniu. Wdrażając jakiekolwiek rozwiązanie z rodziny produktów z systemów SAP, na przykład właśnie wspomniany przez Ciebie SuccessFactors, trzeba o tym pomyśleć zanim się zacznie podchodzić do projektu. Trzeba się do tego przygotować. To wesprze organizację w procesie uruchomienia przedmiotu wdrożenia z jak największym sukcesem.

Świadomość dotycząca change managementu

Hanna Dziubińska: Czyli change management jest na początku, jeszcze przed wdrożeniem, ale także w trakcie trwania wdrażania.

Michał Sarna: Dokładnie. Myślę, że jak popatrzymy na ostatnie 10 lat w branży projektów SAP-owych, to moje osobiste obserwacje są takie, że ta świadomość odnośnie change managementu w Polsce zdecydowanie rośnie. Zaczyna pojawiać się na rynku zapotrzebowanie na tego typu kompetencje, zarówno po stronie firm partnerskich, jak i także po stronie klientów. I patrząc na ten okres trzeba powiedzieć sobie, że mogliśmy obserwować zarówno projekty, które zakończyły się sukcesem, jak i te, które tym sukcesem się nie zakończyły, na projekty, które zostały wstrzymane, zamrożone i nigdy się nie odmroziły. I myślę sobie, że przy negatywnym scenariuszu najlepszym efektem, jaki po wdrożeniu klienci otrzymywali, było obniżenie efektywności pracy pracowników i ich motywacji. To był najmniejszy wymiar negatywny.
Natomiast dziś już klienci i rynek mają większą świadomość. Widać, że zapotrzebowanie na te kompetencje, tak jak powiedziałem, zaczyna się pojawiać i widać, że zaczynają organizacje kierować swoją uwagę w pozyskiwaniu takich osób, czy to poprzez firmy konsultingowe, czy też poprzez zatrudnienie ich do wewnątrz organizacji.

Kompetencje zarządzania zmianą, a rola partnera wdrożeniowego

Hanna Dziubińska: A jak, Tomku, to z Twojej perspektywy wygląda? Czy ten świadomościowy wymiar faktycznie jest coraz lepszy w Polsce, czy faktycznie te organizacje coraz częściej myślą o Change Managemencie?

Tomasz Zubrzycki: Świadomość takiej potrzeby jak najbardziej jest w organizacjach, jest ona coraz większa. Natomiast jedna rzecz to mieć świadomość tego, że potrzeba jest odpowiednich kompetencji i sposobu zarządzania zmianą w ramach projektu wdrożeniowego, ale drugim zagadnieniem jest przygotowanie organizacji na tę zmianę, w szczególności chociażby od strony kompetencji osób, które by tę zmianę miały przeprowadzać. I tutaj już ta sytuacja nie wygląda tak kolorowo, klienci raczej niezbyt często mają już na pokładzie osoby, które byłyby odpowiednio przygotowane do prowadzenia tego typu projektów. Ale to nie może dziwić. Gdy mówimy w kontekście projektów wdrożenia rozwiązań z obszaru HR-owego, z SuccessFactors, to jest to projekt, który odbywa się w organizacji raz na ładnych parę lat, może nawet na kilkanaście. Utrzymywanie tego typu kompetencji na pokładzie, gdzie w szczególności zarządzanie zmianą ma różne aspekty i specyfikę w kontekście projektu HR-owego, byłoby co najmniej nieracjonalne. I tych kompetencji często w organizacjach brakuje. Natomiast to, że ich brakuje, według mnie nie jest niczym nadzwyczajnym. To jest sytuacja jak najbardziej normalna. I uważam, że tutaj leży duża odpowiedzialność po stronie partnera wdrożeniowego, żeby po pierwsze też uświadomić klienta, jakich kompetencji potrzebuje, żeby podpowiedzieć, czy w ramach organizacji, nawet na etapie spotkań wcześniejszych, przygotowawczych do projektu, procesów sprzedażowych, czy zauważone zostały takie osoby, które mają odpowiednie cechy i można powiedzieć pewnego rodzaju też background, który będzie pomagał w tym, by taka osoba mogła być odpowiedzialna, czy też uczestniczyć w tym procesie zarządzania zmianą. I tak naprawdę uważam, że odpowiedzialność za ten change management, przynajmniej na początku projektu, jest po stronie partnera i to partner powinien być doradcą dla klienta.

Wyzwania change managementu: brak znajomości celu

Hanna Dziubińska: Miałam się tutaj zapytać o konsekwencje takiego braku przygotowania, ale już Michał trochę o tym powiedziałeś. Mówiłeś o spadku efektywności. Czy możesz wymienić jakieś inne wyzwania, z którymi mierzymy się podczas takiego przygotowania do wdrożenia?

Michał Sarna: Tak, tak. Zdecydowanie tych wyzwań może być mnóstwo. Słusznie Tomek zauważył, że klienci potrzebują doradztwa oraz pokazania im perspektyw wewnątrz ich organizacji i odpowiedniego poziomu przygotowania. Jeśli mówimy o wyzwaniach, to na pewno spotykamy się z różnymi sytuacjami. Na przykład, gdy pracownicy organizacji, która zamierza wdrożyć jakieś rozwiązanie z rodziny SAP, nie są zaznajomieni z celem, jego ważnością i podstawowym kierunkiem, który to wdrożenie, czy ten projekt ma wspierać. To oczywiście leży u podłoża komunikacji. To komunikacja jest kluczem, by po podjęciu decyzji o projekcie, wdrożeniu czy dużej zmianie organizacyjnej, pracownicy byli dobrze poinformowani, jak mogą się do tego przygotować i jak powinni współpracować, żeby te wspólne cele organizacji osiągnąć. Tak jak powiedział Tomek, na początku doradzając jeszcze przed procesem sprzedażowym, czy zaraz na jego początku. W tej fazie już zaczyna się komunikacja dotycząca zmiany oraz rozmowy z klientami o tym, jak zbudować ich wewnętrzną strategię komunikacji. Tak, aby informacja dotarła do tych osób w organizacji, które potem na tym systemie, czy na tych rozwiązaniach, które będziemy wdrażać, będą osobiście pracowały.

Kogo dotyczy change management?

Hanna Dziubińska: No właśnie, bo Change Management to nie jest jedynie wyższy szczebel organizacji. Change Management przechodzi przez wszystkie szczeble w firmie, prawda?

Michał Sarna: Tak, tak. Zdecydowanie. Możemy nawiązać do definicji PMBOK-owej, która mówi, że zarządzanie projektem to jest wykorzystywanie umiejętności, wiedzy, narzędzi i różnych technik, do tego, żeby dostarczyć ludziom wartość poprzez wdrażanie jakichś rozwiązań czy uruchamianie w naszym przypadku systemów z rodziny SAP. Natomiast change management jest trochę z boku. To jest przeprowadzanie użytkowników przez cały proces zmiany po to, żeby na końcu osiągnąć zmiany w ich zachowaniu i nawykach. Czyli dokładnie to, co ty powiedziałaś – to musi przejść przez całą strukturę organizacji i dotrzeć właśnie do tych osób, które potem są użytkownikami tego systemu na co dzień, żeby to one wiedziały, jak z niego korzystać i jak się do tego przygotować.

Wyzwania change managementu: brak zaangażowania

Hanna Dziubińska: Ale wróćmy do wyzwań, bo powiedzieliśmy o tym, że pracownicy muszą wiedzieć, dlaczego coś zostaje wprowadzone. Czy jakieś inne kwestie też warto poruszyć?

Michał Sarna: Możemy powiedzieć też o sytuacji, która niestety bardzo często nas dotyka, czyli brak zaangażowanie tak zwanego średniego szczebla zarządczego. W przypadku tego typu zmian, które, tak jak Tomek wspomniał, mogą się wydarzyć raz na kilka, kilkanaście lat w organizacji, gdzie wprowadzany jest jeden duży system, jedno duże rozwiązanie, trzeba na to zwrócić szczególną uwagę. Nie możemy pracować tylko z przedstawicielem zarządu, który będzie sponsorem projektu od strony klienta, ale też pracować z osobami z organizacji, które mają bezpośrednie przełożenie na swoich podwładnych. Bo tak naprawdę brak zaangażowania, brak zrozumienia celu całego projektu, całej zmiany u tych osób będzie się przekładał na członków ich zespołu. I to nie jest stan, który będzie wspierał to wdrożenie.

Wyzwania change managementu: zabezpieczenie czasowe

Hanna Dziubińska: A ty, Tomku, z jakimi wyzwaniami zderzałeś się w firmach, z którymi pracowałeś?

Tomasz Zubrzycki: Do tego, co powiedział Michał, dodałbym jeszcze dwie kwestie, które bezpośrednio dotyczą zarządzania zmianą i zmiany w organizacji. Pierwsza kwestia to to, że ciągle jeszcze się zdarza, że pracownicy działów HR, czy też osoby, które po stronie klienta zajmują się projektem – nie mam tu na myśli PM-a od strony klienta, ale po prostu pracowników działów, w których to rozwiązanie jest wdrażane – ci pracownicy często te zadania, które są przewidziane na projekcie, mają, można powiedzieć, jako zadania dodatkowe. I przygotowanie do projektu nie uwzględnia tego, że to zaangażowanie w pewnych etapach projektu będzie bardzo duże i że wymagać to będzie odpowiedniego czasu. Powoduje to pracę po godzinach. Może to powodować frustrację, może to też powodować to, że pewne zadania, które takie osoby powinny przemyśleć, oswoić się z nimi, nie są wykonywane w pełni efektywnie tak, jak mogłyby być wykonane, gdyby te osoby miały odpowiednio zabezpieczony czas na przygotowanie i na udział w tym projekcie. No i to może potem rodzić różnego rodzaju konsekwencje dla całości projektu.

Wyzwania change managementu: stare nawyki

Tomasz Zubrzycki: A drugą kwestią, o której bym chciał wspomnieć w kontekście zarządzania zmianą jest to, że ciągle jeszcze się zdarza, może nie tak często, ale zdarza, że klienci wdrażają nowe rozwiązanie, wybrali nowe narzędzie i w tym nowym narzędziu chcą realizować stare procesy. Oczywiście, czasami coś dodatkowo automatyzując, rozbudowując, usprawniając, bo po coś to narzędzie zmieniają, ale summa summarum podejście i nastawienie do projektu jest takie: niech będzie jak wcześniej, tylko w nowym narzędziu.

Hanna Dziubińska: Taka „trochę-zmiana”.

Tomasz Zubrzycki: Taka „trochę-zmiana”, dokładnie. I to jest kardynalny błąd, jeżeli chodzi w ogóle o samo założenie, czym jest nowy projekt, w szczególności, gdy mówimy o obszarze HR-owym. Taki projekt zawsze będzie się wiązał z transformacją. Większą, mniejszą, ale to będzie transformacja. Transformacja, czyli zmiana, czyli też konieczność przygotowania się do tej zmiany, no i uświadomienie klientom tego, że należy się nastawić na to, żeby coś zmienić, usprawnić, poprawić, ułatwić. To jest ogromnym zadaniem partnera wdrożeniowego, to też jest zadaniem dostawcy rozwiązań – nie uchylam się od odpowiedzialności po naszej stronie, żeby właśnie ta świadomość była oczywista w organizacji, że ten projekt będzie niósł zmiany i nie będzie tak jak było. Ma być lepiej.

Change Manager a Project Manager – różnice

Hanna Dziubińska: Chociaż na początku też pewnie będzie trochę trudniej, prawda? Bo do tego trzeba się przygotować. Dobrze, mówiliśmy o tym, że duża odpowiedzialność leży po stronie partnera wdrożeniowego. Mówiliśmy o tym, że firma, która wdraża dane rozwiązania, nie może zrezygnować ze zmian wewnątrz organizacji, ale powinna być jakaś osoba, która tym wszystkim zarządza. I wtedy wchodzi osoba change managera, ale chyba nie zawsze, prawda? Czy część obowiązków change managera na niektórych projektach przejmuje project manager? Czym się różnią te dwie role?

Michał Sarna: To też jest bardzo fajne pytanie. No właśnie, czy change manager zawsze jest nam potrzebny? Bazując na moim doświadczeniu, powiedziałbym, że nie zawsze. Wszystko zależy od wielkości projektu i jego złożoności. Oczywiście, jeżeli rozmawiamy o takich dużych, rozległych transformacjach jak dziś, to należy się nad tą rolą bardzo mocno zastanowić. Natomiast to będzie też zależało od kultury organizacji klienta. Od tego, jak ona funkcjonowała do tej pory, jak była otwarta na zmianę, jak wyglądały poprzednie wdrożenia, jak organizacyjnie z takimi przedsięwzięciami sobie radziła do tej pory.
Natomiast wracając do pytania, czy Project Manager realizuje też te funkcje. Na pewno znajdziemy takie miejsca w projektach, gdzie ta linia pomiędzy Project Managerem a Change Managerem jest bardzo cienka czy nawet zanika i na pewno znajdziemy momenty, w których do tej pory, czy w ostatnich latach Project Managerowie wchodzili w buty Change Managera, jeszcze nie wiedząc, że cały ten trend płynie do nas wielką falą. Natomiast z mojego punktu widzenia, uważam, że te role powinny być traktowane rozdzielnie. Przede wszystkim dlatego, że wiąże się to z bardzo dużym obciążeniem czasowym i żeby je skutecznie realizować, powinny być realizowane przez dwie osoby.
Pytałaś czym to się różni. Możemy powiedzieć, że Change Manager jest od tego, żeby przeprowadzić ludzi, przygotować organizację, przygotować osoby zarządzające w tej organizacji do tego, żeby one z kolei mogły przygotowywać swoich ludzi do tego, żeby na końcu wydarzyła się, wspomniana przeze mnie, zmiana nawyków i działanie na poziomie operacyjnym, bo to jest clou całej zmiany. Tutaj mówimy o aspekcie ludzkim. Z kolei Project Manager odpowiada za dostarczenie rozwiązania, które było zamówione. Tu i teraz, w budżecie, w czasie, w zakresie. Jest odpowiedzialny za rozwiązanie, które będzie wykorzystywane w organizacji klienta. To jest techniczna strona projektu.

Change Manager i Project Manager – współpraca

Hanna Dziubińska: Czy to są osoby, które ze sobą współpracują jakoś ściśle, czy to są raczej obszary niełączne?

Michał Sarna: Na pewno punktów przenikania się jest wiele. Jak to powinno wyglądać tak książkowo w świecie idealnym, to myślę, że powinniśmy spojrzeć na strukturę dużego projektu, gdzie komórka Project Managementu funkcjonuje równolegle do komórki Organization Change Managementu, bo tak tę komórkę określa SAP w swoich metodykach. I rozdzielamy Project Managera, który razem ze wsparciem PMO pracuje nad projektem i mamy Change Managera, który pracuje równolegle, ale też może być wspierany dodatkowymi kompetencjami. Wszystko zależy od skali i podejścia, które bezpośrednio podlegają pod komitet sterujący projektu.

Metodyka SAP Activate / Cloud Mindset / analiza retrospektywna

Hanna Dziubińska: I jak ten Change Manager pracuje? Jakich metodyk używa? Jak zarządza zmianą?

Michał Sarna: Metod jest mnóstwo, powstawały przez lata. Możemy się skupić dzisiaj na kilku z nich. Na pewno one dzielą się na takie, które bardziej wspierają organizację do przygotowania się bardzo szeroko do zmiany, po takie, które bardzo mocno koncentrują się na jednostce, na człowieku w zmianie i wsparciu danego człowieka w przejściu przez tę zmianę. Myślę, że możemy zacząć od tego, co tak naprawdę dostajemy od razu od dostawcy systemów SAP wraz z metodyką SAP Activate. W niej znajdują się aktywności związane z Organizational Change Management w streamie tzw. Solution Adoption. Tam znajdziemy aktywności i każda z osób, która jest tym zainteresowana, może do tego materiału sięgnąć wertując roadmapy projektów SAP, które są dostępne online. Jeśli popatrzymy, co się tam znajduje, to jest szereg aktywności, które, jak już zostało powiedziane wcześniej, mogą być podejmowane na początku drogi, kiedy myśli się o nowym systemie. Jeżeli mówimy o rozwiązaniach cloudowych to zaczynamy od tego, żeby klient zastanowił się, czy jest gotowy na przejście na rozwiązania chmurowe. To się nazywa w metodyce Cloud Mindset, czyli zastanowienie się jak nasza organizacja reaguje na przejścia na rozwiązania chmurowe, z czym się to wiąże. Idąc dalej, trzeba pomyśleć o identyfikacji interesariuszy w projekcie, o celu, o korzyściach biznesowych, jakie mają stać za tym, jak i też podejściu do zalążków strategii komunikacji – jak to powinniśmy zakomunikować w organizacji, żeby poczucie istotności tego projektu było w organizacji wystarczająco wysokie.
Ja bym tu jeszcze dodał od siebie na tym etapie coś, co moglibyśmy nazwać analizą retrospektywną, czyli osoby zarządzające organizacją klienta zachęcałbym do tego, żeby usiadły i zastanowiły się nad tym, jak do tej pory organizacja reagowała na tego typu projekty. Czy one się kończyły sukcesem i osiągnięciem zamierzonego efektu. Jeśli nie, to co robili, co było wykonywane, jak na to reagowali ludzie, jak całościowo organizacja była na to przygotowana. Bo spojrzenie na to, co już się w danej organizacji wydarzyło, daje nam fajny punkt startu do kolejnych projektów. Czyli można już pomyśleć o tym, co wtedy nie zagrało, co zagrało, co można kontynuować, a co powinniśmy zmienić. Możemy się posiłkować cytatem Alberta Einsteina o tym, że szaleństwem jest oczekiwanie innych rezultatów, robiąc dokładnie to samo. To jest fajny punkt, który pozwala już na starcie powiedzieć: OK, to już wiemy – jeśli chcemy, żeby tym razem zadziałało, to nie róbmy tego.

Trzy cele metodyki SAP Activate

Hanna Dziubińska: Tomku, sam mówiłeś o tym, że SAP jest dostawcą rozwiązań, dostawcą produktów, a tutaj pojawia się SAP Activate metodyka, która ma sprawić, żeby te produkty i rozwiązania działały. Opowiedz więcej o tym, jak to się stało, że pojawił się taki produkt w waszym portfolio.

Tomasz Zubrzycki: Dokładnie. Tutaj już Michał fajnie scharakteryzował elementy naszej metodyki SAP Activate. Natomiast gdybym miał odpowiedzieć na pytanie, po co ta metodyka została stworzona, to generalnie wskazałbym na trzy cele. Pierwszy cel to efektywne wykorzystanie zasobów po stronie klienta w trakcie realizacji projektu. To ma umożliwić drugi cel, czyli skrócenie czasu na przeprowadzenie projektu oraz optymalizację od strony kosztów tego projektu. Trzeci cel to jest oczywiście zrealizowanie tych celów biznesowych, które zostały postawione na początku projektu w najbardziej efektywny sposób.

Zarządzanie zmianą na każdym etapie wdrożenia wg SAP Activate

Tomasz Zubrzycki: Mówiąc o metodyce SAP Activate warto zwrócić uwagę, że jest tak skonstruowana, by można ją było zastosować do dowolnego projektu, czy to HR-owego, czy z innego obszaru. Ta dowolność dotyczy także wielkości projektu. Czy to będzie małe, punktowe wdrożenie jednego modułu, obszaru, na przykład szkoleń, czy też będzie to duży, transformacyjny projekt w ramach całej globalnej organizacji. Możemy zastosować tę metodykę. Ona po prostu tak jest zbudowana, żeby się do tego nadawała.
Wcześniej Michał wspomniał, że zarządzanie zmianą dzieje się równolegle do projektu. Ja bym nawet poszedł o krok dalej: zarządzanie zmianą przy nowoczesnych projektach, w szczególności tych, które polegają na wdrożeniu rozwiązań w modelu chmurowym, jest koniecznym elementem projektu wdrożeniowego. Ta zmiana w tym przypadku zawsze będzie miała miejsce i metodyka, którą proponujemy to uwzględnia. W pierwszym etapie, który polega na planowaniu projektu określamy m.in. cele projektu, żeby wszyscy widzieli do czego zmierzamy, co chcemy osiągnąć. W oparciu o różnego rodzaju narzędzia, szablony, procedury, które ta metodyka przynosi, jest przygotowana taka rama funkcjonowania projektu, komunikacji, dokumentacji. Również w ramach tego etapu osoby po stronie klienta są zapoznawane z rozwiązaniem, żeby ta rozmowa o procesach biznesowych już bazowała na wykorzystaniu wiedzy o narzędziu, które będzie wdrażane w organizacji. Na tym pierwszym etapie pojawia się już zagadnienie zarządzania zmianą, choć co prawda tylko na poziomie założeń strategicznych.
Kolejny jest etap eksploracji, który jest klasycznym elementem projektu wdrożeniowego, gdzie mapujemy procesy organizacji na narzędzie, gdzie weryfikujemy, czy są jakieś luki funkcjonalne, zastanawiamy się, co zrobić z tymi lukami funkcjonalnymi, czy konfigurować funkcjonalności dodatkowe, które te luki wyeliminują, czy też zmienić proces i zastanowić się, jaki to będzie miało wpływ na zmianę w organizacji, jak do tego podejść. W ramach tej fazy również należy ustalić zakres danych, które będziemy migrowali, podejście do migracji, integracji z całym ekosystemem rozwiązań. Te systemy dzisiaj już nie funkcjonują jak jakieś rozwiązania wyspowe, tylko są częścią pewnego ekosystemu, który funkcjonuje w organizacji.
Trzeci etap to realizacja, podczas której konfigurujemy system i kładziemy większy nacisk na partnera wdrożeniowego. Konfigurujemy procesy, przygotowujemy różnego rodzaju mechanizmy do zaimportowania danych z systemów źródłowych. W tej fazie po stronie klienta leży ogromna odpowiedzialność, która też jest jednym z wyzwań projektowych – to jest odpowiedzialność za dokładne przetestowanie procesów. To, co się odbija niejednokrotnie czkawką na projektach, jest to, że procesy nie były dobrze przetestowane. Zarówno od strony migracji danych, jak również od strony tego, co zostało dostarczone w ramach konfiguracji systemów. Jeżeli coś nie zostanie dobrze przetestowane, to i tak to wyjdzie, tylko wyjdzie później i będzie powodowało zakłócenia.
Natomiast nawiązując do samego zarządzania zmianą, to na etapie realizacji projektu jest opracowywany – i na to ta metodyka wskazuje – plan, jak zmiana ma być wprowadzona w organizacji.
Finalny etap projektu, czyli uruchomienie rozwiązania, zakłada przeprowadzenie komunikacji w ramach organizacji, poinformowanie pracowników o tym, co ich czeka, co się zmieni, co będzie inaczej wyglądało, co będzie fajniejsze, bo oczywiście tutaj trzeba nacisk kłaść na korzyści, które osiągną menadżerowie, pracownicy, wszystkie osoby w organizacji. No i kwestie takie jak odcięcie starego systemu, uruchomienie produkcyjnego nowego – to są rzeczy oczywiste.
Jak widać, na każdym etapie tej metodyki jest położony nacisk na to, by uwzględnić aspekty związane z zarządzaniem zmianą, bo jest to nieodzowne.

Embedded Launch Activities – co to jest?

Hanna Dziubińska: Jeszcze Tomku, w przewodniku wspominałeś o narzędziu, który się nazywa Embedded Launch Activities. Co to takiego?

Tomasz Zubrzycki: Tak. Embedded Launch Activities to propozycja, którą przygotowaliśmy dla naszych klientów, pomagająca realizować projekt zgodnie z metodyką, którą proponujemy. Najprościej rzecz ujmując, ta EMLA, jak my to tak czasami w skrócie określamy, obejmuje trzy elementy. Pierwszym elementem są materiały szkoleniowe w postaci filmu wideo, które prezentują procesy biznesowe realizowane w SuccessFactorsie ze wskazaniem mocnych stron tych procesów, tłumaczące, co organizacja zyska, decydując się na taki przebieg procesu, a nie inny. To jest również możliwość skorzystania z konsultacji z ekspertami w postaci sesji pytań i odpowiedzi. To się doskonale wpisuje w pierwszą fazę projektu, gdzie klient powinien poznać narzędzie i jego możliwości, już w takim bardziej szczegółowym wymiarze niż to miało miejsce na etapie wyboru rozwiązania.
Drugim elementem tej oferty jest dostęp do systemu, dodatkowego środowiska projektowego, które jest skonfigurowane zgodnie z wiodącymi praktykami, które przychodzą wraz z systemem, bo to też bardzo ważny element i pomysł, który stoi za sposobem dostarczania rozwiązań w modelu usługowym w chmurze. A mianowicie, system czy też rozwiązanie proponuje pewnego rodzaju sposób realizacji procesów i najbardziej efektywne wykorzystanie narzędzia będzie wtedy, jeżeli organizacja te procesy zaadoptuje. W takim zakresie, w jakim oczywiście to będzie miało swoje uzasadnienie, ale jednak adopcja procesów, które oferuje rozwiązanie, to jest punkt wyjścia do modelowania tego, jak procesy powinny funkcjonować. Klient otrzymuje dodatkowe środowisko, które jest w pełni skonfigurowane z przykładowymi danymi, również ze skryptami, które obejmują scenariusze tego, jak poruszać się po środowisku. To się doskonale wpisuje w drugi etap projektu, gdzie mapujemy obecne procesy na rozwiązanie. Gdyby nie było takiego środowiska, nie dałoby się tych procesów zobaczyć i podotykać, jak one faktycznie będą wyglądały, jak będą funkcjonowały. To jest dużo trudniejsze do wyobrażenia, niż gdy po prostu klient będzie miał takie środowisko, na którym to zobaczy, przetestuje i może się upewnić – faktycznie to jest dobry kierunek, możemy wykorzystać to, co to rozwiązanie daje.
Trzecim elementem oferty jest możliwość zmniejszenia efektów tego projektu. Jak to się odbywa? Z jednej strony w ramach tej oferty są dostarczane odpowiednie ankiety, które można przeprowadzić w organizacji, które pozwalają nam zmierzyć poziom adopcji rozwiązania. Ale drugi aspekt tego zbadania efektów, który uważam, że jest bardzo ciekawy, polega na tym, że proponowane są różnego rodzaju KPI-e biznesowe, tak bym to powiedział, które na ogół są mierzone na początku projektu i po zakończeniu projektu, gdy system będzie też, kolokwialnie mówiąc, wygrzany. Gdy te procesy już zaczną funkcjonować, tak jak było to planowane, znowu mierzymy odpowiednie KPI-e i przez porównanie tego, co było na początku i na końcu, jesteśmy w stanie dojść do wymiernych efektów takiego projektu, w postaci przeliczenia tych wskaźników na pieniądz, który pokaże też organizacji, co się udało zaoszczędzić, jakie efekty stricte finansowe, twarde, mierzalne zostały osiągnięte poprzez zrealizowanie projektu.
Co ważne, opcja EMLA nie jest związana z żadnymi dodatkowymi kosztami dla naszych klientów. Po prostu, dla każdego nowego klienta, który zdecyduje się na SuccessFactors, bądź też dla dotychczasowych klientów, którzy podejmą decyzję o rozszerzeniu projektu o nowe moduły, takie środowisko zostanie udostępnione. Co więcej, to środowisko obejmuje szerokie spektrum modułów, które mamy w ramach SuccessFactors. Czyli nawet jeżeli klient zdecyduje się na jeden moduł, dostanie środowisko, które pokazuje szerszy kontekst tych procesów. Dowie się, jak one mogą wyglądać, jeżeli by się zdecydował na rozszerzenie projektu w przyszłości o kolejne elementy. To jest, można powiedzieć, funkcja edukacyjna tego programu.

Podsumowanie. Komunikacja + budowanie zespołu zmiany

Hanna Dziubińska: Świadomość rośnie, metodykę mamy, narzędzia mamy. Wygląda na to, że firmy powinny angażować się w change management, a jednak ciągle mierzymy się z wieloma wyzwaniami. Może podsumujmy i powiedzmy, o czym najczęściej zapominają firmy wdrażając projekty.

Michał Sarna: Dobrze, ja bym powiedział myślę, że o trzech rzeczach. Pierwszą jest komunikacja, na którą kładłbym naprawdę bardzo mocny nacisk. Komunikacja powinna być spójna, wypracowana, z dobrze zdefiniowaną grupą odbiorców. Żeby przechodziła przez wszystkie szczeble organizacji aż do osób, które będą konsumować efekty tej zmiany, czyli będą pracować na nowym systemie. To jest jedna rzecz.
Druga rzecz wynika z metodyki Johna Kottera i jego ośmiu kroków. Zachęcałbym do budowania zespołu zmiany, czyli jeszcze przed projektem, zanurzyć się bardziej w wodach change managementu, zbudować zespół, który będzie tę zmianę wspierał. Powinny być w tym zespole osoby, które będą charakteryzować się różnymi cechami, różnymi talentami, różnymi umiejętnościami. Możemy tam wskazać wspomnianego przeze mnie wcześniej sponsora zmiany wewnętrznego, który powinien mieć formalny wpływ na całą organizację. Powinniśmy mieć osobę, która ma wpływ bardziej nieformalny – jest w organizacji długo, ma szerokie spektrum wpływu na ludzi. Powinniśmy mieć osoby, które mają wiedzę techniczną. Powinniśmy mieć osoby, które będą wspierać komunikację. I warto też zwrócić uwagę na to, żeby do tego zespołu angażować przedstawicieli grupy tak zwanej „nie-nie”, czyli osób, które nie będą aktywnie wspierały wdrożenia z różnych przyczyn. W każdej organizacji znajdziemy takie osoby. I ta akurat metodyka wskazywana przez Johna Kottera mówi o tym – słuchajcie, nie róbcie tego błędu, nie omijajcie tej grupy, spróbujcie do takiego zespołu zmiany zaangażować kogoś, kto jest przeciwny. Jak będzie ta osoba podróżowała przez tę zmianę w zespole, to uzyskacie dzięki temu przynajmniej dwie korzyści: szansę, że ta osoba wchłonie zmianę będąc współtwórcą tego co się dzieje i zaangażuje się oraz wpływ na to, co osoba komunikuje w innych częściach organizacji.
I ostatnia sprawa. Pamiętajmy, że change manager, który pojawia się w organizacji, czy przy projekcie, czy to ze strony dostawcy, czy jest osobą zatrudnioną z zewnątrz – on wszystkiego sam, jednoosobowo nie zrobi. To nie jest człowiek, który ma magiczną różdżkę, którą pomacha i wszystkie nasze bolączki, które sobie tutaj z Tomkiem wymieniliśmy, magicznie rozpłyną się po organizacji. Na pewno jest tak, że osoba w tej roli, angażując się i wspierając przedmiot zmiany, będzie powodowała, że ta adopcja, ta zmiana w organizacji będzie skuteczniejsza, będzie bardziej efektywna i będzie przynosiła oczekiwane rezultaty na koniec.

Gotowość na nowoczesny HR / decyzyjność działu HR

Hanna Dziubińska: To domknijmy klamrę i wróćmy z powrotem do SAP SuccessFactors, bo rozwiązania HXM z portfolio SAP-a wspierają nowoczesny HR. Czy z doświadczenia SAP-owego wynika, że organizacje są gotowe na ten nowoczesny HR?

Tomasz Zubrzycki: Powiedzieć, że są gotowe, to według mnie, jak nic nie powiedzieć. One bardzo potrzebują i chcą tych zmian. Widzę, że jest duża potrzeba po stronie HR, żeby realizować takie projekty. HR–y są gotowe, są otwarte, są bardzo chętne, żeby tego typu projekty przeprowadzać. Jest też bardzo duża świadomość po stronie organizacji. Firmy wiedzą, co chciałyby usprawnić, jakie chciałyby uzyskać efekty. To, gdzie trzeba wspomóc organizację, co jest zupełnie naturalne, to pokazanie narzędzi czy też sposobów, jak uzyskać efekty, które są planowane czy oczekiwane. Natomiast od strony zarówno gotowości, jak i chęci, uważam, że wygląda to wręcz modelowo, patrząc w szczególności na polski rynek.
Patrząc na Polskę versus inne kraje, kraje zachodnie, niestety ciągle jeszcze dosyć często zdarza się, że dział HR nie jest umocowany w strukturach organizacyjnych na poziomie, który by dawał odpowiednią decyzyjność, jeżeli chodzi o realizację projektów i forsowanie strategii oraz pomysłów z obszaru HR. W świecie zachodnim pełnienie przez szefa HR-u, dyrektora ds. personalnych również roli członka zarządu jest coraz bardziej powszechnym zjawiskiem. U nas trend jest też w tym kierunku, coraz częściej, na szczęście, takie sytuacje widzę. Natomiast ciągle jeszcze zdarza się, że ten HR nie ma takiej, można powiedzieć, mocy w ramach organizacji. To oczywiście później komplikuje przeprowadzenie takiego projektu. Bo kolejnym wyzwaniem w projekcie HR-owym jest jego odpowiednie sprzedanie zarządowi i decydentom. Czyli przełożenie projektu na twarde wyliczenie, co zyskamy, gdzie będą oszczędności, jak od strony czysto ekonomicznej ten projekt nam pomoże w organizacji.
Jako SAP wychodzimy naprzeciw tym potrzebom. Mamy, w ramach propozycji dla klientów, wsparcie przy budowaniu biznes case'ów i przy przygotowywaniu takiego konkretnego uzasadnienia, bazującego na twardych wyliczeniach, na wskaźnikach, na różnego rodzaju pomiarach oczekiwanych oraz możliwych do osiągnięcia efektów z realizacji danego projektu. Dzięki temu HR może mówić językiem finansów i bronić tych projektów.

Hanna Dziubińska: Ja oczywiście nie chciałabym zakończyć bolączką, więc ja ze swojej strony życzę w takim razie nowoczesnego HR-u zarówno organizacjom, jak i pracownikom, którzy w tych organizacjach będą pracować.

Tomasz Zubrzycki: Żeby nie kończyć bolączką, to wspomnę jeszcze o jednej rzeczy, która jest dla mnie uderzająca. Coraz częściej widzę, że polskie oddziały, nawet tych dużych grup międzynarodowych, są coraz prężniejsze, jeżeli chodzi o promowanie, realizowanie projektów, wdrożenia rozwiązań w obszarze HR-owym. Coraz częściej widzę, że nawet programy pilotażowe w ramach całej grupy obejmują Polskę. Polskie organizacje chcą uczestniczyć w takich projektach, same takie projekty zgłaszają. Odwagi i chęci naszym firmom nie brakuje. To na pewno.

Hanna Dziubińska: Trzymamy kciuki za dalszy rozwój. Dziękuję bardzo za rozmowę.