Гроші за впровадження заплачені, система налаштована, навчання проведено. Через два місяці виявляється, що менеджери ведуть клієнтів у старій таблиці, а в нову систему заносять дані наприкінці тижня «щоб було».
Це найдорожчий сценарій автоматизації: витрати понесені, ефекту немає. І майже ніколи причина не в тому, що «люди не хочуть змін».
Чотири справжні причини
Так довше. Найчастіша й найзрозуміліша. У таблиці рядок заповнюється за десять секунд, у системі — за хвилину: обовʼязкові поля, вибір зі списків, кілька екранів. Людина з десятками клієнтів на день робить раціональний вибір на користь швидшого способу.
Користь дістається не тому, хто вводить дані. Менеджер витрачає час на заповнення, а звіти читає керівник. Із погляду виконавця це чиста додаткова робота. Поки він не побачить власної вигоди — нагадування про дзвінок, історія клієнта під рукою, менше пояснень із колегами — мотивації не буде.
Автоматизували хаос. Якщо процес не був описаний, у системі відтворили плутанину зі старого порядку, тільки з обовʼязковими полями. Про це є окремий матеріал про те, як описати бізнес-процес перед автоматизацією.
Страх контролю. Іноді опір справді про це: у системі видно, скільки заявок оброблено й скільки загублено. Тут допомагає не переконування, а чесна розмова про те, як ці дані використовуватимуться.
Що зробити до запуску
Показати вигоду кожній ролі окремо. Не «компанія стане ефективнішою», а «тобі не доведеться шукати по чатах, що обіцяли клієнту минулого місяця».
Прибрати всі поля, без яких можна жити. На старті лишіть мінімум обовʼязкового. Додати поле згодом легко, привчити заповнювати десять полів із першого дня — майже неможливо.
Взяти в команду свою людину. Не керівника й не підрядника, а того, хто працює в системі щодня й до кого підходять із питаннями. Логіка ролі така сама, як у матеріалі про те, хто відповідає за сайт у компанії.
Перенести дані так, щоб у системі було все потрібне. Якщо половина історії лишилася в старій таблиці, люди відкриватимуть обидва вікна — і швидко повернуться до одного, старого. Що переносити, а що ні, розібрано в матеріалі про міграцію даних у нову систему.
Перші два місяці
Плануйте падіння продуктивності на перші два тижні — це нормальна плата за перехід, а не ознака невдачі.
Далі — короткі щотижневі зустрічі на пʼятнадцять хвилин з одним питанням: що незручно. Зібрані незручності мають перетворюватися на правки в налаштуваннях, інакше зустрічі перестануть мати сенс і люди замовкнуть.
Паралельна робота в старому й новому інструменті допустима не більше двох-трьох тижнів. Довше — і подвійний облік стане нормою назавжди.
І обовʼязково закрийте старий канал у визначену дату, попередивши заздалегідь. Але тільки після того, як у новій системі стало не повільніше, ніж було.
Навчання, після якого щось залишається
Дводенний семінар із демонстрацією всіх можливостей — найпоширеніший і найменш дієвий формат. Через тиждень у памʼяті не лишається майже нічого, бо показане не стосувалося конкретної роботи конкретної людини.
Працює інший підхід: коротке навчання під роль. Менеджеру показують рівно те, що він робитиме щодня, — прийняти заявку, поставити наступний крок, знайти клієнта. Тридцять хвилин замість двох днів.
Друга обовʼязкова частина — короткі письмові інструкції на три-пʼять кроків із зображеннями екрана, які лежать там, де їх шукатимуть. Як вести такий набір, описано в матеріалі про базу знань для команди.
І третє: перший тиждень поруч має бути людина, до якої можна підійти з дрібним питанням без відчуття, що відриваєш когось важливого.
Як зрозуміти, що впровадження зупинилося
Ознаки видно в самій системі: записи зʼявляються пачками наприкінці тижня, а не в момент дії; більшість карток заповнена мінімально; у коментарях порожньо, зате в робочому чаті обговорюють тих самих клієнтів.
Ще один симптом — питання «а де подивитися» через два місяці після навчання. Це не про памʼять, а про те, що людина туди не заходить.
Регулярний перегляд цих ознак — частина супроводу, а не разова акція. Про те, у що це виливається за витратами, є матеріал про підтримку системи після впровадження, а типові прорахунки зібрані в матеріалі про помилки автоматизації.
Коротко
Команда уникає нової системи не через консерватизм, а через чотири конкретні причини: у ній повільніше, вигоду отримує не той, хто вводить дані, автоматизували неописаний хаос або люди бояться контролю. До запуску варто пояснити вигоду кожній ролі окремо, залишити мінімум обовʼязкових полів, призначити відповідального зсередини команди й перенести дані так, щоб не доводилося тримати два вікна. Перші два тижні продуктивність падає — це нормально; далі потрібні короткі щотижневі збори незручностей із реальними правками. Паралельна робота в старому інструменті допустима два-три тижні, не довше. А якщо записи зʼявляються пачками наприкінці тижня — впровадження вже зупинилося, і повертати процес треба зараз.
Ми в Obliko впроваджуємо системи разом із командою клієнта: спочатку прибираємо зайві кроки, потім навчаємо — і лише потім закриваємо старі канали.
Чому співробітники повертаються до Excel після впровадження CRM?
Майже завжди тому, що в новій системі та сама дія займає більше часу, ніж у таблиці, і людина не бачить, що отримує натомість. Друга причина — система вимагає заповнювати поля, які потрібні керівнику, а не виконавцю. Якщо працювати в ній повільніше, а користі особисто для себе немає, повернення до старого способу неминуче.
Чи допоможе заборонити старі інструменти наказом?
Заборона працює лише разом із поясненням і спрощенням. Якщо просто закрити доступ до таблиць, не прибравши зайві поля й не показавши вигоди, люди почнуть вести облік «в столі» — у блокноті чи особистому чаті, і дані стануть ще менш повними, ніж були.
Скільки часу займає звикання до нової системи?
Для простих інструментів — від тижня до місяця активної роботи. Перші два тижні продуктивність зазвичай падає, і це нормально: люди роблять звичні дії повільніше. Якщо через два місяці частина команди досі уникає системи — справа не у звичці, а в самому процесі або в тому, що ніхто не відповідає за впровадження.
Кого призначити відповідальним за впровадження?
Людину зсередини команди, яка щодня працює в системі й має авторитет у колег, а не лише керівника чи зовнішнього підрядника. Її завдання — збирати незручності, домовлятися про зміни в налаштуваннях і показувати колегам робочі прийоми. Без такої ролі впровадження зупиняється на другому місяці.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.