Представьте энергетическую систему международной космической станции — это комплекс солнечных батарей, аккумуляторов и другого оборудования. Ее модернизация происходит постепенно. Например, в 2019-2020 годах за пять выходов в открытый космос поменяли никель-водородные батареи на литий-ионные. Никто не будет менять такую систему одномоментно. Во-первых, это технически невозможно, во-вторых, слишком велика цена ошибки. Похожая ситуация с ключевыми корпоративными системами, которые отвечают за жизнеобеспечение бизнеса. 

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

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

В чем сложность замены ERP? 

Во многих компаниях ключевые процессы завязаны на систему, которую разработали 20-30 лет назад. Часто это иностранные системы, производители которых ушли из России в 2022. Или это самописное решение на стеке, в котором сейчас разбирается относительно малое количество специалистов, например, Delphi. Архитектура практически всегда монолитная, функциональность писали под конкретную компанию с учетом особенностей ее работы, логики процессов и т. д. Документации, разумеется, нет. Знакомая ситуация? 

Все понимают, что рано или поздно эту систему придется менять. Хочется упростить поддержку, расширить функциональность, уйти от иностранных технологий, наконец. Но с какой стороны за это взяться? Сложностей много, как технических, так и организационных. 

Бизнес-вызовы: 

• Необходимо обеспечить непрерывность процессов. Нельзя допустить остановки бизнеса, так как на систему завязаны и обязательства перед клиентами, и экономика компании. 

• Соблюдение сроков и бюджета. Ни одна компания не одобрит проект с бесконечно растянутыми дедлайнами и расплывчатыми суммами. 

Технические вызовы: 

• Монолитная архитектура. Много функциональных модулей работают на одних и тех же сильно связанных данных, трудно выделить «куски» для замены. 

• Много нетривиальной и недокументированной функциональности. Если нужно с точностью перенести функциональность из старой ERP в новую, то подготовка ЧТЗ — сверхсложная задача. 

• Тяжелый и растянутый выход в опытно-промышленную (ОПЭ) и промышленную эксплуатацию (ПЭ). Новая ERP уже написана, но запуск затягивается из-за риска перевода пользователей в нерабочую систему. 

Подходы к замене ERP

Существует два подхода для вывода новой системы в ОПЭ и ПЭ: 

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

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

Разберем каждый подход в деталях. 

Большой взрыв 

Этапы замены ERP по методологии Большого взрыва линейны и понятны: 

• Написание ЧТЗ, проектирование системы

• Разработка и тестирование

• Сдача системы заказчику, ПМИ/ПСИ/UAT

• Миграция данных 

• ОПЭ 

• Выход в ПЭ 

Какие могут возникнуть сложности? 

Во-первых, проектирование системы на этапе написание ЧТЗ. По сути надо повторить функциональность существующей ERP.  Документации часто нет или она не полная, опрос ключевых пользователей и даже реверс-инжиниринг не дают 100% гарантии, что вы «угадали» как старая система работает внутри, например, рассчитывает стоимость оказываемых услуг.  Заказчик понимает, что идти в ОПЭ с такой системой через Большой Взрыв не позволительный риск и как результат процесс написания и согласования ЧТЗ максимально растянут, а само ЧТЗ отяжелено избыточными функциональными требования, ведь права на ошибку при выходе в ОПЭ нет.  

Во-вторых, момент истины, вывод в ОПЭ. После выхода в ОПЭ открывается «ящик пандоры» начинается шквал ЗНИ и гнева бизнес-пользователей. Сроки на доведения системы до ума сверх сжатые (1-2 недели). Если за это время не удается все исправить, то придется вернуться к старой системе. Но новая система какое-то время работала, в ней завели какие-то документы, начали какие-то процессы. Чтобы ничего не потерять, требуется обратная миграция, это еще несколько дней до возвращения пользователей к полноценной работе. А теперь представим, что успешно пройти ОПЭ удалось не со второго раза, а с третьего или с четвертого, ведь учесть все нюансы каждой операции в крупномасштабной системе, которая развивалась 20+ лет и по которой мало документации, просто нереально. 

Parallel Running 

Архитектура  Parallel Running базируется на компоненте «Модуль синхронизации и мониторинг консистентности», который в режиме реального времени синхронизирует данные. 

Процесс замены ERP по методологии Parallel Running идет помодульно и сочетает подходы Waterfall и Agile.  

Основные этапы: 

• Весь проект разбивается на модули со своими сроками по разработке, выводу в ОПЭ и командой.

• Разработка каждого модуля начинается со стадии MVP (идет по Waterfall).

• Перед выходом в ОПЭ настраивается репликация данных.

• После выхода в ОПЭ переходим на Agile (работа спринтами по ЗНИ).

Процесс представлен на рисунке ниже.   

Что происходит при использовании Parallel Running? 

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

Для эффективного использования бюджета и снижения time-to-market пишется ЧТЗ на минимальный функциональный объем, максимально быстро проверяется его работоспособность в реальных условиях и дальше 2-3 недельными спринтами доводится до необходимой функциональной полноты.  

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

Технические сложности при Parallel Running

Главный вызов при Parallel Running — как технически реализовать репликацию данных между системами. Сложностей много. 

• Сложный маппинг. Схема новой и старой БД может заметно различаться. Например, текстовому полю в старой БД может соответствовать несколько таблиц в новой БД.  

• Сложности поиска изменений в БД (так называемый CDC).   

• Запрет на внесение изменений в схему старой БД.  

• Устаревшие RDBMS, такие как Sybase, Informix, IBM AS400, Btrieve etc. для которых нет готовых коннекторов для поиска изменений через чтения журнала транзакций.

• Конфликты репликации. Так как данные модифицируются и в старой и в новой системе возникают случаи, когда найденное изменение не может быть записано в БД назначения, например, из-за ошибки «constraint violation». Требуется наличие специального механизма разрешения таких ситуаций. 

• Необходимость частичной репликации/«перезаливки» части данных в случае сбоя или ошибки маппинга.    

Для решения вышеописанных проблем мы в Хоулмонт разработали свой сервис xDbStream для универсальной синхронизации БД любого типа. Его основные компоненты:

Сервер для однонаправленной отложенной репликации между БД различного типа, который  позволяет настраивать потоки репликации (создание, изменение, удаление).

Система предоставляет пользователю:  

• Выбирать способ поиска изменений: чтения журналов транзакций, сканирование по меткам времени, сравнение образов, обработка событий \триггеров.

• Выбирать способ маппинга, включая поддержку сложного маппинга через Groovy Script или вызов Custom service.

• Выбрать поход: репликация плоских таблиц, графов объектов, N:M связей и т.д.

• Мониторить производительность.

• Обнаруживать и разрешать конфликты репликации.  

• Синхронизировать только часть данных в случае сбоев.

Мониторинг консистентности данных.

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

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

Это решение мы использовали на проектах британских компаний (служба такси, агентство по обслуживанию недвижимости, коллекторское агентство), а также в крупной российской компании, которая занимается грузовыми ЖД-перевозками (все имена под NDA). 

Плюсы и минусы подходов, выводы 

Вернемся к сравнению Большого взрыва и Parallel Running, для наглядности — плюсы и минусы подходов в одной таблице. 

Таким образом, Parallel Running лучше использовать, если:  

• Трудно гарантировать, что ЧТЗ точно и полно опишет все функциональные требования.

• Важна высокая отказоустойчивость.

• Система или отдельный модуль критичны для обеспечения непрерывности бизнеса.

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

В остальных случаях лучше не усложнять и использовать Большой взрыв. 

Больше о компании Haulmont и наших проектах в Telegram и на сайте. Подписывайтесь, чтобы не пропустить новые материалы!