Руководитель 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 мин): пригласить команду на ведение табелей. Показать интерфейс табеля времени. Сотрудник списывает часы по дням с указанием проекта, типа работы и класса времени.

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

Часто задаваемые вопросы