Програма для опису бізнес процесів зазвичай потрібна аналітику, який малює схеми для великої компанії. Власнику, який хоче навести лад у замовленнях або автоматизувати їх, потрібне інше: текст, за яким сторонній розробник зрозуміє, як у вас іде замовлення, як рахується ціна, хто що робить і які документи виходять на кожному етапі.
Якщо ви вже шукали такий інструмент, то бачили, що пропонує пошук: навчальні програми університетів, форуми з порадами про Business Studio, Visio і yEd, курси з нотації BPMN. Усе це написано для бізнес-аналітиків. Як описати процес так, щоб за описом зібрали робочу систему, там не пояснюють.
Ця стаття — для власника або операційного директора компанії на 5–100 людей. Розберемо, чим опис для системи відрізняється від схеми для аналітика, дамо шаблон із восьми блоків і заповнений приклад, порядок роботи на тиждень, чекліст готовності й типові помилки. Наприкінці — коли спеціальна програма і BPMN усе-таки потрібні.
Коротко
- Програма — не головне. Опис під систему можна зробити в Google Docs чи Word. Важить зміст: етапи, ролі, дані, формули, документи, винятки.
- Схема показує порядок кроків, але не правила. Формулу ціни, поля картки й права доступу на діаграмі не намалюєш. Їх треба написати словами й підкріпити прикладами.
- Контрольні приклади важливіші за схеми. Кілька реальних замовлень із правильною відповіддю — найкращий критерій, що система рахує так, як ваша команда.
- Тиждень на опис — реальний термін. Саме стільки в нас триває етап «Опис процесу». Після нього перша версія системи готова за кілька днів, бо код пише ШІ за описом і критеріями готовності від архітектора.
- BPMN потрібен у вужчих випадках: коли процес виконує BPM-система, коли відділів і погоджень багато або коли служба якості веде регламенти.
Що пропонує пошук за запитом «програма для опису бізнес процесів»
Програми, які трапляються в пошуку, можна поділити на чотири групи. Кожна відповідає на своє питання, і лише одна з них зручна для власника.
Системи бізнес-моделювання
Business Studio, ARIS та подібні. Вони зберігають сотні процесів, пов’язують їх з оргструктурою, документами й показниками, будують регламенти. Business Studio — російська розробка, розрахована на середній і великий бізнес, навчальні матеріали до неї переважно російською. Щоб такою системою користуватися, потрібен аналітик, який її знає, і місяці на моделювання. Для компанії з двадцяти людей це надмірно.
Редактори BPMN-схем
Bizagi Modeler, Camunda Modeler, yEd, draw.io. Вони малюють процес у стандартній нотації: події, задачі, розвилки, доріжки для ролей. Більшість має безкоштовний варіант. yEd безкоштовний навіть для комерційного використання і працює на Windows, macOS і Linux. Bizagi Modeler вміє вивантажити описану модель у документ Word. Camunda дає веб-редактор BPMN без оплати для команди до п’яти користувачів. draw.io має безкоштовну програму для комп’ютера, яка працює без інтернету.
Дошки і редактори блок-схем
Miro, Visio, той самий draw.io. Стікери, стрілки, ромби. Зручно, коли треба на нараді разом з командою побачити, де застрягає замовлення. Строгих правил тут немає, і це плюс для першої розмови.
Текст і таблиці
Google Docs, Word, Google Sheets, Notion. Жодних нотацій і навчання. Саме в такому вигляді найзручніше описувати процес під систему, бо в текст влазить те, чого немає на схемах: формули, винятки, приклади.
| Тип програми | Приклади | Для кого | Що дає для майбутньої системи |
|---|---|---|---|
| Системи бізнес-моделювання | Business Studio, ARIS | аналітики великих компаній, служби якості | модель усієї компанії; формули й поля доведеться описувати окремо |
| Редактори BPMN | Bizagi Modeler, Camunda Modeler, yEd | аналітики, розробники BPM-систем | точну послідовність кроків і розвилок |
| Дошки | Miro, draw.io, Visio | команда на нараді | спільне розуміння, де губиться час |
| Текст і таблиці | Google Docs, Word, Google Sheets | власник і менеджери | правила, формули, приклади — те, з чого пишуть код |
Схема для аналітика і опис для системи: у чому різниця
Обидва документи описують той самий процес. Але відповідають на різні питання, і плутанина між ними коштує тижнів переробок.
Що показує схема
Схема відповідає на питання «в якому порядку». Хто приймає заявку, коли рахують ціну, де розвилка «клієнт погодив чи ні», куди йде замовлення після оплати. Нотація BPMN робить це строго і однаково для всіх, хто її знає. Поточну версію стандарту, BPMN 2.0.2, консорціум OMG опублікував у січні 2014 року (OMG).
Схема корисна, коли процес довгий і в ньому багато учасників. На ній видно дублювання, зайві погодження і місця, де замовлення лежить без руху.
Чого схема не скаже розробнику
Візьмімо крок «Розрахувати ціну». На схемі це один прямокутник. Для системи за ним стоїть десяток питань. З якого поля береться площа? Звідки ставка? Як визначають коефіцієнт складності? Що робити, якщо матеріалу немає в прайсі? Хто може змінити ціну вручну? Чи бачить менеджер собівартість?
Так само з кроком «Виставити рахунок». На схемі — прямокутник. У системі — реквізити клієнта, нумерація, сума прописом, умови оплати, PDF, хто відправляє і коли.
Схема без цих правил — як креслення меблів без розмірів. Видно, що буде шафа, але виготовити її не можна.
Чому для ШІ-розробки важливий саме текст
Коли код пише ШІ-агент, опис стає головним документом проєкту. GitHub, запускаючи набір інструментів Spec Kit для розробки за специфікацією, сформулював проблему прямо: розмите завдання змушує модель вгадувати тисячі невисловлених вимог, тому джерелом правди має бути записаний намір, а не код (GitHub Blog).
Проблема не нова і не лише про ШІ. У дослідженні PMI 2014 року неточна робота з вимогами була головною причиною у 47% проєктів, які не досягли своїх цілей. Через погану роботу з вимогами втрачалося 5,1% кожного витраченого на проєкти долара (PMI, Pulse of the Profession: Requirements Management).
Ми працюємо так: архітектор перетворює опис власника на критерії готовності, ШІ-агент пише код і тести, людина перевіряє результат на реальних замовленнях. Чим точніший опис, тим менше вгадування і переробок.
Що описати, щоб за описом зібрали систему: вісім блоків
Опис під систему відповідає на вісім питань. Іти по порядку не обов’язково, але жоден блок не можна пропустити. Якщо якогось блоку немає, розробник або ШІ-агент заповнить прогалину здогадом, і ви дізнаєтеся про це на першому ж реальному замовленні.
1. Етапи замовлення і умови переходу
Перелічіть етапи, через які проходить замовлення: заявка, розрахунок, КП надіслано, погоджено, передоплата, у виробництві, готово, відвантажено, закрито. Для кожного етапу запишіть дві речі: що має бути зроблено, щоб замовлення туди потрапило, і хто переводить його далі.
Приклад умови: «У виробництво — лише після передоплати і коли всі питання до клієнта закриті». Для системи це правило, яке вона перевіряє сама. У Saloy, нашій компанії з виробництва на верстатах з ЧПК, система попереджає, якщо замовлення з відкритими питаннями до клієнта намагаються перевести у виробництво. Саме попереджає, а не блокує: так вирішили під час опису.
2. Ролі і що бачить кожна
Описуйте ролі, а не людей: власник, менеджер, виробництво, бухгалтер, монтажник. Для кожної ролі — що вона робить у системі і що бачить. У системі Saloy три ролі: власник, менеджер, виробництво. Прибуток бачить лише власник.
Два питання краще вирішити одразу, бо вони впливають на всю систему: чи бачить менеджер собівартість і чи може він змінити ціну вручну.
3. Дані: картка клієнта і картка замовлення
Випишіть поля. Клієнт: назва або ПІБ, контактна особа, телефон, Telegram, для юросіб — код ЄДРПОУ, IBAN, юридична адреса. Замовлення: що замовили, розміри, матеріал, кількість, термін, адреса доставки чи монтажу, файли й фото.
Найпростіше — взяти таблицю, в якій ви зараз ведете замовлення, і пройтися по її колонках. Позначте, які заповнюють завжди, які іноді, а які вже давно ніхто не дивиться. Останні в систему не переносьте.
4. Формули розрахунку
Найважливіший блок, і саме його найчастіше пропускають. Запишіть формулу словами і вкажіть, звідки береться кожне значення.
Приклад із Saloy: ціна деталі — це площа × ставка × коефіцієнт складності × кількість, плюс заготовка за об’ємом. Заготовка рахується з припусками: за замовчуванням 10 мм по довжині й ширині та 3 мм по товщині. Кожне слово тут — поле в картці або значення з довідника.
Якщо формули живуть в Excel, додайте файл до опису. Але Excel сам по собі не опис. У ньому видно, що рахується, але не видно, чому саме так і коли правило не діє.
5. Документи
Які документи виходять із замовлення і на якому етапі: комерційна пропозиція, рахунок, видаткова накладна, акт, договір. Для кожного — зразок, який ви надсилаєте зараз, і звідки в ньому беруться дані. Обов’язкові реквізити первинних документів і порядок їх створення ми розбирали у статті про програму для обліку замовлень.
6. Винятки
Тут ховаються найдорожчі помилки. Термінове замовлення без передоплати. Клієнт змінив розміри після запуску у виробництво. Часткова оплата. Повернення. Брак. Постійний клієнт із відстрочкою. Для кожного винятку запишіть, що відбувається і хто ухвалює рішення.
Просте правило: якщо менеджер на питання відповідає «ну, тут по-різному», ви знайшли виняток, який треба записати.
7. Сповіщення і терміни
Хто про що має дізнатися і коли. Менеджеру — про нову заявку. Виробництву — про замовлення, яке перейшло в роботу. Клієнту — нагадування про погодження, якщо він мовчить. Власнику — про замовлення, що прострочили етап.
У Saloy одне замовлення програли саме тому, що вчасно не нагадали клієнту. Тепер ШІ-асистент у призначений день пише клієнту в Telegram, розбирає відповідь і записує її в картку. Якщо відповідь неясна, він перепитує.
8. Контрольні приклади
Три-п’ять реальних замовлень з минулого: що прийшло від клієнта, яку ціну ви дали, які документи надіслали, чим усе закінчилося. Це і є критерії готовності. Система готова, коли на цих прикладах дає той самий результат, що й ваша команда.
Шаблон опису процесу: заповнений приклад
Нижче — шаблон, який вміщується в один документ на дві-три сторінки. Приклад умовний, для ілюстрації: компанія, що виготовляє і встановлює металеві ворота й паркани під замовлення.
| Блок | Що написати | Приклад |
|---|---|---|
| Етапи | список етапів і умова переходу на кожен | заявка → замір → розрахунок і КП → погодження → передоплата → виготовлення → фарбування → монтаж → акт і доплата → закрито; у виготовлення — лише після передоплати й затвердженого заміру |
| Ролі | хто що робить і що бачить | власник, менеджер, замірник, виробництво, монтажна бригада; виробництво бачить розміри й креслення, але не ціну |
| Дані | поля клієнта і замовлення | клієнт: ПІБ або назва, телефон, адреса об’єкта; замовлення: тип воріт, ширина, висота, заповнення, колір, автоматика, фото з заміру |
| Формули | ціна словами і джерело кожного значення | площа полотна × ставка за типом заповнення + стовпи + фурнітура + автоматика за прайсом + монтаж за тарифом виїзду; ставки власник оновлює сам |
| Документи | що, коли, з яких даних | КП у PDF після розрахунку, рахунок на передоплату, акт після монтажу, рахунок на доплату |
| Винятки | що відбувається і хто вирішує | змінили розміри після заміру — новий розрахунок і погодження; нестандартний колір — довший термін; об’єкт за містом — доплата за виїзд |
| Сповіщення | кому, про що, коли | замірнику — адреса і час; клієнту — нагадування, якщо КП не погоджене; власнику — щоранку список прострочених етапів |
| Контрольні приклади | реальні замовлення з правильною відповіддю | три останні замовлення: заміри, ціна, документи, що пішли клієнту |
Як те саме виглядало б у BPMN
У BPMN цей процес — десяток задач, кілька розвилок і п’ять доріжок для ролей. Схема вийде акуратна. Але на ній не буде формули ціни, полів картки, того, що виробництво не бачить ціну, і правила про нестандартний колір. Ці речі все одно доведеться дописувати текстом. Тому для системи ми починаємо з тексту, а схему малюємо лише тоді, коли процес справді розгалужений.
Короткий варіант для одного вузького місця
Якщо вам поки треба розібрати одну проблему, а не весь процес, є коротша версія на шість пунктів — шаблон опису процесу для ШІ. Його можна заповнити за 15–20 хвилин. Ще більше прикладів того, як виглядають процеси в компаніях із цехом і складом, — у статті з прикладами бізнес процесів на виробничому підприємстві.
Як описати процес за тиждень: порядок дій
Саме стільки в нас триває етап «Опис процесу». Ось як розкласти роботу, якщо ви робите її самі. Відповідає за опис одна людина — власник або операційний директор. Решта команди дає відповіді.
День 1. Пройдіть шлях трьох останніх замовлень
Відкрийте листування, таблицю, рахунки. Для кожного замовлення запишіть: звідки воно прийшло, хто що робив, де дані переписували вручну, де замовлення стояло без руху. Три різні історії покажуть більше, ніж будь-яка теорія.
День 2. Етапи і ролі
З трьох історій складіть спільний список етапів і ролей. Покажіть його менеджеру і людині з виробництва. Вони скажуть, чого бракує. Не пропускайте цей крок: значна частина знань про процес є лише в людей, які його виконують. У дослідженні Panopto 42% робочих знань виявилися унікальними для конкретного працівника і не передавалися колегам (HR Dive про дослідження Panopto). У малій компанії це часто одна людина, без якої процес зупиняється.
День 3. Формули і контрольні приклади
Візьміть Excel або калькулятор, яким рахують ціну. Попросіть людину, яка рахує, пояснити вголос один розрахунок від початку до кінця. Записуйте все, особливо фрази на кшталт «а тут я додаю трохи на складність». Підберіть три-п’ять замовлень із правильною відповіддю.
День 4. Документи і дані
Зберіть зразки документів, які надсилаєте клієнтам. Пройдіться по колонках таблиці замовлень. Позначте обов’язкові поля і ті, без яких можна обійтися.
День 5. Винятки, сповіщення і читання вголос
Спитайте кожного: «Коли процес іде не так?» Запишіть винятки і те, хто про що має дізнаватися. Потім прочитайте опис людям, які роблять роботу, і виправте те, що вони поправлять.
Фінальний тест простий. Чи міг би новий менеджер провести замовлення за цим описом, нікого не питаючи? Якщо так, опис готовий.
Чи можна доручити опис ШІ
Частково. ШІ-помічник на кшталт ChatGPT, Claude чи Gemini добре складає чернетку з ваших нотаток, голосових повідомлень і Excel-файлу. Він розкладе все по блоках і поставить питання, яких ви не помітили. Але формули, винятки і контрольні приклади перевіряєте ви. ШІ не знає, що постійному клієнту ви даєте відстрочку, поки ви йому про це не скажете.
Як зрозуміти, що опис готовий: чекліст
Перед тим як віддати опис розробнику, пройдіться по списку:
- кожен етап має умову входу і відповідального за перехід;
- для кожної ролі записано, що вона робить і що бачить;
- для кожного поля зрозуміло, хто його заповнює і чи воно обов’язкове;
- кожна формула записана словами, і для неї є щонайменше три контрольні приклади з правильною відповіддю;
- для кожного документа є зразок;
- винятки записані; якщо їх немає взагалі, ви ще не всіх спитали;
- опис прочитали люди, які роблять роботу;
- відомо, що буде в першій версії, а що можна додати потім.
Чому контрольні приклади вирішують
У виробника металоконструкцій ціну ферм рахував інженер в Excel-книзі на 104 аркуші: 96 таблиць ферм, понад 2 000 варіантів, снігові навантаження для 27 регіонів. Ми робили для цієї компанії калькулятор. Перед запуском звірили його з Excel на контрольних прикладах — збіглося до копійки.
А в самому Excel знайшли помилки. Для кроку ферм 4,25 м таблиця видавала #Н/Д, у кількох місцях рахувала неточно. Ми не виправляли мовчки, а передали інженеру. Для одного випадку в калькуляторі є перемикач «як в Excel» і виправлена схема. Без контрольних прикладів ці помилки тихо переїхали б у нову систему.
Як відрізнити готовий опис від недописаного
Недописаний опис легко впізнати за словами «зазвичай», «як домовимося», «менеджер знає». Кожне таке слово — рішення, яке система не зможе ухвалити. Перепишіть його у вигляді правила: «якщо… то…», «вирішує…». Якщо правила немає і вирішують щоразу по-різному, так і запишіть: «вирішує власник, система лише нагадує».
Типові помилки, через які опис не працює
Описують, як має бути, а не як є
Власник пише ідеальний процес, якого в компанії ніколи не було. Система, зібрана за таким описом, не збігається з реальною роботою, і люди повертаються до таблиць. Описуйте спочатку, як є. Покращення додавайте окремим списком.
Малюють схему замість правил
Гарна схема в Miro створює відчуття, що роботу зроблено. Але формул, полів і винятків на ній немає. Схема — додаток до опису, а не його заміна.
Описує одна людина
Власник знає продажі, але може не знати, як виробництво рахує заготовки. Бухгалтер знає документи, але не знає, як менеджер погоджує знижку. Опис однієї людини завжди має сліпі зони.
Забувають винятки
Основний шлях замовлення описати легко. Гроші губляться на винятках: часткова оплата, зміна розмірів, термінове замовлення. Якщо винятків в описі немає, вони все одно трапляться, але система не знатиме, що з ними робити.
Описують усю компанію одразу
Опис усіх процесів займає місяці і застаріває раніше, ніж його дописують. Почніть з одного процесу, де губляться гроші, найчастіше це шлях замовлення від заявки до оплати. Довгий перелік процесів, з яких можна почати, є у статті про автоматизацію бізнес процесів підприємства.
Плутають ролі з людьми
«Оля погоджує знижки» — це про людину. «Знижку більше встановленої межі погоджує власник» — це правило. Люди змінюються, відпочивають, хворіють. Правило має працювати без конкретної Олі.
Що відбувається після опису: як за ним будують систему
Від опису до першої версії
Опис — вхід для архітектора. Він перетворює текст на критерії готовності: що система має робити і як перевірити, що вона це робить. Далі ШІ-агент пише код і тести, а людина перевіряє результат на реальних замовленнях.
Основа вже готова і працює в наших проєктах: заявки, клієнти, замовлення з етапами, документи (рахунок, видаткова накладна, акт, комерційна пропозиція, сума прописом, PDF), вхід через Telegram, ролі, сповіщення, резервні копії. Тому перша робоча версія готова за кілька днів, а вся система — за 2–4 тижні після опису процесу. Модулі додаємо по одному. Два тижні система працює паралельно зі старим способом, щоб ніхто нічого не втратив.
Приклад: опис і запуск системи Saloy
Влітку 2026 року для Saloy розглядали готові варіанти: KeyCRM, зв’язку Google Sheets і Trello, ERPNext. Вони не підійшли через те, що виявив опис процесу: ціна за формулою, заготовки, попередження перед передачею у виробництво, виплати за операції, Telegram як основний інтерфейс. ERPNext закривав більше, але налаштування зайняло б місяці.
Перша робоча версія була готова за 1 день: воронка, картки замовлень і клієнтів, канбан, дашборд, вхід через Telegram, форма з сайту. На другому тижні додали заготовки, доручення, уточнення, що блокують передачу у виробництво, і автоматичні нагадування. На третьому — виплати за операціями, облік часу, прибуток власника, рахунки й накладні. Усі модулі — за 3 тижні. Детально — у кейсі власної системи управління.
Опис — живий документ
Перші тижні роботи системи показали те, чого не було в жодному описі. Великі замовлення приходили дзвінками, а не через форму. Одне замовлення програли через безкоштовні візуалізації без обмежень, звідси нове правило: передоплата і ліміт правок. Ці правила додали в опис уже після запуску.
Ще один урок — технічний. Одного разу оновлення зі старої копії затерло свіжий модуль, і його відновлювали вручну. Тепер контроль версій і резервні копії працюють з першого дня, а опис зберігається поруч із кодом і оновлюється разом із ним.
Коли спеціальна програма і BPMN справді потрібні
Опис текстом підходить не завжди. Ось випадки, коли варто брати спеціальну програму або не робити опис узагалі.
Коли варто взяти BPMN-редактор
- Процес виконує BPM-система, наприклад Camunda чи Bizagi. Тоді схема і є програмою, і малювати її треба строго за стандартом.
- У процесі багато відділів і погоджень, і завдання — знайти зайві кроки. Схема покаже це наочніше за текст.
- Служба якості веде регламенти і систему менеджменту якості. Тут знадобляться системи бізнес-моделювання з версіями документів і зв’язками між процесами.
Коли опис не допоможе
- Процес змінюється щотижня, бо бізнес ще шукає свою модель. Описувати рано: опис застаріє до запуску системи.
- Немає людини, яка відповідає за процес. Опис буде, але ніхто не стежитиме, щоб система йому відповідала.
- Проблема не в процесі, а в попиті, ціні чи людях. Жодна система не продасть те, що ринку не потрібне.
Коли краще готова програма
Якщо у вас типовий процес продажів без власних формул і особливих документів, готова CRM буде швидшою і дешевшою за розробку. Чесний тест на 15 хвилин — готова CRM чи своя система. Які процеси автоматизувати першими і якими програмами, ми розбирали в статті про автоматизацію бізнес процесів.
Часті питання
Чи потрібна програма для опису бізнес процесів, якщо я хочу автоматизувати один процес? Ні. Для одного процесу досить Google Docs або Word і шаблону з восьми блоків. Спеціальна програма знадобиться, якщо процес виконуватиме BPM-система або якщо процесів десятки й ними опікується аналітик.
Чи можна просто віддати розробнику схему з Miro чи Visio? Можна, як доповнення. Схема покаже порядок кроків, але без формул, полів, ролей і винятків розробник буде вгадувати. Додайте до схеми текст за шаблоном і три-п’ять контрольних прикладів.
Скільки часу займає опис процесу? Один процес від заявки до оплати — близько тижня, якщо команда відповідає на питання вчасно. Стільки ж триває наш етап «Опис процесу». Далі перша версія системи готова за кілька днів.
Якщо ви хочете автоматизувати замовлення, розрахунки чи документи, опишіть за шаблоном вище, як у вас зараз іде одне замовлення, і надішліть нам. Покажемо систему на демо за 30 хвилин і чесно скажемо, що вам вигідніше: готова програма чи система під ваш процес. Детальніше — ШІ-система управління бізнесом.
