В одной упряжке

Совершенствование архитектуры предприятия, как правило, не входит в число главных приоритетов ИТ-директора отечественной организации. Между тем просчеты в ее проектировании и развитии приводят к тяжелым и трудноустранимым последствиям.

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

Ведущая шестеренка

Необходимо рассматривать бизнес-архитектуру и системную архитектуру как части единого целого — архитектуры предприятия, уверен Виктор Галактионов, главный системный архитектор, директор департамента управления архитектурой АКБ «Рос­ЕвроБанк». Изолированное друг от друга рассмотрение и проектирование этих компонентов является большой методической ошибкой, считает он. Главную роль в этой связке играет бизнес-архитектура. Ее можно сравнить с ведущей шестеренкой в коробке передач: ее вращение определяет движение ведомой шестеренки, в нашем случае — трансформацию системной архитектуры. Если рассматривать иерархию архитектур сверху вниз (от бизнес-архитектуры на верхнем уровне к архитектуре приложений и затем до технической архитектуры, или архитектуры оборудования), то увидим их явную зависимость от бизнес-архитектуры.

«Бизнес-архитектура и системная архитектура — две равноправные составляющие архитектуры предприятия», Дмитрий Назипов, старший вице-президент банка «ВТБ», руководитель департамента информационных технологий

Если совершаются промахи при проектировании бизнес-архитектуры, масштаб негативных последствий для организации будет особенно велик. В России это усугубляется тем, что за последние 10–12 лет в основном развивалась системная архитектура, в первую очередь архитектура приложений, архитектура данных. Сформировалась прослойка грамотных прикладных архитекторов, однако число бизнес-архитекторов, по оценкам Галактионова, явно мало, и понимание значимости и принципов формирования бизнес-архитектуры у отечественных специалистов часто отсутствует.

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

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

Подходы к построению процессов управления архитектурой в организации напоминают историю становления процессов управления проектами, считает Галактионов: «Лет десять назад я недоумевал, зачем разрабатывать внутренние регламенты и процедуры для управления проектами, зачем начинать с регламента на пяти страницах, чтобы затем в течение нескольких лет его «растягивать» каждый раз до желаемой степени детализации, почему нельзя открыть PMBOK и сделать все изначально правильно». Подобное происходит и при внедрении процессов управления архитектурой, особенно бизнес-архитектурой — сознание бизнеса должно пройти эволюционный путь, похожий на долгий путь становления процессов прикладной архитектуры. Как нельзя просто взять и использовать PMBOK, так не получится и просто взять рекомендуемый для банков подход Banking Industry Architecture Network (BIAN) или стандарт электронных сообщений на финансовых рынках ISO 20022. Но все же именно бизнес-архитектура играет ведущую роль в построении архитектуры предприятия и непосредственно влияет на решения в области системной архитектуры, через которую оказывает влияние также на техническую архитектуру (последняя абсолютно вторична по отношению к бизнес-архитектуре).

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

Отсутствие осознанной структуры понятий приводит к тому, что в случае необходимости оказывается чрезвычайно трудно извлечь все объекты, имеющие отношение к интересующей в данный момент теме. Сложно понять, на какие продукты, каналы продаж и процессы может повлиять изменение внешней среды, например изменения в законодательстве. И уж совсем непросто ответить на вопрос «Что будет, если?..».

Галактионов считает, что наличие пусть даже неполного, неоптимального представления о структуре различных аспектов хозяйственной деятельности в основании принятия решений всегда лучше ее полного отсутствия. В качестве примера можно рассмотреть ст. 9 Федерального закона № 161 «О национальной платежной системе». Она требует, чтобы банки с января 2014 года оговоренным с клиентом способом уведомляли их о платежах, выполненных с использованием электронных средств. Для реализации этих требований необходимо вначале определить полный перечень операций, относящихся к понятию «платеж», затем отобрать из этого множества операции, выполняемые с использованием электронного средства платежа (ЭСП), чтобы именно по этим операциям отсылать уведомления. При отсутствии четкой структуры понятий поиск таких операций часто выполняется не сверху вниз, а наоборот — с уровня бухгалтерского учета, с АБС: для начала отбираются все дебетовые проводки по клиентским счетам. Однако в эту выборку попадают операции по ежемесячному списанию банком комиссии, которые не являются платежом клиента с использованием ЭСП. Еще один спорный момент: когда правильнее уведомлять клиента — при выполнении операции по карте или при отражении бухгалтерской проводки по счету клиента в балансе банка?

Очевидно, что ответы на поставленные вопросы на уровне бизнес-архитектуры повлияют на архитектуру приложений. Одной из основных причин того, что Госдума отложила вступление в силу этой статьи закона на год, стал большой размер клиентских баз, который не позволил банкам вовремя выполнить все необходимые операции — заключить дополнительные соглашения и определить каналы доставки сообщений. Однако и здесь сказалась недостаточная проработка бизнес-архитектуры: было непонятно, атрибутом какого объекта информационной системы являются реквизиты для отправки уведомления клиенту — счета клиента, карты? В случае привязывания этого атрибута к счетам клиентов могли возникнуть осложнения в их обслуживании: если владелец счета выпустит дополнительную карту (например, на имя жены, которая расплачивается ею за рубежом), то уведомление в этом случае будет приходить владельцу счета, а не владельцу карты — в нашем случае жене клиента. Чтобы удостовериться, что операции по карте не мошеннические, придется связаться с женой и попросить ее сообщить о покупках, что, согласитесь, далеко не всеми будет воспринято с пониманием.

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

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

«В архитектуре предприятия главную роль играет бизнес-архитектура. Ее можно сравнить с ведущей шестеренкой в коробке передач», Виктор Галактионов, главный системный архитектор, директор департамента управления архитектурой АКБ «РосЕвроБанк»

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

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

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

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

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

На равных правах

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

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

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

Следующей по значимости, с точки зрения Назипова, является тенденция интеграции и безбумажного процесса поддержки банковских продуктов, когда продукт заказывается и покупается клиентом через каналы дистанционного банковского обслуживания, а все информационные системы настроены на то, чтобы с минимальными затратами проводить операции через сквозные системы, интегрированные друг с другом. Например, кредитные заявки потенциально могут обрабатываться вообще без участия кредитного сотрудника, если кредитная история клиента выглядит благополучной. Аналогичная ситуация складывается и с другими продуктами. Клиенты могут сами размещать депозиты, переводя средства с других счетов, и осущест­влять платежи без участия банковских сотрудников.

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

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

Влияет на бизнес-архитектуру еще одна заметная тенденция — объединение различных видов бизнеса (например, инвестиционного, страхового и банковского) в рамках одного финансового холдинга, что дает возможность осуществлять кросс-продажи и продажи комплексных продуктов. Это явление влияет на построение сети продаж, интеграцию продуктов, способы организации клиентской работы, считает Назипов. В частности, выявляются категории клиентов, которым можно осуществлять кросс-продажи (например, те, кто приобретает кредиты, вполне могут войти в целевую группу для продажи лизинговых или факторинговых продуктов). Подобные зависимости должны быть своевременно отражены в CRM-системах, связанных с реализацией кросс-продуктов. Возможно, также имеет смысл предоставить клиентам сквозные продукты — скажем, расчеты, при которых платежи в рамках факторинговых и лизинговых схем привязываются к проданному продукту, что исключает ошибки сотрудников банка и позволяет увидеть целостную картину всех платежей клиента. Объединение разных финансовых продуктов в один портфель требует серьезных усилий по интеграции продуктовых модулей информационных систем, организации сквозной обработки и предоставления через все каналы доступа ко всем продуктам. Это большой комплекс ИТ-проблем, который затрагивает CRM-системы, удаленное банковское обслуживание, интеграцию платежных систем и продуктовых модулей.

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

Во втором случае речь идет о вхождении компании в структуру финансового холдинга или организации нового бизнес-направления внутри холдинга. Для группы «ВТБ» примером является присоединение Банка Москвы и организация нового «Лето Банка». В последнем случае имеется совершенно иная ситуация в части развития системной архитектуры: необходимо «в чистом поле» с минимальными затратами построить новый ИТ-ландшафт на основе существующих или новых, более современных ИТ-решений. В связи с этим «Лето банк» получился очень специфическим в плане ИТ-поддержки бизнеса, отмечает Назипов. Значительная ее часть отдана на аутсорсинг, кроме того, широко используются облачные технологии, что практически не встречается в традиционных банках.

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

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

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

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

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