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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SOA, проблемы компонентного подхода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технология индивидуальных дистрибутивов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как вам кажется, как банку можно оптимально бюджетировать свои отношения с вендором в ситуации высокой неопределенности?

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

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

Изменения в регулировании и АБС

Мы несколько раз упоминали регулятора. Насколько я знаю, с 1 января 2016 года вводятся очередные изменения в план счетов. Как это повлияет на рынок АБС?

— Повлияет это в первую очередь на нервозность всех вокруг, если говорить о 446-П (постановлении о новом плане счетов). Как всегда, уже недалеко 1 января, а ясности нет. Есть много связанных с этими изменениями проектов, про которые не известно, выстрелят они или нет. Это наша российская специфика. В Европе изменения выходят заранее, например за полгода, разработчики успевают подготовиться, а клиенты перейти на обновления.

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

Кстати, мы являемся участниками рабочей группы по новой системе отчетности — по переходу на XBRL. Это огромное изменение, если оно будет когда-нибудь внедрено. Мы надеемся, что такие крупные изменения Центральный банк будет обсуждать с вендорами.

Для вас как для производителей АБС переход на XBRL — это угроза?

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

— На повышение конкурентоспособности в конечном итоге.

— И конкурентоспособности, если говорить про мировую арену. Еще один аргумент в пользу XBRL: сейчас банки активно лишаются лицензий, и очень часто одной из причин является то, что обнаруживается дыра в балансе банка. Получается, что существующая сегодня отчетность, хотя ее очень много (в Европе меньше отчетов), не позволяет эти дыры обнаружить. Отчетность построена таким образом, что перекрестных форм в ней очень мало, практически каждая из них является уникальной и отражает часть бизнеса банка. И если что-то в этих формах подкрутить, то ЦБ, пока не введет в банк своего временного управляющего, не поймет, что его обманывали годами.

Мы надеемся, что крупные изменения, например, такие, как XBRL,  Центральный банк будет обсуждать с вендорами.

— В завершение разговора хотелось бы спросить, какие тренды в развитии АБС вы видите?

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

Следующий тренд — это развитие интерфейсов b2b-систем. Я уверен, что через несколько лет это будет общим требованием к корпоративному ПО. Сюда же можно отнести и «единое окно», о котором мы с вами уже говорили.