Содержание
Завод нельзя остановить на год под капитальный ремонт. Заказы идут, смена в цеху, бухгалтерия закрывает месяц. Так же живёт ERP: бизнес дышит через неё каждый день. Полная замена с нуля за двенадцать месяцев звучит как план со слайда. На практике срывается срок, учёт разъезжается в Excel, и команда уже не верит следующему финальному дедлайну. Рабочий путь другой: переезжать цех за цехом, пока завод продолжает выпускать продукцию.
Дальше про дорогу от первого контура до переключения. Завод при этом не останавливают. В литературе этот приём называют Strangler Fig, удушающая лиана. По-русски точнее постепенное замещение. Куда эволюционировать платформу, метаданные и движки, разбирает статья о современной ERP 2026. Здесь про то, как доехать, не ломая дорогу под собой.
Ключевые выводы
Большой взрыв переносит риск в одну ночь. Пока пишут новую ERP, старая продолжает обрастать исключениями. В день переключения сравнивают уже не две версии одной системы, а два разных мира и год накопленных расхождений.
Постепенное замещение идёт сразу в трёх плоскостях: интерфейс, API, владение данными. Красивый новый экран поверх старой таблицы ещё не миграция. Миграция начинается, когда ясно, кто пишет истину и как старый контур перестаёт быть единственным источником.
Первый модуль выбирают по формуле боль × изоляция × ценность. Идеальный кандидат болит у бизнеса, относительно отделим от ядра и даёт измеримый выигрыш за квартал. Иначе программа утонет в желании сначала вынести фундамент.
Двойной прогон без сверки обманывает команду. Параллельная запись и чтение имеют смысл, только если расхождения видны каждый день, их классифицируют и чинят до переключения. Обещание разобраться после запуска этого не заменяет.
ИИ в 2026 ускоряет карту зависимостей и черновики контрактов. Он не принимает решение переписать систему за людей. Без эксперта, который знает закрытие месяца и договор с банком, модель уверенно нарисует несуществующую границу. Подробнее в разборе ИИ на 15-летнем легаси.
Почему план переписать ERP за год почти всегда провал
Корпоративная система растёт вместе с бизнесом: исключения, регуляторика, интеграции, отчёты только для этого склада. Почему монолит становится монстром, разобрано в отдельной статье. Важнее другое. Стоимость остановки обычно выше стоимости сопровождения. Склад не может подождать релиз.
Типичный сценарий большого взрыва выглядит знакомо. Руководство утверждает программу замены ERP. Команда уходит в зелёное поле. Через полгода требования уже не те, что в уставе: появился новый канал продаж, изменился налог, интегратор банка обновил протокол. Старая система за это время получила ещё двадцать временных доработок. В день X нужно перенести историю, обучить тысячу пользователей и убедиться, что ночные задания не сломают закрытие периода. Цена ошибки здесь не баг в интерфейсе, а срыв отгрузки или отчётности. Про экономику отказа см. стоимость сбоя.
Есть и культурный провал. Пока новая система живёт в лаборатории, бизнес считает миграцию чужой проблемой ИТ. К переключению выясняется, что процессы в голове бухгалтера и процессы в коде рассказывают разные истории. Документация устарела ещё в 2019-м. Знания живут у двух людей, один из которых в отпуске.
Поэтому вопрос не в том, успеете ли вы написать новую ERP. Вопрос в том, можете ли вы непрерывно поставлять ценность, не останавливая завод. Постепенное замещение отвечает да, если границу контура держат и сверяют данные до переключения.
Паттерн постепенного замещения в мире ERP: три плоскости
Новое растёт вокруг старого и со временем заменяет его, не снося здание целиком. В ERP это удобно разложить на три плоскости. Иначе команда чинит только то, что видно на демонстрации заказчику.
Плоскость интерфейса
Пользователь открывает новый экран заявок, а за ним всё ещё старый сервис и старые таблицы. Так проще учить людей и снимать страх. Связанность ядра при этом не уменьшается. Красивый фасад легко маскирует отсутствие прогресса по данным.
Плоскость API и процессов
Новый сервис принимает команды создать заказ и провести документ, а старый модуль на время остаётся реализацией. Или наоборот: шлюз отправляет часть трафика в новый контур. Здесь появляется контракт: какие поля обязательны, какие статусы допустимы, кто отвечает за идемпотентность. Без контракта временная обёртка становится вечной.
Плоскость данных и владения
Самая дорогая. Пока обе системы пишут в одну таблицу как получится, это не миграция, а распределённый хаос. Нужно явно решить, кто источник истины. На этапе N это старая база. На этапе N+1 это новая. На этапе сверки пишут обе, но с правилами разрешения конфликтов. Иллюзия универсальной схемы, которая якобы избавит от миграций, разобрана в ошибке универсальной ERP и в разборе EAV. Не тащите её в новый контур заодно.
Метафора завода снова полезна. Новая табличка на цехе меняет интерфейс. Переложенные трубы между цехами меняют API. Пока не ясно, кто отвечает за склад сырья, смена будет работать по двум журналам и врать в отчётах.
Как выбрать первый модуль для выноса
Новички начинают с фундамента: общая модель контрагентов, единый справочник номенклатуры, ядро платформы. Фундамент касается всех, значит любой сбой бьёт по всему заводу. Первый контур должен быть ограниченным и полезным.
Практичная формула отбора:
- Боль. Модуль тормозит бизнес или ИТ: долгие доработки, частые инциденты, жалобы пользователей.
- Изоляция. Мало синхронных зависимостей от ядра. Понятный вход и выход: события, файлы, REST. Не двадцать соединений с центральными таблицами в каждом запросе.
- Ценность. За один–два квартала можно показать более быстрый релиз, меньше ошибок, понятнее отчёт. Иначе спонсор устанет.
Хороший кандидат часто живёт сбоку: заявки на ремонт, один канал продаж, модуль со своим API. Плохой кандидат бьёт по всему заводу сразу. Главная книга в середине финансового года и расчёт зарплаты за неделю до выплаты как раз такие.
Результат выбора не слайд, а одностраничный паспорт контура: где он кончается и кто отвечает за него со стороны бизнеса. Без этого владельца техническая команда будет мигрировать в пустоту.
Контракты и границы до первой строки кода
До репозитория и спринта нужна карта. Иначе постепенное замещение превращается в ещё один сервис рядом с монолитом. Минимальный набор артефактов такой.
Карта зависимостей. Кто читает и пишет таблицы контура, и какие ночные задания от них зависят? Здесь ИИ реально экономит недели, если репозиторий и схема проиндексированы. См. ИИ и легаси.
Контракт операции. Для каждой команды запишите вход, выход и что будет при повторе. Создать заказ в старой системе и в новой должно значить одно и то же для вызывающего.
Граница данных. Список сущностей контура, правила ключей, что считается историей, что считается оперативным срезом. Явно запишите, что не входит в контур. Иначе рамки расползутся к универсальной платформе за один квартал.
Права и роли. Кто видит документы после переноса? Миграция без модели доступа приглашает к утечке. Связка ERP и корпоративного ИИ с ролями разобрана в статье ERP как источник знаний.
Календарь ограничений. Окна закрытия месяца, инвентаризации, регуляторные отчётные даты. Переключение в любую пятницу остаётся мифом.
Эти артефакты дешевле любого быстрого прототипа на новых технологиях. Прототип без границ станет вторым монолитом за полгода. Тот же парадокс, из-за которого ERP сжимаются в монстра.
Параллельный контур: двойной прогон и сверка
Пока пользователи ещё на старом контуре, новый должен доказать, что ведёт себя так же или лучше по заранее согласованным правилам. Три режима часто путают.
Теневой прогон. Трафик или копия событий идёт в новый контур молча. Пользователь не видит результат. Вы сравниваете ответы и побочные эффекты. Это безопаснее записи, но ловит не всё: часть логики срабатывает только от реального интерфейса и ручных шагов.
Двойная запись. Операция фиксируется и в старой, и в новой системе, или в новой с зеркалом в старую. Нужны правила первичности и очередь на разбор конфликтов. Без очереди и владельца конфликтов двойная запись превращается в два источника лжи.
Двойное чтение. Критичные экраны и отчёты читают оба контура и показывают расхождение оператору или в мониторинг. Это полезно на поздней стадии, когда доверие к записи уже выше.
Сверка держит весь плейбук. Договоритесь о метрике расхождения: доля документов, у которых не сходятся сумма или состав строк. Рядом держите время до устранения и короткий список отличий, которые заранее признали допустимыми, например округление. Каждый день разбирайте красный список. Пока он не сжимается устойчиво, переключение запрещено, сколько бы ни давил спонсор.
Технически хватает журнала, где старый ключ сопоставлен с новым, и алерта, если после релиза расхождения растут. Повторная доставка события не должна создавать второй документ. Не усложняйте ради идеальной шины. Достаточно надёжного канала и честной таблицы сверки.
Переключение без ужаса
Переключение не молитва после выкладки. Это процедура с откатом и окном наблюдения.
Критерии готовности. Сверка стабильно ниже порога N дней. Нет открытых дефектов уровня блокер по контуру. Обучена пилотная группа. План отката прогнан на стенде хотя бы один раз. Бизнес-владелец письменно подтвердил окно. Мониторинг и дежурная смена назначены.
Стратегия включения. Часто лучше канареечное переключение: сначала один склад, один регион, одна роль, не вся компания. Флаги функций и маршрутизация на шлюзе позволяют вернуть трафик за минуты, если сверка поплыла.
Откат. Заранее решите, что именно откатываете: интерфейс на старый контур, запись в новый, или полное восстановление из резервной копии. Последнее при модульном замещении почти никогда не нужно и почти всегда опаснее. Откат должен быть отработан, а не описан на слайде.
Коммуникация. Пользователи узнают не из инцидента. Короткий сценарий, что изменилось, куда звонить и как откатим, снижает панику сильнее любой заставки.
После включения наблюдение усиливают: сверка чаще, список инцидентов контура отделён от общего шума. Только когда контур скучный несколько циклов (неделя или закрытие периода, смотря по контексту), можно планировать вывод старого кода и таблиц. Удалять рано значит оставить себе мины без запаса.
Типичные сроки для среднего контура: недели на карту и контракт, месяцы на двойной прогон, дни на само переключение. Для всей ERP часто 12–24 месяца непрерывной поставки, а не один релиз всего сразу. Это согласуется с эволюционным путём к платформе в гайде 2026. Здесь акцент на операциях, а не на движках метаданных.
Люди, команды и календарь: о чём забывают архитекторы
Технический план без оргконтура уже даёт половину катастрофы. На заводе нельзя одновременно чинить все линии и требовать прежний объём выпуска без смены графика. В ERP то же самое.
Две роли на контур. Бизнес-владелец отвечает за процесс и приёмку: можно переключать или нельзя. Технический ведущий отвечает за контракт, сверку и откат. Если обе роли сидят на ИТ, бизнес узнает о миграции из инцидента.
Заморозка изменений. На время двойного прогона договоритесь, какие доработки старого контура ещё принимаются, а какие уходят в очередь после переключения. Иначе вы вечно догоняете движущуюся мишень. Так срываются программы замены.
Параллельные команды. Одна группа сопровождает легаси и тушит пожары. Другая ведёт новый контур. Без явного разделения люди будут на час отвлекаться на прод и не закончат сверку. Платформенная цель, метаданные и движки, может жить у третьей группы. Она не должна блокировать первый вынесенный модуль. Иначе снова начнёте с фундамента.
Обучение короткими сценариями. Не сорокачасовой курс по новой ERP, а как оформить заявку за три минуты и куда звонить, если сумма не сходится. Пилотная смена становится внутренними преподавателями для следующей волны.
Календарь священен. Закрытие месяца, инвентаризация, пик сезона и выплата зарплаты попадают в красные зоны. Впишите их в паспорт контура крупнее, чем выбранный фреймворк.
История, отчёты и регуляторика
Операционный контур можно вынести относительно быстро. История и отчётность тормозят программы миграции чаще кода.
Варианты, которые работают на практике:
Горячий срез и холодный архив. Открытые документы и активные остатки переезжают в новый контур. Закрытые периоды остаются в старой системе только для чтения или выгружаются в архив, откуда можно достать документ за 2019 год.
Дозагрузка истории волнами. Сначала год–два, потом глубже, по мере стабилизации. Не обещайте всю историю в день X, если объём и преобразования не измерены на пилоте.
Отчёты как отдельный контур. Аналитика и регуляторные формы часто зависят от грязных представлений и ночных витрин. Их миграция требует отдельного паспорта. Иначе замещение операционки похоронит отчётность. Иногда отчёты временно читают оба источника через слой согласования.
Регуляторика. Если аудитор требует неизменности прошлых проводок, переписывать историю ради красоты схемы нельзя. Зафиксируйте политику: что мигрирует как есть, что пересчитывается, что остаётся в архиве с хешем или подписью по правилам компании.
Путаница между источником истины для операции и источником истины для отчёта за прошлый год часто срывает сроки. Разведите их явно в паспорте контура.
Роль ИИ в миграции унаследованной ERP (2026)
Искусственный интеллект не заменяет дисциплину постепенного замещения. Он ускоряет разведку и черновики там, где человек тонет в миллионах строк.
Где модель полезна:
- Поиск всех мест, где читается таблица или вызывается модуль.
- Черновик карты зависимостей и списка ночных заданий.
- Черновик описания контракта по фактическому коду, с обязательной проверкой человеком.
- Подсказки по тестам сверки: какие поля сравнивать, какие случаи краевые.
- Объяснение фрагмента легаси новому участнику команды.
Где модель опасна:
- Просьба сгенерировать новую ERP по описанию.
- Слепое доверие к несуществующим API и к границам, которые модели кажутся очевидными.
- Рефакторинг без владельца бизнес-правила и без окна отката.
Связка 2026 года такая. Эксперт задаёт рамки и принимает решения. Модель читает код и не устаёт. Подробный разбор границ в статье про ИИ и 15-летний проект. Для целевой архитектуры после выноса модулей смотрите платформенный подход. ИИ не отменяет метаданные и движки. Он помогает до них дожить.
Сама миграция устроена как эксперимент. Гипотеза: новый контур ведёт себя не хуже старого. Метрики сверки и журнал наблюдений проверяют гипотезу. Без журнала на проде остаётся гадание.
Типичные ошибки
Начать с самого связанного модуля, потому что он главный. Главный на первом шаге и есть самый опасный.
Считать новый интерфейс миграцией. Без смены владения данными вы купили косметический ремонт.
Двойная запись без владельца конфликтов. Расхождения копятся, сводки никто не читает, в день X внезапно находится тысяча документов.
Переключение всей компании в одно окно. Нет канарейки, нет дешёвого отката по сегменту.
Удалить старый код через неделю. Запасной контур ещё нужен на первое закрытие периода и на первый странный отчёт аудитора.
Параллельно строить универсальную платформу на все случаи. Рамки расползаются. См. универсальная ERP как ошибка.
Игнорировать календарь бизнеса. Миграция склада в пик сезона или зарплаты в день выплаты превращается в лотерею.
Путать программу миграции с проектом внедрения ИИ. Поиск по корпусу и ассистенты могут опираться на ERP как на источник знаний (интеграция), но не заменяют пошаговый вынос контуров.
Что сделать сегодня
Если вы только обсуждаете замену ERP, не открывайте тендер на новую систему целиком. За одну–две недели соберите минимальный набор.
- Выберите один кандидатный контур по формуле боль × изоляция × ценность. Запишите паспорт на одну страницу.
- Нарисуйте карту зависимостей, хотя бы вручную и с помощью ИИ по репозиторию: таблицы, задания, интеграции, отчёты.
- Опишите контракт трёх главных операций контура и правило, кто источник истины на этапе 1.
- Договоритесь о метрике сверки и пороге, ниже которого можно думать о переключении.
- Назначьте бизнес-владельца и техническую дежурную смену на пилот. Зафиксируйте запретные окна календаря.
- Запланируйте теневой прогон или двойную запись на узком сегменте, не на всей компании.
- Отдельно решите судьбу истории и двух критичных отчётов: переезд, архив или временное двойное чтение.
Этого достаточно, чтобы отличить серьёзную программу от слайда про переписывание за год. Дальше идут итерации. Каждый вынесенный контур учит команду дешевле, чем один большой взрыв.
FAQ
Сколько длится миграция ERP постепенным замещением?
Для одного ограниченного контура часто от нескольких месяцев до года, с учётом двойного прогона и закрытия периода. Для всей системы среднего размера нередко 12–24 месяца непрерывной поставки. Срок определяется связанностью и календарём бизнеса, а не выбранным фреймворком.
Когда полная замена одним ударом всё же допустима?
Редко. Система крошечная, и полный простой бизнеса уже согласован и оплачен. Тяжёлой истории нет, и команда уже делала такой перенос. Если сомневаетесь, вы не в этой категории.
Нужен ли сразу брокер событий вроде Kafka?
Не как религия. Нужен надёжный шов между контурами: события, очередь или файловый обмен с идемпотентностью, то, что команда умеет сопровождать. Сложность шины без дисциплины сверки не спасает.
Что делать с пользователями, которые не хотят новый экран?
Пилот на добровольцах и на сегменте, где боль максимальна. Параллельный доступ на время. Обучение короткими сценариями вроде того, как закрыть смену, а не курсом на сорок часов. Страх снимает успешный канареечный запуск, а не презентация.
Как ИИ помогает именно в миграции?
Быстрее строить карту, кто трогает эту таблицу, черновики контрактов и списки краевых случаев для сверки. Сгенерировать целевую ERP без архитектора и без паспорта контура он не поможет.
Чем этот плейбук отличается от статьи про платформенную ERP?
Платформенная статья отвечает, какой должна стать система. Этот плейбук отвечает, как доехать без остановки завода.
Комментарии