Миграция с MS Project и Primavera: чеклист перехода

Миграция с MS Project или Primavera — это переход на новую систему управления проектами с переносом активных графиков, справочников и привычек команды. Технически данные переносятся через XML (MS Project) и XER/XML (Primavera), организационно — через пилот и короткий параллельный период. Главное правило: мигрируют процессы, а не файлы. Если попытаться перенести «всё как было», вы получите старые проблемы в новой обёртке — и заплатите за это дважды.

Когда пора переходить

Формальные причины известны: вендоры ушли, лицензии не продлеваются, для госзакупок действует национальный режим по постановлению № 1875. Но есть и практический триггер: старая система перестала отвечать на рабочие вопросы — кто свободен, успеваем ли, зарабатываем ли на контракте. Тогда миграция — повод не воспроизводить старый процесс, а починить его. Типичный пример: бюро годами вело в MS Project графики «для заказчика», а загрузку людей — в соседнем Excel. Переносить в новую систему обе привычки бессмысленно. Правильная цель миграции — один контур, где график, люди и часы связаны. Какие системы смотреть — в обзорах аналогов MS Project и аналогов Primavera.

Чеклист миграции: восемь шагов

Шаг 1. Аудит: чем вы пользуетесь на самом деле

Откройте реальные файлы за последний год и честно ответьте: что из возможностей системы работало? Часто выясняется, что из всей мощи P6 использовались сроки этапов и список ответственных, а MS Project служил рисовалкой Ганта для заказчика. Итог шага — короткий список функций, без которых нельзя, и список того, чем никто не пользовался. Второй список не менее ценен: за неиспользуемые возможности не стоит платить ни деньгами, ни сложностью интерфейса новой системы.

Шаг 2. Инвентаризация данных

Составьте реестр: активные проекты (переносятся), завершённые (архивируются), шаблоны и справочники — ресурсы, календари, ставки, коды работ (переносятся выборочно). Решите судьбу каждой категории до выбора системы, а не после: объём переноса влияет на сроки и бюджет.

Шаг 3. Выбор целевой системы под процесс, а не под файлы

Критерии из шага 1 важнее «поддержки XER». Проектной организации, где узкое место — люди и экономика, нужны ресурсное планирование и учёт трудозатрат; строительному подрядчику — календарно-сетевой движок. Проверьте наличие кандидата в каталоге российского ПО, если работаете с госзаказом. Полная методика — в гайде как выбрать российскую СУП.

Шаг 4. Пилот на одном-двух живых проектах

Не тестовые данные, а реальный контракт со всей его кривизной: сменами объёмов, отпусками, субподрядом. Пилот за 2–4 недели отвечает на три вопроса: садится ли структура работ, тянет ли команда ежедневную работу в системе, получаются ли нужные отчёты. Провалившийся пилот — это дёшево; провалившееся внедрение на всю компанию — нет.

Шаг 5. Перенос данных

Порядок имеет значение: сначала справочники — люди, роли, календари, ставки; затем структуры активных проектов; затем остатки работ. Графики из MS Project уходят через XML, из Primavera — через XER/XML, но рассчитывайте на ручную доводку: назначения ресурсов, проценты готовности и нестандартные календари при автоимпорте искажаются чаще всего. Историю завершённых проектов в новую систему не тащите — архив в PDF плюс исходники.

Шаг 6. Обучение через роли, а не лекции

Каждой роли — свой получасовой сценарий: исполнителю — как списывать часы, ГИПу — как смотреть загрузку и план-факт, директору — как читать сводку по портфелю. Общий четырёхчасовой вебинар «обо всём» забывается к обеду. Настройте процесс так, чтобы ежедневное действие занимало минуты, — иначе саботаж гарантирован.

Шаг 7. Параллельный период и сверка

2–4 недели ведите пилотные проекты в обеих системах и сверяйте: сроки, назначения, часы и деньги — до копейки. Расхождения — повод чинить настройки, а не повод вернуться. Зафиксируйте дату, после которой старая система доступна только для чтения.

Шаг 8. Отключение и точка невозврата

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

Что переносится, а что нет: карта данных

Ожидания здесь важно откалибровать заранее. Иначе на середине проекта начнётся разочарование «а нам обещали». Честная карта:

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

Кто отвечает за переход: три роли

Миграция без владельца растягивается на год. Минимальный состав команды перехода:

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

Остальная компания подключается после пилота. Не раньше. Искушение «раскатать на всех сразу, чтобы два раза не вставать» стоило провала не одному внедрению: масштабировать можно только то, что уже работает на малом.

Сколько это стоит по времени

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

Главный ускоритель — отраслевая готовность целевой системы. Если структура работ, роли и типовые отчёты уже соответствуют вашей отрасли, этап настройки схлопывается с недель до дней. Критерии готовности разбирали в статье про выбор между конструктором и отраслевой системой.

Чем мерить успех перехода? Тремя признаками через месяц после точки невозврата. Команда вносит данные в новую систему без напоминаний. Руководители принимают решения по её отчётам, а не по личным таблицам. И никто не просит «открыть старую базу на минутку». Если все три пункта сошлись — миграция состоялась.

Типичные ошибки миграции

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

Весь чеклист одним списком

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

• ☐ Проведён аудит: что реально использовалось в старой системе;
• ☐ Составлен реестр данных: переносим / архивируем / выбрасываем;
• ☐ Выбрана целевая система под процесс, проверен реестр ПО;
• ☐ Назначен владелец миграции с полномочиями;
• ☐ Пилот на живом проекте завершён, решение подтверждено;
• ☐ Перенесены справочники: люди, роли, календари, ставки;
• ☐ Перенесены активные проекты, остатки работ переоценены;
• ☐ Завершённые проекты выгружены в архив;
• ☐ Команда обучена по ролям, ежедневные действия занимают минуты;
• ☐ Параллельный период пройден, данные сверены;
• ☐ Назначена и объявлена дата точки невозврата;
• ☐ Старая система переведена в режим «только чтение».

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

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