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

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

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

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

Каким образом была перестроена работа с внутренними заказчиками?

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

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

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

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

Насколько устойчива эта схема работы? Что обеспечивает единство подходов к архитектуре ИТ-систем всех отделов?

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

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

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

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

Третий цементирующий слой — конт­роль за ходом проектов. Любой проект так или иначе использует общие ресурсы — инфраструктуру, службу поддержки. Для решения этой задачи нами разработаны проектные KPI. В их расчете задействованы такие параметры, как смещение сроков проектов, выполнение запланированного состава и объема работ и другие показатели, позволяющие отслеживать наше продвижение по каждому проекту. Для поддержки данного процесса мы используем Microsoft Project. Всех руководителей проектов, а также тех, кто их контролирует, мы обучили на курсах проектных менеджеров, разработали методологию — как вести работы, как отражать статус задач; раз в неделю проходят встречи с трекингом, скажем, по средам и четвергам фиксируется все сделанное, а в пятницу CIO получает полный отчет о текущем состоянии дел по всем проектам.

Наконец, четвертый цементирующий слой традиционен — это финансы и бюджет.

Практика управления проектами, контроль качества — это общебанковский стандарт или особенность ИТ-департамента?

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

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

Расскажите, как вы приступили к изменению технологии взаимодействия с бизнесом, — с чего начинали?

Прежде всего нужна команда единомышленников. Конструкцию взаимодействия с бизнесом в «Юникредите» нужно было полностью изменить, и именно под эту задачу и искали CIO. У меня подобный опыт был в Импексбанке, где стояли точно такие же проблемы, и именно к такой схеме мы пришли. В «Юникредите» мы продвинулись значительно дальше, поскольку в Импексбанке приходилось ломать сложившийся порядок, а здесь была поддержка правления и готовность к изменениям. Конечно, ИТ-служба, где люди проработали по десять-пятнадцать лет, ничего менять не хочет, все говорят, что ничего не получится. Были периоды, когда я каждую неделю приходил на правление, рассказывал о статусе проекта, о проводимых изменениях. Шел туда как в тумане, а выходил с уверенностью и ощущением правильности принимаемых шагов. Это было очень сложное время, и если бы сейчас мне предложили вновь решить такую задачу — наверное, я не стал бы браться за неё, уж очень хлопотное, тяжелое это дело.

А как теперь, в роли руководителя бизнес-блока, вы используете созданную систему взаимодействия?

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

Вы сказали о том, что для контроля качества ведения проектов применяются KPI. Насколько это комплексный подход для банка и насколько сложно вам было установить такие показатели для ИТ-службы?

Это тоже практика только ИТ-департамента. В нем шесть отделов. У каждого есть свой KPI, интегральный показатель по проектам этого отдела. В KPI входит два-три показателя, в том числе процент смещения сроков. Смотрим статус по всем задачам: желтый, красный, зеленый. Видно, куда, к какому цвету приходит набор показателей за неделю, месяц, квартал или год. Что означает желтый или зеленый, каковы конкретные параметры KPI, мы согласовывали с каждым отделом, в течение полугода подбирали верные значения параметров. Вначале мы не привязывали KPI к результату. Затем эта привязка была сделана, но все же она не жесткая, нет прямой зависимости, скажем, желтый KPI — премия такого-то размера. KPI и успешность ведения проектов на вознаграждение влияет, но определяет не более 40% его суммы. Если в целом в организации такая система не работает, то в рамках ИТ-отдела ее тоже нельзя жест­ко привязывать к вознаграждению.

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

Применяете ли вы сервисный подход, стоит ли задача формализации отношений с бизнесом, заключения внутренних SLA?

Нет, в целом пока не стоит. Мы пытались написать внутренние SLA на поддержку, но не получилось, по­скольку бизнес пока не чувствует в этом экономической необходимости. Функция поддержки у нас не разделена по бизнес-блокам, она общая, и затраты на нее берутся из общего котла. Пока такое положение не перестанет устраивать какой-либо отдел, оно не изменится — скажем, ему поддержки требуется мало, а платить за нее приходится много, как и тем, кому поддержка нужна в больших объёмах. Поэтому о масштабном переходе к сервисной модели речь пока не идет.

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

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

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

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

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