Софтверна чехарда незабаром стане дуже поширеною хворобою компаній. Міняти один софт на інший через кожну дрібницю, стрибати з технології на технологію, експериментувати на живому бізнесі стає нормою. При цьому в офісі починається справжня громадянська війна: формується рух опору впровадженню, партизани ведуть підривну роботу проти нової системи, шпигуни пропагують новий чудовий світ з новим софтом, керівництво з броньовика корпоративного порталу веде мовлення про мир, працю, 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