Управление объектом в ERPNext: задачи, диаграмма Ганта, табели и процент выполнения

Управление проектами в ERPNext строится на двух документах: Project (объект) и Task (задачи с иерархией, зависимостями и весами). Гант, табели и процент выполнения вырастают из них. Ниже: как это настроить для монтажного объекта, где есть подводные камни и что проверить на своей версии.

Как устроен проект в ERPNext: Project, Task, зависимости и вехи

Проект в ERPNext это карточка объекта: название, заказчик, ожидаемые даты начала и окончания, статус, метод расчёта процента выполнения и блок затрат. К ней привязываются задачи (Task), табели (Timesheet), закупки и счета. Именно поэтому в нашей схеме внедрения ERPNext под ключ объект сделан отдельным Project: один объект, одна точка, где собираются заявки, закупки и часы. Для небольшой подрядной компании это заметно проще, чем держать график в Excel, а деньги в другой системе.

Задача (Task) имеет тему, проект, приоритет, статус (Open, Working, Pending Review, Overdue, Template, Completed, Cancelled), ожидаемые даты начала и окончания, вес (Task Weight) и процент прогресса. Задачи образуют дерево: у задачи есть родитель (Parent Task), причём родитель должен быть помечен как группа (Is Group). Зависимости задаются таблицей Depends On: задача зависит от других задач. Вехи в ERPNext отдельной сущностью не оформлены, это флажок Is Milestone на обычной задаче.

Сразу несколько правил, которые код в версии 15 проверяет при сохранении. Даты задачи не могут выходить за ожидаемые даты проекта: сохранение блокируется с ошибкой. Ожидаемая дата окончания дочерней задачи не может быть позже, чем у родителя. Задача не закроется (статус Completed), пока не закрыты или не отменены задачи, от которых она зависит. Если вы заводите проект без реалистичных дат, эти проверки начнут мешать в первый же день, так что даты проекта лучше ставить с запасом.

Для типовых работ есть Project Template: шаблон из списка задач, который при создании проекта разворачивается в готовое дерево. У шаблонной задачи есть начало (смещение в днях) и длительность, а зависимости переносятся в новый проект. Для монтажа котельной это удобно: «Подготовка», «Монтаж», «Пусконаладка» создаются одним действием, а не вручную.

• Project: объект, даты, заказчик, метод процента выполнения
• Task: статус, вес, прогресс, родитель, Is Milestone
• Depends On: зависимости между задачами
• Project Template: шаблон дерева задач для типовых объектов
• Timesheet: часы по задаче и типу работ

Диаграмма Ганта в ERPNext: что умеет и что проверить на своей версии

У списка задач есть несколько представлений: список, Kanban, календарь и диаграмма Ганта. Гант это функция платформы Frappe: он рисует задачи отрезками по ожидаемым датам, а связи показывает стрелками. Двигать отрезок мышью можно, и это меняет даты задачи. Для небольшого объекта этого хватает, чтобы руководитель увидел, что «Монтаж» упирается в «Подготовку».

Честная оговорка. В материалах сообщества описаны сбои более старых версий: в v10 удаление связи не убирало стрелку, в v12 перетаскивание могло сдвинуть даты на месяц назад. Исправлено ли это в v15 и v16, я по документации подтвердить не смог, поэтому не утверждаю. Перед запуском объекта прогоняю Гант на стенде той версии, которую ставлю. Список проверок ниже, и его же можно взять как чек-лист приёмки.

Одно поведение подтверждено по коду v15 и полезно знать заранее. Когда вы сдвигаете дату окончания задачи, система автоматически переносит зависимые задачи, но только те, что в статусе Open и у которых начало раньше нового конца предшественника. Сдвинутая задача сохраняет свою длительность. Задачи в статусе Working или Pending Review так не переносятся: график «поедет» не целиком, а частично, и на диаграмме это выглядит как разрыв. Поэтому статусы стоит вести аккуратно, а не «на потом».

Чек-лист приёмки Ганта на стенде (критерий готовности в конце каждого пункта): 1. Перетащите задачу на другую дату. Критерий: даты изменились на ожидаемые, а не уехали на месяц назад. 2. Удалите связь между задачами. Критерий: стрелка на диаграмме исчезла. 3. Измените длительность предшественника. Критерий: открытые зависимые задачи пересчитались. 4. Создайте проект из Project Template. Критерий: все вложенные задачи появились с зависимостями. 5. Откройте Гант с телефона. Критерий: можно прочитать график без горизонтального хаоса.

Как считается процент выполнения: четыре Completion Method

В карточке проекта поле % Complete Method (имя поля в коде: percent_complete_method) принимает четыре значения. Manual: процент вводит руководитель. Task Completion: доля задач, закрытых или отменённых, от общего числа. Task Progress: среднее значение прогресса всех задач. Task Weight: взвешенное среднее прогресса с весами задач. Метод определяет, что увидит директор в списке проектов, поэтому выбирать его надо осознанно, а не оставлять по умолчанию.

Разница заметна на простом примере: три задачи с весами 50, 30 и 20 и прогрессом 100 %, 50 % и 0 %; закрыта одна задача. Метод Task Completion даст 33,33 %, потому что закрыта одна из трёх. Task Progress даст 50 %: (100 + 50 + 0) / 3. Task Weight даст 65 %: 100 × 0,5 + 50 × 0,3 + 0 × 0,2. По коду v15 вес делится на сумму весов, так что веса не обязаны давать ровно 100. Все числа здесь условные, но порядок разницы реальный: один объект может быть «на 33 %» или «на 65 %» в зависимости от метода. | Метод | Как считается | Для примера | |---|---|---| | Manual | Вводит руководитель | Любое значение 0–100 | | Task Completion | Закрытые и отменённые задачи / все задачи | 33,33 % | | Task Progress | Среднее значение прогресса задач | 50 % | | Task Weight | Взвешенное среднее, вес делится на сумму весов | 65 % |

Мой выбор для монтажного объекта: Task Weight, а веса задаю по трудоёмкости (часам или стоимости работ). Task Completion обманывает, когда задачи разного масштаба: закрыли пять мелких, а крупная «Монтаж трубопроводов» только началась, и проект выглядит почти готовым. У Task Weight своя ловушка: если у задач не проставлены веса, расчёт даёт ноль, ведь без весов делить не на что. После перехода на этот метод заполните вес у всех задач проекта.

Статус проекта тоже зависит от метода: при 100 % он переходит в Completed, а иначе остаётся Open, если вы не поставили вручную On hold или Cancelled. Для проекта вообще без задач есть исключение: если поставить ему статус Completed, код сам переключит метод на Manual и выставит 100 %.

Табели Timesheet: кто вносит часы и откуда берутся даты факта

Timesheet это документ с табличной частью: строки по дням и задачам, в строке указаны тип работ (Activity Type), проект, задача, часы, ставка себестоимости и ставка для выставления счёта. Сотрудник заполняет его сам, там есть таймер для записи времени. Как из табеля получается счёт для сервисной компании, мы разбираем в отдельной статье про биллинг по времени; здесь важнее другое: что табель даёт объекту.

По коду v15 проект при обновлении затрат пересчитывает по проведённым табелям (docstatus 1) суммарные часы, затраты и сумму для выставления, а также фактические даты: Actual Start Date это самое раннее начало строки табеля, Actual End Date это самый поздний конец строки. Отсюда практический вывод: пока табели не проведены, факт в проекте пустой. Если бригада не заполняет часы, график показывает только план, и сравнить «плановое с фактическим» нельзя.

Кто вносит часы, решается организационно. На монтажных объектах я не заставляю монтажников заполнять веб-форму ежедневно: бригадир раз в день вносит часы по бригаде одним табелем, а руководитель по пятницам проводит их. Часы идут в затраты объекта, а проводка табеля делает данные видимыми проекту. Для отслеживания загрузки в системе есть отчёты вроде Daily Timesheet Summary и Timesheet Billing Summary; их набор и названия сверьте на своей версии.

Здесь же важное ограничение. Затраты проекта по закупкам считаются отдельно (по счетам поставщика), и до проведения счёта на карточке проекта их не видно. Поэтому «план, факт часов и факт по закупкам» складываются в одну картину не мгновенно, а по мере проведения документов.

Как руководителю следить за объектом: Connections, Project Update, Collect Progress

Карточка проекта показывает блок Connections: связанные документы (задачи, табели, заявки, заказы, счета) с количеством и быстрым переходом. Руководителю достаточно открыть проект и увидеть, сколько заказов оформлено и сколько табелей проведено, без отчётов. Это самая простая форма контроля, и её хватает для объекта на 11 человек.

Для регулярного статуса есть два механизма. Project Update фиксирует состояние проекта на дату и позволяет разослать отчёт участникам. Collect Progress включается флажком в проекте и по расписанию (раз в час, дважды в день, раз в день или раз в неделю, в заданное время, с учётом списка выходных Holiday List) рассылает участникам письма с вопросом о прогрессе; ответы сводятся в статус. Список полей есть в карточке проекта: частота, время рассылки, текст сообщения. Рассылка идёт по электронной почте, поэтому исходящая почта в ERPNext должна быть настроена, иначе механизм не заработает.

Я включаю Collect Progress не всегда. На небольшом объекте письмо с вопросом раздражает прораба, если он и так отвечает по телефону. Рабочий вариант: письмо раз в неделю в пятницу, текст из двух вопросов («что закончено», «что мешает»). Для директора важнее не частота писем, а то, чтобы они складывались в Project Update и на проекте была видна история.

Если на объекте нужны также ограничения по деньгам и по количеству материалов, сам проект это не решает. Лимиты суммы задаёт документ Budget, о котором у нас отдельный разбор, а объёмы по спецификации договора контролируются доработкой. Общую картину того, где ERPNext подходит для производства и работ, даёт обзор открытой ERP для производства.

Разбор: «ТеплоПуть» ведёт монтаж котельной в одном проекте

Условный пример, цифры вымышленные. Компания по монтажу котельных «ТеплоПуть», 11 рабочих мест: директор, главный инженер, два прораба, снабженец, бухгалтер и бригады монтажников. Типичный заказ: котельная на 1,5 МВт в здании заказчика, срок 14 недель. Раньше график вели в таблице у главного инженера, часы бригады писали в бумажный журнал, закупки отслеживали в мессенджере. Через месяц никто не мог сказать, сколько часов реально ушло на обвязку.

Мы завели Project Template «Котельная до 2 МВт» с тремя группами задач: «Подготовка» (обследование, проект, согласования, заказ оборудования), «Монтаж» (котлы, насосная группа, трубопроводы, электрика, автоматика) и «Пуск» (гидроиспытания, режимная наладка, сдача). Всего 22 задачи, у 14 из них заданы зависимости, три помечены как вехи. Веса поставили по трудоёмкости: монтаж трубопроводов 25, электрика и автоматика 15, остальные от 2 до 10. Метод выполнения выбрали Task Weight.

Бригадир раз в день вносит часы одним табелем по бригаде с типами работ «монтаж», «сварка», «наладка». Главный инженер по пятницам проводит табели и сдвигает даты задач, если в этом есть необходимость. В первую же неделю система остановила сохранение задачи «Пуск» из-за даты позже ожидаемой даты проекта: срок проекта оказался на неделю короче реального. Теперь ожидаемые даты проекта ставят с запасом при создании. Вторая находка: у восьми задач не были проставлены веса, и процент выполнения стоял на нуле; после заполнения показатель ожил.

Итог за три месяца условного пилота: на карточке проекта видно, что «Монтаж» закрыт на 70 %, часы по факту выросли на 12 % относительно плана, и этот сигнал пришёл на пятой неделе, а не в конце. Главная польза для директора в том, что обсуждение сроков теперь идёт по данным проекта, а не по ощущениям. Это иллюстрация метода, а не обещание результата для вашей компании. Ход настройки от шаблона до проведённого табеля покажем на демостенде erp-demo.itfresh.ru по запросу.

Где управление проектами в ERPNext не подойдёт

ERPNext не заменяет специализированные системы планирования для крупных проектов. Нет сетевого графика с критическим путём и выравниванием ресурсов на уровне Microsoft Project или Primavera; Гант рисует отрезки и связи, но не считает критический путь. Нет и сметно-расчётного модуля с расценками в российском формате: КС-2 и КС-3 печатаются по доработанным формам. Если вам нужно именно планирование ИТ-задач в команде, посмотрите разбор про OpenProject и Redmine вместо Jira.

Второе ограничение: дисциплина. Модуль работает на данных, и если табели не вносят, процент не обновляют, а даты не двигают, проект превращается в красивую, но устаревшую картинку. Третье: версии. Поведение Ганта и точные имена полей в v15 и v16 различаются, и вы обязаны проверить их на своём стенде. Четвёртое: затраты по закупкам попадают в проект после проведения счёта, а не на заявке, так что ранний контроль денег нужно строить отдельно.

Частые вопросы