CRM та бізнес-процеси, що може бути не так?
У компанії може бути CRM та бізнес-процеси, можуть бути їхні статуси, й завдання, що створені за бізнес-процесом, автоматизації та звіти… Але при всьому цьому керівник усе одно не знає, де перебуває конкретне замовлення. Не тому, що інформації немає — її може бути навіть забагато. Проблема в іншому: незрозуміло, яку саме інформацію вважати ознакою того, що робота перейшла на наступний етап.
У цій статті розберемо, чому так відбувається і де пролягає межа між налаштуванням кнопок у програмі та реальною керованістю роботи.
Чи визначені у вас процеси і як ви це реалізували?
У подібних ситуаціях проблему часто шукають у самій CRM. Починають змінювати програму, додавати нові поля, переналаштовувати статуси чи намагатися прописати автоматичні сповіщення.
Але питання виникає раніше: а сам процес у компанії взагалі хтось визначив?
Не намалював схему на презентації. Не створив десять статусів у системі. А саме визначив: що запускає роботу, що повинно відбутися далі, хто за це відповідає і за якої умови можна сказати, що крок справді виконано. Але все це потрібно, щоб реалізувати робочу модель CRM та бізнес-процеси автоматизувати з її допомогою.
Різне розуміння однієї роботи та систематизація бізнес-процесів
Якщо запитати кількох людей в одній компанії, як у них проходить звичайне замовлення, можна отримати зовсім різні відповіді. І всі будуть по-своєму праві, бо бачать лише власну частину процесу.
Менеджер поставить задачу — і для нього робота передана. Виконавець її ще не відкривав — і для нього вона не передана. Бухгалтер чекає підписаний документ і взагалі не бере це замовлення до уваги. А керівник бачить у системі статус «В роботі» й розраховує, що хтось прямо зараз закриває завдання.
У CRM при цьому все може виглядати цілком пристойно. Але сама по собі програма не вирішить, чия картина світу правильна. Вона лише дасть усім учасникам віконця для фіксації їхніх власних уявлень. Якщо єдиної логіки немає у звичках і домовленостях, система просто зафіксує цю плутанину в цифровому вигляді.
Визначений процес — це не список статусів, а впровадження CRM
Якщо прибрати CRM і попросити людей пояснити на одному конкретному замовленні, що відбулося від початку до кінця, відповіді мають приблизно збігатися. Не слово в слово, але логіка має бути одна:
- Звідки прийшла робота;
- Що саме перевірили перед стартом;
- Хто її прийняв;
- Що є умовою переходу далі;
- Що означає «готово».
Якщо на ці питання кожен відповідає по-своєму, проблема ще не в софті.
Програма CRM та бізнес-процеси — це лише й тільки середовище. Вона зберігає записи, нагадує про дати чи пересуває картку етапами. Але вона не знає реальних умов вашого бізнесу. Коли в системі стоїть статус «В обробці», програмі байдуже, що за цим ховається. Якщо для менеджера це означає «подумаю завтра», а для керівника — «уже відвантажуємо», то система сумлінно покаже звіт, за яким стоїть звичайний операційний хаос.
CRM і бізнес-процеси: Цифрова пам’ять й приватні листування
Коли процес не визначений, пам’ять про роботу залишається в нотатках або особистих месенджерах співробітників.
Якщо менеджер захворів чи пішов у відпустку, робота зупиняється. Новий працівник відкриває картку в CRM, але все одно йде питати колег: що обіцяли клієнту, на чому зупинилися і чому виникла затримка.
Формально система заповнена. Але вона не працює як цифрова пам’ять компанії. Пам’ять — це не список телефонів, а зафіксований перебіг дій: які дані зібрано, яке рішення прийнято і яка дія має відбутися далі. Якщо для з’ясування стану справи треба піднімати приватні листування або телефонувати працівникам, наявність CRM проблему не вирішила.
Межі автоматизації
Автоматизувати можна лише те, що вже має чітку послідовність.
Якщо є домовленість, що після підтвердження готовності деталі клієнту йде SMS — автоматика працює без збоїв. Але якщо всередині компанії немає згоди, хто саме й за якими критеріями перевіряє цю готовність, то автоматизація лише пришвидшить надсилання помилкових повідомлень.
CRM може дуже добре виконувати те, що їй налаштували. Проблема виникає тоді, коли самі правила роботи ніхто толком не сформулював.
З чого почати
Якщо софт у компанії існує окремо від реальної роботи, тобто не пов’язані між собою CRM та бізнес-процеси, варто на час відкласти налаштування кнопок.
Можна зробити простішу річ: взяти одне реальне замовлення й пройти його разом із командою за тим сценарієм, як це відбувається в житті. Подивитися, де робота зупиняється, де передача йде «на словах», а де кожен трактує статус по-своєму.
Часто з’ясовується, що проблема взагалі не в програмі. Вона в тому, що всередині компанії ще немає спільних правил. І тільки коли ці правила стають зрозумілими, налаштування інструменту стає звичайною технічною задачею.
CRM для бізнес-процесів, потреба уточнення
Якщо правила роботи потребують уточнення, постає наступне запитання: а що саме треба визначати в першу чергу?
Зазвичай намагаються описати одразу все діяльність — і опиняються в новій павутині з регламентів. Але починати варто не з правил взагалі, а з об’єкта управління.
Потрібно зрозуміти, навколо чого розгортається робота: це картка клієнта, окреме замовлення, деталь на виробництві, автомобіль у сервісі чи проєкт? Плутанина в CRM найчастіше виникає тоді, коли компанія намагається контролювати складний процес через один універсальний об’єкт — наприклад, розмиваючи весь ремонт чи виробництво всередині звичайної «угоди».
У наступному матеріалі розберемо цю тему детальніше:
👉 Клієнт, замовлення, робота: що саме має бути окремим об’єктом управління (посилання на продовження дискусії стане активним після виходу наступної публікації серії)
iCOLOR користується OneBox OS та впроваджує саме цю систему з 2016 року.
