Система управління ризиками: терміни, бюджет, ресурси

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

Стаття для власника або операційного директора компанії на 10–100 людей, яка веде кілька проєктів одночасно: будівництво й монтаж, впровадження обладнання, розробка на замовлення, інжиніринг, сервісні контракти. Проєктний офіс (PMO) у такій компанії — часто одна людина або сам директор. Задачі живуть у Jira, Asana чи Excel, витрати — в бухгалтерії, домовленості — в Telegram-чатах. Статус-звіт збирають руками.

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

Коротко

Ризик видно в даних раніше, ніж у розмовах. Темп закриття робіт, план/факт витрат і завантаження ключових людей показують зрив за тижні до дедлайну.
Прогноз рахують формули, а не ШІ. Темп, індекси SPI і CPI дають однаковий і перевірюваний результат щоразу.
Раннє попередження — це гроші за законом. Підрядник, який вчасно не попередив замовника про перевищення приблизного кошторису, виконує роботу за договірною ціною (ЦК України, ст. 844).
ШІ знімає ручну роботу. Він читає листування, пише дайджест і чернетку звіту замовнику, відповідає на питання в Telegram. Рішення лишаються за людьми.
Починати треба зі звітності й дисципліни даних, а не з «передбачення ризиків».

Що таке система управління ризиками в проєктній компанії

Міжнародний стандарт ISO 31000 описує управління ризиками як цикл: знайти ризик, проаналізувати, оцінити, вирішити, що з ним робити, і далі стежити за ним. Для компанії на 30 людей цей цикл зводиться до одного питання. Що може зірвати строк, бюджет або якість конкретного проєкту, і хто про це дізнається першим?

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

Звідки взялася «автоматизована система управління ризиками»

Якщо ви шукали цей термін і потрапили на матеріали митниці, це не випадковість. Митний кодекс у ст. 320 прямо пише, що форми та обсяги митного контролю обирають посадові особи на підставі системи управління ризиками та/або «автоматизованою системою управління ризиками» (Митний кодекс України). Звідси й формулювання на кшталт «забезпечує визначення обсягу» контролю. Податкова служба теж має власну систему ризиків для платників. Для компанії це інший світ: ідеться не про перевірку декларацій, а про власні проєкти, гроші й людей.

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

Реєстр ризиків проти системи

Ознака	Реєстр у таблиці	Система управління ризиками
Звідки ризики	Хтось вписав на нараді	Сигнали з даних плюс записи людей
Як часто оновлюється	Раз на місяць чи квартал	Щодня, автоматично
Що бачить директор	Список зі статусом «моніторинг»	Відхилення з цифрою, причиною й відповідальним
Хто повідомляє про проблему	Той, хто наважиться	Правило ескалації
Що лишається після проєкту	Файл, який ніхто не відкриє	Історія: що пішло не так і коли це стало видно

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

Чому строки й кошториси систематично оптимістичні

Психологи називають це хибою планування. У класичному дослідженні Б’юлера, Гріффіна й Росса 37 студентів оцінювали, коли допишуть дипломну роботу. У середньому вони називали 33,9 дня, а насправді знадобилося 55,5 дня, і вчасно встигли лише близько 30% (Planning fallacy, Wikipedia). Навіть «найгірший сценарій», який студенти назвали самі, — 48,6 дня — виявився кращим за реальність.

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

П’ять ризиків, які зривають проєкти малої компанії

Більшість зривів у компаніях на 10–100 людей мають одне з п’яти джерел. У кожного є свій ранній сигнал, і цей сигнал уже лежить у ваших даних.

Ризик	Ранній сигнал	Звідки дані	Хто реагує
Зрив строку	Темп закриття робіт падає два-три тижні поспіль; роботи критичного шляху стоять	Задачі в трекері або етапи в системі	Керівник проєкту
Перевитрата	Витрати по статті ростуть швидше, ніж виконання	Рахунки, оплати, облік часу	Керівник проєкту і власник
Нестача людей	Одна людина чи бригада запланована на два об’єкти в ті самі дні	Календар ключових ресурсів	Операційний директор
Затримка замовника	Погодження чекає довше за домовлений строк; немає відповіді на запит	Листування, картка проєкту	Менеджер клієнта
Зміна обсягу	«Дрібні» доробки без додаткової угоди; кількість правок росте	Листування, задачі з позначкою «додатково»	Керівник проєкту і власник

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

Зверніть увагу на колонку «Хто реагує». Сигнал без адресата — це шум. Якщо в компанії немає людини, яка має право перекинути бригаду з об’єкта на об’єкт, то й сигнал про конфлікт ресурсів нікому слати. Тому опис ролей іде раніше за налаштування сповіщень.

Фундамент: дані й автоматичні звіти

Перш ніж щось прогнозувати, треба перестати збирати статуси руками. За опитуванням Atlassian серед 12 000 працівників і 200 керівників, команди витрачають 25% часу просто на пошук відповідей (State of Teams 2025). У проєктній компанії цей пошук виглядає так: менеджер щопонеділка відкриває трекер задач, таблицю бюджету й три чати, щоб написати директору, як справи.

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

Мінімальний набір даних

Для всіх розрахунків у цій статті достатньо таких полів:

проєкт і його етапи (віхи);
робота з відповідальним, датою план і датою факт;
обсяг роботи — у годинах або в гривнях за кошторисом;
стаття бюджету й витрата: сума, дата, документ;
залежності: яка робота не може початися без іншої;
позначка «чекаємо замовника» з датою запиту;
позначка «додатково до договору».

Не треба ідеальної моделі. Краще десять полів, які заповнюють щодня, ніж п’ятдесят, які заповнюють перед нарадою. Якщо задачі вже ведуть у трекері з відкритим API (його мають Jira, Asana, Monday), дані можна забирати звідти. Якщо проєкти живуть у таблицях, їх переносять у систему й звіряють на реальних прикладах. У проєкті для виробника металоконструкцій така звірка з Excel знайшла помилки в самій таблиці: для кроку ферм 4,25 м вона видавала #Н/Д. Ми не виправляли це мовчки, а передали інженеру.

Щоденний дайджест у Telegram

Директор не сидить цілий день у дашборді. Він у Telegram, бо там команда, клієнти й постачальники. Тому основний вихід системи — короткий ранковий дайджест. Приблизно такий:

Проєкт В — прогноз здачі зсунувся на 9 днів; бригада оздоблення потрібна на двох об’єктах в один тиждень. Потрібне ваше рішення.

Проєкт Б — відставання 2 дні по монтажу, відповідальний Олег, прогноз здачі не змінився.

Проєкти А, Г, Д — у графіку.

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

Звіт для замовника

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

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

Контроль термінів: як порахувати прогноз затримки

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

Два способи прогнозу

Спосіб 1 — за темпом. Беремо, скільки робіт команда закривала щотижня за останні три тижні, і ділимо на це залишок. Прогнозна дата = сьогодні + залишок робіт / середній темп.

Спосіб 2 — за освоєним обсягом (earned value). Порівнюємо, скільки роботи мало бути виконано на сьогодні за планом (PV), і скільки виконано насправді (EV). Індекс виконання графіка SPI = EV / PV. Прогнозна тривалість ≈ планова тривалість / SPI.

Умовний приклад. Компанія монтує систему вентиляції: 120 робіт на 10 тижнів, по 12 на тиждень. Кінець п’ятого тижня: за планом мало бути закрито 60 робіт, закрито 42. Темп останніх трьох тижнів — 9, 8 і 7 робіт.

За темпом: залишок 78 робіт / 8 на тиждень ≈ 10 тижнів. Здача на 15-му тижні замість 10-го, тобто запізнення близько п’яти тижнів.
За SPI: 42 / 60 = 0,7. Тривалість 10 / 0,7 ≈ 14,3 тижня, запізнення понад чотири тижні.

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

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

Критичний шлях і буфер

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

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

Сходинки ескалації

Стартові правила, які потім калібрують:

1 день прострочки — нагадування виконавцю в Telegram;
3 дні — повідомлення керівнику проєкту разом із прогнозом;
5 днів або будь-яка затримка на критичному шляху — директору, з варіантами рішень;
прогноз здачі зсунувся більше ніж на тиждень — задача «попередити замовника» з чернеткою листа.

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

Чому затримку треба показати замовнику рано

Цивільний кодекс дає замовнику право відмовитися від договору підряду й вимагати збитків, якщо підрядник виконує роботу настільки повільно, що закінчення її у строк стає явно неможливим (ст. 849, ЦК України). Краще, щоб про відставання замовник дізнався від вас. Разом із прогнозом і варіантами: додати людей, перенести строк, скоротити обсяг. А не з власних спостережень на об’єкті.

І навпаки. Якщо затримка через замовника, який не виконав обов’язку сприяння, записаного в договорі, — не погодив креслення, не дав доступу на об’єкт, не надав обіцяних матеріалів, — ст. 850 того ж кодексу дає підряднику право вимагати відшкодування збитків, зокрема через простій і перенесення строків, або підвищення ціни роботи (ЦК України). Щоб цим скористатися, потрібні дати: коли попросили, коли отримали. Система записує їх у картку проєкту сама.

Контроль бюджету: план/факт і прогноз підсумкової вартості

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

План/факт по статтях щодня

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

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

CPI і прогноз: розібраний приклад

Індекс виконання вартості CPI = EV / AC. Тут EV — вартість виконаної роботи за кошторисом, AC — фактичні витрати на неї. Підсумкову вартість проєкту рахують двома способами:

якщо відхилення триватиме й далі: EAC = BAC / CPI, де BAC — бюджет проєкту;
якщо причина разова і більше не повториться: EAC = AC + (BAC − EV).

Умовний приклад. Бюджет об’єкта — 1 200 000 гривень. Виконано роботи на 480 000 гривень за кошторисом, а витрачено 600 000 гривень. CPI = 480 000 / 600 000 = 0,8. Якщо так піде й далі, проєкт коштуватиме 1 200 000 / 0,8 = 1 500 000 гривень, тобто на 300 000 гривень більше. Якщо перевитрата разова, наприклад переплатили за термінову поставку, прогноз — 600 000 + 720 000 = 1 320 000 гривень. Різниця між сценаріями — 180 000 гривень. Який із них ближчий до правди, вирішує не формула, а керівник проєкту, який знає причину.

Часто цитують правило: після 20% виконання CPI майже не змінюється. Воно походить з досліджень оборонних контрактів США, де накопичений CPI не змінювався більш як на 0,10 від значення в точці 20% виконання. Але пізніші дослідження показали, що на малих комерційних проєктах така стабільність трапляється рідко (Mosaic Projects, «The CPI Stability Myth»). Для компанії на 30 людей висновок простий: перераховуйте прогноз щотижня й дивіться на тренд, а не на одне значення.

Пороги по статтях бюджету

Стаття	Приклад порогу	Кому сигнал	Чому так
Матеріали за кошторисом	Відхилення від 5 відсотків	Керівник проєкту	Ціни відомі, обсяги великі
Субпідряд	Будь-який рахунок понад договір	Керівник проєкту і власник	Тут найчастіше «додаткові роботи» без погодження
Власна праця, години	Від 10 відсотків	Керівник проєкту	Перша ознака, що оцінка обсягу була заниженою
Техніка й логістика	Від 15 відсотків	Керівник проєкту	Суми менші, коливання природні
Непередбачене, консультації	Від 20 відсотків	Директор	Рідкісні, але некеровані витрати

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

Приблизний чи твердий кошторис: раннє попередження — це гроші

Стаття 844 ЦК ділить кошториси на приблизні й тверді, причому кошторис вважається твердим, якщо договір не каже інакше. Перевищення твердого кошторису несе підрядник. Якщо кошторис приблизний і через додаткові роботи його доводиться істотно перевищити, підрядник зобов’язаний своєчасно попередити замовника. Хто не попередив вчасно, виконує договір за ціною, встановленою договором (ЦК України, ст. 844).

Перекладемо на мову прикладу вище. Прогноз у 1 500 000 гривень замість 1 200 000 — це 300 000 гривень, які ви або обґрунтуєте замовнику заздалегідь, або заплатите самі. Тому в системі є окреме правило: якщо прогноз перевищує кошторис на заданий поріг, керівник проєкту отримує задачу «попередити замовника» з чернеткою листа й переліком додаткових робіт. Дата відправки лишається в історії проєкту. А тип кошторису в кожному договорі варто перевірити ще до старту — це перший запис у реєстрі ризиків.

Гроші в часі: касові розриви

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

Ресурси, замовник і зміни обсягу

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

Ресурсний календар: одна бригада на два об’єкти

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

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

Ризик ключової людини зараз особливо високий. За опитуванням ІЕД серед 472 промислових підприємств, у липні 2026 року на брак кадрів скаржилися 66% компаній, серед середніх — 74%. Головна причина — мобілізація працівників, її назвали 79,4% (Forbes Україна). Тому в календарі варто позначати людей, яких нема ким замінити, і для кожного — хто може підхопити роботу. Якщо такої людини немає, це запис у реєстр ризиків, а не тема для наради «колись потім».

Погодження з боку замовника

Частина затримок — не ваша. Замовник тиждень не погоджує креслення, не відповідає щодо кольору фасаду, не підписує акт. Система для кожного запиту ставить дату «чекаємо до» і рахує дні очікування. Ці дні видно окремим рядком у звіті: «відставання 9 днів, з них 6 — очікування погодження».

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

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

Зміни обсягу без доплати

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

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

Що робить ШІ, а що — формули і люди

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

Задача	Хто робить	Чому
Прогноз дати й підсумкової вартості	Формула: темп, SPI, CPI	Результат має бути однаковим щоразу й перевірюваним
Сповіщення й ескалація	Правило з порогами	Люди мають знати правило заздалегідь
Розбір листування й нотаток з нарад	ШІ	Текст у вільній формі, формулою його не розібрати
Дайджест і чернетка звіту замовнику	ШІ, перевіряє людина	Текст пише ШІ, цифри підставляє система
Відповіді на питання в Telegram	ШІ за даними системи	Швидше, ніж відкривати три програми
Рішення: додати людей, перенести строк, змінити ціну	Людина	Потрібні контекст і відповідальність

Що робить ШІ

Розбирає повідомлення замовника й команди у вільній формі: знаходить запити на доробки, обіцянки з датами, згадки про проблеми («постачальник переніс відвантаження»).
З нотаток наради витягає домовленості й пропонує задачі з відповідальними та строками. Людина підтверджує.
Пише текст ранкового дайджесту й тижневого звіту замовнику на основі цифр системи.
Відповідає в Telegram на питання «що з проєктом В», «хто відповідає за поставку», «скільки витрачено на субпідряд».
Пропонує записи в реєстр ризиків, коли бачить повторюваний сигнал, наприклад третій тиждень поспіль падає темп.

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

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

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

Як це влаштовано в нашій ШІ-системі управління бізнесом

Ми не продаємо окрему «програму для ризиків». Контроль строків, бюджету й ресурсів — частина ШІ-системи управління бізнесом, яку ми робимо під процес компанії. У ній проєкти й замовлення з етапами, клієнти, документи (рахунок, акт, видаткова накладна, комерційна пропозиція в PDF), оплати, задачі й сповіщення в Telegram, звіти. Код пише ШІ-агент під контролем архітектора, людина перевіряє на реальних даних. Перша робоча версія — за кілька днів, уся система — за 2–4 тижні після опису процесу.

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

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

Чого система управління ризиками не бачить

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

Форс-мажори

Система не передбачить обстріл, тривалий блекаут чи мобілізацію ключового інженера. За опитуванням Європейської бізнес-асоціації в січні 2026 року, відключення світла вплинули на роботу 80% опитаних компаній. Серед наслідків 61% назвали зростання собівартості, 58% — зміну графіків роботи, 48% — простої. При цьому 90% мають власні джерела живлення, а повністю енергонезалежні лише 23% (Dengi.ua).

Що система може: коли форс-мажор стався, швидко перерахувати прогнози й показати, які проєкти й строки зачеплено. І зберегти докази. Сертифікат ТПП не має наперед встановленої сили доказу, воєнний стан не звільняє від відповідальності автоматично, а сторона має довести причинний зв’язок між обставиною й зривом конкретного зобов’язання та вчасно повідомити контрагента (ДТКТ, огляд практики Верховного Суду). Записи в системі — коли зупинилися роботи, на скільки, що саме не вдалося зробити — і є матеріал для такого доведення.

Як підготувати дані, сервер і доступи на випадок збою, ми розібрали окремо, в статті про управління безперервністю бізнесу.

Ризики без даних

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

Малі проєкти й короткі строки

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

Брудні дані

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

Сама система — теж ризик

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

Як запустити: від звітів до прогнозів за кілька тижнів

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

Крок 0. Заміряйте, як є

Два тижні до старту зберіть чотири цифри:

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

Ці цифри потім покажуть, чи система щось змінила.

Крок 1. Опишіть процес

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

Крок 2. Перша версія: картки проєктів, дайджест, ескалації

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

Крок 3. Прогнози, ресурси й розбір листування

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

Чекліст готовності до прогнозів

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

Як порахувати, чи окупиться

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

Вартість часу на звіти

Медіанна зарплата менеджера проєктів в Україні на листопад 2026 року — 50 000 грн за даними 900 вакансій (Work.ua). Роботодавець зверху сплачує ЄСВ 22% (Закон про ЄСВ), разом 61 000 грн на місяць. При близько 168 робочих годинах на місяць це приблизно 363 грн за годину.

Умовний приклад. Двоє керівників проєктів витрачають по 4 години на тиждень на збір статусів і звітів. Це 8 годин на тиждень, близько 35 годин на місяць, або приблизно 12 700 гривень лише за їхній час. Без годин директора на наради «як справи» і без часу, який люди витрачають, відповідаючи на ці питання.

Вартість зривів

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

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

Типові помилки при впровадженні

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

Міряти виконання «на око». Фраза «готово на дев’яносто відсотків» живе тижнями. Простіше правило: робота або закрита, або ні. Для довгих робіт — половина за старт і половина за завершення, або проміжні віхи з чітким критерієм «прийнято».

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

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

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

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

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

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

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

Чи треба відмовлятися від Jira, Asana чи таблиць? Ні. Якщо команда звикла до трекера з відкритим API, дані беруть звідти, а система додає те, чого бракує: бюджет план/факт, ресурсний календар, ескалації й дайджест у Telegram. Таблиці зазвичай переносять у систему, бо їх важко контролювати, але роблять це зі звіркою на реальних прикладах.

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

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

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