Порядок выбора системы управления проектами: обязательные условия, взвешенные критерии, демонстрация по своему сценарию, пилот и стоимость владения за три года.
Обновлено 28.09.2026
Две системы могут одинаково отмечать галочками «диаграмму Ганта», «отчеты» и «согласование» и при этом по-разному решать вашу задачу. Ниже - порядок выбора, который отсекает неподходящие варианты до демонстраций, превращает впечатления в сравнимые баллы и заканчивается пилотом на реальном проекте. В конце - расчет стоимости владения, типовые ошибки и ответы на частые вопросы.
Выбор начинается не со списка функций, а с описания текущего процесса: кто создает проект, утверждает план, сообщает о выполнении, согласует документ и принимает результат. Для каждой проблемы запишите наблюдаемый эффект в часах, днях или рублях. Формулировку «нет прозрачности» проверить нельзя, а «сводка по портфелю собирается два дня» проверяется на пилоте.
Числа нужны, чтобы потом сравнить с результатом. Допустим, каждый из 12 руководителей проектов тратит на еженедельный отчет 4 часа. За год это 12 × 4 × 46 рабочих недель = 2 208 часов - больше годового фонда рабочего времени одного сотрудника. Если система сокращает подготовку отчета до получаса, эффект виден даже без учета качества решений.
Обязательное условие - то, без чего система не подходит при любых других достоинствах. Их проверяют первыми, до сравнения удобства, по принципу «да или нет». Вариант, который не прошел хотя бы одно условие, дальше не рассматривают.
Запись в реестре российского ПО подтверждает, что продукт внесен в реестр в определенном классе. Она не подтверждает автоматически соответствие требованиям информационной безопасности или вашему техническому заданию. Если заказчик закупает по 44-ФЗ, применимость ограничений ПП РФ № 1236 к конкретной закупке определяют профильные специалисты заранее.
Веса фиксируют до первой встречи с поставщиками. Иначе яркая демонстрация незаметно поднимет вес той функции, которую показали лучше всего. Ниже - пример для проектной организации, где проекты ведут вместе с документацией по стадиям. Ваши веса будут другими, важно зафиксировать их письменно.
Каждый критерий оценивайте по шкале с явными определениями: **0** - нет; **1** - обещано или планируется; **2** - есть, но требует настройки или доработки с известной ценой; **3** - есть и проверено на ваших данных. Балл 3 ставят только после проверки, а не по слайду презентации.
Пример. Система А набрала 2,6 из 3 по взвешенной сумме, система Б - 2,3. Но у А вход через каталог сотрудников оценен в 1 балл («будет в следующей версии»), а для вашей компании это обязательное условие. Такой вариант должен был отсеяться еще на шаге 2. Арифметика не должна скрывать критический недостаток.
Отправьте поставщикам сценарий и обезличенные данные за неделю до встречи. Просите показать действие до конца, а не рассказать о нем. Каждый пункт помечайте: «показано на наших данных», «показано на демонстрационных», «обещано».
Демонстрация показывает, что система умеет. Пилот отвечает на другой вопрос: приживется ли она у вас. Для пилота берут один идущий проект с настоящими сроками, бюджетом и людьми - представительный, а не самый простой. На «Проекте 1» с «Задачей 1» не проверяется ничего. Разумный срок - шесть недель, этого хватает на один полный цикл работы.
Участников нужно три-четыре: руководитель проекта, двое исполнителей и тот, кто согласует документы. Если в пилот сразу заводят несколько подразделений, он растягивается и перестает что-либо проверять.
Каждое замечание пилота относите к одной из групп: **настройка** (делает администратор), **доработка** (нужны срок и цена от поставщика), **ограничение продукта** (придется менять процесс или отказаться), **обучение** (пользователь не знал, как сделать). Неудачный импорт одного файла может оказаться исправимой несовместимостью, его нужно разобрать. Но критичный сценарий нельзя считать пройденным на основании обещания.
Сравнивайте одинаковый период и одинаковое число пользователей с учетом роста. Цена лицензии редко оказывается самой большой строкой.
Пример. Система А дешевле системы Б на 400 000 руб. за три года по лицензиям, но не строит сводку автоматически, а Б строит. Каждый из 10 руководителей проектов тратит на отчет 3 часа в неделю: за три года это 10 × 3 × 46 × 3 = 4 140 часов. При стоимости часа 1 500 руб. - 6 210 000 руб. Экономия на лицензии исчезает уже в первом квартале.
volrix.pm - система управления проектами и документооборот, которая ставится на сервер организации и работает без доступа в интернет: лицензия проверяется встроенным ключом, без обращения к серверу поставщика. Установка - одна команда из личного кабинета. Поддерживаются Ubuntu 22.04 и 24.04, Debian 11 и 12, Astra Linux Special Edition 1.7 и 1.8, РЕД ОС 7.3 и 8 - требования к серверу в статье Подготовка сервера.
Продукт внесен в реестр российского ПО: запись № 35213 от 15.09.2026, классы 05.05 «Средства управления проектами» и 06.12 «Программное обеспечение средств внутреннего электронного документооборота». Программа зарегистрирована в Роспатенте: свидетельство № 2026688175 от 15.09.2026.
По сценариям шага 4. План импортируется из MS Project XML, файл .mpp - если на сервере установлен компонент его чтения. Переносятся задачи, иерархия, вехи, связи с лагами и ответственные; календари, стоимость и базовые планы из файла не переносятся (План проекта). Сотрудники входят через LDAP / AD, Kerberos или OIDC, в поставке 14 системных ролей. Выгрузить можно план - в MS Project XML, табличные отчеты - в CSV, всю базу - резервной копией PostgreSQL.
Посмотреть систему изнутри можно на бесплатной лицензии: до 5 пользователей, без ограничения срока. Для решения о переходе есть пилот на вашем проекте за шесть недель - по той же схеме, что описана выше.
Один реальный проект в вашем контуре и решение по итогам
Требования к серверу, поддерживаемые ОС и закрытый контур
Что делать после выбора: роли, миграция, риски
