От миграции к промышленной эксплуатации отечественного софта: взгляд эксперта FIS на развитие корпоративных систем

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

Что на практике определяет совместимость отечественных ИТ-решений, и где чаще всего возникают сложности при их внедрении? 

Если смотреть на нашу практику, то при переходе на отечественный стек мы видим, что возникает не больше проблем, чем при поддержке и обеспечении совместимости любого другого ПО. Если речь идёт о системном программном обеспечении, то здесь — стандартная инженерная работа: настроить, протестировать, устранить пару неочевидных моментов. Если говорить о прикладных системах, то основной вопрос всегда в интеграции с существующим банковским ландшафтом — прежде всего с АБС, которая обычно является и так российской. 

Если сложности и появляются, то они связаны не со страной происхождения продукта, а с самим устройством бизнеса. Гораздо важнее зрелость решения, опыт команды и объём инвестиций в его развитие. Да, мировой рынок больше, поэтому существуют  более функциональные решения, но и этот разрыв сегодня быстро сокращается: ИИ серьёзно удешевляет разработку инноваций. Не случайно российские банковские приложения уже давно считаются одними из самых сильных в мире — многие зарубежные коллеги сегодня скорее спрашивают, как повторить этот опыт, чем наоборот.

Из реальных рисков я бы скорее выделил поддержку устаревших решений, которые достигли стадии end of life — там действительно могут возникать сложности независимо от страны происхождения продукта.

Какие вопросы необходимо решить до начала миграции, чтобы сохранить непрерывность бизнес-процессов?

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

Что определяет успешность системы после пилота и промышленного запуска? Почему даже технологически сильное решение может столкнуться с сопротивлением пользователей?

На практике истории про массовый саботаж сотрудников встречаются гораздо реже, чем принято считать. Обычно это не рыночный стандарт, а особенности конкретного бизнеса, его накопленного legacy и сложившейся культуры работы. И решить такую проблему технологиями невозможно — это всегда управленческая задача. Мы даже сталкиваемся с тем, что заказчики сознательно не хотят переходить на более современный UX или UI. Не потому, что новый интерфейс хуже, а потому что эффективность сотрудника складывается из того, насколько хорошо “подогнаны шестеренки” в связке “человек — система”. Если человек несколько лет выполнял одну и ту же операцию, у него формируется безусловный рефлекс, и любое изменение сначала снижает его скорость работы. 

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