Универсальные системы управления проектами в проектных организациях приживаются плохо. Через три месяца после внедрения ГИПы возвращаются в Excel, а система остаётся жить только в отчётах для директора. Разбираем, почему так происходит и что проверять при выборе.
Почему универсальные системы не приживаются в ПИР
Типовая система управления проектами оперирует задачами и исполнителями. Проектная организация оперирует разделами, марками и стадиями: ИРД, ПД, РД, прохождение ГГЭ. Между этими моделями есть зазор, который приходится закрывать настройкой: марки разделов заводят как справочник, стадии - как статусы задач, связь раздела со сметной строкой не появляется вообще.
Настройка держится, пока в штате есть человек, который её понимает. После его ухода система деградирует до электронной доски с карточками, и учёт возвращается в таблицы.
Чек-лист: что проверять до подписания договора
1. Разделы и марки по ПП-87 в ядре, а не в настройках
Попросите показать карточку раздела. Если марка (КЖ, ЭОМ, ВК), тип документации (ПД/РД) и статус выдачи - это поля системы, а не пользовательские атрибуты, доменная модель есть. Если предлагают «завести справочник» - перед вами универсальный таск-трекер.
2. План-факт с детализацией до раздела
Бюджет всего проекта без разбивки бесполезен для управления: перерасход
обнаружится в конце, когда исправить ничего нельзя. Рабочая схема - аналитический
счёт вида 2024-017/РД/Субподряд: проект, стадия, статья затрат.
Тогда превышение видно в день проводки.
3. Загрузка специалистов с учётом календаря
Сумма назначений по каждому инженеру за период должна считаться автоматически и сравниваться с производственным календарём. Перегруз свыше 100% - сигнал до того, как сорван срок, а не после.
4. Версии томов и маршруты согласования
Том, который согласовывается пересылкой по почте, гарантированно потеряет актуальную версию. В системе должны быть версии с историей и привязка каждого файла к разделу и стадии.
5. Права по ролям, настраиваемые без программиста
Сметчик не должен видеть управленческую отчётность, проектировщик - финансы. Проверьте, можно ли создать свою роль (например, «нормоконтролёр») через интерфейс, не обращаясь к вендору.
6. Прямая интеграция с 1С
Факт затрат живёт в 1С:Бухгалтерия. Если переносить его в систему вручную, через месяц это перестанут делать. Спросите, как именно загружается факт: выгрузка файлом раз в месяц - это не интеграция.
7. Развёртывание on-premise
Проектная документация - чувствительные данные, у части заказчиков есть прямой запрет на облака. Уточните, работает ли система на вашем сервере в закрытом контуре и что входит в сопровождение.
Три вопроса вендору на демонстрации
- Покажите, как выглядит просрочка выдачи раздела. Кто и когда о ней узнаёт.
- Покажите загрузку конкретного конструктора на следующий месяц.
- Что произойдёт с системой, если завтра уволится администратор со стороны заказчика.
По ответам на эти вопросы понятно, видел ли вендор живую проектную организацию или продаёт коробку.
Вывод
Главный критерий - доменная модель ПИР в архитектуре системы. Всё остальное (красота интерфейса, мобильное приложение, искусственный интеллект в маркетинге) вторично: настроить «под ПИР» универсальную систему дороже, чем взять специализированную.