Управління проєктами

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

Простими словами, управління проєктами відповідає на питання:

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

Головне. Управління проєктами потрібне для того, щоб робота не жила в чатах, головах, Excel-файлах і фразі “ми майже закінчили”. Проєкт має мати план, задачі, строки, відповідальних, бюджет, статуси і контроль результату.

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

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

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

Вступ

Проєкти є майже в кожній компанії.

Це може бути:

впровадження ERP;
розробка нового модуля;
запуск інтернет-магазину;
автоматизація складу;
відкриття нової філії;
будівництво;
ремонт;
виробництво складного виробу;
розробка сайту;
маркетингова кампанія;
сервісний проєкт;
переїзд офісу;
інтеграція з банком;
запуск CRM;
модернізація обладнання;
розробка мобільного додатку;
впровадження WMS;
створення нового продукту.

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

Наприклад, щоденний продаж товарів — це операційна діяльність.

А запуск нового напрямку продажів — це проєкт.

Планове технічне обслуговування обладнання — це регулярний процес.

А модернізація виробничої лінії — це проєкт.

Обробка заявок клієнтів — це операційний процес.

А впровадження нової системи підтримки клієнтів — це проєкт.

Управління проєктами потрібне, щоб компанія не просто “робила роботу”, а керувала цілями, строками, задачами, ресурсами, бюджетами, ризиками і результатами.

Що таке проєкт простими словами

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

Приклад проєкту:

Назва: Впровадження CRM
Мета: автоматизувати роботу відділу продажів
Старт: 01.04
Завершення: 30.06
Команда: керівник продажів, аналітик, розробник, адміністратор, тестувальник
Бюджет: 300 000 грн
Результат: CRM запущена, менеджери працюють у системі, звіти формуються автоматично

Проєкт не повинен бути вічним.

Якщо робота не має кінця, це або процес, або дуже небезпечний проєкт.

Для чого потрібне управління проєктами

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

Воно допомагає:

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

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

Проєкт, задача і процес

Важливо розрізняти проєкт, задачу і процес.

Поняття	Що означає	Приклад
Проєкт	Тимчасова робота з конкретною метою і результатом	Впровадити ERP на підприємстві
Задача	Окрема робота в межах проєкту або процесу	Налаштувати довідник контрагентів
Процес	Регулярна повторювана діяльність	Щомісячне нарахування зарплати

Проєкт може складатися з багатьох задач.

Процес може запускати задачі.

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

Наприклад, “зробити новий сайт” — це не задача на 2 години, а цілий проєкт із дизайном, структурою, текстами, розробкою, тестуванням, SEO, запуском і підтримкою.

Основні елементи проєкту

Проєкт зазвичай містить:

назву;
мету;
опис;
замовника;
керівника проєкту;
команду;
строки;
етапи;
задачі;
бюджет;
ресурси;
документи;
статус;
ризики;
пріоритет;
результат;
критерії приймання;
історію змін;
звіти.

Чим складніший проєкт, тим важливіше мати ці елементи в системі.

Мета проєкту

Мета проєкту — це відповідь на питання, навіщо він потрібен.

Погана мета:

Зробити автоматизацію.

Краща мета:

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

Ще краща мета:

Скоротити час обробки заявок на закупівлю з 5 днів до 1 дня, забезпечити погодження в ERP, контроль бюджету, автоматичне формування замовлень постачальникам і звітність по закупівлях.

Мета повинна бути зрозумілою і вимірюваною.

Якщо мета нечітка, проєкт може закінчитися тим, що всі щось робили, але ніхто не впевнений, чи це було те саме “щось”.

Результат проєкту

Результат — це те, що має бути отримано після завершення проєкту.

Приклади результатів:

запущена ERP;
працюючий модуль обліку;
відкритий магазин;
налаштована CRM;
готовий сайт;
введена в експлуатацію виробнича лінія;
виконаний ремонт;
підключена інтеграція;
автоматизований процес;
підготовлений комплект документів;
навчена команда.

Результат повинен бути перевірним.

Погано:

Система має працювати добре.

Краще:

Користувачі можуть створювати замовлення клієнтів, резервувати товар, формувати рахунок, контролювати оплату і відвантаження.

Критерії приймання

Критерії приймання визначають, коли результат можна вважати виконаним.

Приклад для розробки модуля:

реалізовано функціонал згідно ТЗ;
проведено тестування;
критичні помилки виправлені;
користувачі пройшли навчання;
дані перенесені;
звіти формуються;
відповідальний підписав акт приймання.

Критерії приймання зменшують конфлікти.

Без них наприкінці проєкту може з’явитися класичне:

Ми думали, що це теж входить.

І ця фраза дуже добре збільшує строки, бюджет і температуру переговорів.

Життєвий цикл проєкту

Проєкт проходить кілька етапів.

Типовий життєвий цикл:

ініціація;
планування;
виконання;
контроль;
завершення;
аналіз результатів.

Етап	Що відбувається
Ініціація	Визначається ідея, мета, замовник, попередні строки і сенс проєкту.
Планування	Формується план, задачі, бюджет, команда, ресурси і ризики.
Виконання	Команда виконує задачі, створює результат, веде комунікацію.
Контроль	Перевіряються строки, бюджет, якість, ризики, зміни і статуси.
Завершення	Результат приймається, документи закриваються, проєкт завершується.
Аналіз	Команда оцінює, що вийшло добре, що погано, які висновки зробити.

Ініціація проєкту

Ініціація — це стартова точка.

На цьому етапі потрібно зрозуміти:

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

Приклад:

Компанія хоче автоматизувати склад.

Проблеми:

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

Мета проєкту:

впровадити WMS;
підключити сканери;
автоматизувати приймання, розміщення, комплектацію і відвантаження.

Планування проєкту

Планування — один із найважливіших етапів.

Потрібно визначити:

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

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

Структура робіт проєкту

Проєкт потрібно розбити на логічні частини.

Наприклад, проєкт впровадження ERP може мати етапи:

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

Кожен етап складається з задач.

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

Задачі проєкту

Задача — це конкретна робота, яку потрібно виконати.

Задача повинна мати:

назву;
опис;
відповідального;
строк;
пріоритет;
статус;
результат;
коментарі;
файли;
зв’язок з етапом;
трудовитрати;
залежності;
критерії виконання.

Погана задача:

Зробити склад.

Краща задача:

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

Ще краща задача:

Налаштувати структуру складу №1: зони приймання, зберігання, комплектації, відвантаження, комірки A1-A200, правила розміщення за товарними групами. Результат: користувач може приймати товар і розміщувати його в комірки через ERP.

Статуси задач

Задачі повинні мати статуси.

Типові статуси:

нова;
запланована;
у роботі;
очікує інформації;
очікує погодження;
очікує тестування;
на перевірці;
виконана;
відхилена;
повернута на доопрацювання;
скасована;
заблокована;
прострочена.

Статус повинен показувати реальний стан.

Якщо всі задачі мають статус “у роботі”, це не статус. Це туман.

Краще бачити конкретно:

“Очікує даних від замовника”;
“На тестуванні”;
“Очікує погодження бюджету”;
“Заблоковано через відсутність інтеграції”.

Пріоритети задач

Задачі можуть мати пріоритет:

низький;
середній;
високий;
критичний.

Пріоритет допомагає команді розуміти, що виконувати першочергово.

Але якщо всі задачі мають пріоритет “критичний”, значить критичним є вже не проєкт, а система пріоритетів.

Пріоритет має бути реальним.

Критична задача — це та, яка блокує проєкт, створює великий ризик або впливає на ключовий строк.

Залежності між задачами

Задачі можуть залежати одна від одної.

Наприклад:

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

Залежності допомагають планувати послідовність.

Приклад:

Опис вимог → Технічне завдання → Розробка → Тестування → Навчання → Запуск

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

Віхи проєкту

Віха — це важлива контрольна точка проєкту.

Приклади віх:

затверджено ТЗ;
завершено розробку;
завершено тестування;
перенесено дані;
користувачі навчені;
система запущена;
проєкт прийнято замовником.

Віхи допомагають контролювати прогрес.

Вони показують не просто кількість задач, а важливі результати.

Дедлайни

Дедлайн — це кінцевий строк виконання задачі, етапу або проєкту.

У хорошому управлінні дедлайн повинен бути реалістичним.

Погана практика:

Поставити дедлайн “на вчора”, щоб швидше рухались.

Це не управління. Це спосіб отримати демотивацію і багато червоних задач.

Краще:

оцінити обсяг роботи;
врахувати залежності;
врахувати доступність людей;
додати резерв;
погодити строк;
контролювати виконання.

Ресурси проєкту

Ресурси — це все, що потрібно для виконання проєкту.

Наприклад:

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

ERP допомагає бачити, які ресурси потрібні, чи доступні вони і де є перевантаження.

Команда проєкту

Команда проєкту — це люди, які беруть участь у виконанні.

Ролі можуть бути такі:

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

Кожна роль повинна розуміти свою відповідальність.

Інакше виникає класична ситуація: “Я думав, це робить хтось інший”.

А “хтось інший” — один із найнебезпечніших співробітників у проєктах. Його ніхто не бачив, але він винен у багатьох затримках.

Керівник проєкту

Керівник проєкту відповідає за організацію виконання.

Його задачі:

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

Керівник проєкту не обов’язково виконує всі задачі сам.

Його робота — зробити так, щоб потрібні задачі були виконані потрібними людьми в потрібні строки.

Замовник проєкту

Замовник — це сторона, яка потребує результату.

Замовник може бути:

внутрішній;
зовнішній;
клієнт;
власник бізнесу;
керівник підрозділу;
директор;
державна або корпоративна структура.

Замовник визначає:

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

У проєкті важливо мати відповідального замовника.

Якщо замовник “усі”, то рішення часто не приймає ніхто.

Відповідальні за задачі

Кожна задача повинна мати відповідального.

Відповідальний — це людина, яка відповідає за виконання або організацію виконання задачі.

Не варто призначати відповідальними “відділ”, “команду” або “всі”.

Приклад погано:

Відповідальні: IT-відділ

Краще:

Відповідальний: Іваненко
Учасники: IT-відділ

Один відповідальний не означає, що він робить усе сам. Але саме він контролює результат.

Проєктний бюджет

Бюджет проєкту — це план витрат і доходів по проєкту.

Він може включати:

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

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

План-факт бюджету

Управління проєктом потребує план-фактного аналізу бюджету.

Приклад:

Стаття	План	Факт	Відхилення
Розробка	200 000	230 000	+30 000
Тестування	50 000	40 000	-10 000
Підрядники	100 000	120 000	+20 000
Навчання	30 000	30 000	0

Якщо факт перевищує план, потрібно розуміти причини:

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

Трудовитрати проєкту

Трудовитрати — це час, який команда витрачає на задачі проєкту.

Вони можуть вимірюватися в:

годинах;
людино-днях;
людино-тижнях;
спринтах;
змінах;
нормо-годинах.

Приклад:

Задача “Налаштувати інтеграцію з банком”:

план — 16 годин;
факт — 24 години;
відхилення — +8 годин.

Трудовитрати потрібні для:

планування;
розрахунку собівартості;
контролю завантаження;
оцінки прибутковості;
аналізу ефективності;
покращення майбутніх оцінок.

Облік часу в проєктах

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

Працівник може фіксувати час:

по задачах;
по етапах;
по клієнтах;
по видах робіт;
по днях;
по спринтах;
по виробничих операціях.

Приклад:

Працівник за день витратив:

3 години — аналіз вимог;
2 години — розробка;
1 година — зустріч;
2 години — тестування.

Це дозволяє зрозуміти, де реально витрачається час.

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

Завантаження команди

ERP може показувати завантаження працівників.

Наприклад:

Іваненко завантажений на 120%;
Петренко — на 60%;
Сидоренко — на 90%.

Це допомагає розподіляти роботу.

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

Завантаження потрібно планувати реалістично.

Людина не може працювати 8 годин на день над задачами, якщо в неї ще є зустрічі, підтримка, листування, погодження і життя.

Ризики проєкту

Ризик — це подія, яка може негативно вплинути на проєкт.

Приклади ризиків:

затримка погодження;
відсутність ключового спеціаліста;
зміна вимог;
нестача бюджету;
затримка постачальника;
технічна складність;
неправильні дані;
слабка комунікація;
недоступність обладнання;
нестача часу на тестування;
залежність від підрядника;
нестабільне фінансування.

Ризики потрібно не просто записувати, а й керувати ними.

Для кожного ризику бажано визначити:

ймовірність;
вплив;
відповідального;
план реагування;
статус.

Управління змінами

У проєктах часто виникають зміни.

Наприклад:

додали нову вимогу;
змінили дизайн;
змінили інтеграцію;
змінили строки;
змінили бюджет;
змінили відповідальних;
змінили процес;
змінили обсяг робіт.

Зміни потрібно контролювати.

Погана практика:

Давайте ще це додамо, воно ж маленьке.

Десять маленьких “ще це” можуть легко стати другим проєктом.

Кожна зміна повинна відповідати на питання:

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

Scope creep

Scope creep — це неконтрольоване розширення обсягу проєкту.

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

Приклад:

Спочатку потрібно було зробити простий звіт.

Потім додали фільтри.

Потім графіки.

Потім експорт.

Потім права доступу.

Потім автоматичну розсилку.

Потім мобільну версію.

Потім інтеграцію з CRM.

І все це “в рамках того ж завдання”.

Scope creep небезпечний, бо руйнує строки і бюджет.

ERP допомагає фіксувати зміни і погоджувати їх.

Документи проєкту

Проєкт може мати багато документів.

Наприклад:

технічне завдання;
комерційна пропозиція;
договір;
кошторис;
план робіт;
протоколи зустрічей;
акти;
рахунки;
специфікації;
схеми;
макети;
інструкції;
тест-кейси;
звіти;
листування;
презентації;
файли приймання.

ERP повинна зберігати документи поруч із проєктом.

Це краще, ніж коли ТЗ у пошті, договір у юриста, кошторис в Excel, а фінальна версія макета в чаті під назвою “ось цей точно фінал”.

Технічне завдання

Технічне завдання описує, що потрібно зробити.

ТЗ може містити:

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

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

Без ТЗ проєкт часто рухається за принципом “зробіть як треба”.

А “як треба” в голові замовника і виконавця може бути двома різними всесвітами.

Погодження проєктних документів

Проєктні документи можуть потребувати погодження.

Наприклад:

бюджет;
ТЗ;
кошторис;
договір;
зміни;
акти;
рахунки;
етапи;
приймання результату;
закупівлі;
план робіт.

ERP може автоматизувати маршрути погодження.

Приклад:

ТЗ погоджують:

замовник;
бізнес-аналітик;
технічний спеціаліст;
керівник проєкту;
директор.

Зміна бюджету погоджується:

керівником проєкту;
фінансами;
замовником;
директором.

Комунікація в проєкті

Комунікація — одна з головних причин успіху або провалу проєктів.

Потрібно визначити:

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

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

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

Протоколи зустрічей

Після важливих зустрічей бажано фіксувати протокол.

У протоколі можна вказувати:

дату;
учасників;
питання;
прийняті рішення;
задачі;
відповідальних;
строки;
відкриті питання;
ризики.

Протокол допомагає уникнути ситуації, коли всі по-різному пам’ятають, що вирішили.

А пам’ять у проєктах часто працює в інтересах того, хто не хоче переробляти.

Контроль виконання проєкту

Контроль потрібен для розуміння, чи рухається проєкт до результату.

Контролювати потрібно:

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

ERP може показувати статус проєкту:

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

Звіти по проєктах

Для керівника корисні звіти:

список активних проєктів;
статуси проєктів;
задачі по проєктах;
прострочені задачі;
завантаження команди;
план-факт бюджету;
план-факт строків;
трудовитрати;
прибутковість;
ризики;
блокування;
зміни;
документи на погодженні;
проєкти з перевищенням бюджету;
проєкти з високим ризиком.

Звіт повинен допомагати приймати рішення, а не просто прикрашати нараду.

Дашборд проєкту

Дашборд проєкту може показувати:

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

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

Поганий дашборд показує 47 графіків і не відповідає на питання: “Ми встигаємо чи ні?”

Канбан у проєктах

Канбан — це спосіб візуального управління задачами.

Колонки можуть бути:

нові;
заплановані;
у роботі;
на перевірці;
очікує;
виконані.

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

Він допомагає бачити, де накопичуються задачі.

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

Діаграма Ганта

Діаграма Ганта показує задачі на шкалі часу.

Вона корисна для:

планування строків;
залежностей;
етапів;
віх;
критичного шляху;
завантаження;
перенесення робіт.

Приклад:

Аудит              01.04 — 10.04
ТЗ                 11.04 — 20.04
Розробка           21.04 — 20.05
Тестування         21.05 — 31.05
Навчання           01.06 — 10.06
Запуск             15.06

Гант корисний для складних проєктів із багатьма залежностями.

Спринти

У розробці і гнучких методологіях часто використовують спринти.

Спринт — це короткий період роботи, наприклад 1–2 тижні, за який команда виконує певний набір задач.

Спринт допомагає:

планувати короткими циклами;
швидше отримувати результат;
регулярно переглядати пріоритети;
тестувати частинами;
отримувати зворотний зв’язок.

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

Agile, Waterfall і змішані підходи

Управління проєктами може використовувати різні підходи.

Waterfall — послідовний підхід: спочатку вимоги, потім проєктування, розробка, тестування, запуск.

Підходить там, де вимоги стабільні і добре описані.

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

Підходить там, де вимоги можуть змінюватися.

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

Наприклад, у впровадженні ERP може бути загальний план етапів, але розробка окремих модулів може виконуватися спринтами.

Управління якістю

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

Контроль якості може включати:

перевірку вимог;
тестування;
рев’ю;
демонстрації;
приймання етапів;
чек-листи;
контроль помилок;
аналіз відхилень;
погодження результату;
навчання користувачів.

Якість потрібно контролювати під час проєкту, а не тільки в кінці.

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

Тестування в проєктах

Тестування потрібне не тільки в IT.

Його можна застосовувати до:

ERP-модулів;
бізнес-процесів;
виробничих ліній;
складів;
документів;
інтеграцій;
звітів;
обладнання;
сервісних процесів;
навчальних сценаріїв.

Приклад для ERP:

перевірити створення замовлення;
перевірити резерв товару;
перевірити рахунок;
перевірити оплату;
перевірити відвантаження;
перевірити проводки;
перевірити звіти.

Тестування повинно мати сценарії і результати.

Приймання етапів

Великі проєкти краще приймати поетапно.

Наприклад:

прийнято ТЗ;
прийнято прототип;
прийнято перший модуль;
прийнято інтеграцію;
прийнято перенесення даних;
прийнято навчання;
прийнято запуск.

Це зменшує ризик, що в кінці проєкту накопичиться великий список претензій.

Поетапне приймання дозволяє вчасно виправляти проблеми.

Закриття проєкту

Проєкт потрібно не тільки почати, а й правильно закрити.

Закриття може включати:

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

Проєкт без закриття часто продовжує жити як “ще трохи доробимо”.

А “ще трохи” може тривати роками.

Постпроєктний аналіз

Після завершення проєкту корисно зробити аналіз.

Питання:

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

Постпроєктний аналіз допомагає не повторювати ті самі помилки.

Хоча бізнес іноді дуже любить повторювати помилки, просто називаючи їх “новим досвідом”.

Проєкти у впровадженні ERP

Впровадження ERP — це класичний складний проєкт.

Він може включати:

аудит;
опис процесів;
технічне завдання;
налаштування;
розробку;
інтеграції;
міграцію даних;
тестування;
навчання;
запуск;
підтримку.

ERP-проєкти потребують особливої дисципліни, бо зачіпають багато підрозділів:

продажі;
закупівлі;
склад;
виробництво;
фінанси;
бухгалтерію;
HR;
сервіс;
керівництво.

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

Проєкти в розробці програмного забезпечення

У розробці програмного забезпечення проєкт може включати:

аналіз вимог;
архітектуру;
дизайн;
розробку;
тестування;
документацію;
DevOps;
реліз;
підтримку.

Важливо контролювати:

задачі;
баги;
релізи;
версії;
гілки розробки;
тестування;
технічний борг;
пріоритети;
зміну вимог;
приймання.

Для таких проєктів часто використовують спринти, канбан, backlog і релізне планування.

Проєкти у виробництві

У виробництві проєктами можуть бути:

запуск нового виробу;
модернізація лінії;
виробництво складного замовлення;
перенесення виробництва;
впровадження нової технології;
автоматизація цеху;
підготовка до сертифікації;
ремонт виробничого приміщення.

Виробничі проєкти часто пов’язані з:

специфікаціями;
маршрутизацією;
матеріалами;
обладнанням;
плановим ТО;
закупівлями;
собівартістю;
якістю;
строками постачання.

Проєкти в будівництві і ремонтах

Будівельні та ремонтні проєкти потребують контролю:

кошторису;
матеріалів;
підрядників;
графіка робіт;
актів;
оплат;
об’єктів;
технічного нагляду;
змін;
дефектів;
приймання етапів.

ERP може пов’язувати:

задачі;
закупівлі;
склад;
підрядників;
договори;
платежі;
акти;
бюджет;
фотофіксацію;
документи.

Проєкти в сервісі

У сервісному бізнесі проєктами можуть бути:

комплексне впровадження для клієнта;
сервісний контракт;
ремонт великого об’єкта;
гарантійна кампанія;
модернізація обладнання клієнта;
монтаж системи;
запуск обслуговування.

Такі проєкти можуть включати:

сервісні заявки;
виїзди;
запчастини;
графіки;
акти;
фото;
трудовитрати;
рахунки;
гарантії;
SLA.

Проєкти в маркетингу

Маркетингові проєкти можуть включати:

запуск рекламної кампанії;
розробку сайту;
підготовку виставки;
запуск бренду;
створення контенту;
SEO-кампанію;
email-розсилку;
рекламні матеріали;
PR-кампанію.

Для маркетингу важливо контролювати:

задачі;
бюджет;
канали;
дедлайни;
погодження матеріалів;
результати;
витрати;
ліди;
ефективність.

Проєктний облік

Проєктний облік — це облік доходів, витрат, задач, ресурсів і результатів по конкретних проєктах.

Він дозволяє бачити:

бюджет проєкту;
фактичні витрати;
трудовитрати;
закупівлі;
платежі;
доходи;
маржу;
прибутковість;
дебіторську заборгованість;
кредиторську заборгованість;
незавершені роботи;
акти;
рахунки.

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

Доходи проєкту

Доходи проєкту можуть формуватися з:

договору з клієнтом;
етапів;
актів;
рахунків;
передоплат;
підписок;
сервісних платежів;
бонусів;
додаткових робіт.

ERP може показувати:

планові доходи;
фактичні доходи;
виставлені рахунки;
оплачені рахунки;
заборгованість клієнта;
акти;
залишок до виставлення;
прогноз доходів.

Витрати проєкту

Витрати проєкту можуть включати:

трудовитрати;
матеріали;
закупівлі;
підрядників;
відрядження;
обладнання;
ліцензії;
сервіс;
транспорт;
оренду;
адміністративні витрати;
непередбачені витрати.

ERP може збирати витрати з різних документів:

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

Прибутковість проєкту

Прибутковість проєкту розраховується як різниця між доходами і витратами.

Проста формула:

Прибуток проєкту = Доходи проєкту - Витрати проєкту

Приклад:

Доходи — 1 000 000 грн.

Витрати:

трудовитрати — 300 000 грн;
підрядники — 200 000 грн;
матеріали — 150 000 грн;
інші витрати — 50 000 грн.

Разом витрати — 700 000 грн.

Прибуток:

1 000 000 - 700 000 = 300 000 грн

Маржа:

300 000 / 1 000 000 × 100% = 30%

Якщо не враховувати трудовитрати, проєкт може виглядати прибутковішим, ніж є насправді.

Проєкти і платіжний календар

Проєкти впливають на платіжний календар.

Проєкт може створювати:

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

Приклад:

Клієнт платить:

30% передоплата;
40% після першого етапу;
30% після завершення.

Підряднику потрібно платити щомісяця.

ERP повинна показувати cash flow по проєкту.

Проєкт може бути прибутковим у цілому, але мати касовий розрив у середині виконання.

Проєкти і закупівлі

Проєкт може створювати потребу в закупівлях.

Наприклад:

матеріали;
обладнання;
запчастини;
послуги;
ліцензії;
підрядники;
транспорт;
інструмент.

Заявка на закупівлю може бути прив’язана до проєкту.

Це дозволяє бачити:

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

Проєкти і склад

У проєктах можуть використовуватись матеріали зі складу.

Наприклад:

будівельні матеріали;
комплектуючі;
запчастини;
обладнання;
витратні матеріали;
рекламна продукція;
інструмент.

ERP може списувати матеріали на конкретний проєкт.

Це дозволяє рахувати фактичну собівартість.

Якщо матеріали просто “взяли зі складу”, а на проєкт не списали, прибутковість проєкту буде схожа на казку. Гарну, але неправдиву.

Проєкти і документообіг

Проєкти мають багато документів і погоджень.

ERP може пов’язувати з проєктом:

договори;
рахунки;
акти;
заявки;
ТЗ;
кошториси;
накладні;
протоколи;
листування;
файли;
погодження;
зміни.

Це дозволяє бачити всю історію проєкту в одному місці.

Проєкти і CRM

Проєкт може починатися з CRM.

Наприклад:

Лід → Угода → Комерційна пропозиція → Договір → Проєкт → Виконання → Акт → Оплата

CRM допомагає продавати.

Проєктне управління допомагає виконувати продане.

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

Проєкти і підтримка клієнтів

Після завершення проєкту може починатися підтримка.

Наприклад:

гарантійна підтримка;
сервісний супровід;
технічна підтримка;
доопрацювання;
SLA;
абонентське обслуговування.

ERP може переводити проєкт у режим підтримки або створювати сервісний контракт.

Важливо відокремлювати:

роботи в межах проєкту;
гарантійні виправлення;
нові платні роботи;
підтримку;
зміни обсягу.

Проєкти і виробничі замовлення

У виробництві проєкт може бути пов’язаний із виробничими замовленнями.

Наприклад:

Проєкт: виготовлення обладнання для клієнта.

Він включає:

конструкторську підготовку;
закупівлю матеріалів;
виробничі замовлення;
складання;
тестування;
доставку;
монтаж;
запуск.

ERP може пов’язувати виробничі витрати з проєктом.

Проєкти і сервісні заявки

У сервісі проєкт може складатися з багатьох заявок.

Наприклад:

Проєкт: обслуговування мережі магазинів клієнта.

Сервісні заявки:

ремонт каси;
заміна сканера;
налаштування принтера;
виїзд інженера;
заміна блока живлення;
перевірка мережі.

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

Проєкти і табель робочого часу

Проєктний облік може бути пов’язаний із табелем обліку робочого часу.

Працівники можуть фіксувати час по проєктах і задачах.

Це потрібно для:

собівартості;
завантаження команди;
розрахунку зарплати;
виставлення рахунків клієнту;
аналізу прибутковості;
контролю ефективності.

Приклад:

Працівник відпрацював 8 годин:

5 годин — проєкт А;
2 години — проєкт Б;
1 година — внутрішні задачі.

Ці дані можуть потрапити в аналітику проєктів.

Проєкти і фінансова звітність

Проєкти можуть впливати на фінансову звітність і управлінський облік.

Потрібно контролювати:

доходи;
витрати;
незавершене виробництво;
аванси;
дебіторську заборгованість;
кредиторську заборгованість;
платежі;
маржу;
прибутковість;
резерви;
бюджети.

Для великих проєктів важливо бачити фінансовий стан не тільки після завершення, а під час виконання.

Портфель проєктів

Якщо компанія веде багато проєктів, потрібне управління портфелем.

Портфель проєктів показує:

всі активні проєкти;
пріоритети;
бюджети;
ресурси;
ризики;
статуси;
прибутковість;
стратегічну важливість;
завантаження команди;
конфлікти ресурсів.

Приклад:

Компанія має 20 активних проєктів.

5 із них критичні.

3 перевищують бюджет.

4 затримуються.

2 потребують рішення директора.

ERP повинна показати це на рівні керівництва.

Пріоритизація проєктів

Не всі проєкти однаково важливі.

Пріоритет може залежати від:

стратегічної цінності;
прибутковості;
клієнта;
строків;
ризиків;
законодавчих вимог;
впливу на бізнес;
доступності ресурсів;
фінансування.

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

Краще мати пріоритети і чесно розуміти, що можна виконати зараз, а що потрібно перенести.

Внутрішні і зовнішні проєкти

Проєкти можуть бути внутрішніми або зовнішніми.

Внутрішній проєкт виконується для потреб компанії.

Приклади:

впровадження ERP;
ремонт офісу;
автоматизація складу;
навчання персоналу;
запуск нового процесу.

Зовнішній проєкт виконується для клієнта.

Приклади:

розробка сайту;
впровадження системи;
монтаж обладнання;
будівництво;
сервісний контракт;
консалтинг.

Зовнішні проєкти частіше мають доходи і клієнтське приймання.

Внутрішні — економічний ефект, зменшення витрат або покращення процесів.

Типові помилки в управлінні проєктами

Найпоширеніші помилки:

немає чіткої мети;
немає ТЗ;
немає відповідального керівника;
задачі не деталізовані;
строки нереалістичні;
бюджет не порахований;
не ведуться трудовитрати;
не контролюються зміни;
немає критеріїв приймання;
документи розкидані по пошті і чатах;
немає план-факту;
ризики не ведуться;
команда перевантажена;
замовник не залучений;
немає регулярного контролю;
проєкт не закривається формально.

Окрема класика — “ми все обговорили”.

Обговорили — це добре.

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

Excel в управлінні проєктами

Excel часто використовують для управління проєктами.

На старті це може працювати.

Але з ростом кількості задач, людей і документів виникають проблеми:

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

Типовий файл:

План_проєкту_оновлений_фінальний_після_правок_замовника_версія_14.xlsx

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

Автоматизація управління проєктами в ERP

ERP дозволяє зробити управління проєктами частиною єдиної системи підприємства.

Система може забезпечити:

реєстр проєктів;
етапи;
задачі;
відповідальних;
строки;
статуси;
пріоритети;
залежності;
трудовитрати;
бюджет;
план-факт;
документи;
погодження;
ризики;
зміни;
комунікацію;
зв’язок із CRM;
зв’язок із закупівлями;
зв’язок зі складом;
зв’язок із виробництвом;
зв’язок із фінансами;
зв’язок із табелем;
аналітику;
дашборди.

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

Як K2 ERP допомагає з управлінням проєктами

K2 ERP може використовуватися для управління проєктами різного типу: внутрішніми, клієнтськими, виробничими, сервісними, будівельними, IT, маркетинговими, впроваджувальними та організаційними.

Система може охоплювати:

реєстр проєктів;
картки проєктів;
етапи;
задачі;
підзадачі;
статуси;
пріоритети;
відповідальних;
команду;
строки;
віхи;
трудовитрати;
табель робочого часу;
бюджет;
план-факт;
доходи;
витрати;
закупівлі;
складські списання;
договори;
рахунки;
акти;
платежі;
платіжний календар;
документи;
погодження;
ризики;
зміни;
CRM;
виробничі замовлення;
сервісні заявки;
аналітику;
права доступу;
звіти для керівництва.

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

Для середнього бізнесу — проєкти з бюджетами, документами, задачами, трудовитратами, закупівлями і план-фактом.

Для великого бізнесу — повноцінне управління портфелем проєктів, ресурсами, фінансами, договорами, виробництвом, сервісом, інтеграціями і управлінською аналітикою.

Приклад процесу в K2 ERP

Приклад процесу клієнтського проєкту:

у CRM створюється угода;
після продажу формується проєкт;
до проєкту підв’язується договір;
створюються етапи і задачі;
призначаються відповідальні;
формується бюджет;
команда фіксує трудовитрати;
закупівлі прив’язуються до проєкту;
матеріали списуються на проєкт;
рахунки і акти формуються по етапах;
оплати потрапляють у платіжний календар;
керівник бачить план-факт по строках, бюджету і прибутковості;
після приймання проєкт закривається.

Приклад внутрішнього проєкту:

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

Що потрібно описати перед впровадженням управління проєктами

Перед автоматизацією проєктів потрібно відповісти на питання:

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

Чим краще описана логіка проєктів, тим менше хаосу буде в управлінні.

Ролі в управлінні проєктами

У проєктах можуть брати участь різні ролі.

Роль	Що робить
Замовник	Визначає потребу, очікуваний результат, пріоритети і приймає результат.
Керівник проєкту	Планує, координує, контролює строки, бюджет, задачі, ризики і команду.
Виконавець	Виконує задачі, фіксує статус, час, коментарі і результат.
Аналітик	Описує вимоги, процеси, ТЗ, сценарії і критерії приймання.
Фінансовий відділ	Контролює бюджет, витрати, доходи, платежі, cash flow і прибутковість.
Бухгалтерія	Веде документи, акти, рахунки, витрати і фінансове відображення.
Закупівельник	Забезпечує матеріали, послуги, підрядників і обладнання для проєкту.
Керівник підрозділу	Погоджує ресурси, пріоритети, участь співробітників і результат.
Директор	Контролює стратегічні проєкти, бюджети, ризики і ключові рішення.
ERP-адміністратор	Налаштовує довідники, статуси, права, маршрути, шаблони і звіти.

Коротко

Питання	Відповідь
Що таке управління проєктами?	Це планування, виконання, контроль і завершення робіт, які мають мету, строки, бюджет, команду, задачі і результат.
Що таке проєкт?	Це тимчасова робота з конкретною метою, початком, завершенням, відповідальними і очікуваним результатом.
Чим проєкт відрізняється від процесу?	Проєкт має кінцеву мету і строк, а процес повторюється регулярно.
Що таке задача проєкту?	Це конкретна робота в межах проєкту з відповідальним, строком, статусом і результатом.
Навіщо потрібен бюджет проєкту?	Щоб контролювати витрати, доходи, прибутковість і економічну доцільність проєкту.
Що таке трудовитрати?	Це час, який команда витрачає на задачі, етапи або проєкт у цілому.
Навіщо потрібне управління змінами?	Щоб контролювати нові вимоги, їх вплив на строки, бюджет і обсяг робіт.
Що таке критерії приймання?	Це умови, за якими визначається, що результат виконано і його можна прийняти.
Як проєкти пов’язані з фінансами?	Через бюджет, доходи, витрати, рахунки, акти, платежі, дебіторку, кредиторку і cash flow.
Чому Excel незручний для управління проєктами?	Через ручне оновлення, різні версії, слабкий контроль задач, строків, бюджету, документів і трудовитрат.
Як ERP допомагає?	ERP об’єднує проєкти, задачі, бюджет, трудовитрати, документи, закупівлі, склад, CRM, фінанси, погодження і звіти.
Як K2 ERP може допомогти?	K2 ERP може автоматизувати управління проєктами, задачами, строками, ресурсами, бюджетами, документами, трудовитратами, платежами і аналітикою.

Висновок

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

Проєкт не повинен жити тільки в чатах, Excel-файлах, головах керівників і усних домовленостях.

У проєкту мають бути:

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

K2 ERP може допомогти зробити управління проєктами частиною єдиної системи підприємства: від CRM до договору, від задач до трудовитрат, від закупівель до бюджету, від складу до списання, від рахунку до оплати, від плану до факту.

Проєктне управління — це не про красиві таблиці і нескінченні наради.

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

Бо проєкт без управління теж рухається.

Просто не завжди туди, не завжди вчасно і майже ніколи в межах бюджету.