Директор по стратегическому формированию продуктов компании BSS Майк Лисянский поведал Bankir.Ru о новых возможностях платформы CORREQTS, сценариях применения омниканальности в ДБО и о том, как мобильное приложение преобразовывается в банковский офис в кармане. Майк, давай начнем разговор с платформы CORREQTS. Это флагманский продукт BSS для ДБО.

Чем он отличается от аналогов?

CORREQTS — это отечественный ответ на вопрос: как сделать одновременно универсальное и личное ДБО? Банков-клиентов у нас, скажем так, больше трех, и они, с одной стороны, в чем-то похожи, а с другой — время от времени сильно различаются между собой.

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

CORREQTS — это прежде всего промышленная платформа, которая разрешает разработчикам в предсказуемой среде создавать прикладной слой, что уже и есть ДБО в привычном для пользователей виде.

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

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

С чем это связано?

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

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

— Эдакий неандерталец.

— Да, либо кроме того Человек Умелый. В случае если сказать о вправду масштабной реализации омниканальности, то — это компания Apple и ее продукт iCloud, сделавшая нормой возможность доступа к одному контенту, причем достаточно разнородному, с различных устройств. Дальше концепция омниканальности начала переливаться во все остальные виды программного бизнеса.

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

ДБО у нас на данный момент физически поделено на две части: интернет-банкинг и мобильный банкинг.

Имеется и второй принципиальный момент. ДБО у нас на данный момент физически поделено на две части: интернет-банкинг и мобильный банкинг. Это сложилось исторически, потому, что первые мобильные ответы были опциональным дополнением к интернет-банкингу, скорее жаждой сыграть на маленькую, но перспективную аудиторию, чем важным бизнес-ответом.

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

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

Какого-либо определенного триггера, вынудившего пересмотреть подход к технологическим ответам ДБО, не было. Было скорее постепенное давление внешней среды, в котором все больше начали вспоминать об эффективности прежде всего IT-работ, как не «добывающих».

Мысль «давайте что-то сделаем с ДБО» стала появляться сама собой. В случае если сущность одна, для чего настойчиво идти к ней двумя дорогами, тратя уйму ресурсов?

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

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

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

— Не совсем. CORREQTS в далеком прошлом употребляется для обслуживания юрлиц. 20 октября мы выпустили CORREQTS Retail v. 3.2 — это трудящаяся протестированная совокупность для обслуживания физических лиц.

Уже имеется экспериментальное внедрение версии 3.2, подробности о нем будут позднее.

на данный момент готовим новую версию совокупности ДБО для физических лиц CORREQTS Retail, в которой, сохраняя всю функциональность, нужную банкам для обслуживания физических лиц, мы добавляем клиент-серверный API. Это разрешит пользователю трудиться с единой платформой по всему многообразию каналов. У нас уже реализован стенд, на котором видно, как к одной и той же платформе мы подключаемся через интернет-браузер на компьютере, через планшет, через телефон и через приложение.

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

В качестве флагманской разработке мы используем HTML5. Ее главное преимущество — присутствие на всех современных платформах, причем HTML5 возможно легко и комфортно упаковать в приложение-контейнер, что не только будет смотреться как приложение для телефона, но и предоставит доступ ко всем его возможностями — Touch-ID, камере, NFC.

Платформа CORREQTS не изменяется, мы к ней клиент-серверное API, и создаем многообразие каналов.

В итоге мы говорим о том, что платформа одна — CORREQTS, она не изменяется, мы к ней клиент-серверное API, и через него уже создаем многообразие каналов.

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

Он звонит в работу помощи. А оператор говорит: «Понимаете, я не знаю, что вы в том месте делали, давайте-ка все сперва мне объясните, с расстановочкой».

— Мы, в то время, когда разглядывали сценарии применения omni-channel, насчитали четыре варианта.

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

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

Грубо говоря, если ты реализуешь эту историю, то реализуешь и саму базу omni-channel. Ты различаешь каналы, каковые присоединены, и сейчас активны по отношению к платформе. Эти с этих каналов отправляются на платформу, и с платформы отправляются обратно по всем каналам. Происходит синхронизация. Это базисный кейс, что все говорят. А дальше-то что?

В действительности имеется и другие варианты применения.

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

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

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

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

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

Третий сценарий применения omni-channel имеет большее значение для банка. Это возможность создать консьерж-работу. Она пользуется спросом среди VIP-клиентов, в то время, когда у каждого пользователя имеется персональный менеджер, которому возможно поручить, к примеру сделать платежку и послать на подпись.

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

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

Тут omni-channel удачен как раз еще и вследствие того что финдиректор постоянно будет видеть, кто над чем трудится и в какой стадии процесс. Так как синхронизация с платформой происходит мгновенно.

Четвертый сценарий, что связан с omni-channel — это работа технической поддержки. Именно то, о чем вы задавали вопросы. Человек звонит в банк и говорит: «Я тут создаю платежку, но ничего не работает».

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

И сходу на лету исправить, дать совет, растолковать обстоятельство затруднения.

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

— Мы в начале беседы говорили, что в случае если делать параллельно два направления, то это вдвое дороже. Возможно ли сказать, что омниканальность уменьшает затраты в два раза?

— Дабы начать экономить, нужно внедрить соответствующую платформу. К примеру, CORREQTS. И по окончании того, как она внедрена, начинается настоящая экономия на IT-работах, техподдержке, развитии банка.

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

Отечественные технологии сочетания клиент-серверного API и HTML5 быстро повышают скорость доставки функциональности клиенту.

К примеру, отечественные технологии сочетания клиент-серверного API и HTML5 быстро повышают скорость доставки функциональности клиенту. Как это выглядит на практике? У нас главная часть функциональности загружается сервером в мобильное приложение, или прямо в интернет-банк.

Создается некая функциональность, тестируется, выкладывается на сервер, и это сходу появляется везде, а также в приложении.

Другими словами не нужно ожидать, пока это запрограммируют в нативном виде, пока пройдет валидация в App Store либо Гугл Play. Нельзя сказать, что затраты мгновенно сократятся вдвое. В полной мере возможно, они сократятся раза в полтора, но наряду с этим освободившиеся ресурсы будут трудиться на новую функциональность.

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

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

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

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

Но вот как воспользоваться таковой обстановкой — это, скорее, уже вопрос к бизнесу каждого конкретного банка.

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

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

Какие конкретно упрочнения необходимо прилагать чтобы она поддерживалась и не появлялось дополнительных затрат? Это тесно связано с процессингом и с АБС. В каждом случае, даже если вы берёте коробочный