В марте 2009 года был завершен первый этап проекта внедрения СУИС — системы управления ИТ‑сервисами в Банке «Санкт-Петербург». Этот проект закончен, несмотря на кризис, и не только это обстоятельство делает его необычным. Также в проекте применен целый ряд весьма нестандартных решений, которые весьма интересны. О проекте мы беседовали с директором дирекции по информационным технологиям Банка «Санкт-Петербург» Ярославом Шелиным.
Intelligent Enterprise: Какие имелись предпосылки для начала продвижения в области ITSM? Как строилось управление ИТ?
Ярослав Шелин: До некоторого момента ИТ в Банке «Санкт-Петербург» существовали в традиционной модели управления — персонал был разбит на функциональные группы, каждая из которых отвечала за свои системы. К ним и обращались конечные пользователи со своими проблемами. Так продолжалось довольно долго. Но четыре года назад мы обратили внимание на преимущества сервисного подхода. Оказалось, что это действительно здорово. Это и стало первоначальным толчком для нашего движения в сторону ITSM. Сначала мы решили, что справимся сами, и в качестве пробного шара запустили систему ServiceDesk в отделе, который занимался поддержкой пользователей системы «Банк — клиент». Но, как это часто бывает, первый блин получился комом — задача оказалась намного шире, чем нам первоначально казалось. Одним только внедрением системы ServiceDesk ее решить оказалось невозможно. Переход на принципы ITSM требует не только внедрения технических средств и организационных мер, тут нужно менять сознание людей. Иначе тот же ServiceDesk просто не работает. На осознание этого факта ушло довольно много времени, и это стало нам хорошим уроком.
Одновременно мы поняли, что движемся в правильном направлении. Поэтому мы объявили конкурс на внедрение и автоматизацию нескольких процессов управления ИТ-услугами, победителем которого стала компания «ИТ-Эксперт». Внедренную систему мы назвали СУИС: система управления ИТ‑сервисами.
Как вы презентовали этот проект руководству и защищали бюджет? Ведь, как и в случае любого проекта внутри ИТ‑службы, бизнесу не очевидны преимущества и выгоды?
Да, чтобы донести важность этой идеи до руководства, потребовалось много усилий. Получить финансирование для работ по внутреннему проекту всегда сложно, а посчитать экономический эффект крайне тяжело. Но убедить удалось. При этом использовалась та же аргументация, что и в ходе создания технической инфраструктуры. Главным аргументом при этом были преимущества, связанные с преимуществами управления централизованной системой, — это надежней, дешевле, и проще поддерживать нормы по безопасности. Повлиял, например, объем списка телефонов, которые должен был знать каждый сотрудник банка, чтобы обращаться в случае возникновения тех или иных проблем.
Один из основных аргументов перед руководством в пользу нашего проекта состоял в том, что мы теперь можем измерять эффективность работы каждого сотрудника. У нас их 180 человек, и вроде бы все при деле. А сейчас вырисовываются сравнительные характеристики, кто работает хуже, кто лучше, и это легко проанализировать.
Мы пообещали руководству банка хорошие перспективы, нам не очень поверили, но разрешили попробовать. Благо затраты были не очень большими, тем более что проект изначально разбивали на этапы. И определенная отдача намечалась уже по результатам самого первого из них.
Это происходило до начала кризиса?
Да, мы угадали и успели защитить проект до начала острой фазы кризиса. Работы по проекту были начаты в сентябре 2008 года. И он пошел на удивление планомерно, строго вписываясь в заданные рамки. Мы полностью уложились во все сроки, что бывает очень редко. Обычно накладывается одно на другое, и работы идут еще довольно долгое время после формального подписания акта по приемке. А тут все было четко: как планировали запустить систему в конце марта этого года, так и запустили.
Какие процессы из ITIL вошли в вашу систему управления ИТ‑сервисами? И почему вы выбрали именно их?
Консультанты помогли нам разработать четыре процесса. Два из них — стандартные процессы ITIL, управление инцидентами и проблемами. И два других — общесистемные, корневые, которые управляют остальными. Один называется «Планирование», другой — «Контроль».
Управление сводится к контролю выполнения тех или иных заданий. Чтобы процессы развивались, необходимо вносить в них изменения, необходимо дальше добавлять новые процессы. Но сначала надо понять, необходимы они или нет. Вот для этого и внедрены планирование и контроль. Это выходит за рамки ITIL, по крайней мере в его второй версии. Возможно, это влияние третьей версии ITIL, возможно, COBIT.
По сути, эти два процесса — элементы других процессов ITIL. Например, если нужно внести изменения в один из наших рабочих процессов, производится заявка на изменение. В отношении ИТ‑систем у нас заявки на изменение пока нет, поскольку нет процесса управления изменениями. Но заявка на изменение процесса есть — ее зарегистрируют, рассмотрят и проконтролируют ход этого изменения.
Эти процессы были предложены нам консультантами из «ИТ-Эксперт». Возможно, у наших консультантов уже были какие‑то наработки в этой области. Может быть, они были изобретены в ходе нашего проекта. Это своего рода ноу-хау. Консультанты нас убедили, что так будет правильно, и в результате мы получили целостную конструкцию, которая оправдала наши ожидания и дает нужный эффект.
Не страшно было отступать от ITIL? По этим процессам работают специалисты, какие‑то специальные выделенные менеджеры и аналитики?
Это решение нам понравилось. У нас было ощущение, что оно должно сразу заработать. Очень логично — есть два операционных процесса и два управленческих. При этом управленческие поддерживают операционные. При необходимости могут быть добавлены и новые операционные процессы, и при этом сохраняется контроль.
Ведь, повторюсь, мы пробовали запустить ServiceDesk просто как функциональную единицу, без четкого определения управленческих процессов, но полной отдачи от него не было. Хотя при этом нельзя было сказать, что он совсем не работал. Но каковы результаты и куда надо двигаться, понятно было далеко не всегда. Мне кажется, результаты выделения процессов планирования и контроля особенно скажутся, когда мы доберемся до процессов управления изменениями и релизами. Что касается специалистов, то, чтобы процессы планирования и контроля заработали, перед началом работ по данному проекту был создан специальный отдел оптимизации информационно-технологических процессов в рамках дирекции по информационным технологиям. Во многом к этому подтолкнул неудачный опыт прежней попытки внедрить ServiceDesk. Возникла мысль найти специалистов в области ИТ-процессов. Нашел руководителя, пробил создание отдела, который так и называется — «отдел оптимизации ИТ-процессов».
В том, что весь наш ITSM-проект стал успешным, большая заслуга его руководителя. У сотрудников отдела оптимизации ИТ-процессов функции технологов и аудиторов ИТ-процессов. Нам рекомендовали проводить регулярные аудиты, и мы их проводим два раза в квартал. Мы анализируем то, как процесс должен работать согласно документам и как это происходит на самом деле. Если выявляется несоответствие, то определяем, хорошо это или плохо. Ведь не всегда такое различие негативно, сами процессы тоже могут эволюционировать. И если специалисты договорились и что‑то изменили, это далеко не всегда плохо. Также аудит позволяет выявлять узкие места, и готовится план по их устранению. Тем самым, запускается некий цикл по улучшению процессов. Эта функция и закреплена за отделом оптимизации ИТ-процессов.
Таким образом, выстроен управленческий контур, в вершине которого нахожусь я, как ИТ-директор банка, а аудиторы и менеджеры ИТ-процессов заинтересованы в регулярных мелких улучшениях, не связанных с изменением процессов. Метрики процессов мы анализируем каждую неделю. Это дает возможность менять ролевые инструкции, например, брать трубку не на пятый звонок, а на третий. Или фиксировать задания, если исполнители забывают команды, данные им устно. Эти полномочия даны менеджерам процессов. Хотя эти полномочия они не очень активно используют — и это пусть и не большая, но все же проблема. Но со временем мы ее решим.
Как вы компенсировали отсутствие полноценного процесса управлением конфигурациями?
За полгода создать нормально работающую CMDB — задача для нашей инфраструктуры малореальная, ведь у нас около 50 тыс. единиц вычислительной техники. Сейчас все работает без CMDB, и мы используем целый ряд заглушек, позволяющих обходить эту незавершенность нашей системы. Ведь к CMDB так или иначе привязаны почти все процессы. CMDB, необходимая для создания полноценной системы управления ИТ‑сервисами, соответствующей стандартам ITIL, все равно будет разрабатываться. Но тем не менее сейчас управление инцидентами и проблемами у нас работает.
Как вы выбирали систему поддержки ваших процессов, в особенности — планирования и контроля, которые не реализованы в стандартной поставке популярного ITSM-инструментария?
Первоначально мы хотели внедрить систему HP OpenView 4.5, с которой были лучше знакомы. И другие участники тендера тоже предлагали нам ее. Однако консультанты «ИТ-Эксперт» нам честно объяснили, что OpenView версии 4.5 изрядно устарела, а последующие версии вышли не так давно, и опыт по их внедрению пока не накоплен. Они предложили систему OmniTracker, показали результаты ее работы в других местах, что стало дополнительным аргументом в пользу этого решения.
На нем мы остановились и не пожалели. OmniTracker является своего рода workflow для управления любыми договорными процессами. Это дает необходимую гибкость, например, в этой системе наши консультанты смогли реализовать процессы планирования и контроля.
В процессе внедрения были незначительные проблемы, в частности, с неправильным определением кодировок. Но серьезных проблем, когда что‑то из заявленных функций не работает или работает неправильно, не было. По нашим впечатлениям, у системы есть резервы и по масштабированию. Причем это касается и наращивания функциональности, и количества контрольных точек. Нет также тяжеловесности и перегруженности, присущих многим другим продуктам. В результате, когда нам пришлось работать на резервном оборудовании более скромной конфигурации, больших неудобств мы не испытывали. Хотя, конечно, мы пока не создавали CMDB, которая серьезно нагружает систему.
C какими трудностями вы столкнулись в ходе реализации этого проекта?
Я бы не сказал, что это трудности, — это был нормальный проект. Главная задача состояла в том, чтобы приучить и работников дирекции, и сотрудников банка работать по новым правилам. Чтобы система реально работала, а не существовала «для галочки». Ведь мы делали ее для себя, а не для дяди. Здесь пришлось, с одной стороны, заручиться поддержкой руководства банка, а с другой — самим проявить настойчивость. Поэтому у нас было не много проблем, и проект шел на удивление неплохо.
К тому же я впервые увидел, как консультанты из «ИТ-Эксперт» вели проект в форме тренингов и семинаров. Они собирали нашу команду, которая работала над проектом, и не просто отчитывали презентации, но и вели некий диалог: «Мы собираемся решать эту задачу так. Что вы об этом думаете?» После этого начиналось обсуждение, и если в ходе этого спора рождалось что‑то конструктивное, это фиксировалось. Если спор заходил в неконструктивное русло, то оставалась образовательная часть. Меня тоже заставили ходить на эти тренинги. В ходе ИТ-проектов такое наблюдать приходилось впервые — нечто подобное я видел только при внедрении бизнес-методологий.
Впоследствии целый ряд наших сотрудников, участвовавших в этих семинарах и ставших менеджерами процессов, сами проводили такие же тренинги для своих подчиненных. Такие семинары время от времени проходят и сейчас. Таким образом, мы застрахованы от ситуации, когда менеджерам спускают сверху какие‑то документы, и они не знают, что с ними делать и как доводить их содержание до подчиненных. Это было колоссальным плюсом. Именно такая методика позволила нам быстро заменить назначенного менеджера процесса, который не справлялся с этой функцией. А тот, кого назначили на его замену, оказался на нужном месте. В итоге все оказались в выигрыше.
Кроме того, в результате такой формы работы на проекте консультанты из «ИТ-Эксперт» очень хорошо управляли нашими ожиданиями и ожиданиями бизнеса. Они сразу объяснили, что для успеха проекта нужна поддержка руководства. В результате мы выходили на правление банка, регулярно делали промежуточные доклады комитету банка по технической политике. Тем самым, мы вели своего рода PR-компанию внутри банка. Нам не обещали золотых гор, но все, что обещали, — построили. Пусть не на «пятерку», но на твердую «четверку».
Например, в подобных проектах часто говорят о неготовности ИТ-персонала к работе в рамках процессов?
Администраторы, которых отгородили от пользователей, быстро поняли, что с внедрением ServiceDesk им стало проще работать. Отсеялось очень большое количество мелких проблем, да и просто глупых вопросов. Устранены дублирования и пересечения. Теперь, например, перед ИТ‑специалистами в области сетей не стоит задача управлять средствами защиты периметра. Все прописано и закреплено в ролевых инструкциях, которые значительно дополнили должностные.
Надо сказать, что большим плюсом нашего проекта было то, что ни мы, ни консультанты не собирались коренным образом менять структуру дирекции по информационным технологиям. Так, сохранены все функциональные группы. Но при этом к ключевым специалистам в отделах мы привязали метрики работы тех или иных процессов. Раньше они отвечали за определенные ИТ‑системы, теперь же они отвечают за элементы процесса. И задачи по сопровождению ИТ‑сервиса воспринимаются вполне нормально.
Сейчас есть процесс, у которого есть менеджер, и есть роли тех, кто участвуют в этом процессе, и для каждой разработана своя инструкция. В результате создана функционально-матричная структура, где сотрудники сгруппированы, с одной стороны, по процессам, а с другой — по подразделениям. При этом некоторые роли, в частности дежурных специалистов на второй линии поддержки, перераспределяются согласно графику дежурств. Как только были выработаны метрики, появились и системы мотивации, некий аналог доски почета.
Какие были сложности с определением этих метрик? Ведь здесь трудно опереться на чужой опыт, играет роль специфика приложений, интенсивность их использования, надежность инфраструктуры и т.д.
Сначала мы вводили очевидные метрики. Надо сказать, что не все первоначально принятые метрики сейчас сохранены. Что‑то оказалось лишним, а чего‑то не хватало. Сейчас мы можем делать разные метрики, в зависимости от того, чего хотим добиться, например, процент повторно используемых типовых решений при исправлении инцидентов. Пока их уровень не очень высок — быстрый ответ на наиболее часто возникающие вопросы у нас пока получается не очень хорошо. Мы только начинаем понимать, как этим пользоваться.
С анализом инцидентов все относительно просто — событий много, они быстро возникают и быстро устраняются. Благодаря этому мы можем увидеть потенциальные проблемы и вовремя на них реагировать. Тогда как раньше не было вообще видно, кто, как и на что отвечал. Это очевидное преимущество ITIL. С анализом проблем сложнее, их не так много, они медленно вызревают и медленно ликвидируются.
Сейчас появились оценки по результатам четких измерений. Например, процент своевременного закрытия инцидентов. В результате каждый сотрудник видит, ближе он к первым или к последним. Мы все эти результаты публикуем. Не последнюю роль в развитии процессов играет и финансовая мотивация, на основе измеримых и понятных для сотрудников критериев. Несмотря на влияние кризиса, ее мы также смогли внедрить.
Кстати, дирекция по информационным технологиям была единственным подразделением в банке, где не произошло сокращений. Во многом благодаря тому, что мы смогли объективно доказать необходимость каждого. И проект создания системы управления ИТ‑сервисами стал в этом дополнительным помощником.
Нередко в таких проектах сталкиваются с сопротивлением бизнес-пользователей, которое не преодолеть тренингами ИТ-персонала…
Недовольство бизнес-пользователей при внедрении было, и избежать его нельзя. Но мы разработали разумный план внедрения. Ведь ценность ServiceDesk в его доступности, туда всегда можно принести свои проблемы. Сейчас, к примеру, у нас время ожидания на линии меньше 5 секунд, при этом, правда, половина запросов идет по электронной почте. Естественно, если сразу же перевести весь банк на ServiceDesk, то ни о какой доступности не может быть и речи, особенно в условиях ограниченных ресурсов. Так что на его использование разные подразделения переводились поэтапно, согласно приказу руководства. Хотя мы никому не отказывали, если какое‑то подразделение решало вдруг подключиться вне графика. Шаг при этом был двухнедельным. За этот срок мы выясняли, справляется ли система с возросшей нагрузкой или нет. К настоящему времени согласно графику система ServiceDesk обслуживает более 60% пользователей банка. Значительное количество сотрудников стали пользоваться системой по собственной инициативе, когда через внутренние коммуникации банка узнали о проекте. Наши службы вполне справляются, и в настоящий момент мы готовим перевод остальных подразделений банка на обслуживание через ServiceDesk. Впечатление от проекта сугубо положительное.
Как планируется развивать систему управления ИТ‑сервисами?
Прежде всего — совершенствование системы метрик процессов и работы сотрудников. Здесь еще есть куда развиваться. Также мы планируем внедрять управление другими процессами: изменениями и релизами. Тут все упирается в финансирование, с выделением которого есть понятные сложности. Для реализации этих процессов нам надо создавать CMDB, без которой управлять ими сложно. Сложность в том, чтобы не вводить в базу ничего лишнего и при этом не упрощать регистрируемую ИТ-инфраструктуру.
Мы начали работу по заключению с бизнесом соглашений об уровне сервиса (SLA). Задача это непростая, но тут больше неготовности бизнес-пользователей, чем нашей. Мы выступаем в роли локомотива, проводим мониторинг отношения к ИТ по принципу «меняется/не меняется». ITIL рекомендует проводить опросы пользователей, и мы это тоже делаем. Так что только отслеживанием статистики, закрыт или не закрыт тот или иной инцидент, мы не ограничиваемся. И, судя по результатам, реакция пользователей на эти изменения в основном положительная.
Когда консультанты задавали вопросы, как мы планируем развиваться в отношении управления уровнем обслуживания (SLM), я отвечал, что мы будем действовать активно. В нашей деятельности мы научимся мерить, научимся считать, научимся улучшать.
Со временем, когда мы начнем приходить к пользователям со счетами, пусть и виртуальными, нам начнут задавать вопросы, почему наш сервис такой дорогой. Тогда наши клиенты зададут себе вопрос: а все ли им реально нужно, или устроит время реакции в четыре часа вместо одного?
Вот тогда мы научимся управлять затратами на совершенно другом уровне. А сейчас очень часто приходится слышать, что «необходим самый лучший ПК», причем от сотрудника, которому от компьютера не нужно ничего, кроме функций пишущей машинки.
Кроме того, в банке приступили к управлению непрерывностью и разработке плана восстановления после сбоев. В прошлом году мы запустили резервный центр обработки данных. Когда проходил его аудит, специалисты из PricewaterhouseCoopers в качестве основного замечания высказали, что проект выглядит чрезмерно дорогим, поскольку в банке нет перечня критических систем, и, не имея его, ИТ‑служба зарезервировала все приложения и данные. Сейчас задача состоит в том, чтобы сокращать затраты, и в первую очередь сокращать то, что менее важно. И тут ITSM позволит нам сделать заметный шаг.
