Как заменить ИТ-систему в финансовом секторе: 5 советов

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

Почему в финансовом секторе актуальна замена корпоративного ПО 

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

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

В банках, страховых компаниях и финансовом секторе в целом ИТ-проекты обычно ведет собственная команда. Как организовать ее работу так, чтобы быстро получить результат без лишних затрат? 

На основе опыта проектов мы выработали 5 советов для замены корпоративного ПО: 

1. Используйте технологии повышения продуктивности разработки в сочетании с безопасными ИИ-инструментами 
2. Объедините первый этап проекта с выбором технологий 
3. Начинайте разработку вместе с партнером и постепенно передавайте задачи своей команде 
4. Делите проект на модули, в первый модуль выносите первоочередную задачу 
5. Переиспользуйте функциональность по максимуму 

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

Совет 1. Используйте технологии повышения продуктивности разработки в сочетании с безопасными ИИ-инструментами 

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

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

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

При выборе технологической базы важно учитывать несколько факторов: 

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

Экосистема для управляемой ИИ-разработки может быть развернута на базе привычных инструментов внутри контура заказчика: 

• ИИ-ассистент помогает подготовить спецификацию для код-агентов 
• Архитектурный шаблон используемой платформы задает структуру, которую воспроизводят код-агенты 
• Окно терминала для общения с ИИ-агентом встроено в среду разработки 
• MCP протокол в рамках среды разработки обеспечивает проверку кода до этапов сборки 
• Можно подключить плагины для визуализации промежуточного результата и дополнительной проверки кода проекта 

Совет 2. Объедините первый этап проекта с выбором технологий   

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

Такой подход решает сразу несколько задач: 

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

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

Чтобы оценить результаты, важно иметь бенчмарк — понять, какой срок разработки ожидается без использования ИИ. Разработка Proof of Concept (PoC) — прототипа для проверки жизнеспособности идеи — при использовании ИИ может занимать 8–10 часов. Создание Minimal Viable Product (MVP) — прототипа, готового к внедрению в реальные процессы — потребует около 3 недель. 

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

Совет 3. Начинайте разработку вместе с партнером и постепенно передавайте задачи своей команде  

Собственный ИТ-отдел — большое преимущество. Внутренняя команда лучше понимает бизнес-процессы, быстрее реагирует на изменения и накапливает экспертизу, которая остается в компании. Однако освоение новой технологической платформы вместе с ИИ-инструментами требует времени. 

Оптимальная стратегия — начать разработку вместе с технологическим партнером и наращивать объем работ внутренней команды. В чем преимущества такого формата: 

Важно, чтобы со стороны заказчика подключались как менеджеры и аналитики, так и разработчики. 

Совет 4. Делите проект на модули, в первый модуль выносите первоочередную задачу 

Правильная декомпозиция проекта на модули позволяет снизить риски и сократить Time to Market. 

Принципы модульного подхода: 

• Начинайте с первоочередного процесса. Если есть жесткий дедлайн по конкретной функциональности, то она должна быть вынесена в первый модуль. Все остальное — в следующих очередях. 
• Запускайте модули в эксплуатацию по мере готовности. Так вы быстрее сможете показать результат бизнесу. Отрабатывать замечания пользователей будет проще по модулям, а не по всей системе сразу. 
• Используйте любую подходящую для вас методологию. Разделение проекта на модули не означает обязательный переход на гибкую методологию. В рамках модуля можно следовать привычной каскадной методологии. 
• Планируйте дорожную карту на несколько лет вперед. Масштабный проект не завершается за один год — важно заранее определить объем работ на последующие очереди. 

Реалистичное планирование позволяет вести масштабный проект в спокойном режиме, без авралов.  

Этапы могут накладываться друг на друга. Когда первая очередь запущена в эксплуатацию, начинается разработка второй. Когда завершилась разработка второй очереди, пришло время для планирования и подготовки ТЗ для третьей и четвертой очередей. 

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

В одной из наших статей мы уже рассказывали, как провести замену системы по методологии Parallel Running. 

Совет 5. Переиспользуйте функциональность по максимуму   

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

Что можно переиспользовать и унифицировать: 

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

Грамотное использование готовых компонентов позволяет разрабатывать каждый модуль быстрее предыдущего. 

Что вы получите в результате 

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

Выбор правильного подхода обеспечит результат сразу в нескольких измерениях: 

1. Соответствие жестким дедлайнам, обеспечение высокой скорости и управляемости разработки. 
2. Быстрая обратная связь от пользователей и бизнеса по каждому этапу от прототипа до функциональных модулей системы. 
3. Быстрое освоение технологий командой заказчика, развитие компетенций параллельно с реализацией проекта. 
4. Сокращение Time to Market и запуск модулей в эксплуатацию по готовности. 
5. Ускорение разработки по мере накопления переиспользуемой функциональности. 

Замена центральной системы — один из наиболее сложных ИТ-проектов, с которыми сталкивается бизнес. Но при правильном подходе это не только вынужденная мера, но и возможность обновить архитектуру, оптимизировать процессы и актуализировать интерфейс. Более того, бизнес может сделать этот путь предсказуемым и безопасным.