Nie ulega wątpliwości, że drukarnie coraz częściej decydują się na znaczną poprawę kontroli swojej rentowności przez wdrożenie informatycznego systemu zarządzania. Wdrożenie takie wiąże się z kilkumiesięcznym innowacyjnym projektem niosącym ze sobą z jednej strony nową technologię, a z drugiej zupełną zmianę w zakresie codziennych zachowań i przyzwyczajeń.
Innowacyjne projekty są wpisane w całą historię ludzkości i stanowią siłę napędową postępu. Czy zbudowanie piramid, muru chińskiego, podróż na Księżyc, powstanie internetu oraz wolnego systemu operacyjnego Linux byłoby możliwe bez innowacyjnej wizji i chęci jej realizacji?
Niestety nie wszystkie projekty udają się, a przyczyny takiego stanu mogą być bardzo różne, jednak w ogólności wiążą się one z pojawieniem się na rynku nowych technologii, a to zawsze oznacza zmianę [4].
W tym artykule chciałbym opisać subiektywne przyczyny problemu „oswajania się” ludzi z nowym systemem zarządzania w drukarni. Wszystkie podane w tej pracy przykłady są autentyczne. Zaczerpnąłem je z kilkuletnich doświadczeń wdrożeniowych systemów informatycznych dla drukarń, które odbywały się w latach 2003–2008.
Przykłady problemów podczas projektu
Zagrożenie zmianą występuje na każdym etapie projektu. Na samym początku, a nawet przed jego rozpoczęciem, gdy nie są rozpoznani interesariusze oraz ich intencje, pojawiają się sytuacje zupełnie nieprzewidziane. Bardzo ważne jest, aby szef projektu był wyjątkowo wyczulony na wszelkie, nawet bardzo niewinnie wyglądające zdarzenia, które wydają się dziwne. Pojawianie się takich zdarzeń praktycznie zawsze oznacza problemy.
Opór pracowników wynikający ze strachu przed nowością jest powszechny podczas wdrożeń wszelkich systemów informatycznych – nie tylko w drukarni. Zapewne najwięcej obaw mają pracownicy starsi wiekiem, którzy obawiają się nowej „zawiłej” technologii informatycznej. Nasze doświadczenia wskazują jednak, że najwięksi wrogowie nowego to lenistwo i stare przyzwyczajenia. Bardzo trudnym przypadkiem jest także chęć utrzymania starego bałaganu, który bywa zawzięcie broniony przez „doświadczonych” pracowników.
Kumulacja problemów technicznych przed fazą instalacji systemu
Są sytuacje, gdy zupełnie nie ma powodów obiektywnych, które tłumaczyłyby zachowanie ludzi podczas wdrażania nowych rozwiązań i technologii. Czasami jest to tylko niechęć, a czasami jawna walka, objawiająca się poprzez piętrzenie drobnych, ale bardzo uciążliwych problemów, które w gruncie rzeczy nie są związane z projektem.
Przykład: „Rzucanie kłód pod nogi”. Opis zdarzenia. Mimo jasnej specyfikacji wymagań instalacyjnych dla naszego systemu dział IT klienta przedstawiał „co chwilę” przeszkody przed instalacją systemu lub w jej trakcie. Oto lista przeszkód (kolejność chronologiczna):
Istniejący w drukarni system wykonywania kopii zapasowych danych wymagał wyłączenia wszystkich aplikacji (wykonywany był w nocy). Nasz system działa i zbiera dane produkcyjne w czasie rzeczywistym i można wyłączać go tylko wtedy, gdy produkcja nie jest w toku.
Istniejąca konfiguracja sieci uniemożliwia dostęp do naszego systemu wszystkim użytkownikom. Dostęp mają jedynie użytkownicy dwóch podsieci. Administratorzy tłumaczą, że nie gwarantują bezpieczeństwa sieci, gdy obecna konfiguracja zostanie zmieniona.
Zakwestionowano możliwość zdalnego dostępu do serwera ze względów bezpieczeństwa, mimo że zdalny dostęp mieliśmy zagwarantowany w umowie. Ponieważ zmiany w parametrach systemu były wykonywane codziennie, dostęp był niezbędny.
Przyczyny problemu. Zachowanie działu IT nie było dla nas zrozumiałe, trudno było znaleźć przyczynę jawnej niechęci wobec nas. Po zakończeniu wdrożenia doszliśmy do wniosku, że jedynym sensownym powodem była niechęć wobec zmian i przekonanie, że pojawią się nowe obowiązki w związku z utrzymaniem systemu.
Rozwiązanie problemu. Wszystkie opisane problemy udało się rozwiązać, ale dopiero po użyciu argumentu o zawartym w kontrakcie zapisie, który zawierał konieczność przygotowania i przystosowania infrastruktury dla wdrażanego systemu. Po zakończeniu wdrożenia pracownicy działu IT sami przyznali, że pojawienie się nowego systemu niewiele zmieniło ich pracę.
Podważanie kompetencji firmy wdrożeniowej
Podważanie kompetencji firmy wdrożeniowej to częsty przypadek, gdy zarząd firmy zdecydował się na zakup systemu wbrew opinii własnego działu IT. Bardzo częstą przyczyną jest „niechciana” platforma systemowa oraz bazy danych. Pracownicy działu IT obawiali się konieczności opiekowania się systemem, którego nie chcieli później utrzymywać.
Przykład: „Podnoszenie kosztów projektu przez klienta”. Opis zdarzenia. Nasz kierownik projektu otrzymał pisemną informację, podpisaną przez zarząd klienta, o konieczności obniżenia naszych kosztów wdrożenia ze względu na pojawienie się ukrytego kosztu zakupu 50 licencji systemu operacyjnego Windows. W uzasadnieniu powoływano się na punkt umowy mówiący o braku kosztów ukrytych wdrażanego systemu.
Przyczyny problemu. Wdrażany przez nas system działa pod kontrolą systemu operacyjnego MS-Windows, czego nigdy nie ukrywaliśmy. Już na etapie prezentacji systemu informowaliśmy o tym klienta. Dział IT, który negatywnie opiniował nasz system, preferował rozwiązania oparte na systemach open source1. W trakcie projektu odkryliśmy bardzo wrogie reakcje pracowników działu IT, którzy próbowali za wszelką cenę jeśli nie usunąć, to przynajmniej osłabić firmę wdrożeniową. Mimo naszej pełnej sympatii dla systemów open source kontakty z działem IT były bardzo chłodne.
Rozwiązanie problemu. Niestety przedstawione przez klienta żądanie obniżenia kosztów wdrożenia nie mogło zostać spełnione ze względów finansowych. Szef projektu bardzo szybko powołał sztab antykryzysowy, który w ciągu 24 godzin przedstawił alternatywny sposób instalacji systemu na serwerze jako serwer aplikacji, zaś dzięki wykorzystaniu usługi terminal services2 serwera MS-Windows 2003 umożliwiono dostęp do aplikacji wszystkim pracownikom, którzy nie posiadali systemu MS-Windows na swoich stacjach roboczych. Wyeliminowano w ten sposób konieczność zakupu 50 licencji.
Dział IT ostatecznie uznał ten kompromis i nie stawiał dalszych oporów.
Rozsiewanie plotek w fazie początkowej projektu
Niestety spotykamy się z plotkami bardzo często, szczególnie w początkowej fazie projektu. Pracownicy w wielu przypadkach potrafią zapytać wprost, czy dana plotka jest prawdziwa. Niestety poniższy przykład pokazuje, że jednak nie zawsze.
Przykład: „Plotki na temat redukcji zatrudnienia”. Opis zdarzenia. W trakcie zbierania informacji technologicznych, które są niezbędne do konfiguracji systemu, szef projektu napotkał opór ze strony jednego działu drukarni. Informacje były przekazywane opieszale i nie zawierały wymaganych danych szczegółowych. Otrzymywaliśmy informacje sprzeczne od różnych osób.
Przyczyny problemu. W drukarni pojawiła się plotka, że nowy system, który przeprowadza studium wykonalności zlecenia na danym parku maszynowym oraz szacuje czas wykonania i koszt zlecenia, będzie przyczyną redukcji etatów wśród pracowników wykonujących kalkulację.
Rozwiązanie problemu. Szef projektu szybko zorientował się, że przyczyną niechęci jest strach. Początkowo sądził, że jest to opór dotyczący zmian w sposobie pracy, jednak mylił się. Potrzebował około miesiąca, aby dowiedzieć się, jaka jest rzeczywista przyczyna zachowania pracowników, a o wszystkim zadecydował przypadek. Podczas wdrożenia z grającego w tle radia nadeszła informacja o masowych zwolnieniach i statystykach dotyczących bezrobocia. Informacja ta bardzo poruszyła pracowników, szef projektu nabrał podejrzeń. Następnego dnia zapytał wprost właściciela drukarni, czy po wdrożeniu systemu planuje redukcję zatrudnienia. Właściciel bardzo się zdziwił pytaniem i poinformował, że grozi mu co najwyżej zwiększenie liczby zatrudnionych – ze względu na otwarcie rynków Europy Zachodniej spodziewa się dwukrotnego zwiększenia ilości zapytań ofertowych. Nie omieszkał dodać, że ma nadzieję, iż pojawienie się nowego systemu pozwoli wykonywać kilkakrotnie większą ilość kalkulacji bez konieczności zwiększania zatrudnienia. Szef projektu poprosił o podzielenie się tą informacją z załogą. Pisemny okólnik do pracowników wyciszył ich obawy.
Rozwlekanie projektu w czasie
Z założenia pracownicy ze strony klienta muszą być zaangażowani w projekt wdrożeniowy i poświęcić sporo czasu, aby wdrożyć system wspólnie z dostawcą. Dość często pracownicy proszą o przełożenie spotkania ze względu na brak czasu.
Przykład: „Permanentny brak czasu pracowników”. Opis zdarzenia. Poszczególni pracownicy, z którymi umawiano się na spotkania, przekładali je zasłaniając się bardzo ważnymi sprawami. W istocie rozwlekali czas wdrożenia systemu, gdyż obawiali się go.
Przyczyny problemu. Dzięki zapisowi w umowie o przesunięciu terminu realizacji wdrożenia w przypadku niedostarczania na czas niezbędnych informacji, szef projektu skrupulatnie odnotowywał opóźnienia i zmieniał niemal codziennie termin końcowy bez ryzyka kar umownych. Niemniej w połowie projektu termin końcowy stał się tak odległy, że ostateczny termin wdrożenia (przy zachowaniu tendencji) mógł być odległy od terminu rozpoczęcia nawet o 6 miesięcy. Mimo że nie zmieniał się czas obciążenia zasobów ludzkich, to jednak tak znaczne rozdrobnienie zadań w czasie skutkowało opóźnieniami w płatnościach i znacznie utrudniało przydzielanie zasobów do zadań w innych projektach.
Rozwiązanie problemu. Szef projektu szukał przyczyny rozwlekania projektu i rozmawiał w tym celu z wieloma pracownikami. Innej przyczyny niż opisana wyżej nie znalazł; pracownicy po prostu obawiali się nowości. Szef projektu poprosił o spotkanie z właścicielem drukarni, na którym dowiedział się, że mimo braku sezonu na usługi poligraficzne akurat pojawiło się bardzo dużo zleceń. Na poprawę sytuacji nie można było liczyć. Ze względu na możliwość przeniesienia zasobów do innego projektu szef zaproponował właścicielowi zawieszenie projektu na 60 dni i realizację wdrożenia systemu do końca w z góry zaplanowanym harmonogramie, bez możliwości przekładania spotkań. Właściciel ostatecznie zgodził się, ale wynegocjował jednodniowe szkolenie po 60 dniach przypominające jego pracownikom, co wydarzyło się podczas pierwszej części projektu. Czas jest dobrym katalizatorem dla nadchodzących zmian i czasami celowa przerwa w projekcie przynosi pozytywne skutki. cdn.
***
1 Są to systemy, które posiadają licencję nakazującą dystrybucję systemu wraz z jego kodem źródłowym i zakładają brak pobierania jakichkolwiek opłat za ich użytkowanie. [8]
2 Komponent systemu operacyjnego Windows 2003 Server umożliwiający zdalny dostęp do serwera użytkownikom, korzystającym z dowolnego systemu operacyjnego. Aplikacja uruchamiana jest po stronie serwera.
