Софтверскиот скок наскоро ќе стане многу честа болест на компаниите. Менувањето на еден софтвер со друг поради секоја ситница, скокањето од технологија до технологија, експериментирањето со жив бизнис станува норма. Во исто време, во канцеларијата започнува вистинска граѓанска војна: се формира движење на отпор за спроведување, партизаните вршат субверзивна работа против новиот систем, шпиони промовираат храбар нов свет со нов софтвер, управување од оклопниот автомобил на корпоративниот портал емитува за мир, труд, KPI. Револуцијата обично завршува со целосен неуспех од едната страна.
Знаеме речиси сè за имплементацијата, па ајде да се обидеме да откриеме како да ја претвориме револуцијата во еволуција и да ја направиме имплементацијата што е можно покорисна и безболна. Па, или барем ќе ви кажеме во што би можеле да влезете во процесот.
Идеална визуелизација на прифаќање на новиот софтвер од вработените - Yandex.Images
Странските консултанти би ја започнале оваа статија вака: „Ако на своите вработени им понудите квалитетен софтвер кој може да ја подобри нивната работа, да има квалитативно влијание врз перформансите, усвојувањето на нова програма или систем ќе се случи природно“. Но, ние сме во Русија, така што прашањето за сомнителни и воинствени вработени е многу актуелно. Природната транзиција нема да работи, дури и со минимален софтвер како корпоративен гласник или мек телефон.
Од каде потекнуваат нозете на проблемот?
Денес, секоја компанија има инсталирана цела зоолошка градина на софтвер (го земаме општиот случај, бидејќи во ИТ компаниите количината на софтвер е двојно или тројна, а проблемите со адаптацијата делумно се преклопуваат и се многу специфични): системи за управување со проекти, CRM/ERP, клиенти за е-пошта, инстант-месинџери, корпоративен портал итн. И ова не го смета фактот дека има компании во кои дури и преминот од прелистувач до прелистувач го врши целиот тим без исклучок (а исто така има и тимови кои се целосно базирани на Internet Explorer Edge). Во принцип, постојат неколку ситуации за кои нашата статија може да биде корисна:
- Постои процес на примарна автоматизација на некоја група задачи: се спроведува првиот CRM/ERP, се отвора корпоративен портал, се инсталира систем за техничка поддршка итн.;
- еден софтвер се заменува со друг поради некоја причина: застареност, нови барања, скалирање, промена на активност итн.;
- се градат модули на постоечкиот систем за развој и раст (на пример, една компанија отвори производство и одлучи да се префрли од на со максимална функционалност);
- Во тек е големо ажурирање на интерфејсот и функционалниот софтвер.
Се разбира, првите два случаи се многу поакутни и типични во нивните манифестации, обрнете посебно внимание на нив.
Затоа, пред да започнете да работите со тимот (кој веќе се сомневаше дека наскоро ќе има промени), обидете се да разберете кои се вистинските причини за промена на софтверот и дали се согласувате дека промените се толку неопходни.
- Старата програма е тешка за работа: скапа е, незгодна, нефункционална, повеќе не ги задоволува вашите барања, не е погодна за вашата вага итн. Ова е објективна потреба.
- Продавачот престана да го поддржува системот или поддршката и модификациите се претворија во бескрајна серија одобрувања и трошење пари. Ако вашите трошоци значително се зголемија, а во иднина ветуваат дека ќе се зголемат уште повеќе, нема што да чекате, треба да намалите. Да, и нов систем ќе чини пари, но на крајот оптимизацијата ќе чини помалку од таквата поддршка.
- Промената на софтверот е каприц на едно лице или група вработени. На пример, CTO сака враќање и лобира за воведување нов, поскап систем - ова се случува во големите компании. Друг пример: проект-менаџер се залага за промена на Asana во Basecamp, потоа Basecamp во Jira и комплексна Jira во Wrike. Честопати единствениот мотив за таквите миграции е да ја покажат својата зафатена работа и да ја задржат својата позиција. Во такви случаи, неопходно е да се одреди степенот на неопходност, мотиви и оправданост и, по правило, со силна волја да се одбијат промените.
Зборуваме за причините за преминот од еден софтвер во друг, а не за примарна автоматизација - само затоа што автоматизацијата е априори неопходна. Ако вашата компанија прави нешто рачно и рутински, но може да се автоматизира, едноставно губите време, пари и, најверојатно, вредни податоци за компанијата. Автоматизирајте го!
Како можеш да преминеш: големиот скок или тигарот што крева?
Во светската практика, постојат три главни стратегии за префрлување на нов софтвер и прилагодување кон него - и тие ни изгледаат многу соодветни, па да не го измислуваме повторно тркалото.
Биг Бенг
Усвојувањето со методот „Биг Бенг“ е најтешката можна транзиција, кога ќе поставите точен датум и ќе извршите остра миграција, оневозможувајќи го стариот софтвер 100%.
Добрите
+ Сите работат во еден систем, нема потреба да се синхронизираат податоци, вработените не треба да следат два интерфејси одеднаш.
+ Едноставност за администраторот - една миграција, една задача, една системска поддршка.
+ Сите можни промени се случуваат во еден момент и се забележливи речиси веднаш - нема потреба да се изолира што и во која пропорција влијаело на продуктивноста, брзината на развој, продажбата итн.
Конс
— Успешно работи само со едноставен софтвер: разговори, корпоративен портал, инстант-месинџери. Дури и е-поштата веќе може да пропадне, а да не ги спомнуваме системите за управување со проекти, CRM/ERP и други сериозни системи.
- Експлозивна миграција од голем систем во друг неизбежно ќе предизвика хаос.
Најважно за овој тип на транзиција кон нова работна средина е обуката.
Паралелно трчање
Паралелното прилагодување кон софтверот е помек и поуниверзален метод на транзиција, во кој се поставува временски период во кој двата системи ќе функционираат истовремено.
Добрите
+ Корисниците имаат доволно време да се навикнат на новиот софтвер додека брзо работат во стариот, да најдат паралели и да ја разберат новата логика на интеракција со интерфејсот.
+ Во случај на ненадејни проблеми, вработените продолжуваат да работат во стариот систем.
+ Обуката за корисници е помалку ригорозна и генерално поевтина.
+ Практично нема негативна реакција од вработените - на крајот на краиштата, тие не беа лишени од вообичаените алатки или начин на вршење на работите (ако автоматизацијата се случи за прв пат).
Конс
— Административни проблеми: поддршка за двата системи, синхронизација на податоци, управување со безбедноста во две апликации одеднаш.
— Процесот на транзиција се протега бескрајно - вработените сфаќаат дека им останува речиси цела вечност и можат уште малку да ја прошират употребата на познатиот интерфејс.
- Корисничка конфузија - Двата интерфејси се збунувачки и предизвикуваат оперативни грешки и грешки во податоците.
- Пари. Плаќате за двата системи.
Фазно усвојување
Адаптацијата чекор-по-чекор е најмеката опција за префрлување на нов софтвер. Преминот се врши функционално, во одредени временски периоди и по оддел (на пример, од 1 јуни додаваме нови клиенти само на новиот CRM систем, од 20 јуни вршиме трансакции во новиот систем, до 1 август пренесуваме календари и случаи, а до 30 септември ја комплетираме миграцијата е многу груб опис, но генерално јасен).
Добрите
+ Организирана транзиција, распределен товар меѓу администраторите и внатрешните експерти.
+ Повеќе промислено и подлабоко учење.
+ Нема отпор кон промената, бидејќи се случува што е можно понежно.
Конс - приближно исто како и за паралелна транзиција.
Па сега, само постепена транзиција?
Логично прашање, ќе се согласите. Зошто да имате дополнителна мака кога можете да направите распоред и да дејствувате според јасен план? Всушност, не е сè толку едноставно.
- Комплексност на софтверот: ако зборуваме за сложен софтвер (на пример, ), тогаш фазната адаптација е посоодветна. Ако софтверот е едноставен (месинџер, корпоративен портал), тогаш соодветен модел е кога ќе го објавите датумот и ќе го оневозможите стариот софтвер на назначениот ден (ако имате среќа, вработените ќе имаат време да ги извлечат сите информации што им се потребни , а ако не сметате на среќа, тогаш треба да обезбедите автоматизиран увоз на потребни податоци од стариот систем во новиот, доколку е технички можно).
- Степенот на ризик за компанијата: колку е поризична имплементацијата, толку побавна треба да биде. Од друга страна, доцнењето е исто така ризик: на пример, се префрлате од еден CRM систем на друг, а во периодот на транзиција сте принудени да платите и за двата, а со тоа ги зголемувате трошоците и трошоците за имплементација на новиот систем, кој значи дека периодот на созревање е продолжен.
- Број на вработени: Биг Бенг дефинитивно не е погоден ако треба да размерите и конфигурирате многу кориснички профили. Иако има случаи кога ултрабрзата имплементација е придобивка за голема компанија. Оваа опција може да биде погодна за системи што ги користат многу вработени, но можеби нема барања бидејќи не е наменето прилагодување. Но, повторно, ова е голем удар за крајните корисници и огромна работа чекор-по-чекор за истата ИТ услуга (на пример, систем за наплата или пристап).
- Карактеристики на имплементација на избраниот софтвер (ревизија, итн.). Понекогаш имплементацијата првично е фаза-по-фаза - со собирање барања, префинетост, обука итн. На пример, секогаш се спроведува прогресивно и ако некој ви вети „имплементација и конфигурација за 3 дена или дури 3 часа“ - запомнете ја оваа статија и заобиколете ги таквите услуги: инсталација ≠ имплементација.
Повторно, дури и знаејќи ги наведените параметри, дефинитивно не може да се оди на една или друга патека. Проценете ја вашата корпоративна средина - ова ќе ви помогне и двајцата да ја разберете рамнотежата на моќта и да одредите кој модел (или комбинација од некои од нивните елементи) е вистинскиот за вас.
Агенти на влијание: револуција или еволуција
Првото нешто на што треба да обрнете внимание се вработените кои ќе бидат засегнати од имплементацијата на новиот софтвер. Всушност, проблемот што сега го разгледуваме е чисто човечки фактор, така што не може да се избегне анализа на влијанието врз вработените. Некои од нив веќе ги спомнавме погоре.
- Лидерите на компанијата одредуваат како новиот софтвер ќе биде општо прифатен. И ова не е место за промотивни говори и огнени говори - важно е точно да се покаже потребата од промени, да се пренесе идејата дека ова е само избор на поладна и поудобна алатка, исто како и замена на стар лаптоп. Најголемата грешка на менаџментот во таква ситуација е да ги мие рацете и да се повлече: ако на менаџментот не му е потребна автоматизација на компанијата, зошто таа треба да биде од интерес за вработените? Бидете во процес.
- Раководителите на сектори (проект менаџери) се средна алка која мора да учествува во сите процеси, да управува со незадоволството, да покажува волја и да работи преку секој приговор на колегите и да спроведува висококвалитетна и длабинска обука.
- ИТ сервис (или системски администратори) - на прв поглед, ова се вашите рани птици, најприлагодливите и најприлагодливите, но... не. Често, особено кај малите и средни компании, системските администратори се противат на какви било промени (зајакнување) на ИТ инфраструктурата и тоа не е поради некакво техничко оправдување, туку на мрзеливост и неволност за работа. Кој од нас не барал начини да избегне да работи? Но, ова нека не биде на штета на целата компанија.
- Крајните корисници, како по правило, сакаат да работат добро и удобно од една страна и, како и секој жив народ, се плашат од промени. Главниот аргумент за нив е искрен и едноставен: зошто воведуваме/менуваме, кои се границите на контролата, како ќе се оценува работата, што ќе се промени и кои се ризиците (патем, секој треба да ги оценува ризиците - иако сме продавачи , но не се обврзуваме да кажеме дека сè секогаш оди без проблеми: постојат ризици во секој процес во бизнисот).
- „Властите“ во компанијата се партизани кои можат да влијаат на другите вработени. Ова не мора да е личност со висока позиција или долгогодишно искуство - во случај на работа со софтвер, „надлежниот“ може да биде напреден познавач кој, на пример, го препрочитал Хабр и ќе почне да заплашува сите за тоа колку сè ќе стане лошо. Можеби нема ни цел да го уништи процесот на имплементација или транзиција - само покажување и дух на отпор - и вработените ќе му веруваат. Треба да работите со такви вработени: објаснете, прашајте и во особено тешки случаи, навестете ги последиците.
Постои универзален рецепт за проверка дали корисниците навистина се плашат од нешто или имаат групна параноја предводена од тактичен лидер. Прашајте ги за причините за незадоволството, за загриженоста - ако ова не е лично искуство или мислење, расправиите ќе почнат да се слеваат по 3-4 појаснувачки прашања.
Два важни фактори за успешно надминување на „движењето на отпорот“.
- Обезбедете обука: продавач и внатрешна. Погрижете се вработените навистина да разберат сè, да го совладале и, без разлика на нивното ниво на обука, да се подготвени да започнат со работа. Задолжителен атрибут на обуката се печатените и електронските упатства (прописи) и најкомплетната документација на системот (самопочитуваните продавачи го објавуваат заедно со софтверот и го обезбедуваат бесплатно).
- Барајте поддржувачи и изберете инфлуенсери. Внатрешните експерти и раните посвојувачи се вашиот систем за поддршка, и едукација и отфрлање на сомнежите. Како по правило, самите вработени се задоволни да им помагаат на своите колеги и да ги запознаат со нов софтвер. Ваша задача е привремено да ги ослободите од работата или да им дадете пристоен бонус за нивниот нов обем на работа.
Што треба да барам?
- Колку напредни се вработените засегнати од промените? (Релативно кажано, ако утре измислат нова сметководствена програма, не дај Боже да го пикнете носот во сметководството со дами над 50 години и да предложите премин од 1C, нема да излезете живи).
- Колку ќе бидат засегнати работните текови? Едно е да се смени гласникот во компанија од 100 луѓе, друга работа е да се имплементира нов CRM систем, кој се базира на клучните процеси во компанијата (и ова не е само продажба, на пример, во постарите изданија влијае на производството, магацинот, маркетингот и врвните менаџери кои заедно со тимот ќе градат автоматизирани деловни процеси).
- Дали беше обезбедена обука и на кое ниво?
Единствената логична транзиција во системот на корпоративно размислување
Што ќе ја спаси транзицијата/имплементацијата на нов софтвер?
Пред да ви кажеме кои клучни точки ќе ви помогнат удобно да се префрлите на нов софтвер, дозволете ни да го привлечеме вашето внимание на една точка. Има нешто што дефинитивно не треба да се направи - нема потреба да се врши притисок врз вработените и да се „мотивираат“ со лишување од бонуси, административни и дисциплински санкции. Ова нема да го подобри процесот, но ставот на вработените ќе се влоши: ако туркаат, тогаш ќе има контрола; Ако ве принудат, тоа значи дека не го почитуваат нашиот интерес; Ако тоа насилно го наметнат, тоа значи дека немаат доверба во нас и нашата работа. Затоа, сè правиме дисциплинирано, јасно, компетентно, но без притисок или непотребно форсирање.
Мора да имате детален акционен план
Се друго можеби нема, но мора да има план. Понатаму, планот е прилагодлив, ажуриран, јасен и неизбежен, во исто време достапен за дискусија и транспарентен за сите заинтересирани вработени. Невозможно е директивно да се пренесе дека од 8 до 10 часот има подвиг, а во 16 часот има војна со Англија, важно е да се види целиот план во перспектива.
Планот мора нужно да ги одразува барањата на вработените кои ќе бидат крајни корисници - на овој начин секој вработен точно ќе знае која посакувана карактеристика и во кое време ќе може да ја користи. Во исто време, планот за транзиција или имплементација не е некој вид непроменлив монолит, неопходно е да се остави можноста за финализирање на планот и менување на неговите атрибути (но не во форма на бескраен тек на уредувања и нови „желби“; а не во форма на постојано поместување на роковите).
Што треба да има во планот?
- Главните преодни пресвртници (фази) - што треба да се направи.
- Детални преодни точки за секоја фаза - како тоа треба да се направи.
- Клучни точки и известување за нив (усогласување на часови) - како ќе се мери сработеното и кој треба да биде на контролната точка.
- Одговорни луѓе се луѓе на кои можете да им се обратите и да поставувате прашања.
- Роковите се почеток и крај на секоја фаза и на целиот процес како целина.
- Погодени процеси - какви промени ќе се случат во деловните процеси, што треба да се промени заедно со имплементацијата/транзицијата.
- Конечната проценка е збир на индикатори, метрика или дури и субјективни проценки кои ќе помогнат да се оцени имплементацијата/транзицијата што се случила.
- Почетокот на работа е точниот датум кога целата компанија ќе се приклучи на ажурираниот автоматизиран процес и ќе работи во новиот систем.
Наидовме на презентации на реализатори во кои црвената линија е совет: спроведувајте со сила, игнорирајте ја реакцијата, не разговарајте со вработените. Ние сме против овој пристап, а еве зошто.
Погледнете ја сликата подолу:
Ново глувче, нова тастатура, стан, автомобил, па дури и работа се пријатни, радосни настани, некои од нив се дури и достигнувања. И корисникот оди во Yandex за да дознае како да се навикне и да се прилагоди. Како да влезете во нов стан и да разберете дека е ваш, првпат отворете ја чешмата, пијте чај, легнете првпат. Како да седнете зад воланот и да се дружите со нов автомобил, ваш, но досега толку вонземјанин. Новиот софтвер на работното место не се разликува од опишаните ситуации: работата на вработениот никогаш нема да биде иста. Затоа, имплементирајте, приспособете се, растете со нов ефективен софтвер. И ова е ситуација за која можеме да кажеме: побрзајте полека.
Извор: www.habr.com