+7(495) 455-32-15   +7(499) 400-41-42 infos@bilpay.su

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

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

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

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

Что это значит? И что для этого нужно?

Во-первых, это значит, что развитие комплексной системы банка и так происходит постоянно, и добавляемые или модернизируемые компоненты/системы должны интегрироваться в общую систему банка, давая заметный ожидаемый результат. Во-вторых, при объединении банков задача усложняется только количеством компонент и наличием «похожих» компонент, различных в множестве деталей. Это множество деталей, как правило очень важных для хорошей работы системы, и вызывает споры и колебания при принятии решений. Как избежать здесь зависимости от «человеческого фактора», есть ли способ сделать этот процесс объективным?

Прежде всего уместно задать вопрос, кто будет «главным интегратором», т.е. кто готов в конечном счёте отвечать за результат работы интегрированной системы? Для этого следует посмотреть функционал мониторинга – если не всей комплексной системы банка, то хотя бы одного из каналов обслуживания клиента. В банке на сегодняшний день их всего четыре: опер-кассы, система дистанционного банковского обслуживания через банкоматы и платёжные терминалы (ДБО), Интернет-банк и Мобильные приложения. Канал ДБО при этом самый показательный.

Сейчас в банках наметились попытки выстроить «единый канал» под названием ОМНИ с целью объединить информацию о клиенте и его услугах, дать клиенту возможность выполнения услуг в различных каналах обслуживания по единым правилам и т.д. Но в эту ОМНИ-систему невозможно заложить специфику работы каждого канала со своими устройствами и возможностями. Поэтому первый уровень интеграции комплексной банковской системы выглядит так: ОМНИ – система ведения общих реестров (клиентов, банковских услуг, выполненных операций, условий оказания услуг и т.д.), а далее – четыре канала обслуживания клиентов со своим мониторингом, диагностикой проблемных ситуаций и управлением обслуживания клиентов. И у каждого канала есть свои устройства и средства управления, своя интегральная ответственность за все выполненные в канале операции, за обработку сбоев и гарантии сохранности данных, своя статистика и аналитика операций и т.д. И каждый из этих каналов имеет собственные системы управления эксплуатацией входящих в него компонент/систем.

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

  • Банкоматы и платёжные терминалы, депозитарные машины и т.п. (далее – АТМ). Каждый с набором специальных, технически сложных устройств от разных производителей оборудования.
  • Процессинг обработки карточных операций (своих и «чужих» банковских карт).
  • Платёжно-интеграционный сервер (HUB), обеспечивающий, в частности, on-line платежи.
  • АБС банка (главная финансово-бухгалтерская компонента во всех каналах).
  • CRM система работы с банковскими продуктами, клиентами и партнёрами банка.
  • Вспомогательные системы банка (CALL-центр, инкассация и др.).

Кроме того, эта система ДБО взаимодействует также с внешними системами:

  • Биллинговые on-line системы провайдеров услуг (таких как Билайн, МТС, Мегафон и др.).
  • Биллинговые on-line системы агрегаторов платёжных услуг (таких как Элекснет, ФСГ и др.).
  • On-line и off-line системы прямых поставщиков услуг (ДПУ-услуг), в т.ч. гос. услуг и услуг бюджетных организаций.
  • Off-line системы поставщиков регулярных услуг (Университеты, школы, детские сады, фитнес-центры, страховые компании, негосударственные пенсионные фонды и мн. др.).

Взаимодействие этих систем с учётом всевозможных сбойных ситуаций, с учётом наличия довольно сложных параметров платёжных операций, считыванием ряда исходных данных, полученных от поставщика услуг (например, считыванием QR-кода квитанции или полученных от поставщика данных о начислениях и задолженности) – довольно сложный процесс, который должен контролироваться от начала до конца, без тупиковых ситуаций, с автоматической обработкой всех сбойных ситуаций, с обеспечением безопасности и защитой интересов банка и клиента. И кроме того, процесс должен быть удобным, динамичным, легко развиваемым, устойчивым и т.д., и т.п.

Нужно ли говорить, что поставщики ПО для всех компонент/систем ДБО стараются максимально удовлетворить бизнес банка в обеспечении сразу всех этих требований. По мере сил и возможностей. Именно в деталях этого обеспечения и кроются трудности в принятии решения: какой системе, какому поставщику ПО отдать предпочтение.

Заметим при этом, что поставленные в банк компоненты/системы быстро устаревают, требуется постоянное их развитие: появляются новые устройства (например, АТМ с ресайклингом), новые услуги (например, платежи бюджетным организациям), новые деньги и карты, новые технологии (например, бесконтактные карточные платежи) и т.д. От поставленных компонент/систем требуется оперативное реагирование и модернизация. Как правило, чем больше поставщик ПО, тем медленнее он реагирует. Иногда буксует в ожидании новой версии ПО другого поставщика (например, ПО процессинга для АТМ с ресайклингом). Естественно, что при слиянии банков приходится сравнивать различные поставленные банкам компоненты/системы по всем этим возможностям с важными техническими деталями.

Известно, что практика есть критерий истины. Чтобы «капитально» решить все описанные выше проблемы, мы предлагаем банкам не только теоретически правильный, но и проверенный на практике путь: осуществить стыковку (взаимодействие) ныне работающих в банках систем и затем провести оптимизацию работы ДБО на основе реального опыта работы этой системы и сравнительных оценок, а главное – с сохранением всех ранее накопленных полезных качеств в системах ДБО объединяемых банков. Для этого:

  • На банкоматах и платёжных терминалах устанавливается мультивендорное ПО МР-Terminal, объединяющее все функции эмулятора DDC/NDC и агента платёжного HUB, вместе с сертифицированным ядром МР-EMV и компонентой МР-Guard для централизованного контроля и синхронизации ПО, экранов и настроек на удалённых банкоматах и платёжных терминалах.
  • Серверные платёжные приложения MobilPay, e-Kassir, AnyWay и т.п. интегрируются и работают параллельно как виртуальные сервера на одном или нескольких серверных компьютерах, сохраняя все свои плюсы и минусы работающих систем в этих банках.
  • Сервер MobilPay обеспечивает общее управление всеми АТМ и интеграцию со всеми другими системами объединённого банка, которые по тем или иным причинам окажутся полезными в общей (комплексной) системе объединённого банка.
  • При этом ПО MobilPay обеспечит единый мониторинг, диагностику и автоматизированное управление системой, включая управление сервисным и инкассационным обслуживанием, управление движением наличности в ДБО объединённого банка, централизованный контроль и обновление ПО на всех банкоматах и терминалах, рабочих станциях операторов ДБО-МР и т.д.
  • ПО MobilPay обеспечит также работу ОМНИ-системы для интеграции ДБО-МР с другими каналами обслуживания клиентов банка (опер-кассы, Интернет-банк и Мобильные приложения).

Пример схемы такой интеграции приведён на рисунке:

На схеме розовым цветом выделены компоненты, участвующие в интеграции комплексной системы ДБО банка: АТМ и некоторые серверы ДБО (имеющиеся у банков серверы платёжных транзакций и сервер интеграции систем с использованием набора Web-сервисов API).

Такая схема интеграции систем банка обеспечивает минимальные риски принимаемого решения:

  • В переходный период проведения интеграции продолжают работать все системы банка и услуги клиентам, бухгалтерия и бизнес продолжают работать по наработанным процедурам (договорам, проводкам, сверкам операций и т.д.).
  • При этом вся система работает под общим мониторингом, диагностикой и автоматизированным управлением эксплуатацией на базе инструментов ПО MobilPay (при этом не отключаются другие инструменты, например, мониторинг Proview и т.п.).
  • Далее осуществляется спокойная оптимизация работы системы: настраиваются наиболее эффективные каналы прохождения транзакций в системе, удаляются дублирующие элементы, унифицируются и настраиваются общие параметры услуг (комиссии, диалоги с клиентом и т.п.).
  • В полную силу внедряется ОМНИ-система унификации и интеграции ДБО с другими каналами обслуживания клиентов объединённого банка (необходимые Web-сервисы для такой интеграции уже разрабатывались для ОМНИ-системы БИНБАНКа).

Возникает вопрос: могут ли другие поставщики ПО для системы ДБО обеспечить такую же безопасную интеграцию систем с последующей их оптимизацией на основе анализа практической работы комплексной системы?

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

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

Некоторые общие разумные требования к компонентам системы ДБО, помогающие принять правильные решения, освещены ниже:

  1. Какое ПО нужно ставить на АТМ?

Безусловно, оно должно обеспечить работу с процессингом и платёжным HUB-ом, а также централизованную удалённую поддержку этого ПО в условиях постоянного развития и усовершенствования. Отсюда – обязательное наличие следующего полного комплекта:

ПО XFS для работы с устройствами АТМ + ПО для работы с процессингом по протоколам DDC/NDC + ПО EMV для работы с чиповыми картами + ПО управления АТМ + ПО управления платёжными операциями ДБО + ПО мониторинга и диагностики устройств АТМ + ПО удалённой поддержки и обновления ПО-АТМ.

Желательно в комплексе, с поддержкой единого поставщика этого ПО-АТМ.

Заметим, что в ряде банков используется разделение ПО-АТМ на агента процессинга (например, эмулятора NDC) и агента платёжного HUB-а (стыкуемого с эмулятором, например, через Web-Extension). Это приводит к последующему «раздвоению» ответственности за наличные и безналичные операции ДБО и к усложнению общих процедур обработки финансовых результатов. Не говоря уже о невозможности обеспечить реальный анализ доступности услуг и их недоступности по конкретным техническим причинам из-за негарантированной доставки сообщений процессингу в рамках протоколов DDC/NDC. Опять же, такой «гибрид» компонент от разных поставщиков делает иллюзорным эффективное динамичное развитие ПО-АТМ, общую ответственность и поддержку ПО-АТМ в условиях бурного развития устройств на рынке. Примером тому – АТМ с ресайклингом.

  1. Какое ПО нужно ставить на платёжно-интеграционный сервер HUB?

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

Оно должно обеспечивать самостоятельное подключение новых on-line поставщиков и агрегаторов услуг, других платёжных HUB-ов и платёжных систем (например, динамически расширяющихся услуг Федеральной Системы «Город»). Т.е. предоставлять инструмент для подключения и настройки реальных шлюзов, шин и внешних систем без программирования. В противном случае, это для банка не только деньги, но и время внедрения новых возможностей и дополнительная зависимость от аутсорсинга доработок ПО и сопровождения новаций.

Оно должно обеспечивать не только оперативный «ручной» мониторинг и диагностику проблемных ситуаций в системе ДБО, но и автоматическую генерацию рутинных инцидентов с автоматизированным процессом оформления сервисных заявок и контролем их выполнения — так называемый Инцидент-Менеджмент. По существу, стыкуемый с системой сервисной организации и контролем выполнения ею SLA-условий сервисного обслуживания АТМ.

Оно должно обеспечивать автоматический сбор, анализ и прогнозирование движения наличных средств в устройствах АТМ и в ДБО в целом (с учётом специфических дней и самообучением прогнозирования), контроль за загрузкой кассет и управление инкассацией (с учётом ресурсов и реальных ситуаций, с снижением фондируемой наличности и т.д.).

В конечном счёте, ПО платёжно-интеграционного сервера (HUB-а) должно обеспечить и ведение единой базы данных по всем событиям и операциям в системе ДБО как для наличных, так и безналичных, и нефинансовых клиентских операций. И ещё 24х7 отказоустойчивость и простую масштабируемость (расширение устройств АТМ).

Возникает вопрос, есть ли хоть одна система ДБО, имеющая такое полноценное ПО? Оказывается, есть. Называется – MobilPay. И это не рекламная акция, приведенный выше набор требований к системе реально работает в ряде банков РФ. В том числе в БИНБАНКе, РНКБ, ТКБ и др.

Более того, ПО MobilPay обеспечивает варианты «виртуального» объединения банков, когда одна система ДБО обслуживает несколько банков (или филиалов) в режиме коллективного пользования. В этом смысле ПО MobilPay можно было бы назвать «базовым ПО для интеграции систем ДБО» при объединении банков, содержащим необходимый и достаточный набор серверных инструментов интеграции (приведенных на схеме).

  1. Какое ПО различных поставщиков можно интегрировать с этим «базовым ПО»?

Да любых, например, E-Kassir, AnyWay и т.п. Сохраняя при этом все возможности этих платёжных HUB-ов, все реализованные и внедрённые услуги и качества (параметры, настройки и схемы выполнения) услуг, все их возможности мониторинга и диагностики. Более того, ПО MobilPay позволяет настраивать (оптимизировать) выполнение той или иной платёжной услуги через выгодного для банка «посредника» (канал), гибко перераспределяя пути выполнения операций в системе ДБО. И оставаясь при этом «генеральным ответственным» за все операции ДБО в целом.

Важно подчеркнуть, что ПО MobilPay в принципе способно обеспечить все перечисленные выше «непростые» технические требования к интеграции систем объединяющихся банков.