Як зрозуміти, що процес вже достатньо описаний і стабільний, щоб його автоматизувати

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

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

Чому «ми і так знаємо, як це робити» — не ознака готовності

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

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

Жодна з цих версій не неправильна сама по собі. Проблема в тому, що їх три. Коли ви автоматизуєте такий процес, система мусить вибрати одну логіку — і два менеджери з трьох одразу відчують, що CRM «заважає працювати». Насправді вона просто забрала у них право робити по-своєму, а готового стандарту, який би всіх влаштовував, ще не існувало.

Опис процесу — це не документ заради документа. Це момент, коли компанія вголос визнає: ми домовились робити саме так, а не інакше. Без цієї домовленості автоматизація будь-якого кроку перетвориться на суперечку «а чому система не дає мені зробити по-своєму».

Три ознаки, що процес дозрів

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

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

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

Приклад: коли опис рятує, а коли шкодить

Клієнт із напрямку роботи з підрядниками хотів автоматично формувати акти виконаних робіт одразу після закриття етапу. Звучить логічно. Але коли ми сіли розписувати процес покроково, виявилось, що «закриття етапу» в різних проєктах означало різні речі: десь це підпис замовника, десь — факт оплати, десь — усне підтвердження в чаті.

Три визначення одного слова в одній компанії — це і є той самий сигнал «процес не готовий». Ми не почали з автоматизації. Спочатку зафіксували одне визначення «закриття етапу» для всіх проєктних менеджерів, прописали, які документи і в якому порядку потрібні для кожного типу підтвердження. Тільки після того, як ця логіка прижилась і перестала викликати суперечки на зборах, ми перенесли її в автоматичне формування актів.

Зворотний приклад — контроль витрат по проєкту. Там правило завжди було одне й те саме: будь-яка витрата понад визначену суму потребує підтвердження керівника. Жодних варіацій, жодних «залежно від настрою». Це описувати довго не довелось — процес уже був стабільний у головах людей, залишалось перенести його в систему.

Що робити, якщо процес ще не готовий

Не намагайтесь автоматизувати процес «попутно», сподіваючись, що система сама його впорядкує. Так не буває. CRM чи будь-яка автоматизація підсилює ту логіку, яку в неї закладено — хаотичну чи чітку, без різниці.

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

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

Коротко про головне

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