Сбербанк России уже достаточно давно, с 2002 года, пользуется рекомендациями методологии ITIL с целью бесперебойного предоставления качественных ИТ-услуг. Более того, в марте 2007 года сертифицированы процессы служб автоматизации Сбербанка на соответствие стандарту ISO/IEC 20000:1-2005. Международный стандарт ISO/IEC 20000:1-2005 «Information Technology — Service Management» устанавливает требования к системе управления информационными сервисами и определяет критерии объективной оценки этих процессов. Сертификат соответствия за номером ITSM 511997 выдан Сбербанку 15 апреля 2007 года международным органом по сертификации BSI (British Standards Institution). О том, как построены ИТ-процессы на базе методологии ITSM и стандарта ISO 20000:1-2005, а также о последующей сертификации системы управления ИТ-сервисами мы беседуем с Андреем Хлызовым, директором Управления внедрения и сопровождения автоматизированных систем Сбербанка России.

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

Андрей Хлызов родился в 1960 году.

Закончил Московский физико-технический институт, Военную академию химической защиты и Академию народного хозяйства при Правительстве РФ. Работал в ВЦ авиационного завода, в системе вооруженных сил (ВЦ, научные организации, управленческие структуры). В 1997-м поступил в «Сбербанк России», где прошел путь от заместителя начальника отдела до директора управления.

Хобби — горные лыжи и силовые упражнения.

Intelligent Enterprise: Вы практически пять лет занимаетесь построением систем управления ИТ-сервисами на основе ITIL / ITSM. Давайте начнем разговор с самого начала — с первых ITSM-проектов. Почему вы начали движение по пути ITSM? Какие ИТ-процессы затрагивали первые проекты и с какими трудностями вы столкнулись при утверждении необходимых инвестиций?

Андрей Хлызов: Строить процессы управления ИТ-сервисами на базе методологии ITSM мы начали осенью 2001 года, выбрав для управления информационными технологиями методологию ITIL/ITSM. Этот выбор мы зафиксировали в концепции автоматизации банка на пять лет, которая принималась в 2002-м. Начали мы с того же, с чего сегодня начинает большинство компаний, — с постановки процессов управления инцидентами, конфигурациями и проблемами; одновременно с этим была создана диспетчерская служба по вопросам автоматизации — service desk. Первоначальные инвестиции составляли несколько десятков тысяч долларов. Столь небольшая сумма определялась тем, что процессы ITSM внедряли сотрудники ИТ-подразделений банка с незначительным привлечением внешних консультантов.

Такой подход — постановка процессов ITIL/ITSM собственными силами — был вызван тремя причинами. Во-первых, наши специалисты обладают необходимой квалификацией в области ITIL/ITSM. Во-вторых, стоимость внешних консультантов в 2001 году была чересчур высока. И в-третьих — фактически ни одна компания-интегратор в 2001 — 2002 году не была готова к реализации подобных проектов. И в дальнейших ITSM-проектах продолжаем идти тем же путем, хотя и пользуемся технической поддержкой компаний-интеграторов и (в небольшом объеме) консалтингом внешних консультантов.

Несмотря на небольшие затраты проект был весьма масштабным, он затрагивал инфраструктуру центрального аппарата банка и восемьсот офисов по Москве. Все подготовительные работы: выбор программного обеспечения для автоматизации ITSM-процессов, разработку основных процессных регламентов, подбор исполнителей, обучение сотрудников диспетчерской службы — были выполнены за три месяца, и 1 января 2002 года диспетчерская служба заработала.

При выборе программного обеспечения мы сравнивали системы от Remedy, Computer Associates и HP. На тот момент их возможности были примерно одинаковыми, хотя HP OpenView Service Desk до определенной степени превосходила своих конкурентов и методологию ITSM поддерживала в наиболее полном объеме. Стоимость продукта также была весьма конкурентоспособна. Кроме того, в банке уже использовались продукты семейства HP OpenView для мониторинга локальной сети, серверов и баз данных. В результате выбор был сделан в пользу HP OpenView Service Desk.

Проект по организации и внедрению процессов управления инцидентами, проблемами и конфигурациями вы провели очень быстро. А каков был эффект?

Мы считаем, что получили стопроцентный возврат инвестиций. На самом деле внедрение HP OpenView Service Desk полностью окупилось за первые четыре месяца. Причем с учетом не только стоимости самой системы, но и затрат на персонал. Создание и автоматизация диспетчерской службы очень быстро привели к потрясающим результатам. В течение первого года мы сократили количество инцидентов на 25%, а время их устранения — в три раза. А за прошедшие пять лет сроки устранения инцидентов сократились примерно в десять раз и в десятки раз уменьшилось их количество.

Сбербанк России

Сбербанк России занимает 66-е место в рейтинге 1000 круп­нейших банков мира за 2007 год по версии журнала The Banker. В рейтинге 500 крупнейших компаний мира, который ежегодно составляется газетой The Financial Times, банк занял 103-е место, поднявшись с 232-го места в 2006 году. Филиальная сеть банка является самой разветвленной в России. В нее входят 17 территориальных банков, 819 отделений и 19 355 внутренних структурных подразделений.

В каком направлении вы двигались дальше?

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

Сейчас можно констатировать, что в центральном аппарате и в московских отделениях банка внедрены все процессы, которые требуются стандартом ISO 20000:1-2005 «Information Technology — Service Management». Хотя понятно, что все они имеют различный уровень зрелости, поскольку, во-первых, мы начинали их построение в разное время, а кроме того, такие процессы, как, например, управление ИТ-финансами и управление возможностями, требуют гораздо больше интеллектуальных вложений, нежели организационных.

Другое направление — распространение подходов ITSM и требований стандарта ISO 20000:1-2005 на территориальные банки Сбербанка России. В структуре Сбербанка 17 территориальных банков, а всего у нас более 20 000 точек обслуживания. На текущий момент проведено обучение руководителей и главных специалистов ИТ-подразделений территориальных банков. Основные элементы процессов СУИС внедрены во всех территориальных банках, хотя развиты они, конечно, не везде до такой степени, как в цент­ральном аппарате. В стадии развития находится процесс управления непрерывностью, сложнее дело обстоит с управлением ИТ-финансами, возможностями и доступностью ИТ-сервисов. И задача нынешнего и, наверное, первой половины следующего года состоит в том, чтобы довести процессы в территориальных банках до нашего уровня. В 2009-м мы планируем начать сертификацию на соответствие стандарту ISO 20000:1-2005 ИТ-подразделений всех территориальных банков. Таким образом, мы планируем сертифицировать всю ИТ-службу Сбербанка России.

Эти направления были зафиксированы в концепции автоматизации? И каков горизонт планирования этих проектов?

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

Подробный план работ в области СУИС по конкретным процессам мы составляли на год — в зависимости от уже достигнутых результатов. И только сейчас мы можем говорить о двухгодичной перспективе: чем дальше продвигаешься по пути ITSM, тем глубже понимаешь процессы и можешь увеличивать горизонт планирования.

С какими серьезными проблемами вы столкнулись при реализации ITSM-процессов?

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

Вторая проблема — в инструментальных средствах. К сожалению, на рынке нет единого решения, которое полностью покрыло бы наши потребности в сфере автоматизации процессов системы управления ИТ-сервисами, поэтому мы вынуждены применять разнообразные продукты. Некоторые процессы можно автоматизировать на базе HP OpenView Service Desk и других продуктов HP Software. Но, например, для управления конфигурациями мы используем целый набор различных продуктов от разных производителей, и тем не менее сто процентов информации мы автоматически не собираем, часть приходится вносить вручную. А, скажем, для автоматизации управления непрерывностью вообще нет никаких инструментов. В области управления ИТ-финансами мы посмотрели несколько продуктов, но ни один не позволял в полном объеме рассчитать стоимость наших ИТ-сервисов. Поставщики подобных инструментов до сих пор, похоже, живут какими-то своими представлениями о таких расчетах, далекими от реальности.

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

В России постановка процесса взаимоотношений с потребителями услуг пока еще редкость, поэтому расскажите об этом подробнее.

Во-первых, здесь мы пока не до конца использовали рекомендации ITSM. Сейчас у нас каждый ИТ-сервис имеет индивидуальные условия (уровни) обслуживания конкретных бизнес-клиентов. С ними согласуются время поддерж­ки, уровень доступности систем, время перевода операций в резерв­ный комплекс, параметры производительности, объем операций и т. д. Учет индивидуальных условий обслуживания — процесс тяжелый, требующий дополнительных затрат, хотя здесь всё более-менее автоматизировано. И сейчас мы работаем над тем, чтобы условия обслуживания всех ИТ-сервисов сгруппировать по четырём уровням. Условно 7×24×365 — режим поддержки ключевых систем банка, например процессинговых сервисов или интернет-банкинга. А режим 5 дней в неделю 22 часа в сутки с учетом часовых поясов — для централизованных систем.

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

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

Какова была реакция бизнеса, когда вы посчитали стоимость ИТ-сервисов?

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

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

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

Несмотря на то что в центральном аппарате процессы СУИС уже достигли достаточной зрелости и мы накопили серьезный опыт в их постановке, просто перекладывать их в территориальные банки неправильно. Ведь эти процессы подразумевают определенный набор задействованных систем, людских ресурсов, определенную квалификацию. Например, для расчета стоимости ИТ-услуг мы используем систему собственной разработки, которая на текущий момент не является тиражируемой. Хотя, конечно, это верно не для всех подсистем, скажем, для управления возможностями мы сейчас внедряем HP OpenView Performance Insight и, по всей видимости, скоро будем готовы тиражировать его в территориальных банках.

Во-вторых, территориальные банки обладают определенной самостоятельностью и у них есть свои приоритеты в решении проблем. Так, один из них внедрил HP OpenView Service Desk в первую очередь не для внутренних пользователей, а для внешних клиентов. Этот подход мне очень симпатичен, поскольку Сбербанк старается быть клиент­ориентированным. В данном случае ИТ-директор по-своему взглянул на методологию ITSM и внедрил ее там, где были наибольшие проблемы. В результате радикально сократились сроки устранения инцидентов у клиентов банка и тем самым повысилась их удовлетворенность.

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

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

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

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

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

Другой вопрос, что сертификация на соответствие стандарту ISO 20000:1‑2005 предъявляет очень жесткие требования, но это требования верхнего уровня, касающиеся функционирования процессов и документации СУИС. Замечу, что и сам стандарт ISO 20000:1-2005 состоит из двух «разделов»: собственно стандарта и рекомендаций вместе с лучшими практиками.

Однако надо учитывать, что стандарт ISO 20000:1-2005 несколько отличается от методологии ITSM. Например, в ISO 20000:1-2005 присутствует процесс управления документацией, а процессы управления непрерывностью и доступностью, в отличие от ITSM, объединены в один. Кстати, последнее — совсем не простой вопрос: мы тоже долго думали, как реализовать эти процессы, под одним менеджером и одним ресурсом или разделить. В конце концов мы разделили ресурсы, отвечающие за эти процессы, и правильно сделали. Потому что процесс управления непрерывностью очень трудозатратен и если выделить для него отдельного менеджера, то это правильное решение. Кроме того, в рамках процесса управления непрерывностью мы минимизируем риски, связанные с крайне редкими ситуациями. Самое страшное, что приключилось, — это отключение электричества в Москве. Кстати, большинство ИТ-сервисов мы продолжали поддерживать и обслуживали клиентов на большей части города несмотря на то, что прекратили работать провайдеры.

Есть и еще отличие, которое, кстати, скорее говорит о недостатках ITSM: по сравнению с этой методологией необходима постановка процесса управления ИТ-персоналом. И вообще управление персоналом я считаю одним из ключевых процессов, за который руководители получают свои зарплаты. К сожалению, в ITSM ему не уделяется должного внимания, хотя и в ISO 20000:1-2005 это процесс обеспечивающий.

Какова была цель сертификации по ISO 20000:1-2005? Тем более, если отклонения от методологии ITSM не приводили к ее нарушению…

Стандарт ISO 20000:1-2005 создан на базе BS-15000 и принят в 2005 году. Это первый международный стандарт в области управления ИТ-сервисами. Замечу, что ряд российских компаний объявил о сертификации ИТ-служб по стандарту ISO 9001, но на мой взгляд целесообразнее проходить сертификацию по стандарту ISO 20000, во всяком случае для внутренних ИТ-подразделений.

Так сложилось, что в 2006 году мы завершили реализацию концепции автоматизации, в том числе и в области управления ИТ. Когда решена задача создания централизованной автоматизированной системы, всё понятно — вот она работает. А чем мы подтвердим решение задачи в области управления ИТ-сервисами? Возникла идея сертификации, мы посмотрели стандарт, поняли, что на 90 % он соответствует нашей практике, и решили, что в подтверждение выполнения поставленной в концепции задачи целесообразно проверить построенную систему управления ИТ-сервисами на соответствие стандарту.

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

Расскажите, как проходил аудит и какие процессы СУИС он охватывал. С какими трудностями вы столкнулись?

Весь процесс сертификационного аудита занял чуть больше полугода. Сначала проводилось два предварительных аудита — первый в октябре, второй в декабре 2006 года — и аудит документации. А затем — заключительный сертификационный аудит, который проходил в марте 2007 года. На основании заключительного аудита специалисты BSI сделали выводы о том, что система управления ИТ-сервисами соответствует стандарту ISO 20000:1-2005. После этого материалы были проверены в головном офисе BSI и нам выдан сертификат соответствия.

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

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

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

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

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

Какое влияние проект системы управления ИТ-услугами на базе ITSM оказал на статус ИТ-службы, на организационную структуру ИТ-департамента?

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

Что касается оргструктуры, то ITSM — это методология, которая пропагандирует процессный подход, так что прямой связи между ней и организационной структурой не существует. ITIL/ITSM ложится на любую организационную структуру. Единственное, что тут можно заметить: желательно выделить диспетчерскую службу, но именно желательно, а не обязательно (в этом снова гибкость методологии). Результирующая организационная структура очень сильно зависит от конкретных сотрудников, от того, есть ли человек, готовый возглавить службу, или нет. Что касается менеджеров процессов, то в банке нет ни единого выделенного менеджера процесса СУИС. За процессы отвечают начальники отделов (либо их заместители), которые сопровождают конкретные автоматизированные системы, и часть своего времени они выделяют на управление соответствующими процессами.

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

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

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

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

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

Если говорить о системе управления информационными сервисами в целом, то мы будем заниматься оптимизацией системы целей ИТ. Бизнес хочет, чтобы всё всегда работало, чтобы развитие шло в соответствии с его потребностями и чтобы это стоило понятных денег. Это и есть наши главные цели, которые далее распадаются на дерево целей. Мы хотим выстроить четкую структуру целей и ключевых индикаторов их достижения. Показатели эффективности уже действуют в ряде процессов и подразделений (в частности, у диспетчеров, где это показалось самым простым); работают они и на верхнем уровне ИТ-менеждмента. Но мы хотим сделать их сквозными, фактически довести до каждого ИТ-сотрудника. И, конечно, будем подтверждать сертификат соответствия стандарту ISO 20000:1-2005.