Сколько занимает миграция с SAP в крупной компании: от чего зависит срок

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

Разберём, что на самом деле определяет сроки.

Почему размер компании — плохой предиктор

Интуиция подсказывает: больше выручка и больше сотрудников — дольше миграция. На практике связь слабая.

Компания с оборотом в десятки миллиардов, которая использует SAP как учётное ядро без глубоких доработок, мигрирует быстрее, чем компания вдвое меньше, где за десять лет накопились сотни пользовательских разработок, а половина бизнес-логики живёт в ABAP-коде, написанном уволившимися сотрудниками.

Определяют срок четыре вещи, и ни одна из них не про размер.

Фактор первый: сколько модулей реально используется

Самое частое открытие первых недель аудита — существенная часть внедрённой функциональности не работает. Отчёты, которые никто не открывает. Справочники, заполненные один раз при внедрении. Модули, купленные в составе лицензии и так и не запущенные.

По нашей практике разбора таких систем треть и более функциональности оказывается мёртвой. Её не нужно замещать, и отказ от переноса сокращает проект сильнее любых ускорений в разработке.

Отсюда практический вывод: инвентаризация до оценки сроков — не бюрократия, а самый выгодный этап проекта. Пока она не проведена, любая оценка длительности является гаданием.

Фактор второй: объём доработок

Коробочный SAP мигрируется по понятной схеме. Проблема в том, что коробочного SAP в живой компании не существует — за годы эксплуатации накапливаются доработки под конкретные процессы.

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

Отдельная сложность: часть логики никем не задокументирована и существует только в коде. Разбор такого кода занимает время, сопоставимое с написанием заново, а иногда и больше.

Фактор третий: интеграции

ERP редко стоит изолированно. К ней подключены склад, производство, банк-клиент, ЭДО, маркетплейсы, порталы поставщиков, BI-системы.

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

Фактор четвёртый: готовность команды заказчика

Самый недооценённый и самый частый источник срыва сроков.

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

Если такие люди не выделены явно, проект встаёт не на разработке, а на приёмке. Разработчики сдали контур, ждут проверки, проверка сдвигается на две недели из-за закрытия квартала. Пять таких сдвигов — и полугодовой план превращается в годовой.

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

Ориентиры по этапам

Для компании среднего размера с типичным набором доработок:

Аудит и карта процессов — 3–4 недели. Инвентаризация активной функциональности, схема интеграций, приоритеты.

Пилот одного критичного процесса — 6–10 недель. Один процесс переносится на целевой стек параллельно с работающим SAP и проверяется на реальных данных. Пилот отвечает на вопрос, сколько реально стоит перенос одного контура, — и только после него оценка всего проекта перестаёт быть предположением.

Поэтапная миграция — от 6 месяцев. Контуры переезжают волнами, каждая заканчивается сверкой и переключением пользователей. Для крупной компании эта фаза занимает годы.

Вывод из эксплуатации. Архивация истории в доступном для проверок виде, закрытие лицензий, окончательное переключение интеграций.

Сколько людей нужно на миграцию

Вопрос задают почти всегда, а в планах он появляется редко. Ориентиры для компании среднего размера, на одну волну миграции:

Со стороны подрядчика — 4–7 человек. Архитектор (частичная занятость), двое-трое разработчиков, интеграционный инженер, аналитик процессов, тестировщик. На пилоте команда меньше — два-три человека.

Со стороны заказчика — 3–5 человек, и это решающая часть. Владелец процесса, который объясняет, как всё работает на самом деле; ключевой пользователь, проверяющий результат на своих данных; специалист по 1С или учётной системе; представитель ИТ по инфраструктуре и доступам. Плюс человек, принимающий решение о переключении.

Критично не число, а доля их времени. Рабочий ориентир — 20–30% занятости на протяжении волны, а в недели приёмки — до половины. Если люди участвуют «по остаточному принципу», между сдачей контура и его проверкой появляются паузы в одну-две недели, и полугодовой план превращается в годовой без единой технической проблемы.

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

Отдельно: миграция с SAP в банках

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

Первая: SAP в банке — это не то, что обслуживает клиентов. Ядро банковской автоматизации — АБС, и она почти никогда не SAP. SAP в банке стоит на бухгалтерии, казначействе, закупках, управлении персоналом, иногда на консолидированной отчётности. Отсюда следствие, которое сильно меняет оценку: мигрирует не «всё», а периметр вокруг ядра, зато этот периметр плотно сшит с АБС и с отчётными контурами. Проект выглядит меньше, чем кажется по названию, и одновременно сложнее по интеграциям.

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

Третья: банк, как правило, субъект критической информационной инфраструктуры. Это меняет не столько технику, сколько процедуры: согласование изменений, требования к средствам защиты, аттестация контуров. Работа идёт параллельно разработке, но приёмку тормозит именно она.

Сколько людей. Ориентиры для одной волны те же, что выше: 4–7 человек со стороны подрядчика и 3–5 со стороны банка. Разница в том, что волн одновременно идёт несколько — по контурам и владельцам процессов, — плюс добавляются роли, которых нет в обычном проекте: специалист по регуляторной отчётности и представитель информационной безопасности. На практике это означает, что суммарная команда исчисляется десятками человек, но ни одна отдельная волна больше не становится — растёт их число, а не размер.

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

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

Что растягивает проект вдвое

Три сценария встречаются чаще остальных.

Попытка перенести всё. Без инвентаризации в план попадает мёртвая функциональность, и треть бюджета уходит на воспроизведение того, чем никто не пользуется.

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

Отсутствие выделенных людей у заказчика. Разработка идёт по плану, приёмка — нет. Сроки удваиваются без единой технической проблемы.

Подробнее про порядок этапов и параллельную работу контуров — в разборе миграции с SAP на российское ПО, про методологию поэтапного перехода — в статье об импортозамещении без остановки бизнеса.

Итог

Спрашивать «сколько занимает миграция с SAP» без вводных — то же самое, что спрашивать стоимость дома без этажности и региона. Ответ определяется долей живой функциональности, объёмом уникальных доработок, числом интеграций и наличием людей для приёмки.

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

Если задача актуальна — посмотрите услугу импортозамещения SAP и Oracle и кейс замены WMS с интеграцией в 1С и развёртыванием on-premise.