Об ИТ-стратегии, централизации, возможностях аутсорсинга и методологиях разработки мы беседуем с ИТ-директором российского «Нордеа Банка» Аркадием Затуловским.
Intelligent Enterprise: Многие годы банковская и — шире — финансовая отрасль была одной из самых передовых в области информационных технологий. Но сейчас, похоже, ситуация в различных отраслях более или менее выровнялась, а подходы к автоматизации стали более разнообразными. Взять хотя бы централизацию ИТ-инфраструктуры. На сей счет высказываются разные мнения — может быть, она не так уж и нужна банкам?
Аркадий Затуловский: С точки зрения ИТ-директора централизация, безусловно, полезна, потому что позволяет легче управлять основными банковскими системами, если мы говорим о прикладном программном обеспечении, или же инфраструктурой. Для бизнеса значение централизации, на мой взгляд, заключается, во-первых, в возможности унифицировать все продукты и бизнес-процессы (иначе этот вопрос решить не удается), а во-вторых, в более серьезном контроле: руководители разных бизнес-блоков могут видеть, что происходит и в филиалах, и в банке в целом, и соответственно грамотно управлять.
Централизация инфраструктуры дает нам полный контроль и управляемость. Она очень благоприятна с точки зрения информационной безопасности — хотя бы потому, что позволяет внедрять технические решения, рассчитанные на единую точку входа: например, достаточно защитить только один канал доступа в Интернет, только одну почтовую систему. Но это, конечно, сопряжено с дополнительными затратами, потому что сразу повышаются требования к каналам связи и т.д. И хотя с точки зрения затрат централизация инфраструктуры не всегда выгодна, с позиций управляемости и снижения рисков, еще раз повторю, такая инфраструктура однозначно лучше.
Некоторые российские банки провели у себя так называемую техническую централизацию — то есть создали единый ЦОД и поставили там серверы с копиями банковских систем каждого филиала. В работе прикладных программ при этом, разумеется, ничего не меняется, но создаются условия для того, чтобы сделать следующий шаг и перейти к действительно единой системе, обслуживающей все филиалы.
Для своего развития банки часто используют стратегию поглощений. Насколько важна централизация в этом случае?
Судя по практическому опыту слияний, который я стараюсь отслеживать, централизация очень важна, и без инвестиций в нее объединение не будет успешным. Решая купить активы и увеличить свой баланс, банк — да и любой другой бизнес — должен понимать, что предстоят еще затраты на техническое объединение. Лишь при этом условии актив, на мой взгляд, будет работать, и работать хорошо. Разобщенная же система рано или поздно станет неуправляемой, а риски возрастут до недопустимых значений. Поэтому мне представляется совершенно очевидной необходимость ввести вновь приобретенный банк в свою инфраструктуру — либо, наоборот, самому перейти в его инфраструктуру, что тоже является вполне штатным вариантом. Выбор зависит от того, какие системы установлены в двух банках, как они работают, насколько удовлетворяют существующим на данный момент требованиям.
Смежный вопрос — интеграция работающих в банке систем. Какая интеграционная стратегия, на ваш взгляд, оптимальна для банковской отрасли и какие технологии для нее наиболее актуальны?
В 1990-х годах все банки буквально молились на так называемые моновендорные решения. Считалось, что один поставщик способен обеспечить банк комплексом систем, которые вместе смогут охватить все сферы его деятельности, от расчета зарплаты и внутренних хозяйственных операций до собственно банковских приложений — кредитов, депозитов и прочего. А интеграция получится автоматически, просто за счет того, что все системы разработаны одним и тем же поставщиком. Наверное, в этом представлении была своя логика, но в начале 2000-х ситуация стала меняться. Банки поняли, что такого поставщика, который мог бы обеспечить все их потребности, просто-напросто не существует, и с этого момента в реальную жизнь начал активно внедряться ныне хорошо известный подход, получивший название best of breed — лучший в своем классе. Иначе говоря, банки начали покупать системы разных производителей, но при условии, чтобы они были лидирующими в своих областях.
Естественно, тут же встал вопрос, как организовать взаимодействие всех этих систем между собой. Это была очень тяжелая задача, вследствие актуальности которой и массовой востребованности соответствующих решений на рынке стали активнее развиваться интеграционные подходы, причем в виде разных технологий. Появилась известная модель SOA. Однако на рынке еще долго не было прикладных систем в этой архитектуре — их и до сих пор практически нет. Соответственно для интеграции применялись довольно-таки примитивные инструменты, такие как файловый обмен или прямая связь баз данных — DB Link. Реализацией таких решений занимались либо банковские отделы автоматизации, либо — очень часто — разработчики систем по договору с банками.
Сам по себе механизм DB Link очень неплох, особенно при централизованной архитектуре и достаточной пропускной способности сети. Недостаток только один: все взаимодействующие системы связаны попарно. Получающаяся паутина работает быстро и надежно, но поддерживать ее, особенно при смене версий, крайне хлопотно. Я знаю это не понаслышке, потому что в начале 2000-х участвовал в построении такой системы в банке, в котором тогда работал. Взаимодействие шло по схеме «точка — точка», и всё было прекрасно, кроме поддержки при внесении изменений в любое из интегрированных решений, на что уходило очень много сил.
Когда на рынок вышли промышленные интеграционные решения, это был ответ на сформировавшуюся — во всем мире и с некоторым запозданием в России — потребность в таких решениях, абсолютно независимых от тех систем, которые интегрируются. И после того как наш банк вошел в состав банковской группы Nordea, мы приняли ИТ-стратегию, где был специальный пункт о развитии интеграционного решения. Мы отлично понимали, что Nordea, покупая «Оргрэсбанк», рассчитывает на более серьезные результаты, чем 74-е место в рейтинге российских банков. Соответственно должны будут меняться системы, расти объемы и т.д. Первым пунктом была централизация, вторым или третьим — интеграция. Это четкая, ясная и понятная тенденция.
Так что мы осознанно занялись интеграцией. Начинали еще на старой АБС, к счастью, не торопясь. У нас не было необходимых компетенций, так что мы обратились к аутсорсингу: выбрали очень неплохого интегратора, с которым, кстати, продолжаем работать и сейчас, и он приступил к построению решения на основе IBM WebSphere. Мы предпочли этот продукт по той простой причине, что с ним уже тогда умели работать многие российские партнеры IBM. Сейчас мы продолжаем проект с нашим интегратором в рамках смены банковской системы.
К настоящему времени мы достигли той стадии, когда практически все проекты по смене прикладных платформ с самого начала увязываются через интеграцию: скажем, внедряется не просто клиент — банк, а клиент — банк, интегрированный с АБС через ESB. Для нас это стратегический подход, и насколько я знаю от коллег, с которыми встречаюсь на разных конференциях, все крупные банки действуют сейчас так же. Недавно на одной конференции я слышал доклад ИТ-архитектора Сбербанка, где описывалась именно такая смена подсистемы: поменяли только клиент — банк, а все остальное сохранилось в прежнем виде. Это мечта любого ИТ-директора — мы меняем какую-то систему, а сервисы, с помощью которых она обменивается с другими подсистемами, остаются. Помимо снятия ряда технических проблем это очень выгодно еще и с финансовой точки зрения. Интеграция позволяет нам на деле применять подход «лучший в своем классе», без нее все свелось бы к красивым словам без настоящих достижений.
Насколько, по-вашему, сегодня реален переход на аутсорсинг для отечественных предприятий?
Отношение к аутсорсингу развивалось по стандартному гартнеровскому циклу зрелости технологий: сначала завышенные ожидания, потом — разочарование, избавление от иллюзий и наконец осознание реальных возможностей. Сейчас стадия сильных колебаний, на мой взгляд, практически осталась позади и стало возможным говорить о практическом использовании. Для меня совершенно очевидно, что стратегически аутсорсинг — очень востребованная вещь, и он, конечно, будет развиваться. Его будут активно использовать предприятия всех типов и отраслей, хотя в России условия для аутсорсинга не такие благоприятные, как на Западе. Могу говорить об этом не без основания, потому что мне знаком опыт работы с атусорсерами в Скандинавии, где находится наш материнский банк.
Я не очень верю в вероятность стопроцентного аутсорсинга по той простой причине, что передача на аутсорсинг по сути означает снижение твоих возможностей по управлению рисками. Безусловно, на аутсорсинг можно отдать неосновную деятельность — так считают западные коллеги, да и на российском рынке у многих такое же мнение; но там, где сосредоточены основные риски, желательно все-таки опираться на собственные ресурсы. На данный момент заказчики не решаются отдавать системы, обеспечивающие ключевые процессы, и их опасения вполне обоснованы, потому что аутсорсеры не могут (да и не демонстрируют желание) взять на себя реальную ответственность. Естественно, аутсорсинг становится слишком рискованным для заказчика. Скорее всего должны еще сформироваться условия для следующего шага. Но рынок развивается в этом направлении.
Если говорить о финансовой стороне дела и об отечественном рынке, то мне лишь в последние год-два попадаются более или менее приемлемые предложения — в большинстве же случаев аутсорсинг оказывается существенно более дорогим вариантом, чем использование внутренних ресурсов. Судя по всему, норма прибыли, которую закладывают в свои предложения российские поставщики услуг, существенно выше, чем на Западе. Но сейчас уже некоторые компании научились нанимать специалистов в регионах и за счет разницы зарплат снижать цену для заказчика. Возможно, это один из путей.
Не могли бы вы привести пример использования прикладного решения класса best-of-breed и рассказать о наиболее характерных моментах, связанных с его внедрением?
В качестве примера могу рассказать о внедрении в нашем банке решения Oracle Siebel CRM, которое мы реализуем совместно с командой AT Consulting.
У компании Oracle есть такая услуга: консультанты бесплатно выполняют некое (естественно, не слишком глубокое) обследование бизнес-задач заказчика и представляют отчет, с помощью каких продуктов Oracle можно решить те или иные задачи, каким образом, в какие сроки и с каким бюджетом. Это очень полезно с точки зрения принятия решений, потому что бизнес получает некий сторонний взгляд и может сравнить мнение серьезного консультанта со стороны разработчиков с мнением внутреннего ИТ-отдела.
В нашем случае рассматривались в основном операции, охватываемые системой Siebel. Для нас Siebel — один из стратегических продуктов, с помощью которого мы собираемся решать задачи двух типов. Во-первых, Siebel содержит механизм управления потоком работ — Workflow engine, на основе которого мы можем строить кредитные конвейеры. Во-вторых, это система управления взаимоотношениями с клиентами — CRM, так что она дает нам возможность, например, добавить CRM-составляющую в кредитный конвейер или построить CRM для работы с корпоративными клиентами. В идеале, если позволит бюджет, мы хотели бы, конечно, создать на основе Siebel полноценный единый фронт-офис. Конечно, в Siebel есть элементы, которые не очень подходят к российским условиям, — в основном они связаны с особенностями нашей системы учета, которая существенно отличается от западной, но развитые возможности кастомизации закрывают эту проблему.
С точки зрения развития прикладного решения в нашем банке важно, что Siebel — не коробочный продукт с собственной жесткой логикой, которую трудно изменить под себя. Вместе с тем это и не универсальный конструктор, где можно сделать всё что угодно, но всё надо запрограммировать. Для нас это нечто среднее — предметно-ориентированная платформа, позволяющая работать с блоками «удобного размера», не слишком крупными, но и не очень мелкими. В Siebel есть объекты, относящиеся к тому или иному виду деятельности предприятия или, как в нашем случае, банка. Это прикладные объекты, которые очень четко отображаются в нашей предметной области, — клиент, заявка, анкета, продукт, кредит.
Вы упомянули ИТ-стратегию. Может быть, мой вопрос покажется примитивным, и все-таки рискну спросить: что вы понимаете под этим термином?
ИТ-стратегия задает направление развития — куда мы идем, — и обосновывает его, почему мы идем именно туда. Куда — это, например, мы меняем АБС, меняем такую-то и такую-то систему, переходим от децентрализованного решения к централизованному. Почему — это связь наших мероприятий со стратегией бизнеса. Бизнес-стратегия говорит, что мы в рознице собираемся делать то-то, в корпоративном блоке то-то, в инвестиционном — то-то, и мы записываем в ИТ-стратегию, каковы должны быть наши действия, чтобы со стороны ИТ-службы обеспечить выполнение этих бизнес-задач. Есть у ИТ-отдела и внутренние задачи, никак не связанные с бизнес-стратегией и тем не менее важные для банка в целом, — скажем, информационная безопасность или восстановление после аварии, если таковая произойдёт. Их обоснование — необходимость повысить надежность и стабильность работы банка и т.п.
Иногда в ИТ-стратегии описываются и конкретные пути достижения поставленных целей, например: мы используем стопроцентный аутсорсинг. Или мы используем аутсорсинг с осторожностью, балансируя между затратами, рисками и выгодами. Или мы выводим все наши ИТ-подразделения в отдельную компанию, самостоятельную в юридическом и финансовом отношении. Или нанимаем компанию, которая будет сопровождать всю нашу инфраструктуру.
А кто должен заниматься разработкой ИТ-стратегии — собственное ИТ-подразделение компании или внешние консультанты?
Я не раз обсуждал этот вопрос с коллегами и в конце концов пришел к выводу, что всё довольно просто. ИТ-директор может отдать разработку стратегии аутсорсеру, если самостоятельно ему документ писать лень или у него нет на это времени (а бюджет есть). Другой случай — когда ИТ-директор хочет заручиться весомым именем консультанта, поскольку понимает, что ему самому руководство может и не поверить. В такой ситуации он постарается пригласить известных зарубежных консультантов, чтобы те преподнесли его идеи как свои. Это совершенно нормальный путь, чтобы добиться от бизнеса необходимых решений. Во всех остальных случаях ИТ-директор пишет ИТ-стратегию сам.
Вы комбинируете собственную и внешнюю разработку. Используете ли при этом какие-нибудь известные методологии?
Что касается специализированных систем, поддерживающих разработку, то здесь ответ отрицательный. Мы попытались использовать Rational Rose, даже заключили договор с партнером IBM и открыли проект, но в итоге его решено было заморозить. Дело в том, что многие функции продукта у нас, как оказалось, есть, потому что мы используем собственную АБС и успели разработать вокруг нее целый ряд программ, решающих вспомогательные задачи, такие как учет заявок на доработку или, скажем, формирование релизов. Мы надеялись, что Rational Rose позволит нам увязывать бизнес-требования с функциональными и в случае возникновения новых требований со стороны бизнеса даст возможность понимать, какие подсистемы реализация этих желаний может затронуть. Но при более детальном изучении продукта стало ясно, что мы этого не достигнем. Не исключено, что мы еще вернемся к данной задаче, потому что какую бы стратегию мы ни выбрали с точки зрения аутсорсинга, та часть, которая называется анализом, или аналитикой, скорее всего все равно будет находиться внутри банка. Но пока я не вижу продукта, который нам подошел бы. На рынке есть инструменты, полезные с точки зрения учета ресурсов, заявок и т.д., но они гораздо проще того, что нам нужно, и не обеспечивают сквозного увязывания требований по всей цепочке, включая тестирование. В том проекте партнер написал нам несколько регламентных документов, которые нам в любом случае не помешают, и это пока все.
Мы используем методологические политики, которые получили от Nordea. У нас классическая постановка процесса разработки: есть аналитик, есть архитектор, есть технический проектировщик для сложных задач, разработчики и группа тестирования.
Но мы не пишем сценариев использования на языках моделирования (UML), а ограничиваемся менее формальным описанием, потому что бизнесу сложно согласовывать техническое задание, которое представлено в форме сценариев. Возможность использования UML обсуждалась, но пока мы отказались от такой идеи, потому что с точки зрения взаимодействия с нашими заказчиками это не самый лучший вариант (чтобы читать UML-документы, нужна определенная подготовка), да и для нас самих здесь нет серьезных преимуществ. Рано или поздно мы, наверное, к этому вернемся, но я не вижу причин спешить. Мы спокойно занимаемся другими делами, в том числе внедряем agile-технологии, недавно начали пилотные проекты по внедрению SCRUM в отделе разработки и технологии КАНБАН в отделе инфраструктуры (эти же проекты ведёт и материнская компания Nordea), активно развиваем концепцию бережливого производства.
