Как заменить центральную ИТ-систему в компании: 5 советов для финансового сектора
Представьте ситуацию: центральная система компании, на которой завязана операционная деятельность, создана на базе иностранной платформы. Требуется замена, причем по одному из ключевых процессов есть жесткий законодательный дедлайн. Все корпоративные проекты по цифровизации ведет собственный ИТ-отдел. Как успеть в срок без остановки процессов и даже найти возможности для оптимизации? Эти вопросы возникли у нашего заказчика — крупной российской компании из сферы финансов и страхования (детали под NDA). В статье мы поделимся советами, которые сформировались по итогам реализации проекта.
Почему в финансовом секторе актуальна замена корпоративного ПО
Корпоративные информационные системы, которые автоматизируют операционную деятельность в финансовом секторе, как правило, разрабатываются с учетом потребностей конкретной компании. Долгое время в качестве технологической базы участники рынка выбирали иностранные платформы, но сейчас пришло время перехода на российское программное обеспечение. Tadviser отмечает, что на 2025 год 64% российских компаний начали процесс импортозамещения. От замены менее критичных бэк-офисных решений рынок переходит к замене центральных систем.
Готовые продукты хорошо справляются с автоматизацией внутри четко очерченной области: документооборот, финансовый учет, бухгалтерия, управление взаимоотношениями с клиентами и т. д. Однако в случае корпоративных систем, которые объединяют широкий набор функций, оптимальным вариантом часто будет построить свою систему с нуля.
В банках, страховых компаниях и финансовом секторе в целом ИТ-проекты обычно ведет собственная команда. Как организовать ее работу так, чтобы быстро получить результат без лишних затрат?
На основе упомянутого проекта, а также опыта других заказчиков мы выработали 5 советов для замены корпоративного ПО:
- Используйте технологии повышения продуктивности разработки в сочетании с безопасными ИИ-инструментами
- Объедините первый этап проекта с выбором технологий
- Начинайте разработку вместе с партнером и постепенно передавайте задачи своей команде
- Делите проект на модули, в первый модуль выносите первоочередную задачу
- Переиспользуйте функциональность по максимуму
Далее разберем каждый из советов подробнее.
Совет 1. Используйте технологии повышения продуктивности разработки в сочетании с безопасными ИИ-инструментами
При сжатых сроках и большом объеме работы необходимо использовать инструменты повышения эффективности разработки, чтобы быстрее получить результат.
Максимальное ускорение дают код-агенты, большие языковые модели и другие ИИ-инструменты — потенциально они могут повысить скорость до 10 раз. Однако на практике искусственный интеллект усиливает как хорошие практики, так и плохие. Кроме того, в финансовом секторе особенно важно исключить риски и обеспечить соответствие требованиям информационной безопасности, включая ограничение на использование отдельных зарубежных моделей ИИ.
Один из возможных вариантов, как совместить скорость агентной разработки и комплаенс — сочетание ИИ-инструментов и формальных методов. Вероятностная логика ИИ-агентов дополняется формальными методами проверки. Это создает систему двойного контроля: агент генерирует код, а инструменты разработки проверяют его по детерминированным правилам. Разработчик при этом остается в контуре и может контролировать код.
При выборе технологической базы важно учитывать несколько факторов:
- Формальные критерии. Среди них может быть присутствие в реестре российского ПО, лицензия ФСТЭК и другие характеристики.
- Совместимость с корпоративной ИТ-экосистемой. В российских реалиях это часто означает поддержку отечественных ОС, СУБД и другого ПО.
- Баланс скорости, гибкости и безопасности. На практике это означает подбор оптимальной комбинации ИИ, визуального инструментария Low-Code и платформ для разработки без отказа от кода.
- Технологическая независимость. Заказчик должен получить полный исходный код и возможность развивать систему самостоятельно.
- Популярный стек. Чем более распространены технологии, тем проще формировать команду разработчиков для развития и поддержки системы.
- Опыт проектов. Для центральных корпоративных систем важно, чтобы платформа прошла проверку опытом аналогичных проектов.
- Безопасность, архитектура, интеграции. Перед проработкой вариантов необходимо составить список актуальных для компании требований, в том числе к использованию ИИ.
Пример Хоулмонт
Хоулмонт предлагает готовую экосистему для управляемой ИИ-разработки на базе платформы Jmix, ИИ-агентов и среды разработки OpenIDE, которые разворачиваются внутри контура заказчика.
- ИИ-ассистент Jmix помогает разработчикам подготовить спецификацию и ориентироваться в структуре платформы
- Архитектурный шаблон платформы Jmix задает структуру для воспроизведения ИИ-агентом
- Окно терминала для общения с ИИ-агентом встроено в OpenIDE
- MCP протокол OpenIDE обеспечивает проверку кода до этапов сборки
- Плагин Jmix Studio визуализирует промежуточный результат и дополнительно проверяет код проекта
Совет 2. Объедините первый этап проекта с выбором технологий
Рискованно выбирать технологическую платформу «на бумаге», опираясь только на документацию и демонстрации производителей. Гораздо надежнее проверить технологии на практике, то есть начать проект с разработки прототипа. При наличии ресурсов можно разработать несколько прототипов на базе разных технологий и продолжать работу с лучшим. Так финальный этап выбора технологической платформы станет одновременно и первым этапом основного проекта.
Такой подход решает сразу несколько задач:
- Вы проверяете, подходит ли платформа конкретно для ваших целей.
- Прототип становится фундаментом для будущей полномасштабной системы.
- Вы получаете быстрый первый результат, что особенно важно при жестком дедлайне.
Внедрение ИИ-инструментов в разработку также можно начать на стадии прототипа. Для изучения их возможностей лучше сформировать отдельную команду энтузиастов и взять задачу без высокого приоритета.
Чтобы оценить результаты, важно иметь бенчмарк — понять, какой срок разработки ожидается без использования ИИ. Разработка Proof of Concept (PoC) — прототипа для проверки жизнеспособности идеи — при использовании ИИ может занимать 8–10 часов. Создание Minimal Viable Product (MVP) — прототипа, готового к внедрению в реальные процессы — потребует около 3 недель.
Пример Хоулмонт
В проекте для крупной российской компании из сферы финансов на этапе прототипа мы реализовали один процесс и базовые механики системы: авторизацию пользователей, ролевую модель, поиск, фильтрацию данных, справочники. Это также стало финальным этапом выбора подрядчика. В результате первый этап функциональности удалось запустить за 10 месяцев. Также заказчик получил отправную точку для развития архитектуры и интерфейса.
Совет 3. Начинайте разработку вместе с партнером и постепенно передавайте задачи своей команде
Собственный ИТ-отдел — большое преимущество. Внутренняя команда лучше понимает бизнес-процессы, быстрее реагирует на изменения и накапливает экспертизу, которая остается в компании. Однако освоение новой технологической платформы вместе с ИИ-инструментами требует времени.
Оптимальная стратегия — начать разработку вместе с технологическим партнером и наращивать объем работ внутренней команды. В чем преимущества такого формата:
| Скорость реализации проекта | Партнер обеспечивает высокую продуктивность на старте и позволяет уложиться в сроки |
| Обучение в процессе работы | Ваша команда осваивает платформу на реальных задачах проекта |
| Контроль над проектом | Вы владеете исходным кодом системы и следите за каждым этапом разработки |
| Независимость на выходе | По завершении проекта внутренняя команда способна самостоятельно поддерживать и развивать систему |
Важно, чтобы со стороны заказчика подключались как менеджеры и аналитики, так и разработчики.
Пример Хоулмонт
Для быстрого освоения платформы Jmix заказчикам доступны бесплатный ИИ-ассистент, обучающие курсы, а также документация, видеоматериалы и поддержка активного сообщества. ИИ-ассистент, построенный на базе технологии RAG, позволяет разработчикам задавать вопросы и получать пошаговые инструкции с примерами кода. За счет этого онбординг разработчиков ускоряется примерно в 2 раза.
Совет 4. Делите проект на модули, в первый модуль выносите первоочередную задачу
Правильная декомпозиция проекта на модули позволяет снизить риски и сократить Time to Market.
Принципы модульного подхода:
- Начинайте с первоочередного процесса. Если есть жесткий дедлайн по конкретной функциональности, то она должна быть вынесена в первый модуль. Все остальное — в следующих очередях.
- Запускайте модули в эксплуатацию по мере готовности. Так вы быстрее сможете показать результат бизнесу. Отрабатывать замечания пользователей будет проще по модулям, а не по всей системе сразу.
- Используйте любую подходящую для вас методологию. Разделение проекта на модули не означает обязательный переход на гибкую методологию. В рамках модуля можно следовать привычной каскадной методологии.
- Планируйте дорожную карту на несколько лет вперед. Масштабный проект не завершается за один год — важно заранее определить объем работ на последующие очереди.
Реалистичное планирование позволяет вести масштабный проект в спокойном режиме, без авралов.
Пример Хоулмонт
В нашем проекте этапы накладывались друг на друга. Когда первая очередь была запущена в эксплуатацию, мы уже начали разработку второй. Когда завершилась разработка второй очереди, пришло время для планирования и подготовки ТЗ для третьей и четвертой очередей.
Если ни в коем случае нельзя допустить простоя системы, для запуска в эксплуатацию, мы используем методологию Parallel Running. Ее основной принцип — во время опытной эксплуатации старая и новая системы работают параллельно на едином наборе данных. В одной из наших статей мы уже рассказывали, как провести замену системы по методологии Parallel Running.
Совет 5. Переиспользуйте функциональность по максимуму
При замене крупной системы не нужно начинать разработку каждого модуля с нуля. Переиспользование готовой функциональности — ключевой способ ускорить проект и снизить затраты.
Что можно переиспользовать и унифицировать:
- Архитектура
- Интерфейс
- Типовая функциональность: ролевая модель, аудит, механизмы обеспечения безопасности, моделирование процессов и т. д.
- Интеграционные механизмы
Грамотное использование готовых компонентов позволяет разрабатывать каждый модуль быстрее предыдущего.
Пример Хоулмонт
Jmix предлагает множество встроенных инструментов для стандартизации архитектуры, интерфейса, безопасности и интеграционных механизмов, а также готовых компонентов, подключаемых через маркетплейс. Кроме того, можно разработать новые компоненты под конкретные задачи каждого заказчика.
Что вы получите в результате
Замена иностранной ИТ-системы не только обеспечит соответствие законодательным требованиям и технологическую независимость, но и принесет результат за счет модернизации. Переход от монолитной архитектуры к модульной поможет уменьшить время отклика интерфейса и упростить поддержку. Процессы в ходе замены системы можно не просто перенести как есть, а переосмыслить: уменьшить количество ручных действий и сделать работу пользователей более удобной.
Выбор правильного подхода обеспечит результат сразу в нескольких измерениях:
- Соответствие жестким дедлайнам, обеспечение высокой скорости и управляемости разработки.
- Быстрая обратная связь от пользователей и бизнеса по каждому этапу от прототипа до функциональных модулей системы.
- Быстрое освоение технологий командой заказчика, развитие компетенций параллельно с реализацией проекта.
- Сокращение Time to Market и запуск модулей в эксплуатацию по готовности.
- Ускорение разработки по мере накопления переиспользуемой функциональности.
Замена центральной системы — один из наиболее сложных ИТ-проектов, с которыми сталкивается бизнес. Но при правильном подходе это не только вынужденная мера, но и возможность обновить архитектуру, оптимизировать процессы и актуализировать интерфейс. Наши советы помогают сделать этот путь предсказуемым и безопасным для бизнеса.