Блог · Выбор системы

Как выбрать российскую СУП для проектной организации: критерии и чеклист

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

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

Почему выбор СУП чаще проваливается, чем сам софт

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

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

Шаг 1. Что именно у вас болит? Определяем класс системы

Сформулируйте боль одним предложением до первого демо. Вариантов немного: сроки («не видим, успеваем ли»), люди («не знаем, кто перегружен, а кто простаивает»), деньги («не понимаем, зарабатываем ли на контракте») и отчётность («каждый отчёт собираем руками неделю»). Если загрузку вы пока сводите в таблицах, полезен разбор, где кончается планирование загрузки в Excel. Боль определяет класс системы:

  • Отраслевые системы для проектных организаций. Готовая модель ПИР: стадии и разделы, загрузка специалистов, нормо-часы, экономика контрактов.
  • Календарно-сетевое планирование (КСП). Графики из тысяч связанных работ: стройка, капитальные проекты, освоенный объём.
  • Портфельные и корпоративные (PPM). Реестр проектов, паспорта, контрольные точки, отчётность для руководства и проектного офиса.
  • Экосистемные платформы. Проекты как модуль внутри 1С или CRM-платформы; сила — в общем ландшафте, отраслевую модель строит внедренец.
  • Таск-трекеры и учёт времени. Задачи, канбан, таймшиты. Быстро и недорого, но без ресурсной математики и экономики контрактов.

Если запрос звучит как «чем заменить привычный планировщик», удобнее идти от бренда. Обзоры аналогов MS Project и аналогов Primavera раскладывают кандидатов по тем же классам.

Когда реестр отечественного ПО обязателен, а когда — нет?

Реестр отечественного ПО — это государственный перечень программ российских правообладателей, который ведёт Минцифры. Для госзаказчиков и компаний с госучастием запись в реестре — как правило, условие закупки: действует национальный режим по постановлению Правительства № 1875. Происхождение ПО может подтверждать российский или евразийский реестр, а применимость запрета и исключений зависит от конкретной закупки — проверяйте её документацию. Частная организация формально свободна в выборе.

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

Шаг 2. Критерии для проектной организации: структура работ, ресурсы, экономика

Общую рамку требований задаёт ГОСТ Р 54869-2011: управление проектом — это планирование, организация исполнения, контроль и завершение, а не только красивый график. Терминологическую базу проектного менеджмента даёт ГОСТ Р 56715.5-2015. Дальше начинается специфика, и у проектной организации она конкретна.

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

Критерий Вопрос на демо Красный флаг
Структура работ «Покажите проект со стадиями П и Р и разделами» Плоский список задач без иерархии
Ресурсное планирование «Кто из главных специалистов свободен в следующем месяце?» Загрузка видна только внутри одного проекта
Учёт факта часов «Как исполнитель списывает часы и сколько минут это занимает?» Отдельный файл или «доработаем позже»
Экономика контракта «Где видна себестоимость и маржа по договору?» Только план, факт — выгрузкой в Excel
Интеграция с 1С «Как попадают в систему ставки и зарплаты из 1С?» Ручной перенос раз в квартал
Отчётность «Соберите план-факт по проекту при нас» Отчёт «настраивается на внедрении»
Срок запуска «Когда команда начнёт списывать часы?» Проект внедрения от полугода

Уклончивый ответ на любой из вопросов — тоже ответ. Отдельная развилка — брать готовую отраслевую модель или строить свою на конструкторе. Эту дилемму разбирали в статье «1С:PM или отраслевая система»: конструктор гибче, зато отраслевое решение работает с первых недель.

Шаг 3. Пилот за 2–4 недели — главный фильтр

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

Если хотя бы один сценарий не сложился за месяц, дальше будет только хуже. Провал пилота стоит пары недель, провал внедрения — год и доверие команды. Переходите со старого планировщика? Совместите пилот с чеклистом миграции с MS Project и Primavera — там он встроен в общий план перехода.

Какие вопросы задать вендору на демо?

Демо ведёт вендор, и по умолчанию оно пойдёт по сильным местам продукта. Перехватите сценарий — задайте свои вопросы:

  1. Покажите живой проект нашей отрасли, а не маркетинговый пример.
  2. Сколько кликов и минут занимает списание часов у исполнителя?
  3. Как увидеть, кто из специалистов свободен в следующем месяце?
  4. Откуда система берёт ставки и как считает себестоимость часа?
  5. Как устроен обмен с 1С и что переносится автоматически?
  6. Что входит в запуск: перенос данных, настройка, обучение?
  7. Сколько длилось внедрение у похожей по размеру компании?
  8. Есть ли запись в реестре отечественного ПО и под каким номером?
  9. Какие из показанных функций входят в базовую лицензию, а какие — доплата?
  10. В каком формате мы заберём данные, если решим уйти?

Ответы фиксируйте письменно. На демо всё выглядит быстрым и простым. На пилоте цифры имеют привычку меняться.

Частые ошибки выбора

  • Выбор по длине списка функций. Платите за возможности, которыми никто не воспользуется, а сложность интерфейса достаётся всем.
  • Внедрение «всем сразу» без пилота. Масштабировать можно только то, что уже работает на малом. Обратный порядок умножает цену каждой ошибки настройки.
  • Игнорирование сбора факта. Без фактических часов план остаётся гаданием: не сверить загрузку, не посчитать себестоимость, не увидеть маржу.
  • Демо только на данных вендора. Подготовленный пример всегда красив. Просите показать ваш сценарий — или переносите разговор в пилот.
  • Выбор комитетом без пользователей. Если инженеры и ГИПы не участвовали в пилоте, они найдут сто причин не вносить данные.
  • Ожидание системы «под всё». Одна покупка не закроет сразу CRM, документооборот, планирование и экономику. Сначала главная боль, остальное — интеграциями.

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

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

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

Решение фиксируйте письменно: какую боль закрываем, какие критерии проверили, что отложили. Такой протокол дисциплинирует выбор и пригодится через год, когда кто-нибудь спросит «а почему мы выбрали именно это».

Чеклист выбора одним списком

Сжатая версия маршрута — для печати и планёрки. Отмечайте по мере прохождения:

  • ☐ Сформулирована главная боль: сроки, люди, деньги или отчётность;
  • ☐ Определён класс системы под эту боль;
  • ☐ Проверено, обязателен ли реестр ПО для ваших закупок;
  • ☐ Составлен короткий список из двух-трёх кандидатов;
  • ☐ Проведены демо по вашему сценарию, ответы зафиксированы;
  • ☐ Отобраны одна-две системы для пилота;
  • ☐ Пилот на живом проекте: загрузка, факт часов, маржа контракта;
  • ☐ Посчитана полная стоимость: лицензии, внедрение, сопровождение;
  • ☐ Согласованы срок запуска и ответственный со стороны вендора;
  • ☐ Решение подтверждено командой пилота, а не только руководством.

Десять галочек. Маршрут от боли до решения укладывается в четыре-шесть недель. Дольше всего обычно длится не проверка, а откладывание её начала.

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

Выбираете систему для проектной организации? Запросите демо HRP — пройдём по вашей боли и покажем пилотный сценарий на ваших данных.

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

Обязательно ли выбирать систему из реестра отечественного ПО?

Для закупок под национальным режимом (постановление № 1875) — как правило, да: происхождение ПО подтверждает запись в российском или евразийском реестре, а применимость запрета и исключения проверяются по документации конкретной закупки. Частная организация формально свободна, но реестр остаётся полезным фильтром. Проверяйте запись сами, а не по слайду презентации.

Когда пора переходить с Excel на СУП?

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

Сколько занимает внедрение СУП в проектной организации?

Зависит от класса системы. Отраслевые решения с готовой моделью запускаются за недели: например, в HRP типовой контур поднимается за 2 недели, полный — около месяца. Конструкторы и портфельные платформы, которые настраивают под методологию заказчика, занимают от одного до нескольких кварталов.

Чем СУП для проектной организации отличается от таск-трекера?

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

Читайте также

Покажем на ваших данных

Рассчитаем план и себестоимость по одному вашему типовому контракту — сравните с тем, как это устроено сейчас.

Запросить демо на ваших данных

Демо-доступ к тестовой базе

Оставьте ФИО и email — создадим персональный демо-доступ. Логин и пароль покажем сразу.