Wdrożenie nowego systemu wśród pracowników: praktyczny plan

System, z którego nikt nie korzysta, to nie projekt zrealizowany w połowie: to pełny koszt, powiększony o drugi system do utrzymania, ponieważ stara metoda nadal działa równolegle. Moment, w którym decyduje się, czy tak się stanie, to nie dzień wdrożenia. To poprzedzające go tygodnie, kiedy osoby, które będą musiały z systemu korzystać, albo są wysłuchane, albo nie są.

Przyjęcie systemu nie jest kwestią dobrej woli pracowników. Jest kwestią tego, w jakim stopniu nowy system pomaga lub przeszkadza w pracy każdej osoby w momencie, gdy ją wykonuje. Kto znajdzie szybszy skrót poza systemem, ten z niego skorzysta, i będzie miał rację.

Kogo zaangażować, gdy wciąż można jeszcze zmienić zdanie

Zaangażowanie nie oznacza zwołania spotkania prezentującego już podjęte decyzje. Oznacza zaproszenie do rozmowy, podczas mapowania procesów, osób, które znają przypadki nieznane nikomu innemu.

• Osobę wykonującą najczęstszą operację, tę powtarzaną dziesiątki razy dziennie: to ona płaci za każde dodatkowe kliknięcie.
• Osobę zajmującą się wyjątkami, czyli tę, do której wszyscy zwracają się, gdy przypadek jest nietypowy. Zwykle nie jest to kierownik.
• Osobę, która odbiera pracę na dalszym etapie i ponosi konsekwencje błędów popełnionych wcześniej.
• Osobę, która rozmawia z klientami, ponieważ wie, jakich informacji się od nich żąda i w którym momencie.

Proces opisany przez kierownictwo jest tym przewidzianym. Ten faktycznie wykonywany zawiera odstępstwa, skróty i szczególne przypadki, które ktoś od lat rozwiązuje z pamięci. Różnica między nimi jest miarą ryzyka projektu.

Szkolić z zadań, nie z funkcji

Najbardziej rozpowszechnioną formą szkolenia jest oprowadzanie po menu: system pokazuje się wszystkim razem, ekran po ekranie. To format, który zapomina się najszybciej, ponieważ nikt z obecnych nie uczy się swojej pracy, lecz pracy wszystkich naraz.

Przydatne szkolenie wychodzi od rzeczywistych zadań każdej roli i wykorzystuje prawdziwe, a przynajmniej realistyczne dane. Trzeba je przeprowadzić blisko momentu, w którym zacznie się korzystać z systemu: jeśli między szkoleniem a wdrożeniem mijają trzy tygodnie, należy je powtórzyć.

Zamknąć stare narzędzia, a nie utrzymywać je równolegle

Dopóki stary arkusz kalkulacyjny pozostaje dostępny i wygodny, część osób nadal będzie z niego korzystać. Nie z powodu oporu wobec zmiany: ponieważ działa, znają go i w danym momencie się spieszą.

1. Ustalić datę, po której stare narzędzie staje się dostępne wyłącznie do odczytu, i tej daty dotrzymać.
2. Przenieść do nowego systemu tylko te dane historyczne, które są naprawdę potrzebne do codziennej pracy, a nie całe archiwum: reszta pozostaje dostępna gdzie indziej.
3. Usunąć skróty pozwalające działać jak dawniej, na przykład wciąż krążące papierowe formularze.
4. Zastępować, a nie dokładać: jeśli nowy system wymaga dodatkowej danej, nie usuwając żadnej innej, przyjęcie systemu wprost konkuruje z czasem pracowników.

Podwójne wprowadzanie danych „dla bezpieczeństwa” musi zostać jasno ustalone, z podanym czasem trwania i datą zakończenia. Jeśli pozostaje nieokreślone, staje się stałe, a wtedy nowy system jest postrzegany jako dodatkowa praca — czym w rzeczywistości się stał.

Gdzie zgłaszać wątpliwości

Jeśli odpowiedź na wątpliwość zależy od tego, kto akurat jest dostępny, ludzie przestają pytać i znów zaczynają improwizować. Potrzebna jest jedna, znana wszystkim ścieżka.

• Osoba kontaktowa dla każdego działu, wybrana spośród uczestników mapowania procesów, z realnie przydzielonym na to czasem.
• Jedno jedyne miejsce, do którego zgłasza się problemy: nie korytarze, nie prywatne wiadomości do konsultanta, nie e-maile do różnych osób.
• Jasno ustalona zasada, co robić, gdy system nie pozwala na wykonanie pilnej operacji: do kogo dzwonić, co zapisać, jak to później uporządkować.
• Oczekiwany czas odpowiedzi, nawet szeroko określony, byle znany: świadomość, że odpowiedź przyjdzie jutro, jest lepsza niż jej brak.

Rejestr problemów i co z nim robić

Rejestr jest przydatny tylko wtedy, gdy ktoś regularnie go przegląda. Przydatnych pól jest niewiele: kto, kiedy, co robił, czego oczekiwał, co się stało, jak sobie w międzyczasie poradził.

Przy cotygodniowym przeglądzie każdy wpis trafia do jednej z trzech kategorii: usterka systemu, którą się poprawia; brakująca wiedza, którą się ponownie wyjaśnia, ewentualnie wszystkim, jeśli się powtarza; nieprzewidziany proces, który wymaga decyzji firmy, a nie dostawcy. Pomylenie trzeciej kategorii z pierwszą to najszybszy sposób na to, by lista zmian stała się nieskończona.

Mierzyć przyjęcie systemu: ukończone działania, a nie logowania

Logowania mówią, że ludzie wchodzą do systemu. Nie mówią, że praca faktycznie przez niego przechodzi. Sygnały, które naprawdę opisują przyjęcie systemu, są inne.

• Odsetek operacji z danego okresu zarejestrowanych w systemie w stosunku do tych, które rzeczywiście miały miejsce.
• Operacje zakończone bez późniejszej korekty, które pokazują, czy pracownicy potrafią je wykonać, czy działają metodą prób i błędów.
• Opóźnienie między zdarzeniem a jego zarejestrowaniem: jeśli rośnie, system jest odbierany jako obowiązek, a nie jako narzędzie.
• Liczba próśb o pomoc w tej samej kwestii: pokazuje, gdzie system albo wyjaśnienie nie działają.

Te sygnały trzeba obserwować dla każdego działu osobno. Dobra średnia przyjęcia może ukrywać dział, który się zatrzymał, i to właśnie z tego działu będą pochodzić brakujące dane, które zepsują widoki wszystkich.

Kiedy warto odłożyć wdrożenie lub zacząć od mniejszego zakresu

Bywają momenty, w których nawet dobrze przeprowadzone wdrożenie i tak zawodzi, i warto je rozpoznać wcześniej.

• Okres sezonowego szczytu albo termin, który pochłania uwagę całej firmy.
• Brak osoby wewnątrz firmy z przydzielonym czasem na nadzorowanie wdrożenia: dostawca nie może jej zastąpić.
• Proces wciąż będący przedmiotem dyskusji między działami: system uwidoczniłby spór, który trzeba rozwiązać wcześniej, i to nie za pomocą oprogramowania.
• Kluczowa funkcja jeszcze niegotowa: lepiej zacząć od jednego działu lub jednego rodzaju operacji i rozszerzać zakres później.

Rozpoczęcie od wąskiej grupy ma zaletę wykraczającą poza samą ostrożność: wykształca wewnątrz firmy osoby, które umieją korzystać z systemu i mogą wyjaśnić go innym własnymi słowami firmy, które działają lepiej niż słowa z instrukcji.

Czego ten przewodnik nie obejmuje

Tutaj mowa jest o przyjęciu organizacyjnym: kogo zaangażować, jak szkolić, jak zamknąć przeszłość, co mierzyć. Techniczne testy, które należy wykonać przed codziennym użyciem oprogramowania — przypadki graniczne, dane testowe, weryfikacja obliczeń i uprawnień — są omówione w przewodniku poświęconym testowaniu. Wybór tego, co znajdzie się w pierwszej wersji, a co poczeka, również ma swój własny przewodnik.