Михаил дробышевский: «заказчики абс хотят жить завтрашним днем, а не вчерашним»

- kbrbank

Михаил дробышевский: «заказчики абс хотят жить завтрашним днем, а не вчерашним»

Не обращая внимания на кризис, развитие банковских совокупностей продолжится, считает Михаил Дробышевский, помощник председателя совета директоров, глава департамента банковского ПО RS-Bank компании R-Style Softlab. О трендах в развитии АБС, важности интерфейсов для b2b-технологии и систем личных дистрибутивов он расказал журналистам Bankir.Ru.

Актуальное в IT: ДБО, оптимизация

— Экономика переживает далеко не самые лучшие времена, а мы с вами собрались сказать об IT, софте, АБС. Как сейчас эти темы актуальны для банков?

— В случае если банк планирует работать , то IT необходимо развивать. На мой взор, как ни парадоксально, на данный момент подходящее время для развития бизнеса. Количество банков уменьшается, они сливаются, поглощаются, клиенты переходят из одних банков в другие. Это время изменений, время громадных трансформаций.

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

— Какие конкретно темы, которые связаны с IT, сейчас приводят к наибольшему интересу у банкиров?

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

Интернет-обслуживания физических и юрлиц. Это в отечественном понимании уже мейнстрим.

— Уже не новация, а мейнстрим?

— Это было новацией лет пять назад. на данный момент это — must have. Кое-какие банки уже сменяют второе либо кроме того третье поколение этих совокупностей.

— Кроме внедрения совокупностей ДБО, что еще происходит в области банковского софта?

— Какое-то время назад у всех банков были самописные совокупности. Позже случился передел рынка и показались вендоры. Начался массовый переход с самописных совокупностей. Позже на какое-то время наступило затишье, переходов стало значительно меньше.

Громадные трансформации по большей части происходили при перемещении IT-сотрудников между банками.

С трансформацией денежной обстановке банки начали вычислять деньги. Весьма многие вспоминали о том, как поменять дорогое ответ на что-то недороже, кое-какие — об оптимизации собственного «зоопарка» совокупностей от разных вендоров, о переходе к комплексным ответам.

Интерфейсы для АБС, «единое окно»

— В случае если сказать про АБС, то, мне казалось, эта область банковских IT в мельчайшей мере подвержена трансформациям. На Западе, к примеру, они эксплуатируются уже десятилетиями. У отечественных банков они более свежие. Но в целом, как я полагал, в данной сфере каких-то революционных трансформаций не происходит.

Либо я не прав?

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

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

В случае если 10 лет назад на интерфейс АБС по большому счету никто не обращал внимания, то на данный момент обстановка изменилась.

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

Раньше веб-приложения были упрощенными, их интерфейсы были через чур несложными и не весьма доходили для операциониста банка, по причине того, что во фронтальной совокупности должно быть довольно много различных объектов, информации, громадных перечней. Но сейчас эргономика web-интерфейса не только приближается к привычным приложениям Windows, но иногда и опережает их.

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

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

— Что вас подтолкнуло заняться как раз интерфейсом? Да, это красиво. Но это же не есть, на первый взгляд, первостепенным запросом со стороны банков!

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

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

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

Кроме этого актуальная тема — это то, что мы именуем «единое окно». Банк обязан обслуживать клиента и предлагать ему все услуги в одном месте, в одном интерфейсе. Сейчас, как мне думается, мало кто из разработчиков думает об эргономичном интерфейсе «единого окна».

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

SOA, неприятности компонентного подхода

Еще одна серьёзная тенденция — это сервис-ориентированная архитектура (SOA). Мы входим в интернациональную группу Asseco, у которой довольно много клиентов в Европе. И мы можем видеть различное отношение к SOA у нас и на Западе. Европейцы вычисляют SOA продвинутой совокупностью, но очень дорогой в эксплуатации.

Исходя из этого они применяют SOA лишь в весьма больших проектах, в то время, когда бюджеты на последующее сопровождение исчисляются миллионами евро. У нас в стране эта тема стремительнее продвигается, чем на Западе. Возможно вследствие того что отечественные совокупности не имели для того чтобы громадного груза прошлого, как на Западе.

Многие из них разрабатывались с нуля, соответственно более открыты в этом замысле.

Вторая тема, которая очень сильно оказала влияние на АБС,— это компонентный подход: разбиение монолита АБС на свободные части. Все начинается по спирали. Когда-то был один поставщик, что ставил все совокупности в банке. Позже пришла мода брать лучшие «кубики» от лучшего производителя и все это интегрировать. Показались шины, каковые как-то все это интегрировали. Многие банки так поработали и неспешно начали снова заниматься укрупнением собственных ответов.

По причине того, что все помой-му в теории с компонентами прекрасно, но сопровождать таковой сложный комплекс тяжелее, чем совокупность от одного поставщика. Поменял Банк России законодательство, изменились процессы на рынке — при с «кубиками» нужно синхронно поменять много совокупностей.

Эргономичное, интуитивно понятное, простое «единое окно», где возможно получить доступ фактически ко всех данных о клиенте,— это тренд в развитии АБС.

Кое-какие поставщики разрабатывали новые совокупности, каковые были основаны на компонентных подходах. Кто-то собственные совокупности разрывал на части. SOA разрешила видеть совокупность как компонентную.

Но наряду с этим не обязательно разламывать то, что и без того прекрасно трудится. на данный момент многие АБС смогут трудиться как мелкий «кубик», в то время, когда употребляется лишь часть их функциональности, либо как комплексное ответ, в то время, когда шина не нужна.

— Преимущество «монолитного» подхода для банка содержится лишь в том, что при трансформации законодательства, к примеру, не нужно вносить трансформации в пара различных совокупностей от различных производителей и как-то их сопрягать позже? В чем еще имеется преимущества?

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

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

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

— Возможно ли как-то вывести зависимость подхода к данной проблеме от размеров банка либо от вида его деятельности? Либо все-таки это «вкусовщина» — кому что нравится?

— Чем банк меньше, тем меньше у него разных инфраструктурных работ. Ему хочется иметь более несложную архитектуру IT и меньшее количество поставщиков и взаимодействующих частей. Чем банк больше, тем сложнее это делается. У большого банка и задач больше, и ресурсов у него достаточно для того, чтобы строить сложные схемы сотрудничества с бессчётными поставщиками.

Бизнес в больших банках имеет громадной вес, ему хочется иметь самые лучшие ответы. И все поставщики, само собой разумеется, желают попасть в большой банк

— У больших банков имеется деньги, дабы экспериментировать?

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

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

И они смогут выбирать IT-совокупность не смотря на все другое, что имеется в банке.

В весьма больших банках может ситуация , в то время, когда департамент, занимающийся кредитованием юрлиц, имеет собственный расходный бюджет, а также на IT-совокупность.

Само собой разумеется, в теории, имеется архитектурные комитеты, каковые должны все согласовывать. Но это в теории. А на практике, в случае если имеется менеджер и бюджет, что вправе тратить эти деньги, то он может выбрать ту совокупность, которая ему нравится, и приобрести ее. И такое происходит частенько.

К примеру, мы столкнулись с тем, что кое-какие банки имеют пара корпоративных хранилищ данных. Но сама концепция хранилища данных предполагает, что оно должно быть одно на всю компанию.

Разработка личных дистрибутивов

— Какое-то время назад во главу угла многие разработчики ставили открытость совокупности, по причине того, что Банк России скоро меняет собственные требования, и банки желали иметь возможность самостоятельно настраивать собственные совокупности

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

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

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

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

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

Сущность несложная: неспециализированный дистрибутив ведется для всех клиентов, но для некоторых клиентов, каковые испытывают в этом потребность, отделяется от какой-то точки неспециализированного дистрибутива такая «ветка». Имеется лишь условие, что она через какое-то время обязана слиться опять с тиражным дистрибутивом. И за счет этого удается избежать ситуации, в то время, когда получаются практически отдельные АБС, каковые разбегаются в различные стороны.

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

— Клиенты сходу осознали эту идею?

— Сперва — нет, само собой разумеется. Но неспешно на жизненных примерах знают. В то время, когда появляется такая обстановка, что клиенту нужна доработка, а полугодовой проект перехода на новый тиражный патч его совсем не радует, по причине того, что он желал бы раньше стартовать, тогда он начинает осознавать, что мы предлагаем.

Так как клиенту чтобы перейти на таковой дистрибутив, необходимо израсходовать значительно меньше времени и ресурсов.

— Мы говорим с вами о долгих процессах, но распространяющаяся на данный момент практика agile-разработки предполагает, что трансформации фактически непрерывно вносятся в существующую совокупность. Как это сочетается?

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

Инсталляцию возможно сократить, в случае если банк начнет приобретать от разработчика личные клиентские дистрибутивы.

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

— Кто заказывает вам эти трансформации в дистрибутиве — бизнес либо IT-департамент банка?

— По-различному. Это зависит от разработок в самого банка. У нас имеется банки, с которыми мы взаимодействуем лишь через IT-эксперта, а уже в банка выстроен процесс согласования. А имеется банки, где мы трудимся напрямую с сотрудниками бизнес-подразделений, по крайней мере в плане задач.

Это зависит от того, кто располагает бюджетом. Частенько бюджет на развитие разработок закладывается бизнес-департаментами.

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

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

А цена — это вопрос переговоров.

Единое окно

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: