Миграция ERP-систем без риска: как уложиться в сроки и в бюджет

Многие компании задумываются о замене ERP, поскольку их системы внедрены 20-30 лет назад и сейчас уже устарели. К тому же часто это иностранные продукты, производители которых ушли с российского рынка. Необходимость замены понимают все, но сложно решиться на запуск масштабного проекта. Чтобы уложиться в сроки и в бюджет, важно правильно выбрать методологию замены ERP. В этой статье разберем, какие подходы существуют, чем они отличаются и для каких проектов подходят.

Почему нужна модернизация ERP

Срок службы корпоративного ПО, в том числе ERP, не бесконечен — в среднем он составляет примерно 10 лет. После этого поддерживать систему становится все сложнее, начинает накапливаться технический долг. Если ERP старше трех лет, то каждый год стоимость владения увеличивается примерно на 15-20%. Добавим сюда еще фактор «черных лебедей». Многие компании выстраивали ИТ-стратегию вокруг сотрудничества с мировыми лидерами на рынке корпоративного ПО, но буквально в течение одного года они ушли из России. Парадоксальным образом разработка новой ERP с нуля обойдется в 3-4 раза дешевле, чем поддержка устаревшей системы. За счет чего бизнес получит экономический эффект:

• Упрощение поддержки и развития

Устаревшие ERP часто имеют монолитную архитектуру. Функциональные блоки сильно связаны между собой, каждое изменение затрагивают всю систему. Переход на модульную или микросервисную архитектуру упрощает поддержку и развитие.

• Снижение затрат на команду

В устаревших ERP используются относительно редкие технологии, например, Delphi. Специалистов, которые в них разбираются, на рынке сравнительно немного. За счет перехода на актуальный стек подбор команды станет проще и дешевле.

• Технологическая независимость

Производители иностранных систем ушли с российского рынка, поэтому сложно продлить лицензии, провести масштабирование или получить поддержку. Переход на российское ПО решает эту проблему.

Несмотря на потенциальные выгоды, многие компании не торопятся менять ERP, поскольку это сопряжено со множеством сложностей.

Вызовы проектов по замене ERP

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

• Система должна быть доступна 24/7. Остановка на время техобслуживания — недопустимая роскошь для бизнеса. Несколько часов простоя может привести к многомиллионным потерям.
• Важно уложиться в сроки и бюджет, при этом на старте сложно оценить объем работ и количество подводных камней.
• За годы развития ERP обрастает сложной функциональностью, разветвленными процессами и уникальной логикой. При этом документации часто нет или она неполная.
• В случае монолитной архитектуры трудно выделить функциональные блоки для замены.
• Нельзя рисковать, отключать старую систему и переводить пользователей в новую, если есть хотя бы малейшая вероятность сбоя.

Грамотный выбор подхода к замене ERP поможет обойти эти сложности.

Два подхода к замене ERP

Подход к замене ERP определяет, как происходит запуск в эксплуатацию, каким образом в новую систему переводятся данные, процессы и пользователи. Существует два варианта:

1. Большой взрыв. В этом случае запуск новой ERP в эксплуатацию происходит одномоментно. Пользователи начинают работать в новой системе, старая система, по сути, замораживается.
2. Parallel running. В этом случае в период опытно-промышленной эксплуатации старая и новая ERP функционируют параллельно на логически едином наборе данных. Можно сказать, что системы страхуют друг друга.

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

Особенности Большого взрыва

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

Этапы работы по методологии Большого взрыва:

• Подготовка ЧТЗ и проектирование системы
• Разработка и тестирование
• Демонстрация системы заказчику, приемочные испытания
• Перенос данных из старой системы
• Выход в ОПЭ
• Переход в ПЭ

Сложности могут возникнуть, прежде всего, на этапах подготовки ЧТЗ и вывода в ОПЭ. В чем они заключаются?

• Подготовка ЧТЗ и проектирование системы усложняется отсутствием документации. Опрос ключевых пользователей и реверс-инжиниринг старой ERP не гарантируют точность ЧТЗ. Существует риск, что логика работы системы будет реализована неправильно, поэтому подготовка и согласование документации затягивается. И даже с учетом этого после выхода в ОПЭ могут быть обнаружены ошибки.
• Рискованно запускать в ОПЭ всю функциональность масштабной системы одновременно. Большое количество ЗНИ и пожеланий от пользователей неизбежно, на их отработку дается 1-2 недели. Высока вероятность возврата к старой системе, но поскольку в новой уже были заведены данные и начаты процессы, на обратную миграцию потребуется время. Это потенциальный риск простоя для бизнеса.

Особенности Parallel running

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

Этапы работы по методологии Parallel running:

• Проект делится на модули, у каждого отдельная команда, свои сроки разработки и вывода в ОПЭ
• Разработка каждого модуля начинается со стадии MVP и проходит по Waterfall
• Перед выходом в ОПЭ настраивается репликация данных
• После выхода в ОПЭ происходит переход на Agile, по спринтам отрабатываются ЗНИ
• Выход в ПЭ

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

Parallel running помогает обойти сложности, возникающие при подготовке ЧТЗ и запуске в ОПЭ.

• Для каждого модуля готовится ЧТЗ по минимальному набору функциональности. Работоспособность системы проверяется при запуске в ОПЭ, доработки вносятся 2-3 недельными спринтами. Это позволяет не тратить много времени на подготовку документации, быстро проверить работоспособность системы в реальных условиях и в разумный срок выполнить все ЗНИ. В результате снижается time-to-market, бюджет расходуется максимально эффективно.
• Синхронизация двух систем обеспечивает полный контроль при запуске в ОПЭ. В случае сбоя можно легко вернуться в старую ERP, не нужно будет тратить время на перенос данных. Риск простоя сводится к нулю.

Основная сложность при Parallel running — техническая реализация модуля синхронизации и мониторинга консистентности.

Технические вызовы при использовании Parallel running

В старых ERP часто используются устаревшие системы управления реляционными базами данных (Sybase, Informix, IBM AS400 или Btrieve), тогда как в новых — современные СУБД (Postgres Pro, PostgreSQL, MS SQL, Oracle). Из-за этого не получится воспользоваться готовыми и простыми решениями.

• Схемы старой и новой БД различаются. Так как схему старой БД изменить невозможно, требуется сложный маппинг.
• Сложный поиск изменений в БД обычно выполняется при помощи технологии Change Data Capture (CDC).
• Нет готовых коннекторов для поиска изменений через чтение журнала транзакций, для каждого случая требуется уникальный подход.
• Конфликты при репликации данных неизбежны. Необходим механизм для их разрешения.
• При сбое или ошибке маппинга требуется «перезаливка» данных. Механизм выборочной загрузки данных позволит обойтись без повторной репликации всей БД.

Подход Хоулмонт к Parallel Running

Чтобы обойти сложности, мы в Хоулмонт разработали собственный инструмент xDbStream. Он содержит два компонента:

1. Сервер для однонаправленной отложенной репликации между БД различного типа

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

Способы поиска изменений: чтение журналов транзакций, сканирование по меткам времени, сравнение образов, обработка событий/триггеров.

Способы маппинга: простой SQL, мощные Groovy-скрипты, вызовы внешних сервисов для преобразования данных «на лету».

Подходы к репликации данных: репликация простых таблиц, сложных графов, M:N связей и т. д.

2. Модуль мониторинга консистентности данных

Его задача — в режиме реального времени выявлять расхождения между БД с возможностью настройки параметров. Эту функциональность можно использовать независимо от сервера репликации.

С помощью xDbStream можно провести начальную миграцию данных, а также обеспечивать их консистентность в дальнейшем.

Когда использовать Большой взрыв, когда — Parallel running

Большой взрыв — это методологически и технологически простой и понятный подход. Вчера пользователи работали в старой системе, сегодня — уже в новой. Просто так откатить к тому, что было, не получится. Это рискованный подход, но очень эффективный, если все сделано правильно.

Parallel running требует дополнительного инструментария для синхронизации систем, а также команды с сильной экспертизой. Однако он позволяет съесть слона по кусочкам — без лишнего напряжения запускать модуля по готовности, а также снизить time-to-market для всей системы.

В каком случае какой подход подойдет лучше — в таблице.

Parallel running позволяет провести управляемую замену критически важной ERP в сложных условиях. При поэтапном запуске модулей без отключения старой системы можно быстро продемонстрировать результат, при этом без риска для рабочих процессов. Как показывает практика, инвестиции в безопасную миграцию многократно окупаются. Команда Хоулмонт готова выполнить проект замены ERP любой сложности. Чтобы обсудить вашу задачу, свяжитесь с нами.