Опір ERP: не проблема людей, а джерело важливих сигналів

Фразу «користувачі опираються системі» можна почути майже в кожному ERP-проєкті. Вона зрозуміла, але часто неточна.

Люди рідко опираються технології як такій. Вони реагують на те, що технологія змінює у щоденній роботі: звичні процеси, розподіл відповідальності, рівень контролю, навантаження, вимоги до даних, автономію у прийнятті рішень та взаємодію з іншими підрозділами.

Тому завдання управління змінами — не «подолати опір», а зрозуміти його причини й своєчасно на них відреагувати.

Одна ERP — десятки різних змін

Для фінансового директора ERP може означати швидшу, надійнішу звітність і кращу прозорість. Для бухгалтера — нові правила проведення операцій та вищі вимоги до своєчасності даних. Для менеджера складу — нові сканування, транзакції та контроль запасів. Для закупівельника — стандартизований процес погоджень. Для керівника виробництва — інші планові горизонти й логіка роботи з даними.

Всі ці люди беруть участь в одній програмі. Але для кожного це різна зміна.

Саме тому загальна презентація про переваги ERP не замінює аналізу впливу змін (change impact analysis). Важливо зрозуміти:

• які процеси змінюються для конкретної групи;
• які задачі, рішення та точки контролю будуть іншими;
• які нові навички необхідні;
• що працівники можуть сприймати як втрату або ризик;
• де можуть виникнути проблеми в перехідний період;
• кому потрібне додаткове залучення, навчання, коучинг чи підтримка.

Звідки виникає опір

Опір — природна реакція на невизначеність, втрату звичного способу роботи або відсутність відповідей на важливі питання. Це не автоматично негативне ставлення чи небажання співпрацювати. Що ми бачимо і чуємо: 

• Це незручно! 
• Це незрозуміло і нелогічно!
• Це займає купу часу!
• Це не працює!
• Я цього не просила!
• Поверніть мені Excel або стару звичну систему!

В ERP-впровадженнях найчастіше причинами є:

• незрозуміла причина змін;
• сумніви, що новий процес буде ефективнішим;
• відчуття, що реальна операційна робота не була врахована в дизайні;
• зміна ролей, повноважень або доступу до інформації;
• зростання прозорості й контролю;
• брак часу на навчання паралельно з поточною роботою;
• попередній негативний досвід трансформацій;
• суперечність між новими процесами та чинними KPI або локальними правилами.

Кожна причина потребує іншої відповіді. Комунікація не замінить навчання. Навчання не замінить участі у дизайні. А підтримка після запуску не компенсує процес, який не врахував критичний операційний сценарій.

Аналіз впливу як основа диференційованого підходу

Аналіз впливу допомагає перейти від загального питання «чи готова організація?» до конкретних:

• Хто найбільше змінює свою роботу?
• Які групи критично важливі для успіху на старті?
• Де зміна найскладніша або найбільш ризикована?
• Які ролі варто залучити до тестування та дизайну раніше?
• Де можуть виникати обхідні шляхи?
• Яка підтримка потрібна різним підрозділам?

Наприклад, для закупівель критичними можуть бути новий порядок погодження та відповідальність за нормативно-довідкові дані. Для складу — можливість швидко й безпомилково проводити операції у реальному темпі. Для фінансів — правильне закриття періоду та довіра до нової звітності.

Спільна мета ERP єдина. Але шлях до її прийняття для різних груп — різний.

Лінійний керівник: не тільки передавач інформації

Безпосередній керівник — ключове джерело інформації про те, як зміна вплине на конкретну команду. Саме до нього звертаються з питаннями: «Що це означає для мене?», «Як ми працюватимемо у перші тижні?», «Хто допоможе, якщо виникне проблема?»

У підході Prosci керівники виконують п’ять CLARC-ролей (ролей керівника під час змін):

• Communicator — комунікатор: пояснює зміни;
• Liaison — зв’язкова ланка: підтримує зв’язок між командою та проєктом;
• Advocate — прихильник змін: демонструє підтримку нового способу роботи;
• Resistance Manager — менеджер опору: виявляє та допомагає усунути бар’єри;
• Coach — наставник: допомагає людям опановувати нові навички.

Керівник не зобов’язаний бути SAP-експертом. Але він має бути активним лідером переходу своєї команди.

Що варто зробити до go-live

Щоб зменшити ризик неприйняття ERP, доцільно:

1. Провести аналіз впливу за функціями, ролями, локаціями та управлінськими рівнями.
2. Залучити ключових користувачів до дизайну, тестування і підготовки матеріалів.
3. Створити двосторонні канали зворотного зв’язку, а не обмежуватися розсилками.
4. Підготувати керівників до розмов із командами про локальний вплив змін.
5. Визначити групи з високим ризиком і спланувати для них додаткову підтримку.
6. Аналізувати запитання, помилки та напругу в командах як дані для вдосконалення підходу.

Опір не є провалом управління змінами. Небезпечніше, коли працівники мовчки погоджуються на зустрічах, а після запуску повертаються до старих способів роботи.

З практичного досвіду Alloy LLC: В одній дуже великій компанії був відділ стратегічного планування закупівель і так склалось, що керівником групи впровадження від клієнта, був керівник цього відділу/департаменту. Зазвичай, як було описано вище, користувачів важко залучати до проєкту, тобто по факту він якби залучений а от по суті це стоїть в нього десь на десятому місці, бо є і так важливі задач, а не ваш проєкт. І що тільки не робилось, але залучення явно просідало допоки Генеральний директор на одній з нарад, а це був перший квартал року, не сказав що на його місці він би порекомендував керівнику відділу стратегічних закупівель подумати над своїм подальшим працевлаштуванням, бо на минулий рік його відділ прогнозував закупівлю у розмірі 4 ххх грошей, а по факту вийшло 2 ххх грошей, а в таких кордонах 4 або 2 він і сам може прогнозувати і без відділу планування стратегічних закупівель в якому, до речі, було десь більше 15 співробітників. І знаєте – як пошептали, з’явилось стільки енергії на участь в проєкті. Коротше, от що “пендель цілющий робить” (читайте Статтю 2 цього циклу про роль спонсора / топ-менеджменту проєкту). І робота пішла, і проєкт став цікавим.