Cуществует множество методологий и стандартов, описывающих управление IT-услугами (IT Serviсe Management, ITSM). Но одна из самых популярных и наиболее полных — библиотека ITIL (IT Infrastructure Library), созданная в Великобритании на основе лучших практик. Российским банкам, как основным потребителям IT, применение ITIL может дать значительные преимущества.

Почему управление услугами необходимо?

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

Но в России привыкли вести бухгалтерию по статьям затрат, а не по полученным услугам. Поэтому каталоги IT-услуг с указанием их стоимости удобны для бизнеса, но не принимаются бухгалтерией для расчетов финансовых показателей. В результате наиболее продуктивный подход при внедрении каталога IT-услуг: вести подсчет и по услугам — для понимания бизнеса, и по статьям затрат — для бухгалтерии.

Переход к процессному подходу в IT

Предоставление четко обозначенных услуг бизнесу становится возможным благодаря процессному подходу к организации IT. Процесс применительно к ITSM — это цепь операций, каждая из которых может выполняться в разных отделах департамента информационных технологий. Именно процесс дает возможность сотруднику для выполнения каждой операции не бегать к начальству и не спрашивать, делать эту работу или нет? Один раз прописывается процедура, и на основании этой процедуры специалисты во всех отделах работают друг с другом, не вовлекая начальство. Все заранее оговорено: как нужно действовать, какой материал на вход нужно подавать, какую информацию должны получить на выходе. В итоге IT работает намного быстрее и дешевле.

В библиотеке ITIL есть определенный, четко описанный набор процессов. Примером может служить процесс «Управление инцидентами» (Incident Management), в котором выстраивается набор реакций на определенные наступающие инциденты. В результате каждый инцидент регистрируется и решается максимально быстро, накапливается база знаний по решению инцидентов. Именно поэтому этот процесс наиболее популярен и обычно внедряется первым. По крайней мере, так было до недавнего времени.

В России привыкли вести бухгалтерию по статьям затрат, а не по полученным услугам

В ITIL версии 2 исповедовался подход, при котором можно выбрать один или несколько наиболее важных для предприятия IT-процесса и внедрять их максимально полно. Именно этот подход до сих пор используется в большинстве банков, по крайней мере российских. Однако такой подход плох тем, например, что IT-поддержка развивается без нормального процесса взаимодействия с бизнесом, не вырабатываются соглашения об уровне предоставления услуг (SLA), IT не понимает, чего хочет бизнес. Можно без конца совершенствовать, шлифовать один процесс без увязки с другим, но общую картину это улучшит ненамного.

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

Даже тем, кто считает, что нужен лишь Incident Management, можно делать на него акцент, но при этом не забывать некоторых ключевых аспектов соседних процессов, таких как «Управление проблемами» (Problem Management), «Управление изменениями» (Change Management) и особенно «Управление релизами» (Release Management). Многие банки, я думаю, зря тратят значительное количество ресурсов, не имея Release Management и внося изменения в операционную среду по факту поступления каждого запроса на изменение. Лучше паковать изменения в релизы и выпускать их раз в квартал. Как показывает практика, банк не настолько динамично развивающаяся организация, чтобы гоняться за ежедневными изменениями. Стабильность бизнеса рождает необходимость в стабильности IT-инфраструктур, а значит, Release Management необходим.

Рациональный сорсинг

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

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

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

Безопасность как процесс

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

Кто должен инициировать внедрение сервисного подхода?

В ITIL версии 3 предлагается более сбалансированный подход, при котором все процессы внедряются параллельно

Это вполне закономерный вопрос, если учесть, что ITSM повышает прозрачность IT и качество услуг для бизнеса. Но бизнес-руководители об ITSM, как правило, даже не знают. На уровне высшего руководства предприятия речь идет больше о так называемом корпоративном управлении IT или IT Governance. ITSM — это подход более низкого уровня, и, конечно, внимание ему должен уделять IT-директор или CIO. При этом он, как правило, сам не занимается организацией ITSM, потому что для него это тоже слишком низкоуровневая тема, а поручает это одному из своих доверенных прямых подчиненных, которые курируют часть, связанную с внутренней организацией работы в IT.

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

Самим или с консультантами?

Если банк решил внедрять сервисный подход в IT, встает вопрос, целесообразно ли привлекать консультантов или лучше сделать это собственными силами? Ответ кроется в готовности банка нести большие единовременные затраты. Консультанты обеспечат быстрое внедрение, но при этом придется заплатить значительную сумму на начальном этапе. Если средств на консалтинг жалко, то можно привлекать и обучать людей внутри компании, которые сделают это самостоятельно, но проект затянется на долгое время. Результат и затраты будут примерно одинаковы, просто во втором случае и то и другое растягивается во времени.

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

Технологии для внедрения сервисного подхода

Автоматизация IT-процессов, как и любых других, требует технологических инструментов. Конечно, можно сделать начальное представление IT-услуг и в Excel — такие примеры есть. Но как только мы сталкиваемся с чуть более сложными конфигурациями, нужны промышленные ITSM-системы. Различия в стоимости и функционале таких систем очень существенны. Системы отличаются также сроками внедрения, качеством поддержки и другими факторами.

Встает вопрос — как бизнесу понять, что ему нужна именно система, скажем, за миллион долларов, которую рекомендует CIO, а не за 10 тыс. рублей, которую предлагает какая-либо компания? Задайте айтишнику вопрос о том, какие бизнес-эффекты будут получены от внедрения этой системы. Если окажется, что они соизмеримы, то решение очевидно.

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

Сопротивление бизнеса

Хотя ITSM приносит обозначенные выше преимущества бизнесу, далеко не всем на местах выгодна прозрачность. Если раньше на многие вопросы руководства можно было ответить, переложив ответственность на IT, то при внедренном процессном подходе этого сделать не получается. Как мотивировать бизнес «выбить у себя из-под ног табуретку»?

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

Зрелость и тенденции

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

Как показывает практика, новая идеология принимается не сразу, продвигается небольшими шагами. Возможно, через пять или десять лет мы придем к ситуации, когда увидим, что произошел качественный скачок, и теперь в России понимают, что такое сервис. Еще в 2000 году такого понимания не было вообще. Сейчас, через 12 лет, оно есть, может быть, у половины. Возможно, когда важность сервиса поймет квалифицированное большинство, около 75%, все скажут, что это очевидно. IT и бизнес наконец будут готовы разговаривать в терминах предоставления услуг. А дальше начнется эволюция от плохого сервиса к более качественному.