По данным исследования ГК «КОРУС Консалтинг», проведенного среди участников Бизнес-форума 1С:ERP 2025, у 43% компаний ERP внедрена не полностью или требует оптимизации, и лишь у 10,3% организаций система действительно выступает ядром управленческого контура. Это значит, что даже формально завершенный проект далеко не всегда дает бизнесу то, ради чего затевался.
В статье разберем, какие данные чаще всего теряются при миграции ERP, как подготовить их к переносу и как выстроить процесс, чтобы учет был полным и достоверным.
Перенос данных — главный риск при замене ERP
На практике замена ERP часто проваливается из-за проблем с переносом данных. Можно и конфигурацию донастроить, и интерфейсы допилить, и обучение провести, но если мастер-данные в новой системе не отражают реальность, полноценно она работать, к сожалению, не будет.
Основная проблема каждого такого переноса в том, что данные редко лежат в одном месте, ещё и в идеальном состоянии. За годы работы в старой ERP стопроцентно накапливаются дубли контрагентов, устаревшие справочники,и даже документы с ошибочными проводками (их обычно никто не замечает, потому что отчетность до этого как-то сходилась). При переходе на другую ERP все это переезжает в новую систему вместе с ошибками.
Исследование SAPLand.ru, проведенное в августе–октябре 2025 года среди более чем 400 респондентов из крупного бизнеса, показало: 57% опрошенных считают перевод крупных инсталляций SAP ERP на российские платформы нереализуемой задачей, еще 28% говорят о серьезных функциональных и технологических компромиссах. Один из ключевых компромиссов — как раз работа с данными. SAP-импортозамещение упирается в невозможность сразу и без потерь перенести всю накопившуюся информацию.
Что пропадает при переносе данных: типичные потери при миграции ERP
Мы собрали пять категорий данных, которые чаще всего страдают при миграции данных ERP. Этот список основан на опыте наших проектов и данных других интеграторов.
Исторические проводки и документы за прошлые периоды
Многие компании переносят в новую систему только остатки на дату перехода, а всю историю оставляют в старой ERP, чисто на всякий случай. А через полгода, например, выясняется, что налоговая запросила документы за позапрошлый год, а доступ к старой системе уже отключен. Или что финансовому директору нужна динамика продаж за три года, а в новой ERP этих данных уже нет. Если решили переносить данные — переносите всё.
Справочники НСИ (нормативно-справочная информация) и мастер-данные
Номенклатура, контрагенты, договоры, банковские счета, классификаторы — все это нужно для работы системы. При переносе справочники часто схлопывают: объединяют дубли, удаляют неактуальные позиции, меняют коды и так далее. В результате в новой ERP могут возникнуть ситуации, когда один и тот же поставщик заведен несколько под разными названиями, а складская номенклатура из-за этого не бьется с бухгалтерской.
Связи между объектами
ERP — это одна большая система связей: например, заказ ссылается на договор, договор — на контрагента, платеж — на счет. При переносе эти связи могут потеряться (и это происходит чаще, чем хотелось бы). Документ вроде бы переехал, но он больше не связан с договором, и система не может построить цепочку «заказ — отгрузка — оплата». Восстанавливать такие связи вручную — адский труд, на который, из нашей практики, может уйти больше времени, чем на всё внедрение до этого.
Настройки и конфигурация
Скорее всего, за годы работы компании у неё сформировались свои индивидуальные отчеты, печатные формы, права доступа и бизнес-правила. При переходе на другую ERP часть этих настроек может не подтянуться автоматически. Мы рекомендуем заложить отдельный этап переноса и проверки всей документации, хоть как-то связанной с бизнес-процессами.
Незавершенные операции
Это самая больная боль при переносе. Дело в том, что открытые заказы, незакрытые авансы, документы в статусе согласования сложнее всего переносить, потому что эти данные по факту ещё в работе. Если их отдельно не проконтролировать, в новой системе возникнет пробел: физически товар отгружен, а в ERP это не отражено.
Подготовка данных: что сделать до начала переноса
Вот что стоит сделать до того, как начнется полноценная миграция ERP.
Провести полный аудит данных
Ключевое слово — полный: какие справочники существуют, сколько в них записей, сколько дублей, какие поля заполнены, какие пустуют. Это нужно для оценки сроков, бюджета и ресурсов. Был случай в практике, когда аудит данных занял почти столько же времени, сколько длились все остальные работы.
Определить владельцев данных
В большинстве компаний никто прямо не отвечает за качество данных в ERP. Классическая ситуация: бухгалтерия считает, что справочник контрагентов — зона ИТ-команды, ИТ говорит, что данные создают пользователи, а пользователи уверены, что за чистоту справочников должен отвечать кто-то другой.
Чтобы такого не было, нужно до переноса назначить конкретных сотрудников, которые будут отвечать за каждую категорию мастер-данных: номенклатуру, контрагентов, договоры, основные средства и так далее.
Очистить данные до переноса
Иногда заказчик говорит: «Давайте перенесём всё как есть, а потом, в новой системе уже всё почистим». На практике это не работает, потому что после переноса у компании возникает много других, не менее важных задач, и старыми данными никто полноценно заниматься не будет.
Согласовать правила маппинга
Пример маппинга: как справочник номенклатуры из SAP будет соотноситься со справочником в 1С:ERP? Или: какие поля переносятся, какие заполняются заново, а какие объединяются? Здесь понадобится помощь ответственных сотрудников из пункта про владельцев данных.
Провести тестовые прогоны на реальных данных
Бывает, что для ускорения тестирования его проводят на какой-то части данных (обычно на той, что уже успели перенести и проверить). Но это ошибка, потому что проверять нужно все перенесённые данные. Тестовый прогон показывает, где рвутся связи, какие поля не маппятся, какие справочники конфликтуют, и если это проверить только на тестовых данных, то после полного переноса могут появиться ошибки.
Стратегия миграции: три подхода и их применимость
Универсальной стратегии миграции ERP нет, она зависит от масштаба, сроков, бюджета и готовности бизнеса к изменениям. Вместо этого мы выделяем три направления, в которых она может идти.
На практике чаще всего используют комбинацию подходов: справочники переносят поэтапно, критичные остатки — с параллельной сверкой, а исторические данные — частями после запуска.
FAQ
Сколько тестовых прогонов ETL нужно сделать до запуска?
Минимум три, а для крупных инсталляций — от пяти, при этом каждый прогон должен быть на полном массиве данных, а не на выборке. Почему минимум три: первый прогон выявляет структурные проблемы, второй — ошибки маппинга, третий — пограничные случаи. Если после третьего прогона ещё расхождения, говорить о полноценном запуске нельзя, нужно доработать данные..
Обязательно ли переносить всю историю данных из SAP в новую систему?
Нет, но нужно определить, какая история действительно нужна. Для налогового и бухгалтерского учета это минимум три года, для аналитики и управленческой отчетности — от пяти лет. Все, что старше, можно перенести в архив и обеспечить к нему доступ через отдельное хранилище.
Что делать, если в старой ERP данные в плохом состоянии?
Очищать, к сожалению, других вариантов нет. Можно нанять временную команду, можно использовать автоматизированные инструменты, но переносить «грязные» данные в новую систему не имеет практического смысла (будут те же проблемы, но на новом технологическом стеке).
Можно ли перенести данные без остановки работы бизнеса?
Да, если использовать инструменты синхронизации (и с временными ограничениями некоторых бизнес-процессов). На рынке есть решения, которые позволяют проводить миграцию критически важных ERP-систем по методологии Parallel Running без остановки бизнес-процессов, но даже с такими инструментами нужен период, когда данные вводятся в обе системы и сверяются между собой.
Заключение
Если вы только планируете переход на российскую ERP и еще не определились с платформой, посмотрите наш разбор основных вариантов: «Импортозамещение ERP-систем: 1С, Галактика или собственная разработка». А если вы уже в процессе миграции и хотите проверить, не теряются ли данные, — начните с аудита. Это дешевле, чем переделывать проект после запуска.
