Софтверная чахарда хутка стане вельмі распаўсюджанай хваробай кампаній. Змяняць адзін софт на іншы з-за кожнай дробязі, скакаць з тэхналогіі на тэхналогію, эксперыментаваць на жывым бізнэсе становіцца нормай. Пры гэтым у офісе пачынаецца сапраўдная грамадзянская вайна: фармуецца рух супраціву ўкараненню, партызаны вядуць падрыўную працу супраць новай сістэмы, шпіёны прапагандуюць новы дзівосны свет з новым софтам, кіраўніцтва з браневіка карпаратыўнага партала вяшчае пра мір, працу, KPI. Рэвалюцыя звычайна заканчваецца поўным правалам аднаго з бакоў.
Мы ведаем аб укараненні амаль усё, таму паспрабуем разабрацца, як рэвалюцыю ператварыць у эвалюцыю і зрабіць укараненне максімальна карысным і бязбольным. Ну ці прынамсі распавядзем, у што вы можаце ўляпацца падчас.
Ідэальная візуалізацыя прыняцця новага ПЗ супрацоўнікамі.
Замежныя кансалтары пачалі б гэты артыкул прыкладна так: "Калі вы прапануеце сваім супрацоўнікам якаснае праграмнае забеспячэнне, якое здольна палепшыць іх працу, аказаць якасны ўплыў на паказчыкі, прыняцце новай праграмы або сістэмы адбудзецца натуральным чынам". Але мы з вамі ў Расіі, таму пытанне падазроных і ваяўнічых супрацоўнікаў вельмі актуальнае. Натуральнай пераходу не атрымаецца, нават з мінімальным ПА тыпу карпаратыўнага месэнджара або софтфона.
Адкуль растуць ногі ў праблемы?
Сёння ў кожнай кампаніі ўсталяваны цэлы заапарк ПА (мы бярэм агульны выпадак, таму што ў ІТ-кампаніях колькасць софту больш удвая ці ўтрая, а праблемы адаптацыі перасякаюцца часткова і вельмі спецыфічныя): сістэмы кіравання праектамі, CRM/ERP, паштовыя кліенты, месэнджары, карпаратыўны партал і г.д. І гэта акрамя таго, што бываюць кампаніі, у якіх нават пераход з браўзэра на браўзэр ажыццяўляецца ўсёй камандай без выключэння (а яшчэ ёсць каманды, цалкам якія сядзяць на Internet Explorer Edge). У агульным выпадку ёсць некалькі сітуацый, для якіх можа аказацца карысным наш артыкул:
- адбываецца працэс першаснай аўтаматызацыі нейкай групы задач: укараняецца першая CRM/ERP, адкрываецца карпаратыўны партал, усталёўваецца сістэма для тэхнічнай падтрымкі і інш.;
- адбываецца замена аднаго ПЗ на іншае па нейкіх прычынах: устараненне, новыя патрабаванні, маштабаванне, змена дзейнасці і г.д.;
- адбываецца нарошчванне модуляў існуючай сістэмы для мэт развіцця і росту (напрыклад, кампанія адкрыла вытворчасць і вырашыла перайсці з на з максімальнай функцыянальнасцю);
- адбываецца сур'ёзнае інтэрфейснае і функцыянальнае абнаўленне ПЗ.
Вядома, першыя два выпадкі значна больш вострыя і тыповыя ў сваіх праявах, звернеце на іх адмысловую ўвагу.
Такім чынам, перад тым, як пачаць працаваць з калектывам (які ўжо западозрыў, што ж-ж-ж-ж нездарма, і хутка будуць змены), паспрабуйце зразумець, у чым складаюцца рэальныя чыннікі змены ПЗ і ці згодны вы з тым, што змены гэтак ужо неабходныя.
- У старой праграме складана працаваць: яна дарагая, нязручная, нефункцыянальная, перастала адпавядаць вашым патрабаванням, не падыходзіць для вашага маштабу і г.д. Гэта аб'ектыўная неабходнасць.
- Вендар перастаў падтрымліваць сістэму, альбо падтрымка і дапрацоўка ператварыліся ў бясконцую чараду ўзгадненняў і выцягвання грошай. Калі вашы выдаткі значна выраслі, і ў перспектыве абяцаюць павялічыцца яшчэ - чакаць няма чаго, трэба рэзаць. Так, новая сістэма таксама будзе каштаваць грошай, але ў канчатковым выніку аптымізацыя абыдзецца танней, чым такая падтрымка.
- Змена ПЗ - капрыз аднаго чалавека або групы супрацоўнікаў. Напрыклад, CTO хоча адкат і лабіруе ўкараненне новай, больш дарагі сістэмы, - такое бывае ў вялікіх кампаніях. Іншы прыклад: праектны мэнэджар выступае за змену Asana на Basecamp, потым Basecamp на Jira, складанай Jira на Wrike. Нярэдка адзіны матыў такіх міграцый - паказаць сваю бурную працу і захаваць пасаду. У такіх выпадках трэба вызначаць ступень неабходнасці, матывы і абгрунтаванасць і, як правіла, валявым рашэннем адмаўляць у зменах.
Мы гаворым аб прычынах менавіта пераходаў з аднаго ПЗ на іншае, а не аб першаснай аўтаматызацыі - толькі таму што аўтаматызацыя апрыёры неабходная. Калі ў вашай кампаніі нешта робіцца ўручную і руцінна, але можа быць аўтаматызавана, вы проста губляеце час, грошы і, хутчэй за ўсё, каштоўныя карпаратыўныя дадзеныя. Аўтаматызуе гэта!
Як можна перайсці: вялікі скок або крадком тыгр?
У сусветнай практыцы існуюць тры асноўныя стратэгіі пераходу на новае ПЗ, адаптацыі да яго - і яны нам здаюцца вельмі прыдатнымі, таму не будзем вынаходзіць ровар.
Вялікі выбух
Прыняцце метадам "Вялікага выбуху" - максімальна жорсткі пераход, калі вы ўсталёўваеце дакладную дату і ажыццяўляеце рэзкую міграцыю, адключаючы старое ПЗ на ўсе 100%.
Плюсы
+ Усе працуюць у адной сістэме, не трэба сінхранізаваць дадзеныя, супрацоўнікам не трэба сачыць адразу за двума інтэрфейсамі.
+ Прастата для адміністратара - адна міграцыя, адны задачы, падтрымаючы адной сістэмы.
+ Усе магчымыя змены наступаюць у адзін момант часу і прыкметныя амаль адразу - няма неабходнасці вычляняць, што і ў якой долі паўплывала на прадуктыўнасць, хуткасць распрацоўкі, продажу і г.д.
Мінусы
- Паспяхова працуе толькі з простым праграмным забеспячэннем: чаты, карпаратыўны партал, месэнджары. Нават электронная пошта ўжо можа даць збоі, не кажучы ўжо пра сістэмы кіравання праектамі, CRM/ERP і іншыя сур'ёзныя сістэмы.
- «Выбухная» міграцыя з буйной сістэмы на іншую непазбежна выкліча хаос.
Самае важнае для такога тыпу пераходу ў новае працоўнае асяроддзе - гэта навучанне.
Parallel Running
Раўналежная адаптацыя да ПА - мякчэйшы і найболей універсальны спосаб пераходу, пры якім задаецца часавы прамежак, на працягу якога будуць адначасова функцыянаваць абедзве сістэмы.
Плюсы
+ Карыстальнікі маюць дастаткова часу, каб прывыкнуць да новага ПЗ, аператыўна працуючы ў старым, адшукаць паралелі, углыбіцца ў новую логіку ўзаемадзеяння з інтэрфейсам.
+ У выпадку раптоўных праблем супрацоўнікі працягваюць працаваць у старой сістэме.
+ Навучанне карыстальнікаў менш жорсткае і ў цэлым абыходзіцца танней.
+ Негатыўная рэакцыя супрацоўнікаў практычна адсутнічае - бо іх не пазбавілі звыклага інструмента або ўкладу спраў (калі аўтаматызацыя адбываецца ўпершыню).
Мінусы
- Праблемы адміністравання: падтрымка абедзвюх сістэм, сінхранізацыя дадзеных, кіраванне бяспекай адразу ў двух прыкладаннях.
- Бясконца расцягваецца працэс пераходу – супрацоўнікі ўсведамляюць, што ў іх у запасе амаль вечнасць, і можна падоўжыць выкарыстанне звыклага інтэрфейсу яшчэ крышку.
- Блытаніна карыстальнікаў - два інтэрфейсы збіваюць з панталыку і выклікаюць памылкі ў працы і дадзеных.
- Грошы. Вы плаціце за абедзве сістэмы.
Phased Adoption
Паэтапная адаптацыя - самы мяккі варыянт пераходу на новае ПЗ. Пераход ажыццяўляецца пафункцыянальна, у абумоўленыя перыяды часу і па падраздзяленнях (напрыклад, з 1 чэрвеня мы ўносім новых кліентаў толькі ў новую CRM-сістэму, з 20 чэрвеня вядзем здзелкі ў новай сістэме, да 1 жніўня пераносім календары і справы, і да 30 верасня завяршаем міграцыю - гэта вельмі грубае апісанне, але ў цэлым нагляднае).
Плюсы
+ Арганізаваны пераход, размеркаваная нагрузка на адміністратараў і ўнутраных экспертаў.
+ Больш прадуманае і глыбокае навучанне.
+ Няма супраціву зменам, таму што яны адбываюцца максімальна мякка.
Мінусы - прыкладна такія ж, як у паралельнага пераходу.
Дык што цяпер, толькі паэтапны пераход?
Лагічнае пытанне, пагодзіцеся. Навошта атрымаць нейкую лішнюю мароку, калі можна скласці графік і дзейнічаць па выразным плане? Насамрэч не ўсё так адназначна.
- Складанасць праграмнага забеспячэння: калі гаворка ідзе аб складаным ПЗ (напрыклад, ), то больш падыдзе фазавая адаптацыя. Калі ПЗ простае (мэсанджар, карпаратыўны партал), то падыдзе мадэль, калі вы абвясцілі пра дату і адсякаеце старое ПЗ у прызначаны дзень (калі пашанцуе, супрацоўнікі паспеюць выцягнуць усю неабходную ім інфармацыю, а калі не разлічваць на шанцаванне, то неабходна прадугледзець аўтаматызаваны імпарт неабходных дадзеных са старой сістэмы ў новую, пры наяўнасці тэхнічнай магчымасці).
- Ступень рызыкі для кампаніі: чым больш рызыкоўнае ўкараненне, тым павольней яно павінна быць. З іншага боку, зацягванне – таксама рызыка: напрыклад, вы пераходзіце з адной CRM-сістэмы на іншую, і ў перыяд пераходу змушаныя плаціць за абедзве, тым самым растуць выдаткі і кошт укаранення новай сістэмы, а значыць, расцягваецца перыяд акупнасці.
- Колькасць супрацоўнікаў: вялікі выбух сапраўды не падыдзе ў выпадку неабходнасці маштабавання і налады мноства карыстацкіх профіляў. Хоць бываюць выпадкі, калі ўльтра хуткае ўкараненне для вялікай кампаніі - балазе. Такі варыянт можа падысці для сістэм, якімі карыстаюцца многія супрацоўнікі, але пры гэтым не могуць мець патрабаванні, паколькі не мяркуецца кастамізацыя. Але зноў жа, гэта big bang для канчатковых карыстальнікаў і вялізная паэтапная праца для той жа ІТ-службы (напрыклад, білінг або прапускная сістэма).
- Асаблівасці ўкаранення абранага ПЗ (дапрацоўка і г.д.). Часам укараненне першапачаткова паэтапнае - са зборам патрабаванняў, дапрацоўкай, навучаннем і г.д. Напрыклад, ўкараняецца заўсёды паступальна і калі вам хтосьці абяцае «ўкараніць і наладзіць за 3 дні ці нават 3 гадзіны» — успомніце гэты артыкул і абыдзеце такія паслугі бокам: усталёўка ≠ укараненне.
Ізноў жа, нават ведаючы пералічаныя параметры, нельга адназначна станавіцца на той ці іншы шлях. Ацэніце ваша карпаратыўнае асяроддзе - гэта дапаможа адначасова зразумець расклад сіл і вызначыць, якая мадэль (або спалучэнне некаторых іх элементаў) вам падыдзе.
Агенты ўплыву: рэвалюцыя ці эвалюцыя
Першае, на што варта звярнуць увагу, гэта супрацоўнікі, якіх закране ўкараненне новага ПЗ. Уласна, праблема, якую мы з вамі зараз разглядаем, чыстай вады чалавечы фактар, таму аналізу ўплыву на супрацоўнікаў не пазбегнуць. Некаторых з іх мы згадалі вышэй.
- Кіраўнікі кампаніі вызначаюць, як у цэлым будзе прынята новае ПЗ. І тут не месца рэкламным прамовам і палымяным выступам, - важна паказаць менавіта неабходнасць змен, пранесці ідэю аб тым, што гэта ўсяго толькі выбар больш стромкай і зручнай прылады, такі ж, як замена старога наўтбука. Самая вялікая памылка кіраўніцтва ў такой сітуацыі - умыць рукі і самаўхіліцца: калі начальству не патрэбна аўтаматызацыя кампаніі, чаму яна павінна быць цікавая супрацоўнікам? Будзьце ў працэсе.
- Кіраўнікі аддзелаў (менеджэры праектаў) - прамежкавае звяно, якое абавязкова павінна ўдзельнічаць ва ўсіх працэсах, кіраваць незадаволенасцю, праявіць волю і адпрацаваць кожнае пярэчанне калег, правесці якаснае і глыбокае навучанне.
- ІТ-служба (ці сістэмныя адміністратары) – на першы погляд, гэта вашы early birds, самыя адаптавальныя і адаптавальныя, але… не. Нярэдка, асабліва ў малых і сярэдніх кампаніях, сісадміны выступаюць супраць якіх-небудзь змен (узмацненняў) ІТ-інфраструктуры, і звязана гэта не з нейкай тэхнічнай абгрунтаванасцю, а з лянотаю і нежаданнем працаваць. А хто з нас не шукаў шляхоў адкасіць ад выканання працы? Але няхай гэта будзе не на шкоду ўсёй кампаніі.
- Канчатковыя карыстачы, як правіла, жадаюць працаваць добра і зручна з аднаго боку і, як і любыя жывыя людзі, баяцца змен. Асноўная аргументацыя для іх сумленная і простая: навошта ўкараняем/мяняем, якія межы ў кантролю, як будзе ацэньвацца праца, што зменіцца і ў чым рызыкі (дарэчы, рызыкі варта ацаніць усім - мы хоць і вендары , але не бярэмся сказаць, што ўсё заўсёды праходзіць гладка: рызыкі ёсць у любым працэсе ўнутры бізнэсу).
- "Аўтарытэты" ўнутры кампаніі – партызаны, якія могуць аказваць уплыў на астатніх супрацоўнікаў. Гэта не абавязкова чалавек з высокай пасадай або вялікім вопытам - у выпадку працы з ВА "аўтарытэтам" можа апынуцца прасунуты ўсезнайка, які, напрыклад, перачытаў Хабра і пачне ўсіх запалохваць тым, як усё стане дрэнна. У яго можа нават не быць мэты разбурыць працэс укаранення або пераходу, - проста панты і дух супраціву, - а супрацоўнікі яму павераць. З такімі супрацоўнікамі трэба працаваць: растлумачыць, распытаць, у асабліва цяжкіх выпадках намякнуць на наступствы.
Ёсць універсальны рэцэпт, як праверыць, карыстачы сапраўды чагосьці асцерагаюцца ці ў іх групавая параноя на чале з падкаваным лідэрам. Спытайце іх аб прычынах незадаволенасці, аб асцярогах - калі гэта не персанальнае перажыванне або меркаванне, аргументы пасыпяцца на 3-4 удакладняючай пытанні.
Два важныя фактары паспяховага пераадолення "руху супраціўлення".
- Праводзіце навучанне: вендорскае і ўнутранае. Пераканайцеся ў тым, што супрацоўнікі сапраўды ўсё зразумелі, засвоілі і незалежна ад узроўню падрыхтоўкі гатовы пачаць працаваць. Абавязковы атрыбут навучання - друкаваныя і электронныя інструкцыі (рэгламенты) і максімальна поўная дакументацыя па сістэме (шаноўныя вендары выпускаюць яе разам з ПА і падаюць бясплатна).
- Шукайце прыхільнікаў і выбірайце інфлюэнсераў. Унутраныя эксперты і раннія паслядоўнікі - ваша апора, якая і навучыць, і развее сумневы. Як правіла, супрацоўнікам самім прыемна дапамагаць калегам, уводзіць іх у новы софт. Ваша задача - часова разгрузіць іх ад працы або годна прэміраваць за новую нагрузку.
На што трэба звярнуць увагу?
- Наколькі прасунуты тыя супрацоўнікі, якіх закрануць змены? (Умоўна кажучы, калі заўтра вынайдуць новую бухгалтарскую праграму, на дай вам бог сунуцца ў бухгалтэрыю з дамамі за 50 і прапанаваць пераход з 1С - жывым не выйдзеце).
- Наколькі моцна будуць закрануты працоўныя працэсы? Адна справа памяняць месэнджэр у кампаніі са 100 чалавек, іншая – укараніць новую CRM-сістэму, на працы ў якой завязаныя ключавыя працэсы ў кампаніі (і гэта не толькі продажы, напрыклад, у старэйшых рэдакцыях закранае і вытворчасць, і склад, і маркетынг, і топ-мэнэджараў, якія разам з камандай будуць выбудоўваць аўтаматызаваныя бізнес-працэсы).
- Ці праведзена навучанне і на якім узроўні?
Адзіны лагічны пераход у сістэме карпаратыўнага мыслення
Што выратуе пераход/укараненне новага ПЗ?
Перш чым распавесці, якія ключавыя моманты дапамогуць вам камфортна пераехаць на новы софт, завастрым вашу ўвагу на адным моманце. Ёсць тое, што рабіць дакладна не трэба - не трэба ціснуць на супрацоўнікаў і «матываваць» іх дэпрэміяваннем, адміністрацыйнымі і дысцыплінарнымі спагнаннямі. Працэс ад гэтага лепш не пойдзе, а вось стаўленне супрацоўнікаў пагоршыцца: раз праціскаюць, значыць, будзе кантроль; раз прымушаюць, значыць, не паважаюць нашу цікавасць; раз гвалтам навязваюць, значыць, нам і нашай працы не давяраюць. Таму ўсё які робіцца дысцыплінавана, выразна, пісьменна, але без ціску і залішняга фарсіравання.
У вас павінен быць падрабязны план дзеянняў
Вось усяго астатняга можа не быць, а план павінен быць. Прычым план карэкціруемы, які абнаўляецца, выразны і няўхільны, пры гэтым даступны для абмеркавання і празрысты для ўсіх зацікаўленых супрацоўнікаў. Нельга дырэктыўна паведамляць аб тым, што З 8 раніцы да 10 - подзвіг, а ў 16:00 вайна з Англіяй, важна бачыць увесь план у перспектыве.
У плане абавязкова павінны быць адлюстраваны патрабаванні супрацоўнікаў, якія будуць з'яўляцца канчатковымі карыстальнікамі - так кожны супрацоўнік даведаецца, якую менавіта жаданую фічу і ў які час ён сапраўды зможа выкарыстоўваць. Пры гэтым план пераходу або ўкаранення гэта не нейкі нязменны маналіт, неабходна пакідаць магчымасць дапрацоўкі плана і змены яго атрыбутаў (але не ў выглядзе бясконцага патоку правак і новых "хацелак" і не ў выглядзе пастаяннага зрушэння тэрмінаў).
Што павінна быць у пляне?
- Асноўныя вехі пераходу (этапы) - што павінна быць зроблена.
- Дэталёвыя моманты пераходу для кожнага этапу - як павінна быць зроблена.
- Ключавыя кропкі і справаздачнасць па іх (зверка гадзін) - як будзе вымерана тое, што зроблена і хто павінен апынуцца на кантрольнай кропцы.
- Адказныя - людзі, да якіх можна звярнуцца і з якіх можна спытаць.
- Тэрміны - пачатак і канец кожнага этапу і ўсяго працэсу ў цэлым.
- Закранутыя працэсы - якія змены адбудуцца ў бізнес-працэсах, што трэба памяняць разам з укараненнем / пераходам.
- Выніковая ацэнка - набор паказчыкаў, метрык ці нават суб'ектыўных ацэнак, якія дапамогуць ацаніць тое, што адбылося ўкараненне / пераход.
- Пачатак эксплуатацыі - дакладны тэрмін, калі ўся кампанія ўвальецца ў абноўлены аўтаматызаваны працэс і будзе весці працу ў новай сістэме.
Мы сустракалі прэзентацыі укараняльнікаў, у якіх чырвонай лініяй праходзіць рада: укараняць сілком, рэакцыю ігнараваць, з супрацоўнікамі не размаўляць. Мы супраць такога падыходу, і вось чаму.
Паглядзіце на малюнак ніжэй:
Новая мышка, новая клавіятура, кватэра, машына і нават праца - гэта прыемныя, радасныя падзеі, некаторыя з іх нават дасягненні. І карыстальнік ідзе ў Яндэкс, каб даведацца, як прывыкнуць, адаптавацца. Як увайсці ў новую кватэру і зразумець, што гэта тваё, упершыню адкрыць кран, выпіць гарбату, упершыню легчы спаць. Як сесці за руль і пасябраваць з новай машынай, тваёй, але пакуль такой чужой. Новае ПЗ на працоўным месцы нічым не адрозніваецца ад апісаных сітуацый: праца супрацоўніка ніколі не стане ранейшай. Таму ўкараняйце, адаптуйце, гадуйце з новым эфектыўным ПЗ. І гэта тая сітуацыя, пра якую можна сказаць: спяшайцеся павольна.
Крыніца: habr.com