Problem zmiany podczas wdrożeń systemów zarządzania w drukarni

Wstęp

Nie ulega wątpliwości, że drukarnie coraz częściej decydują się na znaczną poprawę kontroli swojej rentowności poprzez 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 zdrugiej zupełną zmianę w zakresie codziennych zachowań i przyzwyczajeń. Generalnie 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ę 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.

Zarządzanie zmianą

W ostatnich latach pojawiły się opracowania teoretyczne, dotyczące fazy wzbudzania zaangażowania w uczestnikach zmiany, która jest kluczowym źródłem problemów (nie tylko subiektywnych).

W roku 1951 Kurt Lewin opracował trójwarstwowy model zmiany. W warstwie pierwszej, zwanej rozmrożeniem przezwyciężana jest inercja i rozmontowywanie istniejącego środowiska. Warstwa druga to wprowadzenie zmiany w życie, co wywołuje niestety zamieszanie w organizacji. Trzecia faza, zwana zamrażaniem, służy wdrożeniu (umiejscowieniu) nowości. Po fazie tej organizacja powinna wrócić do stanu równowagi, który występował przed zmianą.

Innym aspektem zmiany zajmowali się pionierzy badań nad rozwojem organizacji – Richard Beckhard i David Gleicher. Są oni autorami tzw. nierówności Gleicher’a:

D×V×F > R,

gdzie:

D – niezadowolenie z istniejącego stanu,
V – wizja stanu po zmianie,
F – działania konieczne do realizacji wizji,
R – opór przeciw zmianie.

Nierówność ta wskazuje, że jeżeli jakakolwiek wartość po jej lewej stronie jest mała (bliska zeru), to wpłynie ona na wynik mnożenia, zatem zmniejszy się opór po zmianie z prawej strony nierówności.

Warunki konieczne, aby zmiana mogła zostać przeprowadzona z sukcesem, opracował Bill Jensen [ 3]. Wyróżnił on cztery istotne warunki konieczne: wizja, plan, zasoby i  siła motywująca. Wizja jest niezbędna, aby określić dokąd zmierzamy, plan definiuje kolejne etapy, określone zasoby, które są niezbędne do przeprowadzenia zmiany. Warunek ostatni, czyli siła motywująca to najciekawszy element. Jensen uważa, że ludzie decydują się tylko wtedy na postęp w nieznane, gdy czują, że nie ma już innego wyjścia i nie ma już możliwości utrzymania starego środowiska.

Przykłady problemów podczas projektu

Zagrożenie zmianą występuje na każdym etapie projektu. Na samym początku projektu, a nawet przed jego rozpoczęciem, gdy nie rozpoznani są 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świadczenie wskazują jednak, że największym wrogiem nowego jest po prostu 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 jest to 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 lub w trakcie instalacji systemu. Oto lista przeszkód (kolejność chronologiczna):

1. 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.

1. 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.

1. 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, więc 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 z opisanych problemów 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 source. 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 services 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

Plotka to z definicji niesprawdzona lub kłamliwa pogłoska, powodująca utratę dobrego wizerunku osoby, której dotyczy, a plotkowanie – jako robienie, rozpowszechnianie plotek. Niestety spotykamy się z plotkami bardzo często, szczególnie w fazie początkowej 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ł na 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 wykonuje 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 ilości 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ć kilkukrotnie 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 muszą poświęcić sporo czasu, aby wdrożyć system wspólnie z dostawcą. Dosyć często pracownicy proszą o przełożenie spatkania 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, 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.

Opór pracowników biurowych

• Przykład – „Bezcenne notatki handlowców”

Opis zdarzenia. Handlowcy z ogromnymi oporami przyjmowali do wiadomości konieczność używania nowego systemu CRM, mimo że system w jawny sposób pomagał im planować kontakty z klientami i dawał możliwość obsługi większej ilości klientów niż dotychczas.

Przyczyny problemu. W drukarni nie istniała centralna baza danych klientów oraz nie było jakiejkolwiek możliwości badania postępów i efektywności sprzedaży. Wszelkie dane klientów były przechowywane w notesach handlowców, zaszyte w skrzynkach poczty elektronicznej lub ukryte w książkach adresowych telefonów komórkowych. W zasadzie nie było żadnej kontroli nad tym, co handlowcy robią na codzień. W takim środowisku czuli się oni bezkarni, a każdy krok zarządu kwitowali rozprzestrzenianiem plotek i gróźb o odejściu i „wyprowadzeniu” klientów do konkurencji. Rozwiązanie problemu. Szef projektu poniósł porażkę, którą odkryto dopiero w końcowej fazie projektu. Polegała ona na tym, że nie przypuszczał, iż dane dostarczone przez handlowców do centralnej bazy klientów mogą być fałszywe, a w najlepszym przypadku bardzo niekompletne. Także zapisy codziennych czynności były wymyślane i niekoniecznie miały pokrycie w rzeczywistości. Szef projektu postanowił zweryfikować dane z bazy danych przekazując dane klientów do pracowników innych działów. W ten sposób wyeliminował kontakty zbędne i nieco uzupełnił braki w bazie. Drugim krokiem było wysłanie e-mailingu do wszystkich klientów z prośbą o weryfikację swoich danych, krok ten przyniósł oczekiwane efekty i baza klientów ostatecznie zawierała sensowne dane. Ostatecznie baza została przyjęta do eksploatacji, ale do dzisiaj nie wiemy, czy zawarte w niej dane są w 100% prawdziwe.

Opór pracowników produkcyjnych

• Przykład – „Strach przed kontrolą i utratą zarobków”

Opis zdarzenia. Pracownicy produkcyjni, czyli tacy, którzy pracują przy obsłudze maszyn drukarskich i introligatorskich bardzo niechętnie podchodzili do korzystania z tzw. terminali produkcyjnych, których zadaniem jest zbieranie i rejestracja wszelkich wykonywanych zadań produkcyjnych przez pracowników. Pracownicy domagali się wielokrotnych szkoleń, twierdząc, że nigdy wcześniej nie obsługiwali komputera i że jego obsługa jest to poza zakresem ich obowiązków. Oddanie terminali do eksploatacji niebezpiecznie się przeciągało.

Przyczyny problemu. Początkowo pracownicy nie widzieli jakiegokolwiek sensu używania terminali. Zaczęli podświadomie wyczuwać, że terminale będą służyć jedynie do rozliczania ich pracy i wpływać negatywnie na wynagrodzenia.

Rozwiązanie problemu. Szef projektu podczas kolejnego szkolenia wygłosił monolog, podczas którego starał się przekonywać pracowników, że dzięki terminalowi dokładnie będą wiedzieli, jakie mają wykonywać zadanie w danym dniu, na jakiej maszynie i jakich dokładnie materiałów mają użyć. Dotychczas jedyną osobą, posiadającą komplet takich informacji był szef produkcji, który nie zawsze był dostępny. Brak informacji lub zmiany w planie produkcyjnym były przyczyną dezorientacji i przestojów produkcyjnych. Szef projektu wpadł na ciekawy pomysł i pojawiał się na około 30 początkowych minut każdej zmiany, gdzie obserwował pracowników, logujących się do terminala, zadawał pytania „czy wszystko w porządku? ” i pomagał przełamywać się pracownikom.

Podsumowanie

Przedstawione w niniejszym opracowaniu przykłady na pewno nie wyczerpują wszystkich przypadków subiektywnych zagrożeń projektów informatycznych, ale obrazują pewne ogólne tendencje zachowań interesariuszy projektów, które obejmują cały zakład produkcyjny, jakim jest drukarnia. Problemem generalnym jest wrażliwość na zmiany, jakie niesie z sobą wdrożenie nowego systemu. Inicjatorzy zmian często koncentrują się tylko na fazie drugiej modelu zmiany według Kurta Lewina, czyli samym przeprowadzeniu zmiany. Nie przywiązują oni w ogóle uwagi do konieczności budowania relacji od samego początku projektu. Tymczasem przed dokonaniem zmiany, w fazie rozmrożenia, należałoby przekonać ludzi do tego, że jest ona potrzebna.

Radzenie sobie ze zmianą nie jest łatwe, ale można i należy zmienić pewne procesy, tak aby utrwalone zachowania nie były już możliwe. Niezbędne jest także usunięcie społecznego poparcia dla „starego świata”. Od tego momentu pewne zachowania muszą po prostu zaniknąć. Wreszcie należy doprowadzić do tego, by ludzie samodzielnie odrzucali swoje dotychczasowe przyzwyczajenia i utarte schematy.

Jeżeli inicjatorzy zmiany, mimo rozpoznania pola sił, nie są w stanie przełamać oporu uczestników poprzez udzielanie im wszelkich informacji, to dzieje się tak najczęściej dlatego, że traktują każdy opór jako obiektywny, mający swoje źródło w braku informacji lub niezrozumieniu faktów. Faktycznie praca z oporem na poziomie rozmrażania sprowadza się do merytorycznej dyskusji, prezentacji faktów, sesji pytań i odpowiedzi lub burzy mózgów. W fazie wprowadzania zmiany najważniejsza jest rozmowa, dialog, uczciwe wysłuchanie racji drugiej strony, wreszcie danie jej czasu na zmianę stanowiska. Faza zamrażania wymaga zaś odbudowy dobrych relacji i zaufania, o co trzeba zadbać jeszcze przed wprowadzeniem zmian. Z chwilą, gdy nadchodzi zmiana i nie jest ona już tylko plotką, u dotkniętych nią ludzi zaczynają wzmagać się emocje, zarówno pozytywne jak i negatywne. Dla szefa projektu może to być trudny okres, dlatego musi się do niego dobrze przygotować. Wszyskie wspomniane w tym opracowaniu techniki są bardzo pomocne w przezwyciężaniu problemów. Nawet gdy nie widać początkowo sensu rozpoznawania interesariuszy, badania pola sił, budowania dobrych relacji, dbania o PR, czy ciągłej gotowości do pozytywnych negocjacji, szefowi projektu nie wolno koncentrować się tylko na systemie, który wdraża.

Bibliografia

[ 1] Anna Mikołajewska; Bogdan Bereza. Psychologia projektu informatycznego. Homo Creatore, 1:6, 2003.

[ 2] Russell W. Darnall. Najwspanialszy projekt świata. Difin, 2002.

[ 3] Bill Jensen. Four knowledgeable facts about executives. Reply (http://www.reply-mc.com/category/bill-jensen/), 1:3, 2007.

[ 4] Dorota Konowrocka. Ten cholerny czynnik ludzki. Computerworld, 700(1):40, styczeń 2006.

[ 5] Philip Kotler. Marketing. Analiza, planowanie, wdrożenie i kontrola. Wydawnictwo Felberg SJA, 1994.

[ 6] Dennis Lock. The Essensials of Project Management. Gower Publishing Limited, 1996.

[ 7] Harvard Business School Press. Twarzą w twarz. Komunikacja w kontaktach osobistych. Wydawnictwo Studio EMKA, 2006.

[ 8] Eric S. Raymond. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (O’Reilly Linux). O’Reilly, October 1999.

[ 9] Joel Spolsky. Zarządzanie projektami informatycznymi. Helion, 2005.

[ 10] Piotr Szturmowski. Monitorowanie a reakcje na zmiany zachodzące w projekcie. Wyższa szkoła Międzynarodowych Stosunków Gospodarczych i Politycznych, 1:18, 2003.

[ 11] Praca zbiorowa. Zarządzania projektem. Meteriały IV edycji podyplomowego studium zarządzania projektem, 2007.