ИТ-ДиректорИТ в бизнесеУправление

Две роли одного CIO

Григорий Рудницкий | 03.03.2014

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Две роли одного CIO

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

Какое место занимает ИТ-департамент в структуре банка?

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

Каким образом в банке реализован механизм запуска новых ИТ-сервисов?

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

Мы используем в проектной деятельности все стандарты PMI (Project Management Institute), а также применяем у себя лучшие зарубежные практики по управлению проектами, адаптированные под нашу турбулентную внешнюю среду. По этой причине больших и «тяжелых» проектов у нас нет, мы их разбиваем на этапы с конкретными и быстрыми результатами. Для каждого проекта расписан анализ затрат и выгод (cost-benefit analysis). Конец проекта знаменует не внедрение системы, процесса или сервиса, а приблизительно трехмесячный период после запуска основного функционала. Таким образом, мы видим реализацию выгод, заявленных на начальном этапе, уже в реальных условиях. Приоритизация начинается формироваться в августе, а завершается в ноябре — декабре. Список проектов является неотъемлемой частью операционного планирования банка на следующий год. 

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

Насколько сложным был процесс построения вашего проектного офиса?

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

Не возникает ли внутреннего противоречия?

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

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

Как в вашем банке реализован механизм финансирования ИТ-проектов? С кем вам приходится взаимодействовать по данному вопросу?

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

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

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

Какими принципами вы руководствуетесь при наборе команды, то есть сотрудников ИТ-департамента?

Здесь тоже нужен баланс. В ИТ есть разные процессы. Одни рутинные, повторяемые и не требующие особых знаний и квалификации. Их можно отдать на аутсорсинг либо выстроить у себя, а на эти позиции набрать неквалифицированных сотрудников, может быть студентов. Поскольку мы работаем в финансовой организации, то очень инновационных людей мы не берем. Для нас важно, чтобы не только человеку, но и организации было хорошо. Во время интервью с кандидатами я смотрю, насколько внутренние ценности компании соответствуют внутренним ценностям человека. Поэтому на повторяемые процессы я приглашаю людей, которые готовы и хотят учиться, набирая знания в разных областях. Далее — специалисты, уже накопившие определенный опыт и стремящиеся к дальнейшему развитию в своей области, но при этом от такого развития должна получать эффект и компания. Третья категория — менеджеры, имеющие опыт управления разными людьми. И я очень большое внимание уделяю внутренним кадрам. Моя команда практически на 100% выращена внутри. Для каждой позиции у меня прописаны компетенции, которыми человек должен обладать. Так, на Service Delivery не имеет смысла ставить очень инновационного человека, здесь должен быть консерватор в хорошем смысле слова. В проектный офис нужно назначать лидеров, которые умеют наладить коммуникации с членами правления, эмоционально уравновешены и обладают блестящей логикой. Архитекторы, как правило, специалисты с огромным опытом, тоже умеющие общаться с людьми. Администраторам не нужно обладать коммуникативными навыками, однако они должны иметь блестящие технические знания. Проще говоря, менеджеры должны уметь общаться с людьми, а администраторы — с системами. Но самая главная компетенция, которая проявляется практически у всех членов моей команды и чем я горжусь, — четкость мышления. Все остальные качества можно развить.

Журнал IT-Manager № 02/2014    [ PDF ]    [ Подписка на журнал ]

Об авторах

Григорий Рудницкий

Григорий Рудницкий

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


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Другие материалы рубрики

Компании сообщают

Мероприятия

17.07.2018
NetApp Directions

Москва