Выделите текст, чтобы комментировать.
Управление проектами в российских госкомпаниях всегда было историей выбора.
Выбирали между удобством управления проектами и отчетом для проверяющих. Между гибкостью методологии и жесткостью форм. Между западными системами, которые умели управлять рисками и сроками, и отечественными, которые понимали КС-2.
Этот выбор не был случайным. Каждая сторона предлагала свой набор возможностей, но ни одна не закрывала все потребности полностью.
Западные системы строились вокруг PMBOK — свода знаний Project Management Institute. Они умели считать освоенный объем, строить сетевые графики и управлять рисками. Но они не умели формировать КС-2, КС-3 и М-29 — формы, которые требуют Росстат и заказчики по 44-ФЗ. Отчетность по ним должна совпадать с актами выполненных работ, а расхождение даже в копейках становится основанием для отказа в оплате.
Отечественные разработчики, наоборот, хорошо знали КС-2. Они встраивали в системы справочники ГЭСН, ФЕР и территориальные расценки. Но с PMBOK было туго. Управление рисками сводилось к полю «комментарий», а портфельное планирование отсутствовало в принципе.
В итоге госкомпании вели проекты в двух, а то и трех системах: западной — для планирования и управления сроками, отечественной — для учета и финансовой отчетности, а сводные отчеты собирали вручную в Excel.
В 2022 году западные вендоры ушли. Лицензии не продлить, поддержку не получить, новую систему не купить. Старая схема с двумя экземплярами данных стала нежизнеспособной.
Нужно было искать выход. И он нашелся в пересборке отечественных продуктов: вендоры начали не просто добавлять функции в свои системы, а менять архитектуру. Так появился подход, который сегодня называют «два контура на одной платформе». Он снимает основное противоречие: команда работает по гибкой методологии, проверяющие получают отчетность по ГОСТу, и это одни и те же данные.
ГОСТ Р 54869-2011 и PMBOK: в чем разница
В основе подхода «два контура» лежат два стандарта: российский ГОСТ Р 54869-2011 и международный PMBOK. Оба описывают управление проектами: этапы, процессы, документы. Разница — в деталях.
В PMBOK 49 процессов. В ГОСТе — 22 подпроцесса. Но это не значит, что российский стандарт беднее. Просто PMBOK более детальный: один процесс в ГОСТе может соответствовать двум-трем в PMBOK.
Например, в PMBOK есть процесс «разработка устава проекта». В ГОСТе — «формирование паспорта проекта». Названия разные, а суть одна: на старте утверждается документ, который дает проекту формальное право на существование и закрепляет полномочия руководителя.
Но есть и различия.
Первое — метод освоенного объема. В российских нормативных документах он не закреплен. В PMBOK он есть, называется Earned Value Management, и там четко описано, как считать плановую стоимость, освоенный объем и фактические затраты. В ГОСТе этого нет.
На практике это означает, что каждый разработчик PPM-системы реализует расчет по-своему. В одной системе показатели считают одним способом, в другой — другим. При интеграции данных это создает расхождения. При обучении — путаницу. При проверках — риски, потому что проверяющий не найдет в нормативах подтверждения, что вы все посчитали правильно.
Второе — документация. В PMBOK нет жестких форм. Есть рекомендации: ведите реестр рисков, фиксируйте изменения, собирайте отчеты. Как именно — решайте сами. В ГОСТе — наоборот. Есть конкретные формы: паспорт проекта, календарный план, бюджет, реестр рисков. Их надо заполнять по утвержденным шаблонам.
Но главное отличие — КС-2 и КС-3. Это формы, которые требуют Росстат и заказчики по 44-ФЗ. В них расшифровывают объемы и стоимость выполненных работ. В PMBOK таких форм нет, потому что PMI — международный институт и под российскую отчетность не заточен.
Третье — плановые показатели. В PMBOK используют три базовых плана: по срокам, по стоимости и управление рисками. В ГОСТ Р 54871-2011 (это стандарт по управлению программами) к ним добавляются показатели эффективности и результативности. Их утверждает вышестоящая организация. Для госкомпании это обязательно. Поэтому система должна уметь такие показатели заводить, считать и выводить в отчеты.
Получается, что методологическая основа одна, а формы, термины и регламенты — разные. Современные отечественные PPM-платформы как раз и созданы, чтобы работать с этими различиями, не заставляя пользователя переключаться между интерфейсами.
Но все эти различия не повод выбирать между стандартами, если система умеет работать с обеими сторонами. Современные отечественные PPM-платформы для этого и созданы: они закрывают и методологию PMBOK, и требования ГОСТа, не заставляя пользователя переключаться между интерфейсами.
Архитектура гибридного управления
Ключевая идея современных российских PPM-решений не в выборе между ГОСТом и PMBOK, а в том, чтобы вести проект в единой среде, где оба подхода существуют параллельно.
Управленческий контур
В этом контуре команда планирует работы, назначает ответственных, фиксирует фактические сроки, оценивает риски. И выбирает инструменты выбирает под свою методологию: сетевые графики, диаграммы Ганта, бэклоги или канбан-доски. Все это в терминах PMBOK и Agile. Задача одна: чтобы руководитель в любой момент видел реальное состояние проекта, а не бумажную отчетность.
Формальный контур
Здесь система автоматически переводит фактические данные в регламентированные отчеты. Календарный план превращается в КС-2. Исполненные сроки — в журнал контроля. Бюджетные отклонения — в отчет об освоении средств.
Проверяющий не видит канбан-досок и бэклогов. Он получает только те формы, которые утверждены приказом Росстата или внутренним регламентом госкомпании. Это ровно то, что нужно для отчетности, и ничего лишнего.
Оба контура работают с одними и теми же данными. Если проектировщик перенес срок начала работ на неделю, в формальном отчете это отражается автоматически. Не нужно заводить отдельный акт или переписывать календарь вручную.
Эту архитектуру часто сравнивают с переводчиком: пользователь говорит на языке PMBOK, а система выдает текст на языке ГОСТа. Обратный перевод тоже работает: проверяющие могут вносить корректировки в утвержденную форму, и система пересчитает их в управленческие данные.
Но все это требует жесткой настройки правил соответствия между справочниками. Например, статья бюджета в PMBOK «Оборудование» должна соответствовать статье КС-2 «Материальные затраты» с определенным коэффициентом пересчета. И таких соответствий могут быть сотни.
Отечественные PPM-решения с поддержкой двух контуров
В реестре отечественного ПО сейчас несколько PPM-решений, которые заявляют поддержку и ГОСТ, и PMBOK. Среди них — «Феликс» (разработка «Ростелекома», с 2026 года развивается под названием «Финист»), «1С:Управление проектами» и Digital Q.PM от «Диасофт».
«Феликс» построен на стандарте PMI PMBOK и включён в реестр отечественного ПО. Система позволяет вести единый реестр проектов, программ и портфелей, управлять графиками, ресурсами, рисками и статусной отчетностью. На 2024 год в ней велось более 1400 крупных проектов в разных подразделениях «Ростелекома».
«1С:Управление проектами» — это модуль для 1С:ERP (в расширенной версии — «1С:ERP+PM Управление проектной организацией»). Он закрывает полный цикл: от планирования содержания и сроков до бюджетирования, управления ресурсами и контрактации.
Digital Q.PM построен на стандартах PMBOK, Agile и ГОСТ. Платформа интегрируется с российскими системами бюджетирования и учета через модули «Бюджетирование проектов» и API. Это позволяет формировать регламентированную отчетность, включая КС-2 и КС-3, в единой среде без ручной выгрузки в Excel.
В целом подходы схожи: везде декларируется единая база для управленческих и формальных отчетов. Разница может быть в глубине интеграции с бухгалтерскими системами, в наличии API и в том, насколько гибко можно настраивать правила пересчета данных между контурами.
От инструмента к методологии
Для госсектора главное — способность системы работать одновременно с ГОСТом и PMBOK, при минимальной нагрузке на команду. И по этим критериям российские системы уже конкурентоспособны.
Но это только текущий срез. Рынок движется дальше.
Российские PPM-системы могут стать не просто заменой ушедших вендоров, а надстройкой над существующими методологиями.
Это значит, что они должны позволять быстро настраивать соответствие между любыми стандартами — не только ГОСТ и PMBOK, но и корпоративными регламентами. Госкомпании в этом случае получат не один инструмент, а платформу, которая адаптируется под любой набор требований.
И тогда вопрос «Какую систему выбрать?» заменится на «Какую методологию мы утверждаем, и какая система лучше ее поддержит?» Это более зрелый подход, чем нынешние поиски аналога Microsoft Project. И он уже появляется в запросах на рынке.
