Чому 70% трансформацій зазнають невдачі

Більшість програм трансформації зазнають невдачі. Вони не досягають своїх цілей.

Я керував змінами в галузі AI та ERP у Novartis. Я побачив правду. Технології — це не найскладніша частина. Програмне забезпечення часто працює добре. Люди просто відмовляються ним користуватися.

Коли проєкт провалюється, керівники звинувачують дані або обсяг робіт. Але це лише симптоми. Справжня причина — рівень прийняття (adoption). Більшість компаній сприймають прийняття як разовий захід із навчання наприкінці. Воно має бути правилом проєктування з самого початку.

Інструмент не приносить жодної цінності, якщо люди його уникають. Я бачив ідеальне програмне забезпечення з рівнем використання лише 30%. Замість нього люди продовжували використовувати старі електронні таблиці.

Ви не отримуєте ROI від придбаного програмного забезпечення. Ви отримуєте ROI від програмного забезпечення, яким люди реально користуються.

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

Щоб виправити це, вам потрібна психологічна безпека. Люди повинні відчувати, що вони можуть безпечно сказати: «Я цього не розумію» або «цей процес зламаний». Без відчуття безпеки люди приховують своє нерозуміння. Приховане нерозуміння призводить до прихованих обхідних шляхів. Обхідні шляхи призводять до провалу.

Дотримуйтесь цього плану, щоб перемогти:

  • Визначте перемогу: Перш ніж щось будувати, пропишіть, як зміниться робота конкретної ролі. Якщо ви не можете показати вигоду для цієї людини, у вас немає плану. У вас є лише розгортання (rollout).
  • Залучайте скептиків: Не спілкуйтеся лише з прихильниками. Посадіть найгучнішого скептика в кімнаті проєктування. Вони виявляють реальні проблеми на ранніх етапах. Коли скептик погоджується з планом, інші підуть за ним.
  • Ведіть за собою чесно: Просіть керівників визнавати помилки. Один чесний момент від керівника будує більше довіри, ніж багато опитувань.
  • Винагороджуйте за чесність: Дякуйте людям, які повідомляють про помилкові кроки. Вони здійснюють контроль якості для вас.
  • Вимірюйте правильні речі: Не відстежуйте лише бюджет і дати. Відстежуйте, скільки людей використовують інструмент і як часто вони вдаються до обхідних шляхів.
  • Виправляйте та повідомляйте: Коли ви вирішуєте проблему, повідомте про це всіх. Покажіть їм, що можливість висловитися змінює систему.

Ставтеся до довіри як до інфраструктури. Ви повинні проєктувати її та закладати на неї бюджет так само, як на свій технологічний стек.

Припиніть аудит своєї архітектури. Почніть запитувати свою команду: «Що могло б зробити це кращим для вас і про що ви боїтеся мені сказати?»

Ті 30%, які перемагають, — це ті, хто вміє слухати.

Source: https://dev.to/cedricbignet/why-70-of-transformations-fail-and-the-people-first-fix-1ff

Optional learning community: https://t.me/GyaanSetuAi