Критерии выбора системы управления проектами: с чего начать, какие вопросы задать до демонстрации, что проверять на живом стенде и что смотреть в лицензии.
Обновлено 10.09.2026
Выбор системы управления проектами обычно начинают со сравнения таблиц с галочками. Это самый быстрый способ ошибиться: галочки есть у всех, а работать в системе будут ваши люди с вашими процессами. Ниже - порядок, который снимает большую часть риска.
Опишите на одной странице, как у вас сейчас проходит работа: кто заводит проект, кто утверждает план, откуда берутся сроки, кто отвечает за бюджет, как согласуются документы. Без этой страницы любая демонстрация превращается в показ красивых экранов.
Дальше отметьте в описании три-четыре места, где сейчас теряется время. Именно их и надо проверять у поставщика, а не весь список возможностей.
Облако поставщика или ваш сервер. Для части организаций это не предпочтение, а требование службы безопасности, и оно отсекает половину рынка сразу.
Если согласования и переписка идут отдельно от проектов, вам понадобятся две системы и интеграция между ними. Это не всегда плохо, но это надо решить до выбора, а не после.
План со связями и базовыми планами требует человека, который умеет их вести. Если такого нет, сложный планировщик не приживётся, и хватит досок с задачами.
От этого зависит и лицензия, и то, насколько простым должен быть интерфейс. Пятьдесят проектных специалистов и пятьсот сотрудников - это разные продукты.
Если себестоимость проекта считается по фактическим часам, табель должен быть внутри системы. Сведение табеля в отдельной таблице съедает выигрыш от автоматизации.
Для госзаказчиков и компаний с госучастием наличие продукта в реестре российского ПО часто обязательное условие, а не преимущество.
Спросите, как выглядит обновление, что происходит при окончании лицензии и можно ли забрать свои данные. Ответ на последний вопрос должен быть конкретным форматом выгрузки, а не словом «конечно».
Побеждает продукт с самым длинным перечнем, а внедряется тот, в котором люди разобрались за неделю. Сравнивайте не количество, а то, закрывает ли система те три-четыре потери времени, которые вы отметили.
Тестовый проект «Проект 1» с задачами «Задача 1» не проверяет ничего. Берите настоящий проект с настоящими сроками и людьми - иначе неудобства всплывут после покупки.
Если систему выбирает только руководство, сопротивление на внедрении гарантировано. Достаточно двух-трёх человек из тех, кто будет работать каждый день.
Просите не обзор, а сценарий. Хорошая проверка выглядит так: заведите проект, добавьте команду, постройте план на двадцать задач со связями, сдвиньте одну задачу и посмотрите, что произошло с остальными. Затем закройте задачу от лица исполнителя и найдите это изменение в отчёте.
Загрузите свой файл плана. Если импорт разваливается на вашем реальном файле, дальше можно не смотреть.
Попросите показать, что видит рядовой участник, а что руководитель. Разграничение проверяется входом под другой учётной записью, а не рассказом о матрице прав.
Если система ставится в закрытый контур, попросите показать её на стенде без внешнего доступа. Отдельные функции обычно отваливаются первыми - лучше узнать это сейчас.
Модель лицензирования: по пользователям или по проектам, годовая подписка или бессрочная лицензия. Что происходит по окончании срока - система переходит в режим чтения или останавливается совсем. Кто выпускает обновления и как они доезжают в закрытый контур, если у вас нет интернета на сервере.
Отдельно спросите про стоимость внедрения и обучения. У корпоративных систем она сопоставима со стоимостью лицензий в первый год, и её редко показывают в первом коммерческом предложении.
Процесс на одной странице, три-четыре точки потери времени, ответы на семь вопросов выше.
Свой файл плана, свой реальный проект, вход под двумя разными ролями, проверка в закрытом контуре.
Модель лицензии, формат выгрузки данных, стоимость внедрения и обучения, порядок обновлений.
Если ваш случай - система на своём сервере, где проекты и документооборот живут в одном контуре, посмотрите, как это устроено у нас: раздел «Управление проектами» и страница про СЭД описывают состав без маркетинговых обещаний.
От месяца до трёх, если делать по порядку. Основное время уходит не на демонстрации, а на описание собственного процесса.
Три-четыре. При двух не с чем сравнивать, при семи сравнение превращается в таблицу, которую никто не дочитывает.
Как способ понять свои потребности - да. Как основа корпоративного процесса - обычно нет: упирается в права доступа и отчётность.
Удобство. Недостающую функцию можно добавить или обойти, неудобной системой просто перестают пользоваться.
Признаки, что пора, и что переносится при замене
Что требуют от российского ПО и как это проверить
Проверка на реальном проекте за шесть недель
Подписка по числу пользователей и бесплатные пять мест
Как система работает без выхода в интернет
730 методов, чтобы связать систему с тем, что уже есть