Jak rozliczać kierowników z zaangażowania w projekt wdrożeniowy?
Decyzja o tym, czy kierownicy działów będą formalnie rozliczani z udziału w projekcie wdrożeniowym, należy do zarządu i musi zostać podjęta jeszcze przed podpisaniem harmonogramu.
Aby rozliczanie zaangażowania było obiektywne i skuteczne, nie powinno opierać się na ogólnej ocenie poświęconego czasu, lecz na zrealizowaniu konkretnych celów biznesowych w przypisanych obszarach. Zgodnie ze źródłami, firmie zaleca się zastosowanie „minimalnego zakresu odpowiedzialności”, w którym każda rola kierownicza ma zdefiniowany obszar decyzyjny oraz precyzyjny miernik sukcesu.
Oto jak w praktyce należy rozliczać kierowników poszczególnych działów:
- Kierownik produkcji – odpowiada za obszar zleceń produkcyjnych (w tym statusy i priorytety). Z jego zaangażowania i poprawności wdrożonych procesów należy rozliczać go na podstawie terminowości zleceń po starcie systemu.
- Kierownik magazynu – jego zadaniem jest podjęcie decyzji dotyczących ruchów, lokalizacji i rezerwacji. Głównym miernikiem do jego oceny powinna być zgodność stanów magazynowych.
- Technolog – odpowiada za poprawne przygotowanie danych technologicznych (BOM-y, marszruty, wersje). Weryfikacją jego zaangażowania i rzetelności prac jest liczba korekt potrzebnych po uruchomieniu produkcyjnym.
- Pełnomocnik jakości – zarządza zasadami kontroli, braków i blokad. Efekty jego prac projektowych należy mierzyć poprzez liczbę niezgodności.
- Kierownik projektu – jest właścicielem decyzji dotyczących zakresu wymiany danych i integracji z innymi systemami. Sukces jego działań mierzy się na podstawie liczby błędów integracji.
Przypisanie mierzalnych wskaźników do konkretnych osób sprawia, że kadra kierownicza rozumie swój realny cel. System informatyczny staje się wtedy narzędziem do poprawy terminowości czy zgodności stanów, z których są oni osobiście rozliczani.
Jakie są główne przyczyny oporu pracowników wobec systemu?
Główne przyczyny oporu pracowników wobec nowego systemu wynikają najczęściej z błędów organizacyjnych i komunikacyjnych, a nie z ograniczeń samej technologii. Należą do nich:
- Niezrozumienie wpływu systemu na codzienną pracę: Opór rodzi się wtedy, gdy pracownikom nie wyjaśnia się w prosty sposób, co dokładnie zmieni się w ich obowiązkach (np. kto i gdzie wprowadzi informację, kto ją zatwierdzi oraz co się stanie w przypadku błędu). Słysząc jedynie ogólniki, pracownicy zaczynają postrzegać system jako niepotrzebny, dodatkowy obowiązek, a nie narzędzie mające na celu uporządkowanie ich wspólnej pracy.
- Komunikowanie wdrożenia jako „projektu informatycznego”: Bardzo często wdrożenie jest niesłusznie przedstawiane jako domena działu IT lub dostawcy oprogramowania. Taki błąd komunikacyjny sprawia, że pracownicy (np. z działu produkcji, magazynu, jakości) odcinają się od projektu, uznając, że nie dotyczy on ich bezpośrednio i nie ponoszą za niego odpowiedzialności.
- Zbyt skomplikowane i niepraktyczne procesy: Pracownicy na halach produkcyjnych i w magazynach oczekują rozwiązań, które będą proste i szybkie w użyciu. Zbyt rozbudowane lub ciężkie procesy są przez ludzi natychmiast omijane. Zasadą jest to, że jeżeli do zrozumienia nowych procedur w firmie potrzebny jest konsultant zewnętrzny, to znaczy, że dokumentacja jest zbyt skomplikowana i wywoła opór u załogi.
- Brak decyzji zarządczych w sytuacjach wyjątkowych: Kiedy organizacja nie ureguluje odpowiedzialności (nie wskaże jasno, kto zatwierdza dane, kto zmienia priorytety, czy kto ma prawo zatrzymać zlecenie), oprogramowanie jest konfigurowane na podstawie domysłów. Gdy brakuje decyzji w sprawach wyjątków, użytkownicy tuż po starcie produkcyjnym zaczynają kwestionować zasady i odrzucają system. Jest to szczególnie powszechne źródło oporu wśród kierowników zmianowych.
- Oderwanie funkcji programu od realnych problemów ludzi: Akceptację pracowników zdobywa się, rozwiązując ich codzienne, rutynowe problemy, takie jak opóźnione zlecenia, błędne wydania materiałów, nieaktualne dokumentacje czy ręczne korekty w Excelu. Przedstawianie systemów przez pryzmat abstrakcyjnych funkcji, zamiast realnych i odczuwalnych korzyści, zniechęca przyszłych użytkowników.