|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Централизация управления на основе интеграции ИТ — один из актуальных трендов в банках — различия между версиямиМатериал из CustisWiki
Текущая версия на 11:17, 17 октября 2014Первый заместитель генерального директора Сергей Тихомиров ответил на вопросы редакции CNews о преимуществах внедрения единых интеграционных решений и значимости централизации управления в банках. Каковы мировые и отечественные тенденции в области централизации управления? Когда интеграционное решение становится инструментом развития? Насколько эти решения оправдывают вложения? Обо всем этом — в материале «Централизация управления на основе интеграции ИТ — один из актуальных трендов в банках». CNews: Интеграция ИТ в банках — о ней много говорят и регулярно заявляют о выполненных проектах. Почему эта тема стала так актуальна? С. Тихомиров: Сейчас практически во всех крупных банках ведутся проекты по интеграции информационных систем. Там, где это делается на основе целостной концепции, интеграционный проект выступает как инструмент развития, в него вовлекается ключевая часть ИТ-ландшафта банка. Причем в рамках этой концепции не только связываются существующие ИТ-компоненты, но и внедряются новые ИТ-системы. Где-то на задачи интеграции смотрят как на сугубо инфраструктурные: если сквозной бизнес-процесс требует связать функциональные блоки, то это делается на локальном уровне — в рамках конкретной задачи и в минимальном объеме. Преимущества внедрения единого интеграционного решения известны: во-первых, уменьшается связность компонентов ИТ-ландшафта; во-вторых, облегчается замена ИТ-компонентов в рамках выбранной стратегии изменений; в-третьих, появляется возможность в полной мере реализовать идею использования best-of-breed решений. Это в принципе обеспечивает банку целенаправленное управление развитием — прозрачное и с просчетом рисков будущих изменений. CNews: Чем интеграция информационных систем полезна с точки зрения бизнеса? С. Тихомиров: Основная причина, по которой бизнес сейчас инициирует масштабные интеграционные проекты, — необходимость повышать эффективность работы организации в целом. Интеграция на уровне ИТ тесно связана с распространением централизованного управления на все сферы деятельности банка. Централизация управления — это один из актуальных трендов в крупных организациях. До кризиса 2008 года все коммерческие компании, включая банки, занимались активной экспансией на рынки. Соответственно, развитие их ИТ имело тот же экстенсивный характер. Банки копировали на Западе лучшие бизнес-решения и старались быстро внедрить их. ИТ, как могли, это поддерживали, не особенно заботясь об архитектурной целостности всей конструкции. Кризис приостановил этот процесс, а спустя год-два после его окончания принципы банковского развития изменились: борьба за эффективность бизнеса вышла на первые позиции. Для успеха в этой борьбе необходимо предварительно сделать организацию прозрачной и управляемой. Львиная доля всех ИТ-задач по централизации связана именно с обеспечением прозрачности и управляемости бизнес-процессов. Еще одна важная задача централизации — это стандартизация деятельности банка, которая распространяется на работу всех отделений, операционных и функциональных подразделений, а также их взаимодействие. Проекты по централизации управления проецируются в различные задачи на уровне ИТ. Например, нам приходилось выполнять работы по централизации учета и ведения единой учетной политики в банках. Консолидированный учет — бухгалтерский, управленческий, налоговый — выстраивается таким образом, чтобы от агрегатных показателей в балансе или конкретных строк в отчетах можно было «спуститься» до набора первичных документов, которые породили эти суммы. Так достигается прозрачность учета во всей организации, включая филиалы. В дальнейшем на базе централизованного учета банку удобно внедрять единую учетную политику, задавать общие правила и подходы и контролировать их исполнение в рамках всей организации. Некоторые банки уже используют новые возможности, например, для создания собственной системы внутренних управленческих нормативов, расширенной по сравнению с требованиями регулятора. CNews: Как, по-вашему, тенденция к централизации управления в отечественных банках соотносится с мировыми трендами? С. Тихомиров: Централизация управления не противоречит мировому опыту. Если продолжить тему учета, то подобные централизованные решения существенно облегчают и ускоряют внедрение международных стандартов Базель II и Базель III, что сейчас является трендом у российских банков. Это связано не только с интеграцией в западное банковское сообщество, но также обусловлено стремлением повышать эффективность. Основная идея Базельских правил — это переход к риск-ориентированному управлению, что отлично ложится в парадигму обеспечения прозрачности и внедрения централизованного управления через единую учетную политику. Полноценная работа банка с рисками возможна только на основе консолидации учетных данных и информации о сделках, которые прозрачным образом собираются из прикладных систем. Так что все ИТ-решения, которые будут поддерживать централизацию учета, также помогут банку вести единую учетную политику и переходить к риск-ориентированной модели управления. CNews: Вы упомянули, что интеграция в ИТ может выступать как средство развития бизнеса. Какие условия необходимы для этого? С. Тихомиров: Чтобы интеграционное решение стало инструментом развития, оно должно в своей концепции нести идею построения единой информационной архитектуры банка. Правильная информационная архитектура гарантирует, что ИТ не будут сдерживать развитие бизнеса и банк сможет перестраивать процессы не только ситуативно под изменения требований регулятора или каких-то рыночных реалий, но и планомерно — исходя из потребностей бизнеса. Чтобы реализовать идею использования функциональных систем класса best-of-breed, нужно иметь возможность быстро и относительно безболезненно менять ИТ-ландшафт. а это возможно только при условии, что в концепцию и реализацию интеграционного решения заложена идея развития, которой также подчинена информационная архитектура банка. Интеграционное решение становится центральным в ИТ-ландшафте банка, а все остальные системы должны соблюдать правила информационного обмена и поддерживать те объекты, которые необходимы на уровне информационной архитектуры. Тогда и отвечать за сквозные бизнес-процессы и «сквозную» архитектуру будет интеграционное решение. Если же интеграционное решение не занимает определяющего места в ИТ-архитектуре, оно превращается в огромный транспортно-перевалочный почтовый узел, куда все системы просто «скидывают» свои информационные объекты. по сути, ничего не меняется по сравнению с системой локальных связей между ИТ-компонентами, только еще и утрачивается очевидность конкретных взаимодействий. CNews: Не секрет, что отношение к большим интеграционным проектам не всегда однозначное. Насколько эти решения оправдывают вложения? С. Тихомиров: Нужно отдавать себе отчет, что большой интеграционный проект — это вложение в будущее. на сегодня большинство таких вложений еще не подтвердили свою обоснованность. Ближайшие года два-три интеграционные решения в банках будут доказывать свое право на жизнь. При этом мы увидим как положительные, так и отрицательные примеры. Оценка эффективности ИТ-решений в принципе сложна и довольно субъективна. Поэтому невозможно заранее предсказать, какой — положительный или отрицательный — исход будут иметь ведущиеся сейчас интеграционные проекты. А года через три, там, где единые интеграционные решения докажут свою эффективность, они вытеснят из банка все остальные средства интеграции, за исключением, может быть, незначительного числа локальных шлюзов, которые уже никак не будут сказываться на управляемости ИТ-ландшафта и выстраивании единой информационной архитектуры в банке. CNews: Не удорожает ли интеграционное решение эксплуатацию всей информационной системы в банке? С. Тихомиров: Нередко приходится слышать, что единые интеграционные решения «монструозные» и порождают большой перерасход средств на ИТ. По-моему, это сильное преувеличение. на самом деле масштабная интеграция не просто сопровождается увеличением затрат на ИТ, а изменяет сам процесс учета этих затрат. Есть прямые затраты, которые можно отнести на появление интеграционного решения, а есть косвенные — на те работы по интеграции, которые раньше включались в строку расходов на доработку конкретной системы. После внедрения единого интеграционного решения все косвенные расходы «отрезаются» от функциональных систем и переносятся непосредственно на него. Совокупная доля этих косвенных затрат оказывается существенно выше, чем затраты, напрямую связанные с его появлением. Кажется, что затраты на интеграцию возрастают, а на самом деле формируется адекватная картина реального распределения расходов. Так что если считать честно, то все затраты на интеграцию, которые раньше были распределены по разным функциональным системам, в случае централизованной интеграции оказываются выделенными и сконцентрированными в одной строке бюджета. CNews: А что можно сказать о временных и денежных затратах на изменение ИТ-ландшафта уже после того, как интеграционное решение внедрено? Приходилось слышать мнение, что они тоже увеличиваются. С. Тихомиров: Это опять из области ложных впечатлений. Если единого интеграционного решения нет и банк использует набор локальных шлюзов между системами, то решения об их изменении принимаются достаточно спонтанно. Соответственно, нет смысла оценивать последующие затраты: они считаются только в моменте, а косвенные затраты, которые связаны с разбором последствий таких изменений, вообще не учитываются. Накладные расходы на локальную интеграцию и ее последствия могут быть высоки, но они не выделены явно и поэтому будут отнесены к функциональным задачам. Будучи «размазанными» по системам, они не станут «лакмусовой бумажкой», сигнализирующей о реальных затратах времени и средств. в отсутствие единого интеграционного решения задача изменения связей между ИТ-системами только кажется простой и недорогой. При наличии централизованного интеграционного решения все долгосрочные последствия изменений обязательно продумываются и решения об изменениях в ИТ-ландшафте принимаются с их учетом. Тут расчеты понятны: все сопутствующие расходы выделяются в специальные статьи текущих и последующих затрат на эксплуатацию измененного решения. Прозрачность и обоснованность оценки расходов повышается. Но поскольку решения принимаются комплексно, с учетом последствий для большого числа связанных между собой компонентов ИТ-ландшафта, это, естественно, затрудняет и замедляет сам процесс. То есть возрастают затраты на процессы управления. В банке, как в большой организации, процессы принятия решений неизбежно сопровождаются бюрократическими процедурами. Поэтому при решении интеграционных задач, которые обязательно должны обсуждаться в централизованном режиме, может даже возникать ощущение, что они тормозят автоматизацию банка в целом. на самом деле это неизбежно, поскольку приходится принимать согласованные решения. CNews: Насколько успех интеграционного проекта зависит от ИТ-службы в банке? С. Тихомиров: Единое решение задает правила интеграции, которые являются, по сути, ограничениями для ИТ-ландшафта. Разумеется, последствия этих ограничений могут быть как положительными, так и отрицательными. Чтобы положительные превалировали, необходимо учитывать требования архитектуры и последствия возможных изменений. Разумеется, это сложная и долгосрочная задача: специалисты ИТ-подразделения должны продумать и взять на себя ответственность за последствия будущих изменений в ИТ-ландшафте. Не все ИТ-службы в банках к этому готовы, да и не все этого хотят. Если ИТ-подразделение занимает активную позицию по отношению к бизнесу, то оно заинтересовано в едином интеграционном решении, поскольку это позволяет в режиме равноправного партнерства реализовать долгосрочные изменения, необходимые бизнесу. А если ИТ-подразделение пассивно и действует из соображений «бизнес чего-то требует, и мы это быстренько и подешевле реализуем», тогда они просто не понимают, зачем от простых локальных связок нужно переходить к комплексной и сложной интеграции. Зачем усложнять себе жизнь, продумывать схему управления, выстраивать архитектуру, прогнозировать последствия — и брать на себя дополнительную ответственность за все это? Если подытожить, то для того, чтобы успешно внедрить крупное интеграционное решение, ИТ-служба должна занимать активную позицию по отношению к бизнесу, быть дальновидной (то есть уметь просчитывать последствия своих решений в долгосрочной перспективе) и обладать хорошими архитектурными навыками (либо самостоятельно, либо уметь привлекать правильных аутсорсеров). Есть еще один необходимый фактор успеха. Интеграционный проект, как и любой масштабный проект, который не ограничивается рамками отдельного подразделения, будет успешным только тогда, когда и если он будет одобрен и заручится организационной и финансовой поддержкой на уровне банка в целом. Он не может находиться в зоне ответственности исключительно ИТ-службы, его нужно вести на уровне всего банка, а не «спускать» в ИТ как чисто инфраструктурную задачу. Если же он останется в ИТ, то будет интегрирована только часть ИТ-ландшафта и какие-то отдельные операции, — это будет выстрел «из пушки по воробьям». к сожалению, так нередко и случается: разворачивается инфраструктура и разрабатывается компонентная архитектура для банка в целом, но без поддержки на должном уровне все скатывается к решению текущих локальных задач. CNews: Практически ко всем интеграционным проектам банки привлекают своих подрядчиков. Как заказчик и исполнитель должны делить зоны ответственности? С. Тихомиров: Интеграционный проект всегда затрагивает многих ИТ-подрядчиков банка из числа поставщиков информационных систем — ведь им придется выполнять те решения, которые будут заложены в концепцию интеграции. Банк может самостоятельно разработать концепцию интеграции, но реализовывать и поддерживать ее будут вынуждены практически все его подрядчики. Если их заранее привлечь к разработке концепции, то это снимет значительную часть рисков чисто технологического типа. Из кресла айтишника банка видны далеко не все последствия и проблемы для ИТ-компонентов, возникающие при внедрении интеграционного решения. Большой интеграционный проект — это и не чисто внутрибанковская задача, и не классический аутсорсинг. Тут правильно создавать партнерскую среду для подрядчиков, чтобы постараться снять или хотя бы снизить неизбежные риски. Результативность интеграционного решения существенно зависит от того, как будет происходить взаимодействие, наращивание дальнейшего функционала и изменение тех компонентов, которые участвуют в интеграции. Представим, что после внедрения интеграционного решения ИТ-подрядчикам будет «вменен» список работ, которые придется выполнять при каждом функциональном изменении. Если стоимость этих работ в разы превысит стоимость самого изменения, доказать эффективность такой интеграции будет крайне сложно. Очевидно, что придется вырабатывать правильные принципы взаимодействия между банком и подрядчиками (поставщиками или разработчиками ИТ-компонентов), чтобы исключить лишние доработки, — корректировать концепцию или конкретные способы ее реализации, упрощая и удешевляя решение. Причем опыт показывает, что основная доля негативных последствий проявляется не столько на уровне концепции или принципов, сколько на уровне способов реализации. Именно их нужно разрабатывать, обсуждать и изменять в кооперации с подрядчиками банка, именно в этой кооперации проверяется адекватность тех или иных интеграционных решений. CNews: Стоит ли банку самостоятельно внедрять единое интеграционное решение или выгоднее прибегнуть к аутсорсингу? С. Тихомиров: Поскольку большой интеграционный проект является стратегическим, а не только инфраструктурным, основную часть решений банк вынужден принимать на основе собственных компетенций. Иначе он отдаст на аутсорсинг один из ключевых процессов, который при правильном подходе является фактором его развития, — а это непозволительные риски. Даже если банк планирует привлечь стороннюю экспертизу на раннем этапе разработки концепции, то критически важным будет приглашение такого подрядчика, который способен просчитать последствия именно в плане дальнейшего развития всей информационной архитектуры, а также отдельных ИТ-систем, которые будут участвовать в интеграции. Привлечь правильного стратегического партнера — либо уже проверенного подрядчика, либо организацию, которая специализируется на оказании подобной услуги, — гораздо важнее, чем наличие какого-то опыта по конкретным интеграционным кейсам. Хотя придется повторить, что опыт реализованных интеграционных проектов в нашей отрасли еще невелик, поскольку реально построенных компонентных архитектур в банках практически нет. А поскольку однозначно хорошо завершившихся историй до сих пор нет, то и выбор среди отечественных подрядчиков, способных внедрять интеграционные решения в крупных организациях, пока невелик. CNews: Что должно отличать подрядчика, способного выступать в качестве стратегического партнера банка по развитию ИТ? С. Тихомиров: От стратегического партнера-подрядчика требуется большой опыт работы в предметных областях, интеграция ИТ-приложений которых наиболее важна для банка. Кроме того, он должен уметь выполнять проверку технологической реализуемости и оценку рисков проекта. И, конечно, он должен уметь выстраивать партнерские отношения с сотрудниками банка и коллегами-подрядчиками, а также быть настроенным на стратегическое партнерство в будущем. Мы считаем, что все эти качества подрядчика должны опираться на прочную технологическую основу. Для нас такой основой при выполнении интеграционного проекта является подготовка прототипа. Поскольку создается решение стратегического уровня, нельзя сразу «бросаться в воду». Мы создаем прототип для макетирования всех ключевых задач, которые должны быть решены в проекте. Прототип помогает снять значительную долю рисков и отработать новую для банка модель взаимодействия, которая задает тренды развития и формирует требования на изменения к конкретным ИТ-компонентам и подрядчикам. Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
||||||||||||||||||||
![]() |
![]() |