Автоматизація закріплює правила процесу в системі. Якщо правила не описані, розробник змушений відновлювати їх із суперечливих пояснень, а працівники очікують різну поведінку. У результаті система може технічно працювати, але не відповідати реальному бізнесу.
Якісний опис не обов'язково має бути складною нотацією. Для більшості малих і середніх компаній достатньо однієї зрозумілої карти та таблиці правил, якщо вони охоплюють основний потік, рішення й винятки.
Спочатку визначте межі процесу
Назва «обробка замовлення» занадто широка. Для одного працівника вона починається з дзвінка, для іншого — з оплати, а для складу — зі списку на комплектацію. Тому зафіксуйте чотири межі:
- Подія запуску: що саме створює новий екземпляр процесу.
- Вхід: які дані й документи потрібні для початку.
- Результат: який перевірений стан означає завершення.
- Власник: хто відповідає за результат усього процесу, а не окремого кроку.
Приклад: процес починається, коли сайт передає підтверджене замовлення. Завершується, коли склад отримує коректне завдання на комплектацію із зарезервованим товаром. Доставка та повернення до першої межі не входять.
Мінімальний паспорт процесу
| Поле | Що записати | Приклад |
|---|---|---|
| Мета | Бізнес-результат, а не дія системи | Передати складу повне й перевірене замовлення |
| Старт | Конкретна подія | Сайт створив підтверджене замовлення |
| Фініш | Перевірюваний стан | Товар зарезервовано, завдання складу створено |
| Власник | Відповідальний за результат | Керівник відділу продажів |
| Учасники | Ролі, а не прізвища | Менеджер, склад, бухгалтер |
| Системи | Джерела та отримувачі даних | Сайт, облік, служба доставки |
| Показники | Час, якість, вартість | Час до резерву, частка виправлень |
Паспорт потрібен до малювання кроків. Він не дозволяє непомітно розширювати проєкт і додає спільний критерій завершення.
Опишіть поточний процес AS-IS
Не починайте з бажаної системи. Спочатку зафіксуйте, як робота виконується зараз, включно з таблицями, чатами, телефонними уточненнями та ручними обхідними діями. Інакше критична залежність виявиться вже після запуску.
Для кожного кроку запишіть:
- номер і коротку назву;
- роль виконавця;
- подію або результат попереднього кроку;
- вхідні дані;
- дію;
- результат і новий статус;
- нормальний строк;
- можливу помилку або виняток.
| Крок | Роль | Вхід | Дія | Результат | Виняток |
|---|---|---|---|---|---|
| 1. Отримати | Менеджер | Замовлення із сайту | Перевірити контакти та склад позицій | Замовлення прийнято | Немає телефону або адреси |
| 2. Перевірити залишок | Менеджер | Позиції та кількість | Звірити доступний товар | Наявність підтверджена | Дефіцит або резерв іншого клієнта |
| 3. Підтвердити умови | Менеджер | Ціна, оплата, доставка | Перевірити стандартні умови | Умови погоджено | Індивідуальна знижка |
| 4. Зарезервувати | Система або менеджер | Підтверджене замовлення | Створити резерв | Товар недоступний іншим замовленням | Залишок змінився |
| 5. Передати складу | Менеджер | Замовлення з резервом | Створити завдання | Склад бачить актуальну версію | Замовлення змінене після передачі |
Відокремте дію від рішення
Крок «перевірити замовлення» приховує кілька рішень. Системі потрібні точні умови:
- які поля обов'язкові;
- який залишок вважається доступним;
- коли дозволена післяплата;
- яка знижка проходить без погодження;
- що робити з частковою наявністю;
- хто може змінити замовлення після резерву;
- коли потрібне повторне завдання складу.
Правило записують у формі «якщо — то — інакше» та додають джерело даних. Наприклад: якщо всі позиції доступні, сума не перевищує ліміт післяплати й адреса пройшла перевірку, створити резерв автоматично; інакше передати замовлення менеджеру із зазначенням причини.
Створіть окремий реєстр винятків
Винятки не потрібно приховувати або намагатися автоматизувати всі в першому релізі. Для кожного винятку визначте:
- як система його виявляє;
- які дані показує людині;
- хто приймає рішення;
- скільки часу дозволено;
- як процес повертається в основний потік;
- який слід рішення зберігається.
| Виняток | Ознака | Відповідальний | Рішення | Повернення в процес |
|---|---|---|---|---|
| Недостатній залишок | Доступно менше замовленого | Менеджер | Заміна, очікування або часткова відвантаження | Оновити склад замовлення й повторити резерв |
| Нестандартна знижка | Перевищено ліміт ролі | Керівник продажів | Погодити або відхилити | Зафіксувати ціну та продовжити перевірку |
| Зміна після передачі | Версія замовлення новіша за завдання | Склад і менеджер | Зупинити старе завдання | Створити нову актуальну версію |
Намалюйте TO-BE лише після AS-IS
Майбутній процес не повинен бути цифровою копією кожної ручної дії. Перевірте кожен крок:
- чи потрібен він для результату або контролю ризику;
- чи можна отримати дані без повторного введення;
- чи може правило виконуватися автоматично;
- чи можна об'єднати перевірки;
- чи має людина приймати рішення або лише підтверджує очевидне;
- які події треба журналювати.
У прикладі менеджер більше не переносить замовлення й не перевіряє стандартні випадки. Система створює документ, перевіряє поля, резервує товар і передає завдання. Менеджер працює лише з чергою винятків.
Опишіть дані та єдине джерело правди
Для кожного ключового поля вкажіть джерело, формат, власника та момент оновлення. Особливо це стосується ціни, доступного залишку, резерву, статусу оплати, контактів клієнта й версії замовлення.
Якщо сайт і склад мають різні залишки, автоматизація лише пришвидшить конфлікт. До запуску потрібно визначити, яка система є джерелом правди та як інші отримують оновлення.
Додайте права та журнал подій
Карта процесу має відповідати на питання не лише «що відбувається», а й «хто має право». Зафіксуйте, хто може змінювати ціну, скасовувати резерв, повертати процес на попередній етап і закривати виняток. Для значущих дій зберігайте автора, час, старе й нове значення та причину.
Сформулюйте критерії приймання
Критерій має перевіряти бізнес-поведінку. Наприклад:
- стандартне замовлення автоматично отримує резерв не пізніше ніж за одну хвилину;
- замовлення без обов'язкового поля не переходить на склад і містить зрозумілу причину;
- зміна кількості після резерву створює нову версію завдання;
- менеджер бачить одну чергу всіх винятків із строком;
- кожне рішення щодо знижки записується в історії;
- показники до й після запуску рахуються за однаковими правилами.
Фрази «має бути зручно» або «все повинно працювати швидко» не є критеріями приймання.
Типові помилки опису
- Описується лише щасливий шлях. Перший виняток зупиняє роботу.
- Використовуються прізвища замість ролей. Процес ламається після кадрової зміни.
- Кроки названі надто загально. Усередині приховані рішення без правил.
- AS-IS одразу підмінюють бажаною схемою. Втрачаються фактичні залежності.
- Не визначене джерело даних. Системи показують різні стани.
- Немає версії процесу. Після змін незрозуміло, за якими правилами тестувати.
- Не встановлені показники. Неможливо довести результат автоматизації.
Готовий результат підготовки
Перед розробкою команда повинна мати паспорт процесу, карту AS-IS, карту TO-BE, таблицю правил, реєстр винятків, перелік джерел даних, матрицю прав і критерії приймання. Для невеликого процесу це може вміститися в кілька сторінок і одну схему.
Опис погоджують власник процесу, ключові виконавці та технічний відповідальний. Погодження не означає, що документ незмінний: номер версії та журнал змін дозволяють коректно оновлювати правила.
Процеси в Business Reactor
Business Reactor пов'язує ролі, статуси, документи, товари та операції в одному контурі. Завдяки цьому карта не залишається окремою презентацією: її правила можна зіставити з реальними правами, подіями й даними системи.
Після опису процесу потрібно перевірити економічну доцільність: скільки коштує поточна робота, які втрати реально зникнуть і за який строк окупиться впровадження.
Висновок
Коректний опис процесу починається з меж і бізнес-результату. Потім фіксуються поточні кроки, рішення, дані та винятки, і лише після цього проєктується майбутній порядок роботи. Така карта зменшує суперечності й дає перевірювані критерії для розробки.
Наступний крок — перевести час, помилки й затримки у фінансову модель та розрахувати окупність автоматизації. Основа системи Business Reactor.
