Финансовый сектор традиционно является одним из самых активных потребителей ИТ. Уровень автоматизации процессов в банках в среднем заметно выше, чем во многих других отраслях, в том числе в страховании. Однако и у банкиров достаточно проблем. О нынешнем положении дел, тенденциях применения информационных технологий в финансовых учреждениях рассказывает председатель Клуба делового общения банковских ИТ-директоров Олег Подкопаев.
Intelligent Enterprise: Какие тенденции проявляются в применении учетных и профильных банковских систем?
Олег Подкопаев: Главная тенденция такова: если раньше банки в основном ориентировались на интегрированные системы от одного поставщика, где реализовано сразу множество функций, то теперь подход изменился на модульный, на выбор «лучших в своем классе», best of breed.
Сложилась ситуация, когда российские поставщики банковского ПО, в том числе лидеры — ЦФТ, «Диасофт», «Эр‑стайл», — не могут поставить решения, полностью удовлетворяющие банки. Пять и более лет назад основной фокус банковского бизнеса был связан с корпоративным сегментом, и российские системы с этим справлялись. В последние годы фокус сместился на розницу. А в рознице у всех отечественных систем есть весьма существенный недостаток: они не поддерживают требуемую производительность.
Тогда банкиры стали изучать западные системы, но и они не работают по всему объему необходимого функционала. Такие решения могут дать выигрыш на определенных направлениях, но российская бухгалтерия и отчетность в них не реализованы. Все равно их приходится интегрировать с другими инструментами. Есть специализированные решения — ритейловые фронты по выдаче кредитов, например, системы «коллекшнс» (контроля за сбором долгов), но полного набора все равно нет.
Напрашивался вывод, что не стоит искать единое интегрированное решение, его на российском рынке нет. Любая комплексная система сложна во внедрении. Проекты по ее установке могут занять несколько лет и не всегда бывают полностью успешны. Чаще всего их удается довести до определенного логического завершения, но они выпадают из сроков, из бюджетов, страдает качество. К счастью, как раз в этот момент начала продвигаться концепция SOA, и появился новый подход.
Гораздо проще внедрить конкретный модуль, например «кредитный бэк-офис» какого‑либо поставщика, который удовлетворяет конкретным критериям, «нанизать» его на интеграционную платформу, а потом внедрять дополнительные модули. Чем это хорошо? При таком подходе мы получаем для каждого бизнес-направления инструмент, оптимальный с точки зрения функционала. Внедрение и изменения идут легче, так как решение изолированное и изменять придется только часть, а не всю систему.
Тенденция последних трех лет — выбор продуктов по принципу «лучший в классе». Все банки уже дошли до определенного уровня зрелости. Маленьких банковских «стартапов» не так уж много, большинство игроков существуют на рынке минимум пять лет. Поэтому парк ИТ‑систем у них уже сформировался. Если им приходится что‑то менять, то это не замена систем целиком, а только «кусочные» изменения. А для стартапов логика другая, но приводит к тому же подходу: им нужно выходить на рынок быстро. Они не могут покрыть все сразу: берут самые необходимые модули, автоматизируют соответствующие направления бизнеса, запускают, делают следующий шаг. Это гораздо быстрее, чем комплексное внедрение.
Другая тенденция: иностранные игроки так и не смогли выйти на российский рынок учетных систем. Их внедрения, тем более успешные, можно пересчитать по пальцам. В основном продолжают доминировать отечественные разработки. Из западного инструментария используются отдельные модули, в основном ритейловые фронты и специализированные средства.
Из всего этого логично следует интерес к интеграции.
Насколько удачными и полноценными оказались российские попытки перехода на сервисно ориентированную архитектуру?
Надо сказать, что на данный момент реализовать все возможности SOA не смог ни один из российских банков. Во всяком случае, я таких примеров не знаю. В основном получилось развернуть интеграционные платформы и, применяя их как шины, обеспечить с их помощью интеграцию различных систем. Но набора многократно используемых сервисов никто так и не построил. Платформы используются только как middleware. Попытки были, но я не могу сказать, что где‑то SOA реализована так, как это продвигалось вендорами.
Почему так получилось? Делали практически с нуля. Не пришла компания, обладающая опытом, и не показала, как надо сделать. Ни Oracle, ни IBM не выполняли эти проекты сами, не привносили экспертизу на наш рынок: внедрением занимались российские консультанты. Выяснилось, что как только ты уже развернул интеграционную платформу и хочешь в новой системе использовать сервис, разработанный для старых систем, ты видишь, что сервиса как такового нет. И чтобы интегрировать новую систему со всеми остальными, ты должен опять разрабатывать энное число интерфейсов. С этим столкнулось очень большое количество банков. Не получилось реализовать самое важное в этой архитектурной идее — сервисы. Каждый следующий проект не может использовать результаты предыдущего в той мере, как это ожидалось.
SOA пока не реализована, но есть очень большой потенциал роста. Такая архитектура дает большие возможности управления ИТ-ландшафтом. Сам по себе такой архитектурный подход может быть очень плодотворным, если грамотно его реализовать. Он позволяет и быстро внедрять, и быстро менять, и эффективно управлять. В самом интеграционном решении зашит бизнес-процесс. Поэтому, меняя сервисные блоки, можно менять и интегрировать бизнес-процессы. Сейчас это так не работает.
Экспертиза растет, но только на опыте внутреннего рынка. Нет тех, кто разрабатывал эту концепцию, имел бы опыт внешнего рынка и мог бы здесь ее имплементировать. Те вендоры, IBM и Oracle, которые, казалось бы, должны привносить лучшие практики, не делают этого. Их российские партнеры изучают SOA сами и тренируются на клиентах, в том числе и на банках. Это не вполне правильно. Для интеграторов это очень хорошо: сначала так сделают, потом по‑другому, потом еще как‑то. Но не так хорошо для клиентов, которые за все это платят, а потом остаются крайними.
Как правило, банки, которые уже этот путь прошли, о нем не рассказывают. Они говорят: «Да, есть, да, работает, да, есть проблемы». Интеграционные платформы в любом случае помогают быстро внедрять приложения: каждое следующее нанизывается на шину, как на шпажку. Но ожидаемой легкости использования и сопровождения не возникает.
Также модель SOA хороша для банков тем, что, имея реальные сервисы, ты можешь очень хорошо управлять мастер-данными, а пока с ними большие проблемы с точки зрения транзакционных систем.
О каких проблемах работы с мастер-данными идет речь?
Сейчас во многих банках существует проблема единой точки входа к учетной информации. Пока что учетные данные из разных систем приходится интегрировать искусственным путем. Данные каким‑то образом сливаются, очищаются, но проблема в том, что они обратно в свои «родные» транзакционные системы не возвращаются. Если бы нормально работала сервисно ориентированная архитектура, то был бы сервис клиентской информации, единый и централизованный для всех систем. Вычистили бы один раз клиентскую информацию, держали бы мастер-данные, каждая система обращалась бы к этому сервису, сохраняла бы, изменяла бы, запрашивала бы одну и ту же информацию. Это касается, конечно, не только клиентских данных, но и любых других мастер-данных. Тогда очистку как таковую приходилось бы делать только один раз, а дальше вести текущий контроль и вносить уточнения.
Сейчас же приходится делать следующим образом. Собираем данные из всех систем, стараемся их как‑то «срастить», сопоставить, устранить дубликаты и так далее. Дальше вступают в силу сложные политики возврата этих данных в систему. Чаще всего мы не можем вернуть их в систему в том виде, в каком считаем нужным, после очистки. По разным причинам, в том числе юридическим. Если договор был заключен с определенным юрлицом, например, то в данной учетной системе это юрлицо может числиться только так, как написано в договоре, даже если это написание неверное. Поэтому требуется хранить отдельно очищенную версию данных в транзакционной системе и как‑то описывать соответствие между ними. В любом случае нужны сложные организационные процедуры, чтобы донести очищенную информацию до исходных систем.
Поэтому так востребованы системы контроля и даже отдельные сервисы контроля за консистентностью данных. Необходимо запустить серьезный механизм контроля качества данных, который будет работать периодически. Возможно, сам банк будет этим заниматься, а можно привлечь и аутсорсеров, такие услуги на рынке есть. Российские фирмы уже вполне «набили руку» и четко представляют себе, какие проблемы возникают при очистке именно российских данных и как их корректировать. Хотя у них узкая специализация, в этой сфере они значительно превосходят западных поставщиков подобных продуктов и услуг. У российских компаний есть и методики, и инструменты, и отлаженные процессы для таких работ. Но, конечно, если потребуется менять алгоритмы очистки у конкретного клиента, то для них это сложно, поскольку означает перенастройку своих инструментов. В любом случае не получается автоматического цикла управления данными. Чаще всего он прерывается на уровне хранилища. Данные в хранилище выгрузили, очистили, проконтролировали, отчеты сформировали. Все! Максимум это уйдет в CRM‑систему. Как правило, в транзакционные системы данные уже не возвращаются.
Складывается впечатление, что российских банков без аналитических хранилищ уже не осталось.
Банки действительно очень активно используют хранилища. Другой вопрос — что они под этим словом понимают. Некоторые так называют просто большие интегрированные базы данных, из которых потом формируют какие‑то отчеты, как правило плоские. Другие банки довольно серьезно развивают OLAP-инструментарий и предоставляют его конечным пользователям. Но практически 100% — проекты под заказ. Хранилища, готовые к применению, не поставляются, поскольку, с моей точки зрения, не сформированы практики. Каждый банк применяет собственную методику анализа рисков, управленческой отчетности и так далее. Поэтому невозможно взять готовый инструментарий с готовыми отчетами и начать его использовать. Не существует также готовых моделей данных. Они есть у крупных вендоров, но годятся в основном для корпоративного бизнеса и работы с ценными бумагами, то есть для тех областей, где применима западная практика. У розницы таких моделей нет, во всяком случае я не знаю ни одной универсальной модели данных для розничного бизнеса, которую можно было бы поставить, залить в нее данные из транзакционных систем и дать сотрудникам готовые инструменты для анализа. Пока каждый должен проходить эту дорогу сам. Это вопрос зрелости.
Раньше в каждом банке была своя собственная учетная политика, планы счетов, и «Диасофт» в каждом банке был свой собственный, настроенный уникально. Теперь постепенно идет стандартизация как подходов и политик, так и ИТ-инструментов, которые их поддерживают, поскольку происходит перемешивание людей. Что касается хранилищ, то в них этого пока не произошло. Хранилища обязательной отчетности есть, но их так называть можно только условно. По управленческой отчетности подобных решений пока нет, а может быть, и не будет никогда. Некоторые маркетинговые отделы предпочитают инструменты для работы с сырыми данными, продукты SAS, например. Возможно, со временем кто‑то на опыте создаст такой инструментарий, который подойдет большинству организаций, и тогда это станет стандартом де-факто.
Каковы особенности управления ИТ в финансовом секторе?
Идет поступательное развитие. Если раньше чаще всего и название подразделения было еще «ИТ-отдел», то теперь начали формироваться настоящие ИТ-организации. Банковские «айтишники» четко знают, что такое ITIL, ITSM, Cobit, и пытаются внедрять процессы, как с использованием автоматизированного инструментария, так и без него. Люди стали более индустриально грамотными, стремятся применять промышленные подходы. Чаще стали использовать аутсорсинг как средство управления затратами.
Это стало возможно потому, что несколько сместились фокусы владельцев и топ-менеджмента. До недавнего времени они были полностью сосредоточены на основном бизнесе, а что происходит в бэк-офисе, в ИТ, их фактически не интересовало. Теперь, когда основной бизнес запущен, схемы отработаны, управление установлено, и особенно после кризиса, топ-менеджменту стало ясно, что все операционные блоки, включая ИТ, требуют такого же управления: та же оптимизация, тот же контроль эффективности, что и основной бизнес. Стало ясно, что проблемы не решаются простым снижением затрат за счет покупки более дешевого оборудования. Хочется получить больше гибкости, надежности, эффективности за счет грамотного управления процессами. Идет большая ротация. Много специалистов приходит в российские банки из западных. Их и привлекают как носителей определенных технологий, в том числе сервисных подходов к управлению ИТ.
Известны примеры, когда внедрение сервисных подходов позволяет ИТ-директору перейти в функциональные топ-менеджеры: после успешного внедрения ITIL-методик в ИТ-отделе ему поручают навести порядок в АХО, а затем и в операционном блоке. Это единичные случаи или тенденция?
Такое развитие событий — мечта каждого ИТ-директора. Постепенно забрать под себя функциональные подразделения, и чем больше, тем лучше. Ведь одна из шуточных расшифровок CIO — Carrier Is Over, конец карьеры. И куда развиваться дальше? Логичным шагом может стать переход к управлению операционным блоком. Обычно ИТ-директора очень хорошо знают все процессы этого направления, у них структурированное мышление, и сервисный подход в этой области действительно можно весьма удачно применять. Это то, чего директора хотели бы, но на моей памяти удачных примеров не так много, хотя они есть. Но тенденцией я бы это никак не считал. Чаще всего айтишники остаются заложниками своего наименования. Айтишник? Ну так сиди и своими делами занимайся, а в бизнес не влезай. Слава богу, постепенно ситуация меняется: руководитель именуется CIO, его включают в правление, статус при принятии решений растет. Но само по себе это не означает, что он автоматически начнет участвовать в принятии серьезных бизнес-решений. Однако тенденция повышать статус ИТ-директоров явно прослеживается.
Надо сказать, что сами ИТ-директора приложили немало усилий, чтобы изменить отношение к себе. За последние годы около трети банковских ИТ-директоров, по моим наблюдениям, получили статус MBA. Некоторые коллеги имеют второе экономическое образование. Делается это с вполне осознанной целью — дальнейшее развитие карьеры и подъем собственного статуса. Они хотят, чтобы их рассматривали как бизнес-руководителей, и прилагают к этому значительные усилия.
Вы руководитель клуба банковских ИТ-директоров. Как идут в нем дела?
Клубу в декабре 2010 г. исполнилось два года. В нем больше 20 членов. Мы провели в прошлом году две полномасштабные конференции. Регулярно проходят встречи как для профессионального общения, так и для обсуждения неформальных тем. Готовим кулинарное заседание, например. Проводим выездные встречи, в том числе за рубежом. Развиваем общение с другими клубами ИТ-директоров, обучающими организациями. Есть цель участвовать в образовательном процессе, в том числе в составлении программ MBA, чтобы на уровне обучения топ-менеджеров поднимать статус ИТ и информировать их о возможностях, которые ИТ дает бизнес-руководителям, пропагандировать роль CIO. До сих пор этому систематически не учат.
Наши профессиональные встречи проходят по не совсем обычному сценарию. На наши заседания мы приглашаем одного партнера, обычно интегратора, который желает обкатать на нас какую‑то свою бизнес-идею: новую функциональность продукта, новый сервис, какое‑либо новое предложение. Это не презентация с целью продажи: тут мы категоричны. Но мы готовы все вместе послушать поставщика и ответить на его вопрос: а стоит ли продавать это? Если стоит, то как и кому? Встречи проходят в кулуарной обстановке, и дискуссии очень жаркие.
