К статье
Практический материал

Автоматизация · 12 мин

1С: руководитель проекта — что такое проект и как с ним работать

Разбираем, что такое проект в методологии 1С: руководитель проекта: определение, атрибуты, жизненный цикл, настройка и типичные ошибки при внедрении.

Решение «1С:Управление проектной организацией» и методология «1С:Руководитель проекта» (1С:РП) построены вокруг базового объекта — проекта. Понимание того, что именно считается проектом, определяет, как будут планироваться сроки, распределяться ресурсы, считаться трудозатраты и контролироваться бюджет. Ошибка на уровне определения приводит к тому, что в системе появляются «проекты», которые на деле являются текущими задачами, договорами или подразделениями, и вся аналитика рассыпается.

В терминах 1С:РП проект — это временная деятельность с конкретной целью, ограниченная сроками, бюджетом и ресурсами, результатом которой является уникальный продукт: внедрённая конфигурация, разработанный модуль, запущенный участок учёта. Именно уникальность результата и конечность по времени отличают проект от операционной деятельности — регулярной поддержки, сопровождения, рутинных доработок.

Практическая ценность правильного определения в том, что система начинает работать как инструмент управления, а не как электронная картотека. Диаграмма Ганта, загрузка ресурсов, план-факт по бюджету и отчёты по трудозатратам осмысленны только тогда, когда объект «Проект» заполнен корректно и отражает реальную единицу управления.

Что считается проектом: определение и ключевые признаки

Формально проект обладает пятью обязательными признаками. Первый — конкретная цель, выраженная измеримым результатом: «внедрить 1С:ERP на трёх площадках», а не «улучшить учёт». Второй — ограниченность во времени: у проекта есть дата старта и плановая дата завершения. Третий — уникальность результата: даже типовое внедрение уникально, потому что выполняется для конкретной организации с её данными и процессами.

Четвёртый признак — ограниченность ресурсов: на проект выделены конкретные люди, часы и деньги, и их перерасход требует управленческого решения. Пятый — наличие заинтересованных сторон: заказчика, спонсора, команды. Если у активности нет хотя бы одного из этих признаков, это не проект, а процесс или задача, и заводить её в системе как проект — ошибка.

Проверка простая: задайте себе вопрос «когда эта работа закончится и что мы получим на выходе?». Если ответ конкретен — «30 сентября получим работающий обмен с сайтом» — это проект. Если ответ «это постоянная работа» — это процесс, и его место в учёте трудозатрат по направлениям, а не в проектной структуре.

Чем проект отличается от задачи, процесса и договора

Самая частая путаница при внедрении 1С:РП — смешение уровней. Проект состоит из задач, но задача сама по себе проектом не является. Задача «написать модуль загрузки прайсов» — элемент проекта «Автоматизация закупок». Договор с клиентом — юридическое основание, но и он не тождествен проекту: один договор может порождать несколько проектов, а один внутренний проект может вообще не иметь договора.

Процесс — повторяющаяся деятельность без конечной точки: техподдержка пользователей, регламентное сопровождение, ежемесячное закрытие периода. У процесса нет даты завершения и уникального результата, поэтому попытка вести его как проект ломает отчётность: диаграмма Ганта бесконечно растягивается, а план-факт теряет смысл.

Сравнение вариантов

Проект

Есть цель, срок, бюджет и уникальный результат. Подходит для внедрений, разработок, миграций данных. Требует планирования и контроля.

Задача

Атомарная работа внутри проекта или процесса. Не имеет собственного бюджета и команды. Заводится отдельным проектом только если сама по себе даёт уникальный результат.

Процесс

Постоянная деятельность без даты завершения: поддержка, сопровождение. Учитывается через трудозатраты по направлениям, а не через проектную структуру.

Договор

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

Как проект устроен внутри системы: атрибуты и связи

Карточка проекта в 1С:РП — это не просто название. Минимальный набор атрибутов, без которых проект нельзя считать корректно заведённым: наименование, руководитель проекта, заказчик (внутренний или внешний), плановые даты начала и окончания, статус. Дополнительно заполняются приоритет, тип проекта, бюджет и описание результата.

К проекту привязывается иерархия задач — декомпозиция работ до уровня, которым можно управлять. К задачам, в свою очередь, привязываются исполнители, плановые трудозатраты, фактические списания времени, документы и переписка. Именно через эти связи система считает загрузку ресурсов, отклонения по срокам и себестоимость.

Важно понимать роль статусной модели. Проект проходит стадии от инициации до закрытия, и на каждой стадии допустимы свои действия: пока проект в статусе «Планирование», списания трудозатрат на него либо запрещены, либо должны трактоваться как предпроектные. Настройте статусную модель до старта работ, иначе фактические данные попадут в неверные периоды.

РуководительНазначен конкретный сотрудник

Проверьте, что поле заполнено реальным ответственным, а не служебной учётной записью

СрокиЗаполнены плановые даты начала и окончания

Пустые даты делают бессмысленной диаграмму Ганта и контроль отклонений

ЗаказчикУказан внутренний или внешний заказчик

Без заказчика невозможно согласование результата и приёмка

БюджетЗадан лимит по деньгам или часам

Без лимита план-фактный анализ не имеет базы для сравнения

Как определить границы проекта до его создания

Прежде чем создавать объект в системе, сформулируйте границы: что входит в проект, а что — нет. Классическая ошибка — включить в проект внедрения последующее сопровождение. Внедрение заканчивается промышленной эксплуатацией, а сопровождение — это отдельный процесс со своим учётом. Смешение приводит к тому, что проект «не закрывается» годами.

Практический приём — зафиксировать результат проекта в формулировке, которую можно проверить. «Система запущена в промышленную эксплуатацию, пользователи обучены, акт приёмки подписан» — проверяемо. «Улучшить работу отдела» — непроверяемо, значит, это не проектная цель, и её нужно декомпозировать или переформулировать.

Порядок действий
  1. 1
    Сформулируйте результат проекта в проверяемой форме: что будет сдано и как это подтверждается
  2. 2
    Определите плановые даты начала и завершения, зафиксируйте ключевые вехи
  3. 3
    Назначьте руководителя проекта и укажите заказчика
  4. 4
    Оцените бюджет в деньгах и трудозатратах, зафиксируйте лимит
  5. 5
    Создайте карточку проекта и постройте иерархию задач до управляемого уровня
  6. 6
    Назначьте исполнителей и плановые трудозатраты на задачи
  7. 7
    Переведите проект в рабочий статус и начните фиксировать факт

Жизненный цикл проекта и контроль на каждой стадии

Проект в 1С:РП проходит стадии: инициация, планирование, исполнение, контроль, завершение. На стадии инициации определяются цель, заказчик и предварительные границы. На стадии планирования строится иерархия задач, назначаются ресурсы, формируется базовый план — базовая линия, с которой потом сравнивается факт.

На стадии исполнения и контроля ключевые инструменты — план-факт по срокам и трудозатратам, загрузка ресурсов и контроль вех. Отклонение по критической вехе — сигнал пересмотреть план, а не просто зафиксировать факт опоздания. На стадии завершения проект закрывается формально: результат принят, открытые задачи либо завершены, либо перенесены, ресурсы освобождены.

Контрольные точки

Как проверить результат

Диаграмма Ганта
Норма

Все задачи имеют даты, связи и исполнителей, критический путь читается

Тревожный признак

Задачи без дат и связей, план состоит из несвязанных строк

План-факт трудозатрат
Норма

Факт списывается на конкретные задачи, отклонения объяснимы

Тревожный признак

Время списывается «на проект» целиком, детализации нет

Загрузка ресурсов
Норма

Видно перегрузки и простои сотрудников по неделям

Тревожный признак

Один сотрудник назначен на параллельные задачи с полной загрузкой

Закрытие проекта
Норма

Все задачи завершены, результат принят заказчиком

Тревожный признак

Проект «висит» в работе с просроченными задачами месяцами

Типичные ошибки и ограничения подхода

Ошибка номер один — заведение в систему «вечных» проектов: «Поддержка», «Текущие доработки», «Прочее». Такие объекты накапливают трудозатраты, но не дают управленческой информации: у них нет срока, бюджета и результата, поэтому план-факт по ним бессмыслен. Для постоянной деятельности используйте учёт по направлениям или отдельный механизм операционных затрат.

Вторая ошибка — слишком крупная или слишком мелкая декомпозиция. Проект из трёх задач по две тысячи часов неуправляем: отклонения видны слишком поздно. Проект из пятисот задач по полчаса неуправляем по другой причине: администрирование съедает больше времени, чем сама работа. Ориентир — задача длительностью от нескольких часов до нескольких дней.

Третья ошибка — отсутствие базового плана. Если план постоянно редактируется «под факт», отклонения исчезают, и руководство теряет возможность видеть реальную картину. Фиксируйте базовую линию после согласования плана и меняйте её только через осознанное решение о перепланировании.

Типичные ошибки
01
Создание «вечных» проектов для текущей поддержки — план-факт и сроки теряют смысл, аналитика искажается
02
Смешение внедрения и сопровождения в одном проекте — проект невозможно закрыть, бюджет размывается
03
Отсутствие базового плана — отклонения не видны, управленческие решения запаздывают
04
Списание времени на проект целиком без задач — невозможно понять, куда ушли трудозатраты
05
Назначение руководителем проекта служебной учётной записи — теряется персональная ответственность

Когда проектный подход избыточен и какие есть альтернативы

Не всякую работу стоит оформлять как проект. Разовая доработка на несколько часов, консультация, мелкая настройка — это задачи или заявки, и вести их через полноценную проектную структуру дороже, чем сама работа. Критерий простой: если работа требует координации нескольких исполнителей, заметного бюджета и контроля сроков — это проект; если нет — задача.

Маршрут решения

Как выбрать действие

Работа имеет уникальный результат, срок, бюджет и команду из нескольких человекЗаводите проект с иерархией задач и базовым планом
Работа повторяется регулярно и не имеет даты завершенияВедите как процесс: учёт трудозатрат по направлению, без проектной структуры
Разовая работа на несколько часов с одним исполнителемОформите задачей или заявкой, не создавая проект
Один договор включает несколько независимых результатовСоздайте отдельный проект под каждый результат и свяжите их с договором

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

Перед массовым заведением проектов проведите пилот: оформите один реальный проект полностью — от карточки до закрытия — и проверьте, какие отчёты получились. Если план-факт и загрузка ресурсов читаются и помогают принимать решения, модель настроена верно и её можно тиражировать.
ПЗ
Практическое замечание

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

Можно ли вести внутренний проект без договора и внешнего заказчика?

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

Что делать, если в ходе проекта появились работы за его границами?

Зафиксируйте их как изменение объёма: либо включите в проект через решение о перепланировании с корректировкой бюджета и сроков, либо оформите отдельным проектом. Позволять работам «прирастать» молча нельзя — это размывает базовый план.

Какой уровень декомпозиции задач считается оптимальным?

Ориентир — задача, которую один исполнитель завершает за период от нескольких часов до нескольких дней. Более крупные задачи плохо контролируются, более мелкие создают избыточную нагрузку на администрирование.

Нужно ли закрывать проект формально, если результат фактически достигнут?

Да. Формальное закрытие освобождает ресурсы в отчётах по загрузке, фиксирует итоговый план-факт и убирает проект из оперативного портфеля. Проекты, «зависшие» без закрытия, искажают всю сводную аналитику.

Чем проект отличается от этапа проекта?

Этап — часть иерархии внутри одного проекта, объединяющая связанные задачи. Этап не имеет собственного бюджета и заказчика. Если у части работ появляются собственный бюджет, сроки и приёмка — это повод выделить её в отдельный проект.

Можно ли восстановить базовый план, если его не зафиксировали в начале?

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

Итог

Что важно запомнить

Проект в 1С:РП — это временная работа с уникальным проверяемым результатом, сроком, бюджетом и ответственным руководителем. Заводите как проект только то, что соответствует этим признакам, фиксируйте базовый план, ведите факт по задачам и закрывайте проекты формально — тогда план-факт, загрузка ресурсов и отчётность будут отражать реальность.