Tokį elgesį lengva pavadinti pasipriešinimu pokyčiams, tačiau dažniausiai žmonės neprieštarauja technologijai savaime. Jie priešinasi neaiškumui, papildomai rizikai ir pokyčiui, apie kurį sprendimai buvo priimti jiems nedalyvaujant.
Neaiškumas greitai tampa pasipriešinimu
Apie naują sistemą darbuotojai neretai sužino tada, kai projektas jau gerokai pažengęs, o pagrindiniai sprendimai priimti. Jiems pristatoma, kas keisis, tačiau ne visada paaiškinama, kodėl šis pokytis apskritai reikalingas, kokią problemą jis sprendžia ir kaip paveiks kasdienį darbą.
Tokioje situacijoje darbuotojai pradeda patys užpildyti informacijos spragas. Vieni tikisi, kad nauja sistema pridės daugiau administravimo, kiti baiminasi didesnės kontrolės, papildomos atsakomybės ar to, kad teks iš naujo mokytis darbo, kurį iki šiol atliko užtikrintai. Net ir nedidelis funkcionalumo pakeitimas gali būti vertinamas ne kaip patobulinimas, o kaip rizika prarasti įprastą darbo ritmą.
Kuo vėliau apie pokytį pradedama kalbėti, tuo labiau darbuotojams atrodo, kad jų vaidmuo yra tik prisitaikyti prie jau priimto sprendimo.
Baimė tapti nebereikalingu yra visiškai reali
Skaitmenizacijos, automatizavimo ir dirbtinio intelekto projektai dažnai pristatomi per efektyvumą: mažiau rankinio darbo, mažiau pasikartojančių užduočių, greitesni procesai ir mažesnės sąnaudos. Vadovybei tai skamba kaip aiški verslo nauda, tačiau darbuotojas tuos pačius žodžius gali išgirsti visai kitaip.
Jeigu sistema perims dalį jo darbo, natūraliai kyla klausimas, ar ilgainiui įmonei reikės ir jo paties. Ši baimė gali būti nepagrįsta, tačiau vien tai, kad vadovybė apie darbuotojų mažinimą negalvoja, jos automatiškai nepanaikina.
Kai apie tai nekalbama atvirai, darbuotojas gali pradėti ginti ne patį seną procesą, o savo vietą organizacijoje. Tada atsiranda argumentai, kad sistema bus per sudėtinga, neveiks išimtiniais atvejais, neatitiks realaus darbo arba sukurs daugiau problemų nei naudos. Dalis šių pastabų gali būti visiškai pagrįstos, tačiau dalis jų kyla iš neįvardyto nesaugumo.
Todėl planuojant automatizuoti procesus svarbu iš anksto paaiškinti, kaip keisis žmonių vaidmuo. Jeigu sutaupytas laikas bus skiriamas klientams, analizei, sudėtingesniems sprendimams ar kitoms didesnę vertę kuriančioms užduotims, darbuotojai turi tai žinoti dar prieš sistemos paleidimą.
Darbuotojų įtraukimas nėra vien komunikacijos priemonė
Žmonės, kurie kasdien dirba su procesu, dažniausiai geriausiai žino jo išimtis, neformalias taisykles ir vietas, kuriose realus darbas skiriasi nuo vadovybės įsivaizdavimo. Jeigu sistema projektuojama tik pagal formalų proceso aprašymą, dalis svarbių situacijų išryškėja jau testuojant arba po paleidimo.
Ankstyvas darbuotojų įtraukimas padeda ne tik sumažinti pasipriešinimą. Jis leidžia tiksliau suprasti, ką iš tikrųjų verta keisti, kurios funkcijos svarbiausios ir kur naujas sprendimas gali sukurti papildomo darbo vietoje žadėto palengvinimo.
Žinoma, tai nereiškia, kad kiekvienas darbuotojas turi spręsti, kokia sistema bus kuriama. Tačiau žmonės turi turėti galimybę parodyti, kaip vyksta darbas, įvardyti rizikas ir išbandyti sprendimą dar tada, kai jį galima koreguoti be didelių papildomų sąnaudų.
Vien mokymų prieš paleidimą neužtenka
Įmonės dažnai pasirūpina instrukcijomis, mokymais ir atsakingais žmonėmis, kurie padės pradėti naudotis sistema. Tai reikalinga, tačiau mokymai neišsprendžia nepasitikėjimo problemos, jeigu darbuotojas iki tol nesuprato, kodėl pokytis vyksta.
Komunikacija turėtų prasidėti gerokai anksčiau už techninį diegimą. Darbuotojams verta paaiškinti, kokios dabartinio proceso problemos paskatino projektą, kas konkrečiai keisis jų darbe, kokių rezultatų tikimasi ir kaip bus vertinamas pereinamasis laikotarpis.
Lygiai taip pat svarbu aiškiai pasakyti, kas nesikeis. Jeigu sistema nėra kuriama darbuotojų skaičiui mažinti, tai rekomenduojame įvardyti. Jeigu tam tikros atsakomybės išliks, o automatizuojamos tik pasikartojančios užduotys, nereikėtų tikėtis, kad žmonės tai supras savaime.
Nauja sistema keičia ne tik įrankį
Net ir nedidelė sistema gali pakeisti atsakomybių ribas, informacijos matomumą ir sprendimų priėmimo tvarką. Tai, ką anksčiau žinojo vienas žmogus, gali tapti matoma visai komandai. Veiksmai, kurių niekas nefiksavo, gali pradėti palikti aiškią istoriją. Užduotys, kurios anksčiau priklausė nuo asmeninio susitarimo, gali būti standartizuotos.
Vadovybei tokie pokyčiai dažnai atrodo kaip aiškesnis valdymas, tačiau darbuotojams jie gali reikšti mažesnę autonomiją arba didesnį vertinimo skaidrumą. Todėl pasipriešinimo nereikėtų vertinti tik kaip nenoro mokytis. Kartais žmogus labai tiksliai jaučia, kad keičiasi ne vien programa, bet ir jo vaidmuo, atsakomybė ar įtaka procese.
Apie šiuos pokyčius taip pat reikia kalbėti tiesiai, o ne apsiriboti funkcijų pristatymu.
Sėkmingas diegimas prasideda dar prieš programavimą
Naujos sistemos priėmimui daugiausia įtakos turi ne paleidimo diena, o tai, kas vyko iki jos. Ar darbuotojai suprato, kodėl projektas pradėtas? Ar galėjo pasakyti, kur dabartinis procesas neveikia? Ar žinojo, kaip keisis jų darbas? Ar buvo atsakyta į klausimą, kas nutiks jų vaidmeniui automatizavus dalį užduočių?
Jeigu šie klausimai paliekami paskutinei projekto fazei, techninis diegimas gali būti sėkmingas, o organizacinis pokytis – ne.
Darbuotojai nebūtinai turi pritarti kiekvienam sprendimui, tačiau jie turi suprasti jo logiką ir savo vietą po pokyčio. Kai to nėra, nauja sistema tampa primestu įrankiu. Kai yra, ji turi daug daugiau galimybių tapti natūralia kasdienio darbo dalimi.