IT ManagerИТ в бизнесеЧто хочет бизнес

Современная разработка: гибкость, основанная на правилах

Ольга Мельник

Современная разработка: гибкость, основанная на правилах

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

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

В 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-м, чтобы сохранять баланс гибкости, инновационности и управляемости. Мы уверены, что это лучший подход.

 

 

Роботизация, мобильные сервисы, цифровая трансформация, банковские сервисы

Горячие темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 12/2019], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

Я первое время ходил на все встречи с диктофоном, что спасал о меня от ситуации, когда я полностью понял собеседника, идеально подстроился, обо всем договорился… но вот о чем договорился и вообще, что обсуждали –, не помню хоть убей.

А что IT? А мы работаем, совершенствуемся в популярных технологиях и осваиваемся в новых. И пока до Луны ближе, чем до создания искусственного интеллекта, без работы мы не останемся.
«Пока больше некого назначить, поэтому заткнем дыру тобой. Потом переназначим». Упражнение называется «как убить сломать сотрудника за одно действие: повысить и понизить обратно». Для надежности повторять неоднократно.

Компании сообщают

Мероприятия

17.09.2020 — 18.09.2020
Big Data & AI Conference 2020

Москва, Онлайн

23.09.2020 — 24.09.2020
Форум промышленной роботизации

Санкт-Петербург, Чернорецкий пер. 4-6