Системы поддержки принятия решений — на что обратить внимание при выборе
Системы поддержки принятия решений (СППР) стали ценным инструментом, помогающим коммерческих банкам в работе с клиентами. Однако выбрать конкретное решение сегодня непросто. Почему не стоит ориентироваться на функциональность СППР, а нужно оценивать команду вендора и дорожную карту продукта – в материале Ильи КАТЧАНА, руководителя Центра развития аналитических продуктов Axenix специально для Национального банковского журнала (NBJ).
Рынок СППР в финансовой отрасли
Исторически рынок систем класса СППР был сильно консолидирован. Ведущую роль на нём играли несколько западных вендоров ПО, имевшие в России локальные представительства, которые осуществляли продажу и поддержку лицензий, имели свои учебные центры и партнёрскую сеть.
С уходом западных игроков российским разработчикам открылось пространство для развития. Однако, чтобы использовать новые возможности, им нужно сократить путь, который зарубежные вендоры проходили на протяжении десятилетий, до нескольких лет.
Но есть и преимущества: отсутствие технического «легаси» (устаревших технологий) мотивирует разработчиков на использование актуальных архитектурных паттернов и программных компонентов. Например, множество западных решений разрабатывались во времена, когда на рынке аналитики преобладали проприетарные языки, а Python только набирал популярность. Сейчас он стал стандартным языком для анализа данных и машинного обучения.
На рынке есть две категории финансовых организаций, которые рассматривают внедрение СППР. Первая ищет решение для новой задачи. Вторая – планирует заменить работающую иностранную систему на российскую. Мотивация и подходы к выбору новой системы у них сильно отличаются.
При этом объёмы ресурсов для внедрения новой СППР или «переезда» с одной на другую всегда были достаточно внушительными. Этим обусловлено пристальное внимание рынка к функциональным и нефункциональным возможностям решений: получаемые преимущества от внедрения или миграции должны перекрывать расходную часть. Рассмотрим, какие есть варианты и попробуем провести сравнительный анализ.
Внутренняя разработка vs продукт отечественного вендора
Подхватив общемировой тренд на создание бизнес‑приложений с использованием свободного программного обеспечения (СПО), накопив экспертизу и человеческий капитал, банки и финтех‑компании активно включились в гонку создания отечественных программных продуктов, конкурируя с большими интеграторами и средними ИТ‑компаниями.
Использование СПО‑компонентов и принципов микросервисной архитектуры существенно сокращает time2‑market, позволяя достаточно быстро создавать гибкие программные решения, которые пусть не такие функциональные, как SAS, FICO, Experian, но зато более гибкие во внедрении.
Основным риском внутренней разработки может стать ограниченный потенциал продвижения продуктов в своей отрасли. К примеру, собственные продукты банков из ТОП‑10 могут быть достаточно конкурентными в других отраслях, тогда как в финансовой – мало кто из банков захочет стать зависимым от соседа по рейтингу. Второй риск – зависимость от своей команды разработчиков, что в условиях сложного кадрового рынка может стать проблемой для развития продукта. И третий риск – ограниченная возможность получать лучшие практики и передовой опыт с широкого рынка.
Молодой сегмент отечественных ИТ‑вендоров, также сталкиваясь с острым дефицитом профессиональных разработчиков, ведёт себя, тем не менее, достаточно агрессивно, пытаясь занять рыночную долю в нише. Ярких кейсов внедрений российских СППР пока нет, и основной вызов для вендоров – реализовать первый проект в основных банковских рисках или маркетинге.
К потенциальным рискам покупки вендорских решений можно отнести высокую стоимость постгарантийной поддержки и развития функциональности, если вендор не имеет длинного инвестиционного плеча. В среднем, в течение двух лет заказчик может потратить ещё 100% от исходной цены. Второй типичный риск, который не поддается митигации – вендор‑лок, то есть зависимость от поставщика решения. Как‑то повлиять на вероятность ухода вендора с рынка тоже невозможно.
Третий риск связан со сложностью и дороговизной выбора решения из‑за большого количества игроков при отсутствии референсных кейсов. Это накладывает серьёзные требования по контролю за результатом, хотя высокое предложение позволяет выставлять жесткие финансовые условия подрядчикам. При общей готовности интегратора инвестировать в первые успехи это позволяет минимизировать риски неудачи, но от потери времени не страхует.
Требования к ИТ‑вендорам
С учётом рисков формируются требования к отечественным вендорам, которые стоит рассмотреть подробнее. Выделим несколько моментов, которые встречаются в технических заданиях:
1. Заказчики предлагают работать по схеме Revenue Sharing – это модель партнёрской программы, участники которой делят не только прибыль, но и риски. Пока такое условие встречается редко, но вполне вероятно, что интерес к этой схеме будет расти. Типовым критерием выбора новых СППР является отсутствие в исходном коде проприетарных составляющих. Крупные организации, имеющие в штате большое количество программистов, нередко выставляют требования к открытию исходного кода системы для того, чтобы в случае необходимости иметь возможность вносить доработки своими силами. И это уже стандартная опция на рынке.
2. Вызов для вендоров – требование в будущем отдавать решение на внедрение партнёрам. Сейчас этой практики ещё нет, хотя банки начали обозначать такую возможность в техническом задании.
С технологической точки зрения на фоне широкого использование СПО удивить рынок уникальным решением затруднительно. Уровень ИТ в России так вырос, что любая технология, демонстрирующая хорошие результаты на практике, тут же становится типовым компонентом многих архитектур.
Очевидно, что отечественный софт функционально в ближайшие три года не сможет полноценно конкурировать с иностранными аналогами по функциональности. Поэтому заказчикам при выборе отечественных вендоров стоит учитывать четыре ключевых момента:
1. Собственная команда разработки. Это критически важно для стабильного развития продукта.
2. Наличие соответствующей потребностям рынка дорожной карты развития ПО на 1–2 года. У команды должны быть планы по реализации востребованной функциональности, а также ресурсы для того, чтобы выдерживать заявленные сроки по её разработке.
3. Наличие бизнес‑экспертов в команде, способных понимать запросы рынка. Они должны постоянно проводить исследование потребностей клиентов (качественный CustDev). Важность этого пункта подчеркивает статистика: 42% стартапов закрываются, потому что плохо изучили потребности пользователей на старте.
4. Часто заказчики обращают внимание на наличие достаточно длинного инвест‑плеча или возможности развиваться на собственные средства. По нашему мнению, оптимально иметь один год страхового запаса, т.к. это существенно минимизирует риск закрытия бизнеса до конца проекта.
Рисунок 1. Пример low-code интерфейса системы поддержки принятия решений Smartax c встроенным ИИ-ассистентом Codax
Требования бизнеспользователей и ИТ
Финальное решение о внедрении новой СППР обычно принимается на основании оценки со стороны бизнес‑пользователей и технических специалистов.
Бизнес‑пользователи прежде всего обращают внимание на удобство работы с точки зрения low-code, когда исполняемый код стратегий формируется автоматически после «обрисовки» логики в графическом конструкторе (Рис. 1).
Постепенно в повседневный набор инструментов разработчика включаются также инструменты генеративного ИИ (Рис. 1)
Возможность системы работать в условиях Enterprise ландшафта – не менее важное требование. Сюда обычно включают функциональность системы по возможностям совместной работы, разграничения доступов и соответствие базовым требованиям информационной безопасности. Помимо широты функционального покрытия классических элементов стратегий (бизнес‑правила, ветвления, запросы к данным) бизнес‑пользователи обращают внимание на наличие поддержки современных методов машинного обучения – насколько удобна их интеграция в логику создаваемых расчётов.
Ключевые требования технических специалистов к СППР – производительность и надёжность. Для финансовых организаций типичным запросом является возможность развития системы внутри собственного контура. Техническим специалистам важно убедиться, что процесс работы с системой не потребует масштабного вовлечения ресурсов ИТ‑подразделений, а архитектурные элементы соответствуют корпоративным стандартам.
С технологической точки зрения вряд ли стоит ожидать прорыва – развитие ИТ‑рынка и банков вышло на плато. Из нереализованных ранее отраслевых задач можно указать разве что “Расчёт доходов по клиенту” (что является в большей степени регуляторным требованием, хотя и соответствует тренду на персонификацию сервисов).
Как мы упомянули, системы принятия решений в банковском секторе становятся всё более персонализированными. Банки используют данные о клиентах, чтобы предложить им наиболее подходящие продукты и услуги. Это позволяет им лучше понимать потребности своих клиентов и предоставлять им более качественные услуги.
Выводы
Российский рынок СППР далёк от равновесия. За долю в нише борются интеграторы, вендоры, финтех‑компании, банки. Однако их решения пока отстают от иностранных аналогов. Именно поэтому при выборе системы не стоит ориентироваться на её функциональность. Намного важнее наличие собственной команды, адекватная запросам рынка дорожная карта развития и наличие инвест‑плеча.
Но, несмотря на догоняющий характер российского рынка, принимать решение о переходе на отечественную СППР необходимо уже сегодня. А чтобы минимизировать риски неудачного выбора системы, важно учесть особенности развития этого сегмента и опыт заказчиков в использовании подобных ИТ‑продуктов.