Керівник IT-студії в кінці кварталу зводить дані по проекту, який «йшов нормально». Виставлено клієнту 800 000 грн. Витрачено на нього: зарплата команди 540 000, субпідряд дизайнера 120 000, інфраструктура 25 000, переробка двох фіч 85 000. Маржа — 30 000 грн, або 3,7%. А планували 30%.

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

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

Чому без обліку проектів ви дізнаєтесь про збиток лише в кінці?

У IT-студій, агенцій, консалтингу, інженерних бюро є типовий стек:

• Toggl / Harvest / Clockify — облік часу команди
• Excel або Google Sheets — кошторис проекту, бюджет
• 1С / SAP / окрема бухгалтерія — рахунки клієнтам, ЗП, податки
• Jira / Asana / Trello — задачі

У кожній системі — свої дані, свої формати, свої власники. Раз на місяць хтось (зазвичай керівник або фінансист) збирає це в зведену таблицю — і там виявляється, що проект, який «здавався в плюс», насправді на межі. Або вже минув її.

Конкретні проблеми, які створює розрізнення систем:

• Запізніла діагностика. Маржа порахована через 3-6 тижнів після фактичних витрат. На цей момент уже неможливо щось виправити — лише зафіксувати.
• «Невидимі» витрати. Закупили субпідряд 50 000 грн — це пройшло через бухгалтерію, але не потрапило в кошторис проекту в Excel. У звіт по проекту ці гроші не лягли.
• Подвійний ввід. Менеджер вводить години в Toggl, потім переносить їх у звіт для клієнта, потім бухгалтер створює інвойс. Одна година — три введення, помилки на кожному кроці.
• Час непомітно тече в «не оплачуване». Code review, мітинги, переробка — годин багато, а в інвойс клієнту вони не йдуть. Без класифікації часу неможливо побачити співвідношення продуктивний/непродуктивний.
• Виставлення T&M-рахунку — окремий ритуал. Експорт з Toggl, фільтрація, копіювання сум, ручний інвойс. 30-40 хвилин на проект на місяць.

Власник студії з 10 розробниками і 5 паралельними проектами втрачає 8-12 годин щомісяця тільки на звірку цих систем. І все одно отримує запізнілу картину.

Як ERPJS структурує проект?

Проект у ERPJS — це окрема картка з обов’язковими атрибутами і живим зв’язком з усім обліком компанії.

Що зберігається в картці:

• Код і назва — для швидкого пошуку і прив’язки документів
• Клієнт — посилання на картку контрагента; для внутрішніх проектів поле залишається порожнім
• Тип проекту — налаштовується вами (наприклад: розробка, підтримка, маркетинг, дослідження)
• Фази / етапи — окремий довідник, з яким працює бюджет (про це далі)
• Команда — список учасників і до п’яти менеджерів (керівник проекту, технічний лід, аккаунт-менеджер, головний дизайнер тощо)
• Контактна особа клієнта — щоб не шукати в CRM
• Дати — старт, плановий фініш, фактичний фініш
• Статус — активний / завершений
• Ієрархія — проект може бути підпроектом іншого (для великих програм)

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

Як планувати бюджет проекту з нуля?

Бюджет у ERPJS — це окремий документ з матрицею робіт і матеріалів. Не таблиця в Excel — повноцінний обліковий документ з історією, версіями і затвердженням.

Що йде в бюджет:

• Послуги / роботи (рядки з кількістю годин і ставкою)
• Товари і матеріали (з ціною закупки і продажу)
• Розбивка по фазах — кожен рядок прив’язаний до етапу проекту
• Знижки для клієнта

Система автоматично рахує по бюджету:

• Сума робіт
• Сума товарів і матеріалів
• Загальна сума контракту
• Очікуваний прибуток
• Маржа у відсотках
• Націнка

Бюджет підтримує версії. Це важлива деталь: ви робите план А, потім після перемовин з клієнтом — план B зі скороченим скоупом, потім фінальний затверджений варіант. Усі версії зберігаються, можна порівняти що змінилось.

Окремий статус «Затверджено» — поки бюджет не затверджений керівником, він є чернеткою. Затверджений — стає базою для порівняння план/факт.

Як побачити який час реально йде клієнту, а який ні?

Це питання задає собі кожен власник IT-студії або агенції. Команда списала 200 годин на проект, інвойс на 200 годин клієнту — а маржа все одно мала. Чому?

Тому що з тих 200 годин:

• Частина — мітинги і обговорення (не завжди оплачується клієнтом)
• Частина — code review і переробка дефектів (рідко оплачується)
• Частина — час на затримки, очікування відповіді клієнта (накладні витрати)
• Частина — навчання нового розробника на проекті (інвестиція, не дохід)

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

Найпоширеніші приклади того, як компанії розрізняють час:

• Продаваний час — години, які підуть в інвойс клієнта
• Непродуктивний / не визнаний клієнтом — переробка, помилки, час за межами скоупу, які клієнт не оплатить
• Внутрішній — мітинги, навчання, R&D, написання документації, корпоративні події
• Невикористаний — простій, очікування доступів або відповіді клієнта

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

• Скільки годин з тих 200 реально пішли в інвойс
• Скільки «з’їлося» на переробку — це сигнал переоцінити проект або переучити команду
• Скільки часу на внутрішку — це інвестиція, не збиток, але треба знати скільки

Окремо — внутрішні проекти. Для часу, який не йде клієнту взагалі (R&D, внутрішня автоматизація, ваш власний продукт) заводиться проект без клієнта. Час на нього списується тими ж табелями, але в клієнтську аналітику не потрапляє. Так ви точно розрізняєте: робота на клієнтів окремо, інвестиції в компанію — окремо.

Класифікацію визначаєте ви, а не нав’язана структура. Дрібна агенція може мати 2 класи (оплачуваний / неоплачуваний), велика IT-студія — 5-7 (розробка, code review, мітинги, навчання, support, презейл тощо). Табелі затверджуються керівником — у звіти йдуть тільки затверджені години.

Які витрати автоматично потрапляють у проект?

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

1. Час команди. Усі затверджені табелі помножуються на ставки працівників і дають загальну вартість праці на проекті. Якщо у вас різні класи часу — у витрати ідуть усі (бо праця — це факт), але у звіті можна побачити розбивку.

2. Закупівлі і підряд. Кожен вхідний рахунок (від субпідрядника, постачальника матеріалів, інфраструктури) має поле «Проект». Якщо закупівля створена з рядка бюджету — проект підставляється автоматично, не треба нічого вибирати. Якщо закупівля окрема (наприклад, додатковий тестувальник на спринт) — менеджер вказує проект при створенні. Це стандартна логіка прив’язки документів до аналітики.

3. Матеріали зі складу. Якщо в проекті використовуються матеріали (обладнання для клієнта, серверне залізо, witnesses kits) — їх рух фіксується через списання зі складу з прив’язкою до проекту.

Все це збирається автоматично у звіт «Інформація по проекту» — без додаткових вивантажень, без ручної звірки.

Як виставляти рахунки клієнту — Fixed Price чи Time & Materials?

ERPJS підтримує обидві моделі.

Fixed Price (фіксована вартість по фазах). Бюджет містить рядки робіт, прив’язані до фаз. Коли фаза завершена — створюється інвойс із цих рядків. Поле «Виставлено» фіксує номер інвойсу — потім видно, які рядки бюджету вже виставлені, а які ні. Підходить для проектів з чітко визначеним скоупом і поетапною оплатою.

Time & Materials (за годинами). Інвойс формується із затверджених табелів за період, помножених на ставку. Окрема процедура збирає всі години з класом «продаваний» за обраний місяць (або тиждень) і створює інвойс із розшифровкою по днях. Цю процедуру можна викликати вручну в кінці місяця або поставити на крон — раз на місяць T&M-інвойси генеруються автоматично з затверджених табелів, керівнику залишається лише подивитися перед відправкою клієнту.

Можна змішувати моделі в одному проекті — наприклад, fixed price за основні фази + T&M за окремий пул годин на підтримку.

Який звіт показує рентабельність проекту в реальному часі?

Звіт «Інформація по проекту» — основний інструмент для керівника. Він показує по конкретному проекту або зведено по всіх:

• Дохід — сума виставлених і запланованих інвойсів
• Витрати — час команди × ставки + закупівлі + матеріали
• Маржа в грошах — Дохід мінус Витрати
• Маржа у % — наскільки прибутковий проект

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

Можна побудувати звіт по фазах — і побачити, що перша фаза в межах бюджету, а друга вже перевищила план на 20%. Це сигнал діяти зараз, поки треті і четверті фази не повторили історію.

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

Як планувати завантаженість команди вперед?

Окремий інструмент — Менеджер ресурсів, календарний планувальник з трьома режимами:

• Місяць — огляд завантаженості команди на 30 днів вперед
• Тиждень — деталізація по днях тижня
• День — розбиття по годинах усередині робочого дня

Як це працює:

1. Працівники заводяться в системі як ресурси — кожен має свій код, графік роботи, інформацію про роль
2. На проектах створюються задачі — з датами початку, дедлайном і списком виконавців (один або кілька на задачу)
3. Кожна задача має тип — розробка, тестування, мітинг, дизайн, code review — типи налаштовуються з кольорами
4. Менеджер ресурсів автоматично відображає календарну сітку: рядки — працівники, колонки — дати, кольорові блоки в клітинках — задачі по типу

Що видно одразу:

• Хто перевантажений на наступний тиждень (рядок забитий блоками)
• У кого є вільне вікно (порожні клітинки)
• Як розподілений тип роботи по команді (наприклад, чи не все тестування звалилось на одну людину)
• Хто на чому працює саме сьогодні

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

Додатково — робочий процес задач: коли задача закривається з певним результатом, система автоматично створює наступну. Наприклад: задача «розробка» закрилась → автоматично з’являється задача «code review» з іншим виконавцем. Або задача «тестування» закрилась з результатом «потребує доробки» → знову задача «розробка» оригінальному виконавцю. Це базова автоматизація workflow без необхідності в окремому Jira чи Asana для малих команд.

Чесні обмеження:

• Gantt-діаграми з залежностями між задачами «А не почнеться поки не закінчиться Б» — немає. Залежності реалізуються через автоматичні переходи результатів (workflow), не через жорстку прив’язку дат
• Поля «оцінка трудоємності в годинах» на окремій задачі немає — тільки дати початку і кінця. Тривалість обчислюється з них. Якщо потрібна точна оцінка годин на кожну задачу — це обмеження поточної версії

Для команд до 30 людей з 5-15 паралельними проектами цього зазвичай достатньо. Якщо ваш стиль управління вимагає Gantt з критичним шляхом — поки ERPJS не цей вибір.

Як ERPJS інтегрує облік проектів з фінансами компанії?

Це може бути найважливіша відмінність від спеціалізованих PM-інструментів типу Jira або Asana. Облік проектів у ERPJS — не окремий модуль «збоку», а частина фінансового обліку компанії.

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

• P&L по компанії можна побудувати з розбивкою по проектах
• Cash Flow видно як в цілому, так і по проектах окремо
• Дебіторка по проектам — скільки клієнтів винні саме за цей проект
• Не потрібен паралельний облік: одна цифра не може жити в системі проектів і не існувати у фінансах

Це підхід «єдина правда» — на відміну від звичної комбінації Toggl + Excel + 1С, де кожна система знає тільки свою частину, а керівник зводить їх вручну.

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

З чого почати: 30-хвилинний план запуску першого проекту

Реалістичний план: за один робочий день у вас перший проект з табелями і бюджетом. Точніше, за 30 хвилин — мінімальний скелет, далі команда дозаповнить деталі.

Крок 1 (5 хв): створити проект. Картка — код, назва, клієнт, дати, тип. Заповнити обов’язкові поля, зберегти.

Крок 2 (5 хв): додати команду. Вибрати з довідника працівників, які працюють над проектом. Призначити одного-двох менеджерів.

Крок 3 (10 хв): запланувати бюджет. Створити документ бюджету проекту, додати 5-10 основних рядків робіт (наприклад, «розробка backend», «дизайн UI», «тестування», «менеджмент»). Вказати години і ставки. Система порахує суму, маржу, націнку.

Крок 4 (5 хв): налаштувати класи часу. Якщо ще не заведені — створити 3-5 базових класів («оплачуваний», «внутрішній», «переробка» — назви ваші).

Крок 5 (5 хв): запросити команду на ведення табелів. Показати інтерфейс табелю часу. Працівник списує години по днях з зазначенням проекту, типу роботи і класу часу.

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

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