Чек-лист аудиту процесу перед автоматизацією

Визначте межі процесу

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

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

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

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

Пройдіть поточний процес на реальних прикладах

Інтерв’ю з командою корисне, але люди часто описують бажаний порядок, а не фактичну роботу. Візьміть кілька завершених кейсів і відновіть послідовність за листуванням, статусами, файлами та журналами. Це покаже реальні очікування, обхідні шляхи й ручні виправлення.

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

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

Призначте власника процесу та ролі

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

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

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

• Хто затверджує правила й критерії приймання?
• Хто отримує винятки та прострочені задачі?
• Хто має право повторити, скасувати або виправити операцію?
• Хто відповідає за актуальність процесу після запуску?

Перевірте дані та джерело правди

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

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

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

Створіть каталог винятків

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

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

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

• Неповні, суперечливі або дубльовані дані.
• Недоступність CRM, API, пошти чи месенджера.
• Дії, що потребують підтвердження людини.
• Повторний запуск після частково виконаної операції.

Оберіть метрику тестового запуску

Метрика має бути доступною до початку розробки. Якщо команда не знає поточний час обробки або частку помилок, після запуску буде складно довести результат. Достатньо невеликої базової вибірки, але спосіб вимірювання повинен бути однаковим до і після.

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

Додайте захисні метрики. Якщо система прискорила відповідь, але збільшила кількість неправильних маршрутів, успіх сумнівний. Тому поруч з основним показником потрібні якість, частка винятків і кількість ручних виправлень.

Обмежте ризики та повноваження

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

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

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

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

Що має залишитися після аудиту

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

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

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