AI для оптимізації бізнес-процесів: спершу виміряти

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

Стаття для власника чи операційного директора компанії на 5–100 людей: виробництво під замовлення, монтаж, сервіс із виїздом, проєктна робота. Покажемо, які дані система може збирати сама, без вечірніх звітів «для галочки». Розберемо п’ять показників, за якими видно вузьке місце, і порядок дій від першого заміру до першої зміни. Окремо — що в цій схемі робить ШІ, а що рахують звичайні формули.

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

Коротко

Оптимізація починається з журналу подій. Для кожного замовлення потрібні три речі: номер, етап і час переходу. Таблиця з поточним статусом цього не дає.
Найбільше часу забирає очікування, а не робота. Замовлення довше стоїть у черзі, ніж перебуває в руках майстра чи менеджера.
Прискорювати треба вузьке місце. Прискорення будь-якого іншого етапу не скорочує строк для клієнта.
Цифри рахують формули, ШІ пояснює. ШІ розбирає вільний текст, пише звіт про відхилення й нагадує людям, але цифр не вигадує.
Перші тижні — лише замір. Спершу базова лінія, потім одна зміна і порівняння з нею.

Чому оптимізація без даних — це здогадки

Що показують дослідження

У дослідженні Top Lead «AI FOCUS 2026» взяли участь 216 українських компаній. Підвищення ефективності бізнес-процесів назвали причиною впроваджувати ШІ 71,8% з них. Водночас 14,4% ще не отримали від ШІ жодної економічної вигоди, а найчастішим бар’єром стала складність інтеграції з наявними системами (Dengi.ua про дослідження Top Lead).

Схожу картину дав звіт MIT NANDA «The GenAI Divide» за 2025 рік. Автори розібрали понад 300 публічних проєктів, поговорили з представниками 52 організацій і опитали 153 керівників. За їхніми даними, 95% організацій у вибірці не отримали вимірюваного результату від генеративного ШІ. Причину автори бачать не в якості моделей, а у впровадженні: інструменти погано вписані в щоденну роботу (огляд звіту на Let’s Data Science).

Обидва джерела мають обмеження: вибірки невеликі, відповіді — самооцінка компаній. Але висновок з них простий. Щоб ШІ щось оптимізував, він має бачити процес. А щоб бачити процес, його треба записувати.

Відчуття власника і реальний потік замовлень

Власник зазвичай знає, де болить. «Довго рахуємо». «Майстри повільні». «Клієнти тягнуть з погодженням». Іноді це правда. Але відчуття складаються з останніх гучних випадків, а не з усіх замовлень за місяць.

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

Автоматизація і оптимізація — різні задачі

Автоматизація робить окремий крок швидшим або прибирає його зовсім. Оптимізація шукає, який крок обмежує весь процес. Різниця принципова.

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

Тому порядок такий: виміряти, знайти обмеження, прискорити саме його. Загальну логіку автоматизації бізнес-процесів ми описали окремо. Тут зосередимося на вимірюванні.

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

Три поля, без яких нічого не порахувати

Програми аналізу процесів (їх називають process mining) працюють з журналом подій. Microsoft у документації до Power Automate Process Mining називає три обов’язкові поля: ідентифікатор випадку (номер замовлення чи заявки), назву дії або етапу і час події. Додатково корисно знати, хто виконав дію (Microsoft Learn).

Для компанії під замовлення журнал одного замовлення виглядає приблизно так:

понеділок, 9:12 — заявка надійшла дзвінком, записав менеджер;
понеділок, 15:40 — розрахунок надіслано клієнту;
вівторок, 10:05 — відкрито питання до клієнта про колір;
четвер, 17:20 — питання закрито, відповідь записано в картку;
п’ятниця, 8:30 — замовлення передано у виробництво;
п’ятниця, 9:00 — майстер запустив таймер на фрезерування;
п’ятниця, 12:45 — майстер зупинив таймер.

З семи рядків уже видно головне. Розрахунок зайняв пів дня. Погодження — майже три дні. Сама робота на верстаті — менше чотирьох годин.

Чому таблиця зі статусами не підходить

У більшості таблиць і канбан-дошок є колонка «Статус». Менеджер змінює «Розрахунок» на «Виробництво», і попереднє значення зникає. Ви знаєте, де замовлення зараз, але не знаєте, скільки воно пробуло на кожному етапі.

Microsoft пише про це в тій самій документації: таблиці програм часто зберігають поточний стан даних, а не історію подій, яка потрібна для аналізу. Готові CRM історію зазвичай пишуть, але дістати з неї час на етапі не завжди просто. Наприклад, довідка Bitrix24 пропонує для такого звіту зводити угоди й історію стадій у Google Looker Studio (довідка Bitrix24). Для відділу продажів це робоче рішення. Для виробничих операцій і таймерів майстрів — ні.

Що система може записувати сама

Головне правило: дані мають збиратися самі, поки люди роблять свою роботу. Якщо майстра просять увечері заповнити звіт, звіт буде приблизним. Через місяць його перестануть заповнювати.

Що можна записувати без додаткової роботи для людей:

Перехід між етапами. Менеджер натискає кнопку в картці або в Telegram, система пише час і автора.
Реальний час на операцію. Майстер запускає й зупиняє таймер командою в боті. Видно не норму з довідника, а скільки операція зайняла насправді.
Відкриті питання. Питання до клієнта позначаються на картці: коли відкрили, коли закрили, хто закрив.
Канал заявки. Сайт, Telegram, Viber, дзвінок, повторне замовлення.
Причина програшу. Менеджер пише її своїми словами, ШІ відносить до однієї з кількох категорій.
Повернення назад. Якщо замовлення повернули з виробництва на уточнення, це окрема подія, а не тиха зміна статусу.
Простій з причиною. Немає матеріалу, чекаємо клієнта, верстат зайнятий іншим замовленням.

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

Українська специфіка

У багатьох українських компаніях заявки приходять не з форм. Дзвінок, Viber, Telegram, особисте повідомлення менеджеру — і все це поза будь-якою системою. Тому канал «дзвінок» і канал «месенджер» мають фіксуватися так само просто, як форма з сайту. Найпростіше — одна команда в робочому Telegram-боті.

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

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

П’ять показників, за якими видно, де процес гальмує

1. Час проходження і час на кожному етапі

Час проходження — від заявки до видачі чи оплати. Його бачить клієнт. Час на етапі — скільки замовлення пробуло на конкретному етапі. Його бачите ви.

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

2. Час роботи і час очікування

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

Даніел Ваканті, автор книжки про метрики потоку, оцінює її для команд, які за потоком не стежать, у межах 5–15%. Тобто більшу частину часу робота просто чекає. Девід Андерсон, який переніс канбан на інтелектуальну роботу, зауважує, що навіть досвідченим командам важко перевищити 40% (Businessmap). Ці оцінки зібрані на командах розробки, але логіка та сама і для замовлення меблевих фасадів.

Умовний приклад. Замовлення йде від заявки до відвантаження 12 робочих днів, тобто приблизно 96 робочих годин. Таймери майстрів показали 9 годин роботи, ще 2 години менеджер витратив на розрахунок і листування. Разом 11 годин. Ефективність потоку — близько 11 відсотків. Якщо прискорити фрезерування вдвічі, строк скоротиться на 4,5 години. Якщо прибрати три дні очікування між етапами — на 24 робочі години.

3. Незавершена робота і закон Літтла

Закон Літтла пов’язує три величини:

Середній час проходження = кількість замовлень у роботі ÷ кількість замовлень, які ви завершуєте за тиждень.

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

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

4. Повернення і переробки

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

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

5. Втрати за каналами і причинами

Скільки заявок з кожного каналу дійшли до оплати, скільки втрачено і чому. Тут ШІ корисний найбільше. Причини програшу менеджери пишуть вільним текстом, а ШІ зводить їх до кількох категорій: «дорого», «довго відповідали», «не влаштував строк», «пропав». Що робити з такими даними в продажах, ми розібрали в статті про автоматизацію відділу продажів.

Зведення: що рахувати і на що дивитися

Показник	Як рахувати	Звідки дані	Тривожна ознака
Час на етапі	Медіана від входу до виходу з етапу	Переходи між етапами	Медіана росте кілька тижнів поспіль
Ефективність потоку	Час роботи ÷ час проходження	Таймери і переходи	Робота займає малу частку, а черги ростуть
Незавершена робота	Скільки замовлень зараз між заявкою і видачею	Поточні статуси	Замовлень у роботі більше, ніж завершуєте за кілька тижнів
Повернення	Повернення на 10 завершених замовлень	Події «повернуто на етап»	Повернення з однією і тією ж причиною
Втрати	Програні заявки за каналом і причиною	Причини програшу, канал заявки	Багато втрат з причиною «довго відповідали»

Як знайти вузьке місце: покроково

Крок 1. Опишіть етапи з критеріями входу і виходу

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

Крок 2. Три–чотири тижні лише записуйте

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

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

Крок 3. Порахуйте час на етапах і черги перед ними

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

Крок 4. Розкладіть очікування на причини

Дослідники Тартуського університету виділяють п’ять причин очікування в процесах (Тартуський університет). Пакетування: роботу накопичують і роблять партією. Конкуренція за ресурс: потрібна людина зайнята іншими замовленнями. Пріоритети: інші замовлення пішли вперед. Недоступність: людини немає на місці. Сторонні справи: людина зайнята в іншому процесі. Для компанії під замовлення варто додати шосту причину — чекаємо клієнта.

Кожна причина лікується по-своєму:

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

Крок 5. Знайдіть обмеження

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

Крок 6. Одна зміна — і порівняння з базовою лінією

Міняйте одну річ на два–три тижні. Потім порівняйте медіану етапу і час проходження з базовою лінією. Якщо змінити три речі одночасно, ви не дізнаєтеся, що спрацювало, а що заважало.

Хто за що відповідає

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

Пороги: коли реагувати

Стартові пороги, які потім варто підлаштувати під свій процес:

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

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

AI для оптимізації бізнес-процесів: що робить ШІ, а що формули

Що рахують формули

Час на етапі, медіана, черга, ефективність потоку, закон Літтла — це звичайна арифметика по журналу подій. Її рахує база даних запитом, однаково щоразу. Мовна модель для цього не потрібна і навіть шкідлива: вона може помилитися в цифрі й при цьому звучати переконливо. Так само в наших системах ціну рахують формули, а не ШІ.

Що робить ШІ

Розбирає вільний текст. Причини програшу, коментарі майстрів, повідомлення клієнтів перетворюються на категорії, які можна порахувати.
Уточнює деталі з клієнтом. У системі Saloy ШІ-асистент у призначений день пише клієнту в Telegram, розбирає відповідь і записує її в картку. Якщо відповідь неясна, перепитує. Очікування клієнта перестає бути чорною дірою: видно, коли питали і коли відповіли.
Пише звіт про відхилення. Не «усе добре, у роботі 34 замовлення», а що змінилося, на якому етапі і з якою ймовірною причиною.
Нагадує людям. Хто має закрити питання, яке замовлення стоїть без руху довше за поріг.
Відповідає на питання власника. «Чому в жовтні фасади йшли довше?» ШІ дивиться журнал і показує, на якому етапі виросло очікування і що там відбувалося.

Чого ШІ не робить

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

Приклад тижневого звіту

Умовний приклад повідомлення власнику в Telegram:

Тиждень 43. Завершено 9 замовлень, медіана проходження — 13 робочих днів, у базовій лінії було 11. Зросло очікування на етапі «Погодження з клієнтом»: медіана 4 дні замість 2. У 4 з 6 таких замовлень відкрите питання про розміри. Два замовлення стоять у черзі на фрезерування понад 3 дні: верстат зайнятий великим замовленням. Варто перевірити, чи отримали клієнти нагадування в призначений день.

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

Приклад: що показала система Saloy у перші тижні

Saloy — наша компанія з виробництва на верстатах з ЧПК: меблеві фасади, різьблення, деталі під замовлення. Команда — від 3 до 6 людей. Замовлення змішані: частина з каталогу, частина за кресленням клієнта. Перша робоча версія системи запрацювала за 1 день, усі модулі — за 3 тижні.

Реальний час на операцію

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

«Ворота» перед виробництвом

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

Великі замовлення приходили дзвінками

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

Два програні замовлення

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

Урок про збереження даних

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

Повну історію — від вибору між готовими програмами до третього тижня — ми описали у кейсі власної системи управління.

Скільки коштує очікування: формула і умовний приклад

Гроші, які чекають разом із замовленням

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

Гроші в процесі = випуск замовлень за тиждень × час проходження в тижнях × середня доплата при видачі.

Умовний приклад. Випуск — 8 замовлень на тиждень, час проходження — 3 тижні, тобто в роботі 24 замовлення. Середня доплата при видачі — 15 тисяч гривень. Разом 360 тисяч гривень чекають, поки замовлення пройдуть усі етапи. Скоротили час проходження до 2 тижнів при тому самому випуску. У роботі стало 16 замовлень, у процесі — 240 тисяч гривень. Одноразово звільнилося 120 тисяч гривень, без жодного нового продажу.

Замовлення, які не дочекалися

Друга частина ціни очікування — клієнти, які пішли до того, як отримали відповідь.

Втрачена маржа за місяць = заявки, які не дочекалися відповіді × середній чек × частка маржі.

Умовний приклад. З 40 заявок на розрахунок за місяць 5 клієнтів не дочекалися відповіді. Це видно з причин програшу, які ШІ відніс до категорії «довго відповідали». Середній чек — 30 тисяч гривень, маржа — третина. Втрачено 50 тисяч гривень маржі на місяць. Якщо вузьке місце — розрахунок, прискорювати треба саме його. Приклад того, як розрахунок, на який клієнт чекав, перенесли з Excel у калькулятор, є в нашому проєкті для виробника металоконструкцій: там перша версія з’явилася за день, уся робота зайняла 4 дні.

Що перевірити перед тим, як прискорювати

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

Типові помилки

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

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

Просити людей заповнювати звіти вручну. Ручні звіти пишуть з пам’яті, увечері, приблизно. Дані мають виникати як побічний продукт роботи: кнопка переходу, команда таймера, відповідь клієнта.

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

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

Довіряти ШІ цифри. Мовна модель, яку попросили «порахувати середній час по таблиці», може помилитися. Цифри — з запиту до бази, ШІ — для пояснень.

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

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

Чим зібрати дані: таблиця, готова CRM, process mining чи система під процес

Варіант	Що дає	Кому підходить	Обмеження
Ручний хронометраж	Точний замір кількох операцій	Разова перевірка норм	Не показує очікування між етапами, люди під наглядом працюють інакше
Таблиця з датами переходів	Дати етапів, якщо їх вносять	Невеликий потік і дисциплінована команда	Дати забувають, історію перезаписують
Готова CRM	Історія стадій угод	Продажі зі стандартною воронкою	Час на етапі — через окремі звіти, таймерів і виробничих операцій зазвичай немає
Process mining	Карта реального процесу з журналу подій	Великі компанії з ERP, де журнал уже є	Потрібен готовий журнал подій, у малої компанії його зазвичай немає
Система під процес	Журнал подій, таймери, питання до клієнта, звіти ШІ	Виробництво під замовлення, монтаж, сервіс	Процес треба описати, запуск — 2–4 тижні

Серед інструментів process mining відомі Celonis і Power Automate Process Mining від Microsoft. Вони сильні там, де журнал подій уже веде ERP. Малій компанії вони не допоможуть, поки події не записуються: аналізувати просто нічого.

Для Saloy влітку 2026 року ми теж розглядали готові варіанти: KeyCRM, зв’язку Google Sheets і Trello, ERPNext. Готові не підійшли через ціну за формулою, «ворота» перед виробництвом, виплати за операції і Telegram як основний інтерфейс. ERPNext закривав більше, але налаштування зайняло б місяці. Якщо ви вагаєтеся між готовою програмою і власною системою, пройдіть короткий тест «готова CRM чи власна система».

Коли вимірювання не допоможе

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

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

Ви не готові нічого міняти. Дашборд без рішень — витрата часу. Якщо власник не збирається міняти правила черговості чи умови оплати, замір нічого не дасть.

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

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

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

Часті питання

Скільки часу збирати дані, перш ніж щось міняти? Зазвичай три–чотири тижні і щонайменше кілька десятків завершених замовлень. Якщо потік малий, збирайте довше або міряйте лише етапи, без окремих операцій.

Чи можна оптимізувати процес за допомогою ChatGPT без окремої системи? Можна попросити ШІ проаналізувати вивантаження, якщо в ньому є дати переходів між етапами. Але якщо у вас лише таблиця з поточними статусами, аналізувати нічого: історії немає. І цифри краще рахувати формулами в таблиці, а ШІ просити лише пояснити їх.

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

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