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

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

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

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

— То есть бизнес-партнер — это просто другое название аккаунт-менеджера?

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

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

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

— То есть большинство решений в своей области принимает бизнес-партнер. Как проверяется правильность этих решений?

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

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

Бизнес-партнер не только собирает требования бизнеса и переводит их на язык IT, но и отвечает за выполнение этих требований

— Вообще-то мы решили, что термин «online», то есть «в реальном времени» уже несколько дискредитирован, и говорим просто «just in time», то есть «вовремя». У банка всегда есть проблема в получении не только аналитических, но и операционных данных своевременно — начиная от решения по кредиту, когда клиент ждет на кассе, заканчивая необходимостью видеть итоги дня по продажам продуктов. Чем больше становится организация, тем больший объем данных она обрабатывает, и, соответственно, тем больше времени требуется на его обработку — прямая зависимость. Если банк достигает размера выше среднего, то перед ним встает вопрос — либо применять иные технологические подходы и платформы, либо постоянно отставать от времени. Банк уровня топ-7 в среднем проводит около 50 млн транзакций в день. Чтобы посчитать полученную прибыль, надо «просто» взять эти 50 млн транзакций, взять остатки по счетам, а их может быть 100–200 млн, и произвести с ними определенные математические действия. Даже чтобы просто посчитать проводки без каких-либо преобразований, нужны огромные вычислительные мощности. Допустим, стоит клиент в отделении и ждет принятия решения по кредиту. Он оставил заявку, она пошла по верификаторам, андеррайтерам, а дальше эта заявка попадает в модуль принятия кредитного решения. Этот модуль находит данные по клиенту и формирует его риск-профиль. Как правило, исторические данные по клиенту хранятся в базе данных, которая собирает данные всех клиентов за все время, то есть это очень большая база данных — ее объем может достигать более терабайта. При этом эта база реляционная и наполняется реляционным образом, то есть индексы пересчитываются, скажем, раз в день. Поэтому всегда есть сомнения, правильный ли набор данных использовали, актуальны ли они были на тот момент.

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

Вячеслав Благирев, бизнес-партнер по технологиям банка «Открытие»

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

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

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

Если банк достигает размера выше среднего, то перед ним встает вопрос — либо применять иные технологические подходы и платформы, либо постоянно отставать от времени

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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