Недавно мы перешли на новую версию платформы электронного документооборота Extended ECM by OpenText 21.3. Перевод осуществлялся сразу через несколько версий с v.10.5. Мы сделали это in-housе, не прибегая к помощи вендора. Cилами внутренней команды специалистов Х5 Tech мы мигрировали на современную версию платформы и критически пересмотрели системную архитектуру решения. Для демонстрации результатов мы реализовали прототип одного из процессов по подходу Lowcode за одну рабочую неделю. Мы решили поделиться с Хабром своим опытом, так как считаем, что это может быть полезно и другим компаниям, перед которыми стоит та же задача.

Почему мы решили перейти на новую систему электронного документооборота (СЭД)

Предыдущая версия системы внедрялась в компании в 2015 году, поэтому, очевидно, что за 7 лет она морально устарела по всем параметрам. Мало того, что закончилась вендорская поддержка нашей версии самой платформы xECM, так уже и версии операционных систем и ПО окружения снимались с поддержки вендорами. Поэтому команде нашей инфраструктуры становилось всё сложнее и дороже обеспечивать бесперебойную эксплуатацию со своей стороны.

Интерфейсы, спроектированные столь давно, явно требовали пересмотра с учётом текущих тенденций в UI/UX и примеров смежных систем. Технологический стэк смотрелся всё менее привлекательно для команды разработки, и находить новые кадры становилось всё сложнее. Плюс ко всему, требования заказчиков по снижению показателя TimeToMarket заставляли задумываться о кардинальных решениях.

Мы собирали мнения пользователей, подразделений, ответственных за инфраструктуру и безопасность, и пришли к выводу, что необходимо развивать и менять систему в следующих направлениях:

• улучшить возможности и удобство использования: сделать интуитивно понятный интерфейс, модули и компоненты системы, удобные в использовании, совершенствовать UI/UX для интерфейса до современных стандартов, внедрить адаптивную вёрстку для использования на планшетных устройствах;

• усилить информационную безопасность: защиту информации от внешних и внутренних угроз;

• перейти на современное программное окружение для больших возможностей, снизить риски выхода системы из строя;

• перейти на современное окружение – операционные системы, СУБД, компоненты окружения.

Что у нас получилось сделать

Решение Extended ECM by OpenText в компании Х5 Group – одно из самых крупных внедрений не только в стране, но и в галактике за её пределами. Ведь системой в компании ежегодно пользуются десятки тысяч пользователей. Хоть это и вендорский продукт Enterprise уровня, наша внутренняя экспертиза позволила нам самостоятельно и относительно быстро для проектов такого масштаба осуществить переход – мы справились за 10 месяцев. В этот срок мы уложились несмотря на известные проблемы с поставками оборудования (нам даже пришлось брать железо в долг у других проектов).

Новая версия даёт ряд преимуществ, отвечающих практически всем потребностям компании, которые традиционно предлагаются в ECM-системах подобного класса. Если сравнивать с предыдущей версией, то появились новые возможности для развития бизнеса и самой платформы. Например, большая скорость за счёт новых технологий кластерных решений, интеграционные потоки, встроенный нативный поток с SAP. И принцип потока API – там более расширенные протоколы используются, которые позволяют более гибко и быстро настраивать интеграцию.

Не забыли и про плюсы для пользователей. Это современный плиточный интерфейс, он настраивается полностью под потребности пользователя: например, можно вывести на экран нужные графики, настроить виды и пр. И если проваливаться в конкретный функционал, он тоже современный и интуитивно понятный. Не нужно гадать, все кнопки понятные.

Также появился новый инструментарий по настройке фона, в том числе с использованием встроенного движка BPM:

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

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

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

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

Сложности, с которыми мы столкнулись

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

За эти годы в системе накопились порядка нескольких десятков терабайт данных, что требовало большое количество времени на перенос. В процессе переноса использовалась стандартная утилита миграции OpenText Archive Center. При первичных тестах переноса данных замеры показали, что для копирования всего массива потребуются три недели.

Такое время, конечно же, никого не устраивало, т.к. при этом серьёзно поехали бы сроки всего проекта миграции и сроки смежных проектов, которые ожидали завершения нашего. Когда мы начали разбирать причины такого большого срока, выяснили, что большую часть времени занимает механизм проверки данных при копировании. Мы сопоставили все варианты, взвесили риски и приняли решение отключить эту опцию.

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

Помимо этого, мы столкнулись с тем, что часть функционала, который мы использовали, вообще ушёл из системы. Как пример – модуль customizationsrt, на основе которого мы переопределяли файлы html. Поэтому нам пришлось полностью разбирать этот функционал в 10.5 и адаптировать его в 21.3.

Ещё мы столкнулись с проблемой трансляции полномочий на подмаршруты маршрута – это был очень хитрый кейс. Он проявлялся, если после пользовательского шага мы проваливались в подмаршрут или выходили из подмаршрута и там был следующий шаг «Процесс». В итоге мы решили проблему реализацией собственного патча обработки шагов и выдачи необходимых разрешений.

Что дальше

Мы получили технически новую платформу с дополнительными возможностями, и сейчас мы работаем над улучшением клиентского пути (CJM), особое внимание уделяя UI\UX нового решения и его гибкости.