Negocjacje w projektach wdrożeniowych systemów ERP
Negocjacje w projekcie ERP to moment, w którym teoria spotyka się z praktyką. To czas ustaleń, które zdecydują, czy wdrożenie systemu ERP przebiegnie sprawnie, czy stanie się źródłem niepotrzebnych napięć. To etap, w którym na stole pojawiają się nie tylko zapisy umowne, ale także intencje, oczekiwania i mechanizmy współpracy. Dobrze poprowadzone negocjacje ERP pozwalają uniknąć wielu kosztownych błędów i budują zaufanie między partnerami.
Posłuchaj odcinka: kliknij tutaj.
Przeczytaj artykuł: kliknij tutaj.
„Czyli żeby obie strony traktowały to jako praktykę życia codziennego i nauczyły się, że raportowanie postępów, zagrożeń czy problemów nie jest atakiem jednej strony na drugą, tylko przedstawianiem stanu faktycznego projektu.”
Witam, witam! Dzień dobry, dzień dobry. Dzisiejszy odcinek dotyczyć będzie kwestii negocjacji, czy też – jak ja wolę to nazywać – uzgodnień, i będzie się koncentrował na procesie, w ramach którego strony, będące już po wyborze, uzgadniały zasady realizacji tego przedsięwzięcia.
Na początek – uzgodnienia w projekcie ERP
Podstawy współpracy po wyborze systemu ERP
Kolejnym naturalnym etapem w procesie uruchomienia projektu są uzgodnienia, które prowadzą strony, czyli dostawca usługi, dostawca produktu i klient, który planuje wystartować projekt. Ten etap jest stosunkowo prosty, jeżeli przyjmiemy założenie, że obie strony działają w dobrej wierze, a nie próbują, jakby to ładnie powiedzieć, rozegrać drugą stronę.
Więc jeżeli cel jest taki, żeby znaleźć platformę porozumienia i uzgodnić warunki fair, warunki współpracy, to ten etap nie budzi przeważnie zbyt wielkich emocji czy zbyt wielkich kontrowersji. Jeśli te kontrowersje się pojawiają, to znaczy, że coś jest nie tak w uzgodnieniach. Natomiast tak czy inaczej, warto zwrócić uwagę na kilka punktów. Nie będzie ich za dużo, ale zacznijmy od pierwszego.
Zrozumienie intencji stron – bez tego się nie uda
Moim sposobem na prowadzenie tego typu uzgodnień było zawsze wychodzenie nie od zapisów umownych, nie od formułek, tylko w przypadku jakichkolwiek rozbieżności dochodziliśmy do tego, żeby obie strony w sposób jak najbardziej otwarty, w sposób jak najbardziej naturalny przedstawiły swoje intencje. Co chcą uzyskać forsując czy proponując dany zapis, dany paragraf, dany punkt, daną wartość?
Jeśli strona zamawiająca bardzo naciska na kwestie związane z nieujawnianiem danych, no to warto jest zrozumieć, z czego taki lęk wynika, warto jest zrozumieć, o co tak naprawdę chodzi. Być może jest pewna grupa danych, która jest szczególnie czuła, być może jest to złe doświadczenie z przeszłości. Nie ma co wymyślać przyczyn, natomiast w przypadku pojawienia się takich rozbieżności warto jest zrozumieć intencje obu stron – do czego dążą?
I jeśli te intencje na poziomie intencji uzgodnimy, że tak, obie strony chcą pójść w uzgodnienie mówiące o niemożliwości podejmowania takich czy innych działań, lub też, że termin z jakiegoś powodu jest bardzo, bardzo ważny, żeby był to 1 września albo 1 października, albo że bardzo czułym punktem w tym kontrakcie będzie nie podkupowanie pracowników, to jak obie strony rozumieją dlaczego tak jest, po co tak jest, to potem prościej jest zapisać to w formułkach prawnych.
Natomiast wychodzenie od formułek prawnych bardzo często prowadzi do długotrwałych dyskusji, w których nie bardzo wiemy, co jest celem ćwiczenia.
Zabezpieczenie możliwości wprowadzania zmian we wdrożeniu ERP
Procedury i budżet na zmiany w trakcie projektu
Druga kwestia jest taka, że niezależnie od tego, jak bardzo dobrze jesteśmy przygotowani, jak bardzo dobrze mamy przemyślane nasze potrzeby i oczekiwania, to od samego początku warto jest zabezpieczyć się pod kątem możliwości prowadzenia zmian w trakcie prac projektowych.
Czyli już pierwotny kontrakt powinien zawierać jakąś pulę środków i czasu przeznaczonych na potencjalne modyfikacje, jak też bardzo dobrze jest, jeżeli od samego początku będziemy mieli określone mechanizmy i procedury wprowadzania takich zmian. Bo też te zmiany, nawet jak bardzo rozsądne, potrzebne, logiczne by były, nie mogą być wprowadzane zawsze. Powinniśmy określić sobie procedury ich wprowadzenia, ale też moment, w którym zamrażamy zakres, zamrażamy to, co ma być wynikiem prac wdrożeniowych i realizujemy ze świadomością, że być może jednej, drugiej czy trzeciej funkcjonalności na moment startu produkcyjnego nie będziemy mieli, ale będzie to świadoma decyzja. I gdzieś też z boku przygotowana została procedura, jak sobie radzić z systemem w sytuacji braku tych funkcjonalności.
One zostaną dostarczane po dwóch miesiącach, trzech, a może czterech, w uzgodnionym terminie, i wtedy system już będzie uzupełniony o nie. Natomiast, tak jak mówię, niezależnie od tego, jak bardzo rozsądne, logiczne i przydatne one są, nie można sobie pozwolić na to, żeby były zgłaszane zmiany do ostatniego momentu przed testami, ponieważ te elementy będą stanowiły część całego systemu.
Należy je udokumentować, przygotować, wydewelopować, wytestować, zintegrować. Czasami jest tak, że czekamy z projektem, w który włożyliśmy 2000 dni pracy, dlatego że jest zmiana na 20 dni pracy i ona wydłuża całość przedsięwzięcia o kolejne dni, miesiące czy tygodnie. Więc tego proponowałbym unikać i już na poziomie umowy powiedzieć sobie: tak, będziemy wprowadzać zmiany, tak, będziemy je robić w taki sposób, i ostatnim momentem, w którym te zmiany mogą być wprowadzone, jest moment albo data (tutaj pada), albo jakiś kamień milowy w pracach projektowych.
Mechanizmy motywacyjne w projekcie wdrożeniowym
Karać czy nagradzać?
Kolejnym elementem, który bardzo rzadko występuje, a jest przydatny, to jest przygotowanie obustronnego mechanizmu, który byłby czymś motywującym dla zespołu wdrożeniowego po stronie klienta, żeby dotrzymanie terminów uzgodnionych w projekcie było też celem zespołu projektowego wdrożeniowego po stronie klienta.
Jeśli chodzi o motywowanie dostawcy, to przeważnie jest jeden mechanizm – kara za opóźnienie. To też można by się zastanowić, czy nie warto byłoby przewidzieć nagrody za czasowe zrealizowanie prac projektowych, no ale to już jest tak rzadki przypadek, że nie rozważajmy go. Natomiast kilkukrotnie zdarzyło mi się brać udział w projektach, w których kierownictwo, zarząd czy jakaś inna struktura zarządcza przeznaczyła dodatkowe środki na to, aby motywować zespół wewnętrzny.
Przy czym to, co jest istotne, to środki te nie były przeznaczane do opłaty nadgodzin czy dodatkowego wysiłku – to mogło być realizowane zupełnie innymi mechanizmami. Natomiast została przygotowana wprost premia dla zespołu, dla wybranych członków lub dla całego zespołu za to, że prace projektowe zostaną zakończone w uzgodnionych terminach. Jest to czynnik motywujący dla osób, które poza swoją codzienną pracą mają jeszcze zadania dodatkowe, projektowe, i pokazuje to, jak ważny, jaki priorytet dla tych prac został określony po stronie zarządu. Jest to bardzo silny motywator, bardzo dobre wsparcie, no i też tak po ludzku, po prostu ci ludzie za swoją dodatkową pracę i za wspólny sukces zostają nagrodzeni, więc jest to też miłe.
Dlaczego nie wszystkie oczekiwania warto wpisywać do umowy?
Ostatnim punktem, o którym już wcześniej opowiadałem, ale zawsze warto to wspomnieć, to jest unikanie – w szczególności w umowie, ale też we współpracy – formułowania nierealistycznych oczekiwań czy uzgodnień. Wrócę do przykładu, który już omawialiśmy. Nie ma sensu wymagać, żeby system był zgodny z prawem niezależnie od tego, kiedy zmiany w prawie zostaną wprowadzone.
No i jeśli system jest przygotowany i mamy uruchomić go 1 stycznia, a 31 grudnia prawodawca zmieni przepisy prawne w bezsensowny sposób, nie dając szansy na dostosowanie się podmiotom funkcjonującym na rynku, oczekiwanie od dostawcy, że on między 11:59 a godziną 00:01 wprowadzi dostosowanie i wymuszanie to na niego przy pomocy kar, jest po prostu nieracjonalne, nierozsądne.
Podnosi to koszty, no bo dostawca musi się zabezpieczyć, de facto biorąc pod uwagę, że będzie zmuszony zapłacić karę za niewystosowanie systemu czy za opóźnienie. Musi brać to pod uwagę, nawet jeżeli taki przypadek nie zaistnieje. A co więcej, taka kara nie zmotywuje go do tego, żeby on tę funkcjonalność dostarczył, tylko zmusi go do tego, żeby zapłacił za to karę. To jest po prostu nie do zrealizowania.
Jest jeszcze kilka innych tego typu przypadków, gdzie zapis od samego początku widać, że oczekiwanie jest nieracjonalne, nierealistyczne i po stronie dostawcy jest to tylko motywacja do tego, żeby zwiększyć cenę i niejako uwzględnić w cenie oferty to, że nie da się tego zrealizować, że trzeba będzie ponieść karę, że trzeba będzie tą karę zapłacić i należy to jako element kosztotwórczy włożyć do wyliczenia wartości ceny oferty.
Negocjacje ERP a raportowanie postępów
Neutralne mechanizmy monitorowania projektu ERP
W kwestii negocjacji warto jeszcze pamiętać o dwóch pomysłach, które przynajmniej w moim wypadku sprawdziły się w praktyce. Pierwszy z nich dotyczy takiego już od początku uzgodnionego i wprowadzonego w życie modelu czy też metody raportowania postępu pracy, ryzyk, niepowodzeń.
Jest to banalne stwierdzenie, natomiast chodzi mi o to, żeby wprowadzone mechanizmy były traktowane jako takie trochę, jakby to powiedzieć, mechanizmy odhumanizowane, czyli żeby obie strony traktowały to jako praktykę życia codziennego. I nauczyły się, że raportowanie postępów, zagrożeń czy problemów nie jest atakiem jednej strony na drugą, tylko przedstawianiem stanu faktycznego projektu.
Jak raportować ryzyka bez eskalacji emocji?
Bardzo dobrze mi się sprawdzały takie podejścia, w których raportowanie, statusowanie zagadnień odbywało się od pierwszego dnia projektu, kiedy jeszcze ani jedna, ani druga strona nie miała szansy w niczym się pomylić i zapomnieć się albo spóźnić, i wtedy ten mechanizm raportowania statusów, raportowania stanu projektu czy też zagrożeń zidentyfikowanych traktowany był bardzo neutralnie.
I potem oba zespoły weszły w to, przyzwyczaiły się do tego, że takie raporty powstają, że takie raporty są przedstawiane do kierownictwa. Nikogo to nie dziwiło. Jeżeli zaczynamy raportować statusy w momencie, kiedy mamy tydzień, miesiąc lub trzy tygodnie opóźnienia, albo raportujemy zagrożenia, jak któraś ze stron nie dostarczyła drugiej stronie dokumentów lub też materiałów, no to zawsze ma to zabarwienie takie trochę „donosu” i jest to związane z emocjami.
Nie mamy do czynienia z takim stanem w organizacjach, które bardzo często prowadzą projekty, mają ich dużo, mają doświadczenie w tym zakresie. Tych emocji tam nie ma. Problemy, opóźnienia są standardem projektów, nikogo to nie dziwi, nikt nie czuje się zaatakowany, jeśli ktoś stwierdził, że nie dostarczył na czas czy pełnego zestawu danych, czy że te dane były źle opisane, lub też scenariusze testowe nie w pełni odpowiadały oczekiwaniom. Obie strony rozumieją, że jest to ciężki, skomplikowany proces i że potknięcia się będą zdarzały.
Natomiast zadbanie o to, żeby unikać takiej sytuacji, gdzie jedna lub druga strona boi się lub też nie w pełni poprawnie przedstawia dane faktyczne, to jest bardzo istotne zagadnienie, ponieważ łatwiej jest zarządzać nawet opóźnionym projektem, ale jak wiemy gdzie i z jakiego powodu te opóźnienia są, niż zarządzać projektem, w którym na pierwszy rzut oka wydaje się, że jest wszystko dobrze, a tak naprawdę mamy niedociągnięte dwa czy trzy wątki krytyczne, które gdzieś tam ktoś ukrył przed kierownictwem.
Także wniosek jest taki: wypracujmy w trakcie negocjacji praktyczne metody raportowania ryzyk, postępów, niepowodzeń. Nauczmy się wspólnie, że to jest neutralna informacja, która służy temu, żeby wypracować sposoby naprawy tych błędów, tych niedociągnięć, a nie sposób wykrywania winnego. I będzie to nam skutkowało pozytywnymi efektami już w trakcie prac wdrożeniowych.
Przegląd powdrożeniowy – druga szansa na sukces
Dlaczego część potrzeb warto odłożyć na etap po starcie systemu ERP?
Warto jest też już na etapie negocjacji założyć, a co więcej, uzgodnić zasady realizacji takiego przeglądu powdrożeniowego już po wdrożeniu. Na czym to polega? Chodzi mi o to, że mamy, startując pracę projektową, mamy pewien zakres, mamy pewien harmonogram, mamy pewną przybliżoną wiedzę wynikającą z wstępnej analizy, czym powinien być ten system, który wspólnie budujemy. Natomiast w trakcie prac projektowych zawsze, zawsze wychodzą nowe pomysły, zawsze wychodzą nowe potrzeby.
Okazuje się, że któryś z użytkowników o czymś zapomniał, albo któryś z konsultantów źle coś zrozumiał. I teraz, jeżeli od samego początku założymy sobie takie podejście, w którym mówimy: dobrze, musimy uruchomić rozsądne minimum funkcjonalne na go-live, a potem damy sobie jeszcze szansę, żeby dobudować te rzeczy, które pojawiły nam się jako pomysły w trakcie prac projektowych, ale nie są krytyczne, to zwiększa nam to szanse tego, że dotrzymamy terminu uruchomienia, że system, który będziemy uruchamiać, nie będzie przekomplikowany i że będziemy mogli spokojnie, bez emocji, zgodzić się wspólnie na przeniesienie części funkcjonalności i ich uruchomienia już po pierwotnym starcie projektu.
Wtedy mamy to zadanie zaharmonogramowane, zabudżetowane, uzgodnione podejście do jego realizacji, pomaga nam to w spokojnym podejściu wdrożeniowym.
Post-implementation review, czyli co?
W jednej z metod, z której miałem szansę korzystać w trakcie moich tutaj doświadczeń, była wprost nazywana taka faza, która się nazywała post-implementation review, czyli przegląd powdrożeniowy, i on z założenia występował po stabilizacji, czyli uruchomienie przysłowiowego 1 stycznia, 3 miesiące, 4 miesiące, 5 miesięcy stabilizacji, po stabilizacji przegląd powdrożeniowy.
Dodatkową korzyścią z takiego podejścia było to, że po 6, 7, 8 miesiącach użytkowania systemu użytkownicy nabierali już biegłości w jego użytkowaniu. I wtedy coś, co wydawało się być nieergonomiczne, inne niż w poprzednim systemie, które wydawało się dziwne, poprzez nabycie doświadczenia, poprzez nabycie praktyki, okazywało się, że jednak nie trzeba tego zmieniać, bo ludzie się do tego przyzwyczaili, wręcz dostrzegli jakieś zalety takiego, a nie innego sposobu realizacji pewnych funkcji.
Więc nie dość, że odkładaliśmy sobie część modyfikacji, część uruchomienia na po starcie produkcyjnym tym głównym, dzięki czemu łatwiej było nam się skupić na wybranych obszarach, tych najważniejszych, co więcej – część z potrzeb, część z oczekiwań okazywało się niekrytyczne i nie musiało w ogóle być realizowane. Dzięki czemu zarówno mniej pracy było do włożenia, jak i mniej modyfikacji było realizowane, i dzięki temu system wytworzony, system uruchomiony był bliższy standardowi.
Podsumowanie – świadome negocjacje to fundament udanego wdrożenia ERP
Jeśli chodzi o kwestie negocjacji, to chyba tyle. Jeśli byście mieli Państwo, byście chcieli pogłębić którąś z poruszonych tutaj tez, sugestii czy pomysłów, albo mieli jakiekolwiek pytania, to w opisie odcinka jest adres. Bardzo proszę o kontakt. Z przyjemnością odpowiem na wszelkie sugestie, kontakty.
Dzięki!
Co dalej?
W następnym odcinku porozmawiamy o jednym z kluczowych etapów każdego przedsięwzięcia, czyli realizacji wdrożenia. To właśnie na tym etapie teoria spotyka się z praktyką, a dobrze przygotowany plan musi przejść próbę działania w rzeczywistości. Podpowiemy, na co zwrócić szczególną uwagę, o czym warto pamiętać, by wdrożenie przebiegło sprawnie, bez niepotrzebnych komplikacji i z jak najlepszym efektem końcowym.
Nowe odcinki publikujemy w pierwszy wtorek miesiąca. Tydzień później na naszej stronie pojawia się artykuł z podsumowaniem treści oraz kluczowymi punktami poruszonymi w podcaście. Link do naszego bloga znajdziecie w opisie tego odcinka. Znajdziecie tam także adres e-mail, pod którym możecie się z nami skontaktować.
Jeśli macie jakieś pytania lub sugestie, dajcie nam znać. Do usłyszenia w kolejnym odcinku.
>