Тиражные решения или собственная разработка? В каждом конкретном случае выбор делается по разным критериям. О практике и приоритетах создания собственного ПО рассказывает директор Ак Барс Цифровые Технологии Рафаэль Валеев.

Какие бизнес-ориентиры определяют вашу технологическую стратегию?

В 2016 году в Ак Барс Банке началась работа по активному развитию розничного бизнеса. С 1993 года банк работал в основном на корпоративном рынке и сохраняет на нем по-прежнему серьезные позиции. Цель новой стратегии – создание розничного технологичного банка. Это не смена приоритетов целиком, а смещение фокуса на развитие B2C-направления. Такие изменения потребовали новой операционной модели и технологической платформы. Специально для этого был создан центр технологического и цифрового развития Ак Барс Цифровые Технологии.

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

Каковы технологические приоритеты разработки?

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

Что вы роботизируете, какие именно функции?

В роботизации мы выделяем два направления. Первое напрямую связано с операционной эффективностью – автоматизация рутинных функций фронт- и бэк-офиса.

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

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

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

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

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

Примерно такая же ситуация и с программным обеспечением для противодействия мошенничеству (анти-фрод). Мы выполнили серьезный этап предпроектного анализа, рассмотрели практически все решения, которые есть на рынке. Оказалось, что стоимость владения тиражных продуктов выше, чем годы собственных разработок.

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

Какой инструментарий разработки вы используете?

Мы выбрали open source решение Camunda – на наш взгляд, один из самых зрелых bpm-продуктов. Это оркестратор бизнес-процессов. Мы разработали свою библиотеку для облегчения работы в .NET среде и работаем с ней как с внутренним продуктом для команд разработки.

В разработке наша команда исповедует микросервисный подход. Для этого у нас внедрена платформа Red Hat OpenShift. Это целая экосистема, решающая множество проблем, в том числе с мониторингом и логированием. Построен весь конвейер CI/CD: GitLab для хранения кода, TeamCity для непрерывной интеграции кода, Octopus Deploy для внедрения, Artefactory для хранения конечных сборок. У нас есть команда IT4IT, которая развивает и поддерживает эти процессы и практики.
Также в команде есть так называемые devOps-инженеры. У них есть две основные задачи. Первая – обеспечить непрерывную сборку и доставку приложений, автоматизировать этот конвейер, минимизируя влияние человеческого фактора. За счет хорошего ритма некоторые системы обновляются несколько раз в неделю. Вторая задача – решать проблемы производительности, обеспечивать работу под нагрузками и выполнять другие задачи, связанные с эксплуатацией в промышленной среде.

Какую операционную модель вы выбрали?

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

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

В любой команде есть сотрудник с ролью Application Security Engineer. Такие специалисты обеспечивают безопасность приложений, работая в тесном контакте со службой безопасности банка. В промышленную эксплуатацию код с уязвимостями не уйдет: это их зона ответственности. Мы работаем с приложениями и сервисами, которые оперируют деньгами, поэтому вопросы безопасности всегда стоят на первом месте.

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

Гибкая разработка: как вы это понимаете?

С самого начала наша разработка строилась как гибкая. Сначала работали по scrum-методологии, с 2018 года масштабировали этот подход для наших потребностей на основании методологии SAFE.

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

Мы позиционируем себя не как сервисное подразделение, а как партнерское. Это сказывается на том, какую ответственность мы принимаем. Мотивация у нас имеет две составляющие. Первая определяется выполнением бизнес-показателей и показателей уровней сервисов, том числе 10% — доступность систем в зоне ответственности команды. Вторая составляющая – это ежеквартальные выплаты за достижение определенных показателей – целей в разработке продукта, создания функционала или достижения заданных параметров в сервисе.

Agile – это концепция, где результат важнее процесса, но это не значит, что системные процессы не должны развиваться. Однако и в формализации должна быть мера. Есть такой тезис, что не стоит уходить на 5-й уровень зрелости процессов, а лучше оставаться на 3-м или 4-м, чтобы сохранять баланс гибкости, инновационности и управляемости. Мы уверены, что это лучший подход.