Чому користувачі опираються новим ІТ-системам
Перш ніж проєктувати систему, яку люди приймуть, треба зрозуміти, звідки береться опір. За даними McKinsey, 70% проєктів цифрової трансформації не досягають цілей, і причина здебільшого в людях, а не в технологіях. Працівники рідко опираються зі злості чи лінощів. За небажанням стоять глибші, часто несвідомі механізми.
Страх перед невідомим і втратою компетенцій
Людина, яка 10 років доводила до досконалості роботу в старій системі, раптом має починати з нуля. Її експертиза, набута роками, за одну ніч втрачає цінність. Це викликає страх утратити статус чи навіть роботу. Дослідження Prosci показують, що 39% працівників бояться не впоратися з новими інструментами, а 25% тривожаться за своє місце в компанії.
Звичка й комфорт статус-кво
Мозок економить енергію. Знайомі процедури ми виконуємо автоматично, нові вимагають свідомих зусиль. Навіть якщо стара система явно гірша, вона «наша»: ми знаємо її вади й уміємо їх обходити. Нова система є невідомим, яке вимагає зусиль.
Поганий досвід минулого
Якщо попереднє впровадження скінчилося хаосом, понаднормовою роботою та розчаруванням, люди скептично ставитимуться до наступного. Пам'ять організації про невдачі працює як сигналізація: на будь-яку згадку про зміни вмикається захист.
Немає відповіді на питання «навіщо»
Люди приймають зміни, коли розуміють їхній сенс. Якщо нову ERP подають як «рішення керівництва» і ніхто не пояснює, що вона змінить у щоденній роботі, опір майже неминучий. За даними Gallup, працівники, які розуміють мету змін, у 3,5 раза більше залучені до їх упровадження.
Принципи проєктування для користувачів, які опираються змінам
Психологія пояснює проблему. Розв'язання починається на етапі проєкту, коли можна зменшити тертя й подбати про зручність. Добре спроєктовані й добре впроваджені системи можуть підвищити рівень прийняття аж на 80%.
Знайомість: еволюція замість революції
Найкращі системи не виглядають цілком новими. Вони використовують знайомі шаблони інтерфейсу, мають подібну навігацію й посилаються на інструменти, якими люди вже користуються. Якщо команда продажів живе в Excel, нова CRM має пропонувати вигляд, подібний до електронної таблиці, експорт в Excel і схожі гарячі клавіші.
Дослідження Nielsen Norman Group показують, що користувачі опановують інтерфейс на 40% швидше, коли він спирається на знайомі шаблони. Це не означає копіювання старого рішення. Мова про міст між відомим і новим.
Поступове розкриття (progressive disclosure)
Не показуйте все одразу. Новий користувач має бачити найпростішу версію системи, лише з функціями, потрібними на старті. Розширені опції розкривайте поступово, коли він набере впевненості й сам почне їх шукати.
Цю техніку застосовують Google та Apple. Вона сильно знижує перший бар'єр. Користувач не почувається перевантаженим сотнями опцій і вважає систему простою, хоч під поверхнею багато можливостей.
Шлях назад
Дайте людям змогу повернутися до знайомого: кнопка «скасувати», експорт даних у старий формат, робота в обох системах на перехідний період. Парадоксально, такі шляхи назад підвищують прийняття. Користувачі охочіше пробують нові функції, коли знають, що можуть безпечно відступити.
Негайна цінність
Перший досвід роботи із системою має дати щось конкретне. Не за тиждень і не після навчання, а зараз. Це може бути автоматично заповнена картка клієнта, влучна підказка чи звіт одним кліком. Такий «момент прозріння» створює позитивні асоціації й заохочує досліджувати далі.
За даними Pendo, 80% користувачів оцінюють цінність застосунку протягом перших 3-5 хвилин. Ці хвилини треба виграти.
Як залучити користувачів до проєктування
Система, яку проєктують «для користувачів» без їхньої участі, рідко вдається. Залучення майбутніх користувачів покращує продукт і водночас є одним із найкращих інструментів управління змінами.
Знайдіть «чемпіонів» і залучіть їх до роботи
У кожній організації є люди, які попри загальний опір відкриті до нових рішень. Знайдіть їх, залучіть до проєктування й зробіть речниками змін. Їхні зауваження формують продукт, а їхній ентузіазм заразний.
Шукайте їх серед тих, хто повідомляє про проблеми в поточних системах, пропонує покращення чи сам пробує нові інструменти. Це природні лідери змін, яким потрібна лише підтримка.
Воркшопи з реальними користувачами
Перш ніж хтось напише перший рядок коду, проведіть воркшопи з представниками всіх груп користувачів. Не щоб зібрати вимоги, а щоб зрозуміти їхню справжню роботу. Які завдання вони виконують найчастіше? Де втрачають найбільше часу? Що їх дратує в нинішніх інструментах?
Воркшопи мають і другий наслідок: вони створюють відчуття співвласності. Користувач, який бачить свої зауваження в проєкті, захищає систему замість того, щоб її критикувати.
Прототипи й тестування з користувачами
Покажіть прототипи, перш ніж вкладатися в повну розробку. Навіть прості клікабельні макети допомагають виявити проблеми та зібрати відгуки. Заодно вони привчають людей до майбутньої зміни, тож готовий продукт не стане для них шоком.
Дослідження IBM показують, що виправлення помилки, виявленої на етапі прототипу, коштує приблизно в 100 разів менше, ніж після запуску в роботу. Ви заощаджуєте гроші, а ще репутацію системи, яка дуже важлива для прийняття.
Стратегії впровадження, що зменшують опір
Навіть добре спроєктована система може не прижитися, якщо впровадження невдале. Спосіб запровадження змін так само важливий, як і самі зміни.
Пілот замість «великого вибуху»
Не запускайте систему в усій компанії за один день. Почніть із пілотної групи. Оберіть команду, відкриту до експериментів і водночас типову для решти організації. Її досвід допоможе доопрацювати систему й дасть іншим справжні історії успіху.
Пілот також дає час виявити проблеми, перш ніж вони зачеплять усю компанію. Краще виправити критичну помилку з 20 користувачами, ніж із 2000.
Паралельна робота двох систем
Протягом визначеного часу, зазвичай від 2 до 4 тижнів, дозвольте працювати в обох системах. Так, це додаткова робота. Але користувачі почуваються безпечніше, а ви можете перевірити, чи нова система обробляє всі сценарії.
Призначте чітку дату завершення. Паралельна робота не може тривати вічно, бо люди ніколи повністю не перейдуть на нову систему.
Говоріть про вигоди, а не про функції
У комунікації під час впровадження говоріть про те, що користувачі здобудуть, а не про те, що система робить. Замість «нова CRM має модуль звітності з 50 шаблонами» скажіть «місячний звіт ви зробите за 2 хвилини замість 2 годин». Особисті вигоди, як-от економія часу, менше роздратування й легша робота, мотивують сильніше, ніж вигоди для організації.
Навчання та підтримка у прийнятті системи
Навчання не є разовою подією. Воно починається до впровадження й триває довго після нього.
Навчання під конкретні завдання
Класичний тренінг «ось усі функції системи» працює слабко. Люди запам'ятовують від 10 до 20% показаного матеріалу, а решту забувають, ще не повернувшись до робочих місць. Набагато краще працюють короткі сесії, присвячені конкретним завданням.
Допомога, вбудована в застосунок
Найкращі системи навчають самі. Інтерактивні посібники, підказки в контексті та короткі відеоінструкції просто в застосунку знижують бар'єр і зменшують кількість звернень до підтримки.
За даними WalkMe, компанії, які використовують вбудований онбординг, досягають на 50% вищого прийняття, ніж ті, що покладаються лише на традиційне навчання.
Підтримка поруч у перші тижні
Перші тижні після впровадження критичні. Користувачі натрапляють на проблеми, яких ніхто не передбачив на навчанні, а без швидкої допомоги повертаються до старих звичок. Виділена лінія підтримки, чергування консультантів, канал у Slack з експертами: усе, що скорочує шлях від проблеми до відповіді, підвищує шанси на успіх.
Як вимірювати прийняття й реагувати на проблеми
Запуск є початком постійного вдосконалення, а не кінцем роботи. Без вимірювання прийняття ви не знаєте, чи система справді працює.
Ключові показники прийняття
Дивіться не лише на те, чи люди входять у систему, а й на те, як вони нею користуються. Які функції вони використовують, а які оминають? Де зупиняються чи здаються? Ці дані показують проблеми, перш ніж ті виростуть у відкритий опір.
Типові показники: щоденна й щотижнева активність користувачів (DAU і WAU), частка завершених ключових процесів, час виконання типових завдань і кількість звернень до підтримки.
Петля зворотного зв'язку
Спростіть надсилання відгуків: кнопка в застосунку, регулярні опитування, зустрічі з користувачами. Важливіше, щоб ви реагували на ці відгуки й казали, що змінилося. Користувачі, які бачать, що їхній голос має вагу, стають союзниками, а не критиками.
Вдосконалення малими кроками
ІТ-система не витвір мистецтва, яким милуються. Це живий організм, що має розвиватися разом із потребами користувачів. Плануйте регулярні цикли вдосконалень, бо малі й часті оновлення сприймаються краще, ніж рідкісні радикальні зміни.
Проєктуйте для людей, а не проти них
Опір змінам не ворог, якого треба перемогти, а сигнал, який варто зрозуміти й використати. Люди опираються змінам, що ігнорують їхні потреби, порушують відчуття безпеки або здаються безглуздими. Система, спроєктована з емпатією й упроваджена обачно, має шанс не просто бути прийнятою, а стати інструментом, яким люди хочуть користуватися.
Що варто запам'ятати:
Зрозумійте психологічні причини опору, перш ніж проєктувати
Будуйте на знайомому: еволюція замість революції
Залучайте користувачів з перших етапів проєкту
Давайте цінність у перші хвилини використання
Впроваджуйте поступово й чітко говоріть про вигоди
Вимірюйте прийняття та швидко реагуйте на проблеми
Найкраща система та, якою люди хочуть користуватися, а не та, якою мусять.
Якщо ви хочете систему, адаптовану до процесів вашої компанії, зв'яжіться з нами. Допоможемо перетворити бізнес-цілі на ІТ-рішення, які ваші співробітники справді приймуть. Ми проєктуємо CRM, ERP та системи автоматизації з думкою про людей, а не лише про перелік функцій.
