Переход с зарубежной платформы

Уровень международных ECM — на российском стеке, без вендор-лока

Задумались об импортозамещении ECM? Получите привычный уровень функциональности из коробки — на платформе того же класса, локализованной и развиваемой в России. Без функционального регресса и без вендор-лока.

Основной класс заявки в реестр российского ПО — 10.04 «Средства управления информационными ресурсами и средства управления основными данными (ECM, MDM)».

Дилемма

Система работает, но инвестировать в её развитие кажется уже неправильным

В крупных компаниях зарубежная ECM обычно не «сломалась». Наоборот: в неё вложены годы и десятки человеко-лет доработок, российское делопроизводство доведено до состояния, к которому люди привыкли и которое их устраивает. Вопрос не в том, работает ли система. Вопрос в том, куда вкладывать следующие деньги.

A

Остаться

Продолжать вкладывать в платформу, у которой нет обновлений, поддержки и возможности расширять лицензии. Функционально всё работает — но каждый следующий рубль идёт в актив без перспективы.

B

Перейти на систему попроще

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

C

Перейти на платформу того же класса

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

Наш тезис. Привычный уровень функциональности вы получаете из коробки, без нового многолетнего цикла доработок. Дальнейшее развитие идёт настройкой в low-code Studio, с ИИ-контуром внутри вашего периметра. Открытый код, понятная модель лицензирования, никакого вендор-лока.

Чтобы это не осталось обещанием, разговор начинается с сопоставления периметров: мы раскладываем вашу текущую функциональность на то, что закрывается коробкой, что настраивается в Studio и что требует разработки. Этот разбор вы получаете до того, как принимаете решение, и он остаётся у вас независимо от того, чем закончится разговор.

Контекст

Что при этом происходит вокруг системы

Функциональность осталась, а вот условия эксплуатации изменились — и это то, что придётся объяснять службе информационной безопасности и регулятору.

1

Обновления недоступны

Патчи безопасности и новые версии не приходят. Со временем это перестаёт быть вопросом удобства и становится вопросом информационной безопасности.

2

Поддержка недоступна

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

3

Лицензии не расширить

Добавить пользователей или продлить подписку невозможно: рост бизнеса упирается в лицензионный потолок.

4

Требование регулятора

Директива на импортозамещение с конкретным сроком, а целевая система должна быть в реестре российского ПО.

Что важно при выборе

Замена должна быть того же класса

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

КритерийЗарубежная ECM в текущих условияхСЭД, выросшая из канцелярииРуксео
Класс решенияECM-платформаСЭД с надстройкамиECM-платформа
Обновления и поддержкаНедоступны в РоссииЕстьЕсть, разработка и сопровождение в России
Реестр российского ПОНетКак правило даЗаявка подана, класс 10.04 (ECM, MDM)
Лицензия на платформуОтдельная и дорогаяВходит в стоимость продуктаНе взимается: ядро под Apache 2.0
Настройка без вендораЧерез партнёра и вендорские инструментыОграниченнаяСобственная low-code Studio
Серверные лицензииКак правило по ядрам и узламЧасто естьНет: серверы и ядра не лицензируются
ИИ-контурКак правило облачный, вне периметраОбычно отсутствуетВ закрытом контуре, на ваших серверах
Стоимость измененийДоработка через партнёра и вендорские инструментыДоработка под возможности системыВ основном настройка в Studio; ИИ-помощник конфигуратора — в развитии

Сравнение носит позиционный характер и описывает классы решений и типовые условия поставки. Формального тестирования конкретных продуктов за ним не стоит.

Как переходят

Переход разбит на этапы с проверяемым результатом

Наша команда пришла из проектов внедрения тяжёлых ECM в холдингах и переносит не только документы, но и логику работы, которую вы уже выстроили.

Шаг 1

Обследование

Инвентаризация типов документов, метаданных, прав, маршрутов и интеграций действующей системы. На выходе — карта переноса и оценка объёма работ.

Шаг 2

Модель в Studio

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

Шаг 3

Перенос контента

Загрузка документов, версий и метаданных через API платформы, с сохранением связей и контрольной сверкой объёмов.

Шаг 4

Параллельная работа

Период сосуществования систем, приёмочные сценарии на демо-стенде, обучение и постепенное переключение подразделений.

Что мы не обещаем. Универсальной «кнопки миграции» не существует: объём и сроки зависят от состояния исходной системы, качества метаданных и числа кастомизаций. Мы даём оценку после обследования и проверяем перенос на пилотном срезе данных до начала основных работ.

Как устроено сосуществование двух систем — этапы, зеркальные потоки, перенос подписей и регистрационных номеров — разбираем подробно на странице «Переход с действующей ECM».

Частые вопросы

Что спрашивают при переходе

Мы вложили годы доработок. Они пропадут?

Пропадёт код, но не логика. Переносим мы то, что доработки реализуют: типы документов, атрибуты, справочники, права, маршруты и правила регистрации. В Руксео это в основном конфигурация в Studio, поэтому и дальнейшие изменения не потребуют нового цикла разработки. Что именно закрывается коробкой и настройкой, а что всё же потребует разработки, показывает сопоставление периметров на старте.

Вы переносите только документы или процессы тоже?

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

У нас платформа другой архитектуры. Насколько это усложняет переход?

Перенос идёт через сопоставление типов документов, метаданных и прав — это стандартная проектная работа. Разница в архитектуре меняет объём сопоставления; на принципиальную выполнимость она не влияет. Гипотезу переноса мы проверяем на пилотном срезе данных до основных работ.

Сколько времени занимает переход?

Честный ответ — зависит от объёма и числа кастомизаций, поэтому мы не называем срок до обследования. Практика проектов такого класса — от нескольких месяцев для одного контура до поэтапной программы на год-полтора для холдинга целиком.

Что с документами, которые уже подписаны электронной подписью?

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

Не меняем ли мы один вендор-лок на другой?

Ядро платформы открыто (Apache 2.0), форматы хранения открыты, данные извлекаемы штатными средствами. Настройки живут в конфигураторе и остаются вашими. Мы не лицензируем серверы и процессорные ядра, а купленные лицензии бессрочны и продолжают работать без действующей поддержки.

Первым делом — обследование

Посмотрим на вашу действующую систему, оценим объём переноса и покажем целевую модель на демо-стенде. Формат — рабочая сессия с вашими архитекторами.