Подкопаев олег александрович. Олег Подкопаев: На базе сложившейся архитектуры

Что будут делать банки в наступившем году в области ИТ? Какие проблемы и какими средствами станут решать? Своим видением ситуации в российских банках «первой сотни» делится Олег Подкопаев, председатель клуба банковских ИТ-директоров CIO Bank.

Intelligent Enterprise: Банковский сектор - один из самых старых и активных потребителей ИТ. Можно ли говорить о типовой ИТ-структуре крупного российского банка?

Олег Подкопаев: Банки уже привыкли рассматривать ИТ как один из своих основных производственных ресурсов и планировать развитие этого ресурса. У крупных банков стандартизируется и видение, и применяемые технологии. С высокой долей вероятности можно говорить о том, что типовая ИТ-структура современного российского банка сформировалась

Каналы взаимодействия банков с клиентами многообразны и в принципе не ограничены: от отделений, Интернета до самых современных разнообразных мобильных устройств. Бизнес-логика взаимодействия с клиентом рассматривается как единый слой с равным уровнем сервиса вне зависимости от канала взаимодействия, что позволяет предоставлять единый уровень обслуживания вне зависимости от канала доступа, с одной стороны, и с другой – существенно снижает сроки и затраты на внесение изменений и вывод новых продуктов и услуг.

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

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

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

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

Через все эти слои проходит слой «продуктов и клиентов», поскольку банку необходимо на каждом уровне бизнес-процесса иметь полное представление о том, что он делает и с кем он работает. Также сквозным образом обеспечивается доступ к безопасности. Управление ею ведется по всей архитектуре банка централизовано, а не в каждом процессе, продукте отдельно.

Какими технологиями и продуктами, архитектурными подходами реализуется такая структура?

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

Известно, что российские банковские приложения развивались как монолиты. Сейчас происходит их «раздирание на части». Плохо или хорошо это получается – пока сказать довольно сложно. Я знаю единственный хороший опыт в компании ЦФТ. У «Диасофта» я пока не видел хороших внедрений, хотя декларируется неплохая архитектура. При этом все равно происходит формирование практики на клиентах. Компании продолжают мало инвестировать самостоятельно. Их можно понять, поскольку риски существенные, угроза кризиса, и все это приводит к уже известному пути. Инвестиций для создания новой системы с нуля нет. Берут старую систему, разделяют на части, внедряют на клиенте, дорабатывают, и через некоторое время эта новая «инкарнация» признается достаточно хорошей.

Что касается производительности таких систем, то, несмотря на многочисленные тесты, случаев доказанной производительности мало. Принципиальным остается вопрос, на каком оборудовании достигается производительность, на каких «железках». Не каждый даже крупный банк может себе позволить поставить действительно мощный ИБМовский сервер.

В этой ситуации, как ответ на запросы российских банков, идет реакция поставщиков зарубежных специализированных систем. Ясно, что комплексные западные АБС в России не внедряются, в силу сложностей локализации. Но специализированные системы, например кредитный бэк-офис, с привязыванием его к другим действующим приложениям – такие связки внедряются хорошо. Иностранные вендоры ПО стали этим пользоваться и без больших вложений в локализацию проникать на рынок.

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

Что можно сказать о подходах к интеграции приложений?

Это тенденция – изменения в понимании сервисного подхода. Я считаю, что SOA и сервисный подход у нас только в стадии становления, значительной практики пока накоплено не было. Стандартом де-факто в банках является iBM WEB Sphere, далеко за нею – продукты Oracle, и потом уж все остальные. По мере использования накапливается негатив. Высока стоимость интеграции на этих продуктах, есть проблемы с производительностью и внесением изменений.

Поэтому банки активно ищут альтернативу этому продукту, некоторые готовые перейти на «что угодно, только бы уйти с Web Shpere». Однако найти такую альтернативу именно для банковской интеграции довольно сложно. Многие компании предлагают «интеграцию вообще», но интеграторов, имеющих опыт работы именно с банковскими системами, мало, как по решениям, так и по экспертизе. А банки при этом требуют быстроту внедрения, легкость внесения изменений, производительность и надежность, что, основываясь на накопленном опыте, достигнуть довольно сложно.

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

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

Второй крупный минус сегодняшней реализации в SOA заключается в огромном числе сервисов. Я видел уже довольно много решений и могу сразу сказать: если система предоставляет тысячи сервисов – извините, это неуправляемо. Если идет переход на интеграционную шину, то общее число сервисов должно быть не более сотни. Тогда можно вести реальную оркестровку. Если же сервисов тысячи, нужно держать людей, которые будут следить за ними, управлять всем этим многообразием и изменениями в нем, а это практически неподъемная задача.

BI и хранилища: как развиваются они?

С хранилищами и аналитикой все гораздо лучше. В том или ином виде они присутствуют в каждом банке. Есть довольно много российских игроков с прикладными решениями, в том числе по МФСО, по очистке данных с конкретными применениями для российского рынка. Налицо и массированное проникновение западных производителей такого ПО, предлагающих тяжелые решения именно как инструментарий.

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

Существенно, что BI-инструментарий, который сейчас применяется, довольно сложен для бизнеса и требует навыка. Но положительный фактор – полное разделение информационных и аналитических систем. Это дает возможность развивать настоящие средства Business Intelligence. Бизнес получает возможность самостоятельно получать все более сложные отчеты, выявлять связи и зависимости без привлечения айтишников. Стали появляться локальные решения на базе сложных западных инструментариев, что важно, и в частности, подталкивает российских поставщиков подобных систем.

ИТ-аутсорсинг, облака и SaaS – есть ли здесь реальные изменения?

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

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

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

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

Эти тренды связаны между собой. Компонентная архитектура позволяет проще и лучше переходить к сервисам. Слияния в монолиты вновь не произойдет, скорее монолит будет пониматься как единый доступ к сервисам, получение их из одной «розетки». Их только надо будет правильно потреблять. А компоненты выносить в облако значительно легче, чем монолит. Компонентный подход влияет и на востребованность аутсорсинга. Банк занимается интеграцией: берет сервисные компоненты и связывает их так, как ему нужно. Ответственность поставщика – давать те сервисы, которые декларировались.

Материал подготовлен по докладу г-на Подкопаева на конференции «ИТ в финансовом секторе» AHConferences, декабрь 2011 г.

Родился в 1969 году в Москве. Закончил в 1992 году Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины».

8 лет занимался разработкой и внедрением западных банковских систем в России, Словакии, Венгрии, Бельгии и Англии, пройдя путь от разработчика до руководителя проектов.

В 2001-2003 году работал в Управлении банковских технологий Банка Москвы.

В 2003-2004 годах возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка.

В 2004 году успешно сдал экзамен на звание Certified Information System Auditor.

С 2004 года по октябрь 2010 - директор Департамента информационных технологий группы Русфинанс. За время его работы в группе проведено развертывание контакт-центра, насчитывающего более 750 рабочих мест и обеспечивающего обслуживание более 2,5 миллионов телефонных звонков в месяц. Разработана и внедрена инфраструктура, поддерживающая функционирование 60 региональных представительств и более 10 тысяч точек продаж. Успешно проведена инфраструктурная, технологическая и организационная интеграция в рамках группы Русфинанс ООО Русфинанс, Промэк-Банка и банка СКТ. Осуществлено внедрение прикладной архитектуры, обеспечивающей на данный момент обработку более 1,5 миллионов кредитов.

2011 - 2013 гг - заместитель генерального директора R-Style Softlab по стратегическому развитию.

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

Является председателем Клуба делового общения банковских ИТ-директоров (СIOBANK Club).

Семья

Женат. Воспитывает дочь.

Награды

Лауреат национальной ежегодной премии IT Лидер 2007 «За выдающийся вклад в развитие информационных технологий в России».

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

Родился в 1969 году в Москве, в 1992-м закончил Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины».
В 2004-м успешно сдал экзамен на звание Certified Information System Auditor.
В сфере информационных технологий работает более 15 лет, восемь из которых занимался созданием и внедрением западных банковских систем в России, Словакии, Венгрии, Бельгии и Англии, пройдя путь от разработчика до руководителя проектов.
В 2001-2003 годах работал в Управлении банковских технологий Банка Москвы.
В 2003-2004-м возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка.
С 2004-го по настоящее время является CIO группы «Русфинанс».
Лауреат национальной ежегодной премии IT Лидер 2007 «За выдающийся вклад в развитие информационных технологий в России».

Intelligent Enterprise: Каким образом вы планируете развитие ИТ-систем, на что опираетесь при разработке ИТ-стратегии?

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

Наконец третий блок - «экстра». Это суперпроекты, экстраразвитие - нечто такое, что на наш взгляд позволит бизнесу развиваться быстрее, или повысит его эффективность, или даст какие-то дополнительные преиму­щества.

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

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

Как вы этого добиваетесь?

Мы стараемся работать на основе сервисно-ориентированной модели, выступая как некий «поставщик», предоставляющий сервисы своему «заказчику» - бизнесу. Соответственно чтобы успешно работать с заказчиком, необходимо выстроить коммуникации с ним, и для этой цели у нас внедрен институт эккаунт-менеджеров (account manager). Это сотрудники ИТ-департамента, постоянно работающие с определенными бизнес-направлениями. Они опеспечивают связь ИТ-службы с заказчиком - скажем, с департаментом автокредитования или каким-то другим отделом. Именно эккаунт-менеджеры согласуют состав и уровень сервисов, которые мы предоставляем бизнесу, контролируют исполнение проектов, представляют заказчику всю необходимую информацию. Очень важно, что эти люди говорят на языке бизнеса. Например, совершенно бессмысленно говорить бизнесу о «доступности каналов связи до офиса продаж в течение 99,9% времени» - в любом случае там поймут это по-своему. Но фраза типа «вы сможете в этой точке выдавать кредиты по схеме 24×7 с одним часом простоя в две недели в среднем» для функциональных заказчиков вполне ясна и приемлема. Все вопросы о работоспособности приложений мы проговариваем и объясняем в таком же ключе, и это позволяет достичь ясности и однозначного понимания.

Когда мы стали внедрять понятие сервисов, конечно же мы начали с ИТ-сервисов, говорили о доступности линий, приложений и проч. Это вводный этап, когда бизнес приучается к понятиям сервисов, SLA (service level agreement) и учится взаимодействовать с ИТ, а ИТ, в свою очередь, - с бизнесом. С бизнес-подразделениями организуются регулярные встречи, где представляются численные параметры (KPI) качества ИТ-сервисов, обсуждаются отклонения от желаемых значений, планируются корректирующие действия, устанавливаются целевые показатели.

Этот технический язык в принципе работает, для бизнеса понятна техническая нотация (т. е. ее можно объяснить), термины ИТ вполне доступны, но далеко не комфортны. Поэтому сейчас мы переходим на трехуровневую модель сервисов. Самый верхний уровень - бизнес-сервисы. Они показывают бизнесу, что’ он будет иметь от ИТ и сколько это может стоить. Например, сервис выдачи кредитов. У него есть характеристики: время выдачи, режим работы (24×7, 8×5), непрерывность, срок восстановления после сбоя и другие KPI. Такую систему KPI мы уже внедрили для департамента автокредитования, этот подход у нас активно развивается и в других сферах деятельности и новостью ни для кого в компании не является.

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

На следующем уровне - менеджеры по инфраструктуре (infrastructure manager), которые отвечают непосредственно за работоспособность серверов, сетей и телефонии. С ними доступность сервисов также согласовывается, и на уровень бизнеса вновь отправляются согласованные предложения ИТ-службы о реальном уровне доступности сервисов и о мерах, необходимых для их обеспечения. Принципиально важно, что при этом для бизнеса есть один контакт, одна точка входа - его эккаунт-менеджер. Он строит дерево сервисов и их показателей как сверху вниз, так и в обратном направлении - вначале согласовав с бизнесом KPI, дальше транслирует их на уровни приложений и инфраструктуры. Затем мы измеряем реальные уровни сервиса и говорим: KPI на данном уровне такие-то. Для расчёта у нас есть экспертные оценки, цифры сторонних провайдеров и наши собственные системы мониторинга. Эккаунт-менеджер передаёт собранные сведения бизнесу и сообщает, какие реальные значения KPI возможны. Ну а дальше начинаются переговоры. Если требуются существенные улучшения по сравнению с текущим положением, обсуждаются соответст­вующие изменения бюджета.

Бюджетирование ведется тоже с опорой на сервисы?

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

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

А дальше мы видим: чтобы такая новая система нормально работала, нужны подходящие серверы, она должна быть интегрирована в сущест­вующую структуру, все это следует расположить в приемлемом датацент­ре с резервным копированием и так далее - так и выстраивается цепочка. Мы открыто кладем карты на стол и объясняем руководству и бизнесу (нашим спонсорам и заказчикам), зачем в этой цепочке нужен каждый элемент. И так по всем пунктам, по всем планам бизнес-подразделений.

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

Сложно ли объяснить функциональным заказчикам преимущества сервисного подхода к ИТ? С какими проблемами вы сталкиваетесь, переводя взаимодействие на сервисную модель?

Объяснить бизнесу, зачем нужен сервисный подход в области ИТ, по моему опыту проще, чем объяснить это сотрудникам ИТ-службы. Казалось бы, должно быть наоборот, айтишники должны иметь представление об ITIL и связанных с этим подходах, но это не вполне так.

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

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

Какими могут быть аргументы «за»?

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

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

Третий момент - взаимопонимание, коммуникации. Часто люди работают на смежных направлениях, влияющих друг на друга. И совершенно не понимают, что происходит вокруг. Каждый пытается справиться с проблемой изолированно, тратит массу усилий, но ничего не получается. Если бы они по­пробовали решать задачу сообща, дело пошло бы совсем иначе и продвигалось бы быстрей. При сервисном подходе любой сотрудник видит своих смежников, понимает, «на кого он работает», кто и как пользуется его услугами. Мы регулярно, обычно раз в неделю, проводим встречи на каждом уровне сервиса. Их проводят эккаунт-менеджеры. Согласовав какие-то новые требования с бизнесом, расставив приоритеты, они обсуждают изменения и текущее положение дел с инженерами, специалистами, ответственными за инфраструктуру и приложения (infrastructure manager и application manager). Люди начинают общаться, рассказывать о своей работе, и в результате они лучше понимают, что происходит. Такого целостного ви’дения в компаниях обычно нет, и привнести его сложно. А при регулярном общении люди уясняют себе, что в организации кроме них еще кто-то работает и даже делает что-то по­лезное.

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

Как вы оцениваете качество ИТ-сервисов? Ведется ли у вас непрерывный мониторинг их предоставления?

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

Теперь наша цель - интеграция этих сведений в единую картину. Мы планируем на базе HP OpenView создать единую CMDB (Configuration Management Data Base), где будет учитываться состояние любого подключенного к сети устройства, приложения, сервиса. Затем на её основе можно сконструировать единое дерево сервисов. Под каждый сервис расписываются определенные приложения, серверы и пр., и все они имеют агентов, отслеживающих их состояние. Тогда в любой момент можно поднять дерево и выяснить, с чем связана недоступность того или иного глобального сервиса. Это мы планируем сделать в нынешнем году.

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

Вы говорили о значении проектного взгляда на ИТ-затраты. Как у вас организовано проектное управление?

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

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

Отвертеться они не могут: руководство захотело, значит придется, ничего не попишешь. Но чтобы давать результат, проект­ный подход должен быть реально поддержан на всех уровнях. Люди должны созреть профессионально и ментально быть готовыми к принципиальному изменению в подходах к их ежедневной деятельности. Поэтому я исповедую другой подход - снизу вверх: сотрудники должны почувствовать, зачем нужны какие-то действия, убедиться на практике, что это и вправду помогает. Мы так и делаем, вводим какие-то практики де-факто. Например, начинаем нормально планировать. У проекта есть план, при этом регулярно проводятся встречи. И люди видят: да, план выполняется, проект продвигается, у нас получается! Пишем отчеты. Зачем? Чтобы понять, что было в каждый момент времени, что произошло и что нам мешало двигаться дальше. Наконец доходит до итогов. И тут самое время сказать: а вот если бы у нас был паспорт проекта, то сейчас гораздо лучше было бы видно, добились мы того, чего хотели, или нет. Когда всё это вводится, возникает и необходимая структура.

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

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

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

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

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

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

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

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

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