Projekt wdrożenia vs. rzeczywistość
Wróci też inny temat z projektu, tj. przedstawienie procesu podczas rozmów projektowych, a codzienna rzeczywistość. Wykonawca „schodzi” ze szkoleniami do każdej osoby, która ma używać systemu i wówczas słyszy od nich – „ale ja w ten sposób nie pracuję”, „tak się nie da tego obsłużyć”. Wtedy otwieramy projekt, czytamy go wspólnie i pracownik stawia zarzut, że ten kto to przedstawił nie wie jak ten proces naprawdę wygląda. Co więcej, w większości taka osoba ma rację i wtedy pojawia się duży problem. Co teraz można zrobić? Rozwiązań jest kilka:
- Można szybko przemodelować proces – jeśli jest to możliwe.
- Można zatrzymać cały projekt w oczekiwaniu na gotowe rozwiązanie.
- Można pominąć tego pracownika i iść dalej z wdrożeniem, czekając na rozwiązanie dla niego.
To tylko kilka opcji. Jest ich oczywiście więcej. To, że system zaczyna być widoczny w coraz większym zakresie w firmie sprawia, że u klienta „życie” zaczyna się wokół tego programu toczyć. Pojawiają się rozmowy w kuluarach, czasem otwarte zarzuty, że tutaj mieliśmy tak „fajnie”, tak łatwo, a teraz będziemy musieli pracować dwa razy dłużej. To jest też rola dla koordynatora po stronie klienta. Oprócz zadań typowo organizacyjnych spoczywa na nim obowiązek dbania o atmosferę wdrożenia. I tutaj przytoczę kolejny przypadek z życia.
Pierwsze szkolenie u klienta z obiegu dokumentów, ogólnej pracy na systemie, zasad poruszania się po programie. Po szkoleniu pytań brak. Wszyscy są optymistycznie nastawieni do zmian. Na kolejnym spotkaniu szkolenie rozpoczyna się od awantury, że pracownicy nie będą na nowym systemie pracować, że on się nie nadaje i że „jak chcą, niech mnie zwolnią”. Wykonawca nie ma pojęcia o co chodzi, nie było pytań, wszystko poszło sprawnie, a teraz awantura. Okazało się, że jeden z pracowników mylnie zrozumiał informacje z wcześniejszego szkolenia. W tej swojej mylności był tak przekonujący, że wszyscy uwierzyli mu w jego błędny tok myślenia.
Między jednym spotkaniem a drugim narosła atmosfera braku zrozumienia i zaufania, która przelała się na kolejne spotkania. To jest właśnie rola koordynatora, który powinien takie przypadki uspokajać. Pozwoli to uniknąć niepotrzebnych sytuacji.
Jak już jesteśmy przy pracownikach to podam kolejny ciekawy przykład. W pewnej firmie pracownicy bardzo sceptycznie podchodzili do szkoleń. Mimo, że system spełniał wszystkie ich oczekiwania, wyczuć można było atmosferę złości, że mają kolejne szkolenie i trzeba będzie znowu wystawiać te same dokumenty. Po kilku podobnych, męczących obie strony szkoleniach, zorganizowano spotkanie koordynatorów. Po tygodniu wracamy do szkolenia i podejście pracowników zmienia się o 180 stopni. Co się stało między jednym a drugim spotkaniem? Okazało się, że pracownicy mieli przychodzić na szkolenia godzinę przed, lub godzinę po swojej pracy. Byli zmęczeni, ale oprócz tego, że przyswajali nowe informacje, nie byli za ten czas wynagradzani. Działanie koordynatora sprawiło, że zaczęli być wynagradzani za ten dodatkowy czas szkolenia i wręcz prosili się o kolejne spotkania. W bazie testowej pojawiało się mnóstwo nowych dokumentów. Tutaj wielki szacunek dla koordynatora projektu po stronie klienta. Jego postawa sprawiła, że załatwione zostały 3 bardzo ważne sprawy:
- pracownicy zaczęli się angażować we wdrożenie
- wyczyściła się zła atmosfera wokół wdrożenia
- pracownicy zyskali dodatkowe benefity za swoją prace
Jaki był finał tej historii. Tych 8 pracowników było najlepiej przygotowanymi pracownikami z moich dotychczasowych wdrożeń. Podczas uruchomienia potrafili w pełni obsługiwać procesy, które ich dotyczą, a dodatkowo służyli wiedzą innym pracownikom, którzy w mniejszym stopniu przyswoili wiedzę ze szkoleń.
Ktoś mógłby stwierdzić, że to dodatkowy koszt dla klienta, czasem niemały – może i tak. Ale ten dodatkowy koszt przełożył się na sprawniejszą obsługę nowego systemu od momentu uruchomienia. Nie było tutaj przestoju, klienci firmy nie zauważyli zmiany systemu, więc nie było żadnego spadku wydajności w obsłudze kontrahentów. To dla firmy, która jak w tym przypadku opiera się na obsłudze klientów detalicznych, jest niezmiernie ważne. Koszty te, w mojej ocenie zrównoważyły się, a dzięki takiej decyzji wdrożenie odbywało się w zupełnie innej atmosferze i zaangażowaniu obu stron.
Szkolenia to bezwzględnie najważniejszy etap procesu wdrożenia. Teoretycznie obowiązuje tutaj zasada – im więcej tym lepiej, bo praktyki nigdy za wiele. Jednak same w sobie szkolenia nic nie dadzą, bez odpowiednich ćwiczeń. Dobrą praktyką jest zostawianie „pracy domowej” przez wykonawców wdrożenia.
Każdy operator pomiędzy szkoleniami ma do wykonania jasno określane zadania. Koordynator wdrożenia odpowiada za realizacje tych zadań i każde kolejne spotkanie rozpoczyna się od relacji z wykonanych prac. Jeśli nawet taka praca domowa nie jest możliwa do realizacji, to warto samemu, nawet z ciekawości zalogować się, „poklikać”, poczuć co w tym nowym systemie siedzi.
Zasada, która trzyma się w całym procesie wdrożenia jest jedna – wspólna praca i wspólny wysiłek. Odpowiedzialność za sukces jest taka sama po obu stronach. To nie tak, że jeśli nie będę miał trzech szkoleń, tylko dwa to nie będę musiał pracować na nowym systemie. Będę musiał, tylko że będę wiedział mniej. Im więcej wyniosę ze szkoleń, tym lepiej dla mnie. Im więcej zrobię notatek, przeczytam instrukcji, wykonam ćwiczeń, tym lepiej będę przygotowany na uruchomienie.
Musi tutaj występować świadomość u klienta, że wdrożenie nie trwa tylko wtedy, gdy w naszej firmie są przedstawiciele wykonawcy. Wdrożenie trwa również w czasie, gdy wykonawca realizuje prace zdalne, konfiguracyjne. Dobrze by było, żeby właśnie w tym czasie pracownicy próbowali zrealizować swój proces. Wystawić kilka dokumentów, czy zwyczajnie przejść przez okna, które ich dotyczą, żeby „obyć” się z systemem, czy też spisać uwagi – jeśli wystąpią.
