Переход с SAP или Oracle на кастомную ERP-систему — это не только замена одной платформы на другую. В такой проект входят аудит текущих процессов, анализ доработок, перенос данных ERP, восстановление бизнес-логики, настройка интеграций и постепенный запуск новой системы без остановки ключевых операций.
Чаще всего сложность возникает не на этапе разработки, а раньше: когда нужно понять, какие процессы действительно должны быть перенесены, какие данные нужно очистить, какие правила уже устарели, а какие критичны для работы компании. Ошибка на этом этапе может привести к потере истории, сбоям в отчетности, дублированию процессов или длительному простою.
В статье разберем, как подготовиться к миграции с SAP или Oracle, когда кастомная ERP может быть более подходящим вариантом, чем типовая система, как проходит перенос данных в ERP, что делать с историческими данными и бизнес-логикой, и как организовать переход поэтапно, чтобы снизить риски для бизнеса.
В чём главная сложность миграции с SAP/Oracle
При переходе с SAP или Oracle на новую ERP-систему основная сложность обычно связана не с разработкой интерфейсов, модулей или отчетов. Это важная часть проекта, но не самая рискованная. Критичнее другое: корректно перенести данные, сохранить бизнес-логику и не нарушить процессы, которые уже работают внутри компании.
За годы использования SAP или Oracle ERP-система часто становится не просто учетным инструментом, а центральным контуром управления бизнесом. В ней хранятся справочники, договоры, заказы, остатки, финансовые операции, производственные маршруты, правила согласования, роли пользователей, настройки отчетности и интеграции с другими системами. Часть логики может быть описана в документации, часть — реализована в доработках, а часть — фактически существовать только в привычных действиях сотрудников.
Поэтому миграция с SAP начинается с детального разбора текущей системы: какие модули используются, какие данные критичны, где есть кастомные доработки, какие интеграции завязаны на ERP и какие процессы нельзя останавливать даже на короткое время. Без этого новая система может формально повторить структуру старой, но не поддержать реальные сценарии работы бизнеса.
Отдельный риск — перенос данных ERP без очистки и проверки. В старой системе могут быть дубли справочников, устаревшие статусы, неиспользуемые поля, исторические записи с разной структурой, ручные обходные решения и данные из модулей, которые уже давно не применяются. Если просто перенести все как есть, новая ERP унаследует старые проблемы, а иногда усилит их.
Почему не всегда достаточно перейти на 1С
После SAP или Oracle многие компании в первую очередь смотрят на 1С. Это логично: платформа распространена, под нее проще найти специалистов, а типовые конфигурации закрывают бухгалтерию, склад, закупки, продажи, кадры и часть производственных процессов.
Но 1С хорошо работает там, где процессы близки к типовым. Если же в SAP или Oracle годами накапливались доработки, нестандартные согласования, сложные правила расчета, специфичные роли пользователей и интеграции с внутренними или внешними системами, прямой переход на 1С уже не выглядит простым.
В такой ситуации компания часто получает не «быструю замену ERP», а новый проект кастомизации. Нужно переносить бизнес-логику, переписывать интеграции, адаптировать интерфейсы, дорабатывать модули и следить, чтобы новые ограничения платформы не ломали привычные процессы.
Поэтому вопрос не в том, что лучше — 1С или кастомная ERP. Вопрос в том, насколько стандартная система подходит под реальную работу компании. Если процессы можно привести к типовой модели, 1С может быть разумным вариантом. Если бизнес держится на сложной логике, уникальных интеграциях и собственных правилах управления, стоит рассматривать кастомную ERP как более гибкий сценарий перехода.
SAP vs Oracle vs 1С vs кастомная ERP: что выбрать
Универсального ответа здесь нет. SAP, Oracle, 1С и кастомная ERP решают похожие задачи, но подходят для разных условий. Поэтому сравнение 1С и SAP или выбор между Oracle и собственной системой нужно начинать не с названия платформы, а с процессов, которые она должна поддерживать.
| Вариант | Когда подходит | Где могут быть ограничения |
| SAP | Крупные компании, холдинги, производственные и логистические предприятия, международные структуры со сложной отчетностью и большим количеством процессов. | Высокая стоимость поддержки, зависимость от специалистов, сложность доработок и миграции, особенно при большом количестве кастомной логики. |
| Oracle ERP | Компании с развитой финансовой, закупочной, проектной или корпоративной ИТ-инфраструктурой, где важны масштабируемость, аналитика и интеграция с другими Oracle-продуктами. | Сложность внедрения и сопровождения, высокая стоимость владения, зависимость от архитектуры и лицензирования. |
| 1С | Бизнес с типовыми процессами учета, продаж, закупок, склада, кадров, бухгалтерии и производства. Часто выбирается как более доступная альтернатива при отказе от зарубежных ERP. | При сложной бизнес-логике, нестандартных согласованиях и уникальных интеграциях может потребоваться много доработок. |
| Кастомная ERP | Компании, которым нужно сохранить собственную логику управления, интеграции, роли, отчеты и процессы, не подстраивая бизнес под ограничения типовой системы. | Требует детального аудита, проектирования и поэтапной разработки. Такой вариант не всегда быстрее на старте, но может быть устойчивее при сложной архитектуре. |
SAP vs Oracle vs 1С vs кастомная ERP
Этапы перехода: от аудита до полного запуска
Переход с SAP или Oracle на кастомную ERP не стоит начинать с разработки отдельных модулей. Сначала нужно понять, как сейчас работает система, какие процессы нельзя остановить, какие данные нужно перенести и где старая ERP связана с другими сервисами. Поэтому миграция обычно проходит поэтапно: от аудита и проектирования до параллельного запуска и полного перехода.
Аудит текущей системы
На первом этапе команда разбирает, как устроена текущая SAP или Oracle ERP: какие модули используются, какие доработки были сделаны, какие отчеты нужны бизнесу, какие роли настроены и с какими системами есть интеграции.
В работе участвуют бизнес-аналитик, системный архитектор, ERP-консультант, ИТ-команда клиента и представители ключевых подразделений. Их задача — отделить критичные процессы от устаревших сценариев, которые не нужно переносить в новую систему.
Проектирование новой ERP
После аудита формируется архитектура будущей ERP: модули, структура данных, роли пользователей, права доступа, интеграции, требования к отчетности и производительности.
На этом этапе подключаются архитектор, бизнес-аналитик, тимлид, UX/UI-специалист и технические специалисты со стороны клиента. Важно не просто повторить старую систему, а сохранить рабочую бизнес-логику без лишних ограничений и накопленных проблем.
Подготовка и перенос данных
Перед переносом данные нужно проверить: найти дубли, устаревшие записи, неиспользуемые поля, разные форматы справочников и документы с неполной историей. Затем команда описывает правила миграции, настраивает маппинг полей и выполняет тестовый перенос данных ERP.
В этом этапе участвуют дата инженеры, бэкенд-разработчики, QA-инженеры и бизнес-пользователи, которые помогают сверять результат. Без такой проверки перенос данных в ERP может привести к ошибкам в остатках, заказах, отчетах или финансовых операциях.
Разработка модулей и интеграций
Когда структура данных и логика согласованы, начинается разработка новой ERP. Команда создает нужные модули, интерфейсы, роли, отчеты и интеграции с CRM, MES, BI, складскими, финансовыми, производственными и внешними системами.
Здесь работают бэкенд- и фронтенд-разработчики, интеграционный инженер, DevOps, QA и архитектор. Отдельное внимание уделяется тем связям, которые напрямую влияют на ежедневные операции: продажи, закупки, производство, склад, финансы и управленческую отчетность.
Параллельный запуск
На этом этапе старая и новая системы работают одновременно. Это нужно, чтобы сравнить данные, проверить реальные бизнес-сценарии, обучить пользователей и исправить расхождения до полного перехода.
В гибридный период участвуют проектный менеджер, QA-команда, разработчики, бизнес-аналитик, ключевые пользователи и служба поддержки. Такой формат снижает риск простоя: компания продолжает работать в привычном контуре, пока новая ERP проходит проверку на реальных процессах.
Полный переход
После финальной сверки компания переводит основные процессы в новую ERP. Старую систему можно отключить полностью или оставить в режиме чтения, если нужен доступ к архивным документам, отчетам и истории операций.
На этом этапе важно не только запустить систему, но и передать ее в поддержку: настроить мониторинг, регламенты обновлений, обработку инцидентов и дальнейшее развитие модулей.
Как минимизировать простой бизнеса при миграции
Полностью исключить риски при переходе с SAP или Oracle невозможно, но простой можно сильно сократить, если не переносить всю систему за один раз. Более безопасный подход — двигаться по модулям и запускать новую ERP постепенно.
Сначала команда определяет процессы, которые критичны для ежедневной работы: продажи, закупки, склад, производство, финансы, отчетность. Для них заранее готовятся сценарии переключения, резервные варианты и правила отката, если на этапе запуска появятся ошибки.
Чаще всего используется параллельная работа систем. Старая ERP остается рабочей, а новые модули запускаются рядом с ней: команда сверяет данные, проверяет операции, сравнивает отчеты и отслеживает расхождения. Такой гибридный период помогает увидеть проблемы до того, как новая система станет основной.
Еще один способ снизить простой — поэтапный перенос модулей. Например, сначала можно перевести справочники и часть отчетности, затем склад или закупки, после этого финансы, производство и другие критичные контуры. Так бизнес продолжает работать, а команда получает время на проверку каждого этапа.
Что происходит с историческими данными и бизнес-логикой
Исторические данные не переносят в новую ERP автоматически. Сначала команда определяет, что нужно для ежедневной работы, что важно оставить для отчетности и аудита, а что уже устарело и может остаться в архиве.
Обычно в рабочую систему переносят справочники, открытые заказы, остатки, активные договоры, незакрытые финансовые операции и данные, которые влияют на текущие процессы. Перед переносом их очищают от дублей, устаревших записей, ошибок заполнения и разных форматов.
Отдельно готовится маппинг данных: какие поля из SAP или Oracle переходят в новую ERP, как они преобразуются и как обрабатываются неполные или конфликтующие записи. После тестовой миграции данные сверяются по остаткам, суммам, статусам, документам, отчетам и правам доступа.
С бизнес-логикой работа идет отдельно. Нужно зафиксировать правила согласования, расчета цен, резервирования товаров, закрытия периода, формирования заказов и обработки исключений. Часть логики переносится без изменений, часть упрощается, а часть не стоит повторять, если она появилась как временное обходное решение.
Главная цель — не скопировать старую ERP в новом интерфейсе, а сохранить критичные процессы, очистить данные и не перенести в новую систему накопленные ошибки.
Сколько времени и денег занимает переход
Сроки и бюджет зависят от масштаба системы: количества модулей, объема данных, интеграций и сложности бизнес-логики.
Небольшой проект может занять 3-6 месяцев, переход для среднего бизнеса — 6-12 месяцев, миграция крупного предприятия с филиалами, производством и большим числом интеграций — 12-24 месяца и больше.
Точную оценку можно дать только после аудита. Экономить на анализе, переносе данных и тестировании рискованно: ошибки миграции и простой бизнеса обычно обходятся дороже подготовки.
Наш подход к переходу с SAP/Oracle
В СКЭНД мы не начинаем проект с обещания быстро заменить SAP или Oracle новой ERP. Наша команда сначала разбирает текущие процессы, данные, доработки и интеграции, затем проектирует новую ERP-архитектуру и только после этого переходит к разработке, миграции и запуску.
После аудита мы формируем сценарий миграции: что переносить в новую систему, что оставить в архиве, какие модули запускать первыми и где нужен гибридный период. Такой подход снижает риск простоя и помогает не перенести в новую ERP старые ошибки и лишнюю сложность.
СКЭНД помогает с аудитом текущей системы, проектированием архитектуры, разработкой кастомных модулей, переносом данных, интеграциями и запуском ERP. Эти задачи входят в наш подход к разработке и интеграции ERP-систем.
Если вы планируете переход с SAP или Oracle, начните с оценки текущей системы. Это покажет, какой сценарий миграции будет безопасным именно для вашего бизнеса.
Часто задаваемые вопросы (FAQ)
Можно ли начать миграцию, если еще нет четкого технического задания?
Да. На старте достаточно понимать, какие проблемы есть в текущей SAP или Oracle ERP и какие процессы нужно сохранить. Техническое задание обычно формируется после аудита: когда команда уже видит данные, интеграции, доработки и реальные сценарии работы.
Что делать с сотрудниками, которые привыкли к интерфейсу SAP/Oracle?
Лучше не менять все резко. Обычно для ключевых пользователей проводят демо, обучение и параллельную работу в старой и новой системе. Часть привычной логики можно сохранить в интерфейсе, если она действительно помогает работать быстрее.
Кто останется владельцем кода и данных после перехода?
В кастомной ERP код, данные и документация остаются у заказчика, если это зафиксировано в договоре. Это одно из отличий от закрытых платформ: компания не зависит от лицензий и может дальше развивать систему с выбранной командой.
Можно ли мигрировать только часть модулей, а не всю систему сразу?
Да, и часто это самый безопасный вариант. Например, сначала можно перенести справочники, склад или отчетность, а финансы и производство оставить на следующий этап. Такой подход снижает риски и упрощает проверку данных.
Как перенести данные из УПП или другой конфигурации 1С в новую ERP?
Принцип похож на миграцию из SAP или Oracle: сначала анализируются структура базы, справочники, документы, остатки, связи и правила учета. Затем готовится маппинг, выполняется тестовый перенос данных в ERP и сверка с бизнес-пользователями.