Банк не должен отставать на недели

Банк не должен отставать на недели

Банк «Открытие» уже более года ведет значительное преобразование правил управления IT и ландшафта технологической инфрастуктуры.

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

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

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

Дабы избежать для того чтобы «бутылочного горлышка», у нас решено было выстроить горизонтальную либо, вернее сообщить, матричную структуру. Нужно подчернуть, что CIO входит в состав правления банка. Ему подчиняются два поддержки — и департамента развития не. В отделе развития действуют начальники, важные за развитие определенных направлений, мы назвали их «менеджерами продукта». Тут имеются в виду не банковские продукты, а сервисы IT как продукты.

Таких продуктов пять: BI, корпоративные сервисы, фронт-офис, бэк-клиентский опыт «и офис».

Параллельно им, независимо от продуктов, трудятся «начальники команд», каковые распределяют трудовые ресурсы. Это команды по разработке, тестированию, управлению проектами.

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

Один несёт ответственность за кросс-продажи, телепродажи, продажи в сети отделений, клиентский сервис и МСЮ, второй — за операционный блок, бухгалтерию и АХО, я — за риски, банковские продукты и юридическое подразделение.

— Другими словами деловой партнер — это легко второе наименование аккаунт-менеджера?

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

Деловой партнер не только собирает требования бизнеса и переводит их на язык IT, но и несёт ответственность за исполнение этих требований, другими словами командует проектами. На нем лежит и распределение бюджетов в тех областях, за каковые он важен. Он же определяет приоритеты в исполнении проектов.

— Но так как ресурсы необходимы и вторым бизнес-партнерам. Как распределяются приоритеты между ними?

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

— Другими словами большая часть ответов в собственной области принимает деловой партнер. Как проверяется правильность этих ответов?

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

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

— Вообще-то мы сделали вывод, что термин «online», другими словами «в настоящем времени» уже пара скомпрометирован, и говорим легко «just in time», другими словами «своевременно». У банка неизменно имеется неприятность в получении не только аналитических, но и операционных данных вовремя — начиная от ответа по кредиту, в то время, когда клиент ожидает на кассе, заканчивая необходимостью видеть итоги дня по продажам продуктов.

Чем больше делается организация, тем больший количество данных она обрабатывает, и тем больше времени требуется на его обработку — прямая зависимость. В случае если банк достигает размера выше среднего, то перед ним поднимается вопрос — или использовать иные платформы и технологические подходы, или всегда отставать от времени. Банк уровня топ-7 в среднем проводит около 50 млн транзакций в сутки.

Дабы посчитать взятую прибыль, нужно «»эти 50 млн транзакций, забрать остатки по квитанциям, а их возможно 100–200 млн, и произвести с ними определенные математические действия. Кроме того дабы проводки без каких-либо преобразований, необходимы огромные вычислительные мощности. Допустим, стоит клиент в отделении и ожидает принятия ответа по кредиту.

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

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

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

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

— Все это звучит прекрасно, но достаточно технологично. Что именно убедило бизнес в необходимости применения этих идей?

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

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

— А из-за чего эти задачи нельзя решить посредством простых реляционных баз данных?

— Дело в том, что в большинстве случаев банки развиваются неспешно, автоматизируя процессы посредством различных совокупностей. В итоге целый данный «зоопарк» приходится интегрировать, дабы каким-то образом собирать данные, но трудится это все равно медлительно. Преимущества совокупностей класса MPP (Massively parallel processing — массовая параллельная обработка) в том, что они именно могут действенно собирать и обрабатывать неструктурированную данные из различных источников.

Не требуется думать о форматах данных, индексах и т.д. —«» совокупности эти, она их скоро «прожевывает» и формирует в консистентную картину.

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

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

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

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

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

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

— Рассчитывали ли вы срок окупаемости ответа?

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

— Как вы выбирали платформу?

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

— Для каких как раз задач вы собираетесь использовать технологии MPP?

— Посредством этих разработок мы будем руководить эффективностью работы банка и противодействием мошенничеству, прежде всего — AML (Anti-money laundering — противодействие отмыванию доходов). Мы желаем в реальном времени осознавать каждые трансформации профиля клиента. В случае если профиль клиента — физлица либо юрлица — изменился, показался новый акционер либо произошло что-то еще — мы об этом сходу должны определить.

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

— Имеется требования 321-П по обязательному контролю в части ПОД/ФТ, в соответствии с которым кредитная организация обязана делает определенные действия. Большая часть этих действий — диагностику платежей, сделок и т.д. — в силу исторически сложившихся событий у нас в стране, возможно, 99% банков делают на базе АБС. Наряду с этим проверка сотен тысяч транзакций по так называемым стоп-страницам либо «тёмным перечням», формируемым регулятором, значительно нагружает совокупность.

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

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

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

Синдром задержки развития плода. Синдром задержки роста плода


Темы которые будут Вам интересны:

Читайте также: