Жиль Бланшар, директор управления информационных систем «Банка Сосьете Женераль Восток» (BSGV), в российском отделении компании работает два с половиной года. За это время практически полностью была обновлена ИТ-инфраструктура; банк перешел на новые ключевые бизнес-приложения и в целом изменил архитектуру ПО; перестроены отношения ИТ-службы и бизнес-подразделений в соответствии с методологией ITIL и созданы две системы мониторинга — сетевых структур и серверов баз данных и приложений. Об этом — наша беседа с Жилем Бланшаром.

Человек номера

Жиль Бланшар родился 12 марта 1948 года. По образованию — специалист в области математики и информатики. С 1968-го по 1987-й — преподаватель математики, основатель Математического научно-исследовательского института Полинезии и автор двух учебных пособий по этому предмету. В «Банке Сосьете Женераль» работает с 1988 года: сначала отвечал за архитектуру ИТ-систем сети отделений во Франции, затем занимал должность заместителя директора группы «Сосьете Женераль» по закупкам. С 2005-го — директор по информационным системам «Банка Сосьете Женераль Восток».

Intelligent Enterprise: Расскажите о стратегическом планировании работ в обрасти ИТ. Как вы расставляете приоритеты между инновациями и поддержкой сущест­вующих систем? На какой срок составляете планы в области ИТ?

Жиль Бланшар: ИТ-подразделение я рассматриваю как сервис-провайдера, обеспечивающего банку дополнительную добавленную стоимость. Это значит, что мы разделяем цели банка и должны своевременно предоставить ему новые возможности, новые сервисы и новые продукты. С такой точки зрения ИТ-стратегия — это точная копия бизнес-стратегии, но с технологической компонентой.

О банке

Коммерческий акционерный банк «Сосьете Женераль Восток» (BSGV) основан в Москве в 1993 году как инвестиционный.

Является стопроцентно дочерней структурой «Сосьете Женераль» — первой частной банковской группы Франции по объему чистой банковской прибыли и количеству отделений, третьего крупнейшего финансово-инвестиционного банка в еврозоне по объему чистой банковской прибыли и десятого банка в мире по объему привлеченных активов. С 2003 года BSGV — универсальный банк, обслуживающий корпоративных и частных клиентов. На 31 марта 2007-го банк обслуживал более 100 000 част­ных и 2500 корпоративных клиентов. В BSGV работает 1500 сотрудников.

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

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

Вообще рост бизнеса создает два типа проблем. Один связан с будущими бизнес-требованиями. По моему опыту имплементация новой ИТ-системы, включая переход на новую архитектуру, инфраструктуру и новые программные платформы, во всей распределенной структуре отделений банка занимает от восьми до двенадцати лет. С учётом этого периода мы обязаны предвидеть грядущие изменения, и при внедрении новой ИТ-системы нужно принять во внимание, в каком мире мы будем жить в будущем с точки зрения бизнеса, какие будут требования с его стороны и какие условия. А второй тип — это проблемы, возникающие из-за размера территории, сети, систем хранения информации и данных и так далее. Это тоже нужно сразу учитывать. Это уже вопрос не к бизнесу, а ко мне: что нужно сделать, чтобы не ходить потом каждые два года с просьбами выдать еще один-два миллиона на какие-то изменения.

Основные вложения в инфраструктуру и платформы делаются на 8—12 лет. Когда мы делаем инвестиции в создание сети, я планирую на 6—8 лет, в программные продукты — от трёх до пяти. Что же касается рабочих станций, то тут мы не планируем серьезных изменений архитектуры на очень долгое время — только апгрейды и адаптацию. Именно поэтому в 2005 году, создавая новую инфраструктуру, мы закупали оборудование, значительно превышавшее наши тогдашние потребности, с большим запасом, сильно «на вырост». Уже тогда, проектируя вместе со своей командой новую инфраструктуру, я ожидал, что очень скоро бизнес потребует от нас множества новых продуктов. Так и произошло.

Сейчас на ходу что-то менять было бы уже поздно. У BSGV был удобный момент для серьезных изменений в инфраструктуре, когда все проекты развития оказались временно заморожены в связи с коренной перестройкой систем и новых продуктов никто не внедрял. И вот тогда практически одновременно мы сменили центральный компьютер, системы хранения, сетевое оборудование, архитектуру приложений, а также внедрили систему мониторинга и основанную на рекомендациях ITIL службу поддержки (см. врезку «Проект модернизации инфраструктуры и системы мониторинга». — Прим. ред.).

У вас очень перспективное планирование. Ну а если что-то в бизнесе пойдет не так и эти инвестиции окажутся напрасными?

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

А каковы другие ключевые приоритеты ИТ-стратегии, например, в развитии функциональности?

Восемь месяцев назад мы закончили переход на новую банковскую систему Oxygen. Открытие этого проекта было связано с изменением приоритетов бизнеса. В 2003 году руководство приняло решение скорректировать акценты бизнеса «Банка Сосьете Женераль-Восток» — превратить инвестиционный банк в ритейловый и кредитный. Этим и была обусловлена смена банковской системы и переход на полностью стандартизированное, предназначенное для ритейлового банка ПО. При этом мы сохранили лишь несколько старых приложений, например программу составления отчетности для ЦБ, поскольку она представляет собой практически независимое приложение. У Societe Generale в мире 34 дочерних компании, и каждая подстраивает приложение под мест­ные особенности. Мы тоже должны были адаптировать ПО для российского рынка, приспосабливать его к размеру страны, к многочисленным временны’м поясам, алфавиту, различным схемам расчетов.

Проект перехода на новую банковскую систему BSGV занял 14 месяцев — в группе Societe Generale это самое быстрое внедрение. Мы намеренно решили двигаться быстро. Параллельно велись два проекта: построение новой ИТ-инфраструктуры и перевод на новую банковскую систему. Я думаю, что столь быстрое внедрение — в основном следствие очень тесного взаимодействия ИТ и бизнеса, налаженного взаимопонимания между ними. Кроме того, для банка это был проект первостепенной важности. Более того, мы решили вести проект точно по графику — менять график было запрещено.

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

Вы сказали об адаптации стандарт­ного ПО для российского рынка. Насколько жестко ИТ-деятельность регламентирована в рамках Societe Generale, насколько строго вы обязаны подчиняться правилам и нормам, принятым во всей банковской группе?

В банковской группе Societe Generale допускается довольно большая гибкость по отношению к филиалам в разных странах. Ключевое слово здесь — адаптация. У нас не стоит задача повсеместно копировать ИТ-системы. Менеджмент волен в широких пределах адаптировать ПО к нуждам отдельной страны, мы в России столкнулись с этим и были к этому готовы. Другой пример: переговоры о закупке оборудования, как правило, ведутся централизованно, глобальные соглашения с вендорами заключаются на уровне группы «Сосьете Женераль». Сами же закупки осуществляются на местах. При этом мы вправе покупать нужное нам оборудование в рамках глобальных соглашений, но в случае более выгодных условий со стороны других, местных поставщиков вольны и не делать этого. Точно так же мы должны следовать общим правилам, но вправе и отклоняться от них, если можем убедительно мотивировать отход от общей практики.

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

А каковы приоритеты в области развития ИТ-инфраструктуры?

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

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

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

Проект модернизации инфраструктуры и системы мониторинга

Проект модернизации инфраструктуры и системы мониторинга стартовал в начале 2006 года. Его целью было решение двух блоков вопросов: перестройка и дооснащение двух серверных помещений, а также создание централизованной системы хранения и резервного копирования данных. Подрядчиком проекта стала компания IBM Global Services. Сейчас завершены работы в двух серверных помещениях банка и поставлено оборудование, необходимое для нового ЦОДа, включая системы кондиционирования MGE и источники бесперебойного питания производства Liebert-Hiross. Система хранения и резервного копирования данных построена на базе хранилищ IBM DS8100, ленточных библиотек IBM 3584 и программного обеспечения IBM Tivoli Storage Manager.

Сейчас в BSGV созданы две системы мониторинга. Одна отслеживает положение дел в корпоративной сети, включая реальную пропускную способность каналов, доступность тех или иных участков, работоспособность устройств. Она дает возможность не только видеть, что происходит, но и в дистанционном режиме администрировать активное сетевое оборудование. Вторая система отслеживает поведение серверов баз данных и приложений и не только позволяет удаленно администрировать их, но и дает доступ к лог-файлам, чтобы при необходимости быстро получить «историю вопроса». Жиль Бланшар замечает, глядя на «ИТ-сыр» (IT-cheese), в виде которого изображаются на экранах все отслеживаемые системой объекты: «Вот этим я немножко горжусь» (см. рисунок). И справедливо: столь полной и четко организованной системой мало кто может похвастаться.

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

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

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

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

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

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

Нередко бывает очень сложно ввести бурный поток пожеланий в жесткое русло возможностей ИТ-службы. Ваш рецепт?

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

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

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

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

Такая формализация отношений с бизнесом приближает вас к использованию ИТ-аутсорсинга. Каково ваше отношение к этому виду услуг?

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

Формализация процесса тестирования

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

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

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

ИТ-проекты затратны, и обосновать эти инвестиции не просто. Каков ваш опыт в решении таких вопросов?

Я считаю, что это одна из принципиальных задач CIO — убеждать руководство в необходимости тратить средства на модернизацию ИТ. Думаю, CIO должен создать такую ситуацию, когда руководство ему доверяет, быть в постоянном контакте со своими руководителями. Если он все время сидит в своем кабинете — всё пропало. Требуется ряд встреч, множество телефонных разговоров, постоянный обмен мнениями, идеями, чтобы создать некое общее ви’дение, сформулировать единые взгляды на развитие ИТ, на то, какими должны быть ИТ-системы. Только тогда, основываясь на своем опыте, с цифрами в руках, CIO сможет показать, что возможный возврат инвестиций будет именно таков, как он говорит. В ряде случаев мы можем точно посчитать ROI. Но часто сделать это проблематично, в том числе для проекта мониторинга. Но если общее видение есть, если топ-менеджмент понимает, почему требуется именно такой подход и именно такие ИТ-системы, то убедить людей значительно легче.