ИТ-УСЛУГИ
Почему ITSM?
Уже ни для кого не секрет, что влияние информационных технологий (ИТ) на деятельность любой фирмы становится более чем существенным. В последнее время все чаще ссылаются на предприятия с автоматизированным бизнесом (банки, трейдинговые компании, операторы сотовой связи и т. д.), для которых ИТ являются не просто поддержкой, но и движущей силой. В связи с новой ролью ИТ в жизни компаний острее ставится вопрос об эффективном - со стороны информационных технологий - обслуживании бизнеса. Иными словами, там начинают задумываться о том, как сделать ИТ-департамент центром предоставления определенных ИТ-услуг. В странах Западной Европы, где культура сервиса (то есть политика организации, направленная на предоставление услуг) стала частью повседневной жизни, признанным де-факто стандартом управления ИТ является набор руководств, изложенных в книгах библиотеки ITIL (IT Infrastructure Library) - "IT Service Support" и "IT Service Delivery". Эти руководства, основанные на передовом опыте, который был накоплен ведущими компаниями мировой ИТ-индустрии, называются "IT Service Management" (ITSM) - управление ИТ-услугами.
Полный переход на сервисную основу позволит ИТ-департаменту любой компании не только превратиться из затратного подразделения в центр получения прибыли, но и предлагать свои ИТ-услуги за пределами собственной организации, перейдя тем самым к статусу департамента с независимым бюджетом.
Рекомендации, изложенные в указанных выше книгах, не являются прямыми инструкциями к действию, оставаясь лишь "высокоуровневым" описанием эффективной модели управления. Каждое предприятие получает возможность адаптировать "лучшие мировые практики" к особенностям своей ИТ-инфраструктуры и текущему состоянию рынка.
В связи с этим нет единого мнения о том, с чего следует начинать при переводе ИТ-подразделения на сервисную основу работы. Оставляя за любой компанией право на выбор собственного, уникального способа построения процессов ITSM, мы тем не менее хотели бы рассказать о той схеме построения, которая эффективно проявила себя на российском ИТ-рынке.
Тактика быстрых побед
На сегодняшний день руководство российских компаний еще не до конца осознало всю значимость ИТ для бизнеса. Бюджетирование ИТ у них выражено крайне слабо, причем не столько из-за общего дефицита денежных средств, сколько из-за отсутствия представления об ИТ как о стратегическом для развития бизнеса инструменте. Зачастую ИТ-директора сталкиваются с ситуацией, когда внутри ИТ-департамента назрела необходимость реорганизации процессов, но этот факт трудно донести до руководителей высшего звена. В подобном случае особенно эффективным будет применение тактики "быстрых побед". Она заключается в быстром внедрении яркого и эффективного решения, результаты которого могли бы впечатлить руководство компании. Обычно такие решения содействуют тому, что ИТ-департамент получает соответствующий бюджет на будущие проекты.
Именно с этой целью процесс перехода своего департамента на сервисную основу CIO начинают с этапа построения ITSM-процессов, способных принести наиболее заметные результаты.
Что сейчас распространено?
Одним из самых распространенных в России путей перевода ИТ на сервисную основу является построение своеобразной "связки" - службы Service Desk и процесса управления инцидентами.
Service Desk, или служба технической поддержки, является единой точкой контакта при всех обращениях пользователей, связанных с ИТ. Практика показывает, что организация такой точки (единый телефон, e-mail, факс и т. д.) - фактор, повышающий психологическую удовлетворенность сотрудников компании от ИТ. Однако одной лишь службы Service Desk мало для достижения быстрых побед. Можно догадаться, что повышение удовлетворенности окажется недолгим, если заявки пользователей будут, например, теряться или пользователь станет рассматривать ИТ-департамент как некий "черный ящик", который, успешно приняв заявку, не сообщает о происходящей внутри него работе.
Процесс управления инцидентами (Incident Management) - это взаимодействие ИТ-отделов, направленное на максимально быстрое устранение сбоев в ИТ-инфраструктуре. В рамках этого процесса служба Service Desk является основным координирующим работу ИТ-отдела звеном. Она позволяет создать средства автоматического оповещения пользователей о ходе работ по рассмотрению их заявок, значительно повысив ценность ИТ-департамента в глазах рядовых пользователей и руководящего состава.
Статистика пользовательских обращений, появляющаяся после построения процесса управления инцидентами, дает возможность ИТ-директорам оптимизировать нагрузку ИТ-персонала, а также аргументированно обосновывать необходимость выделения бюджета на ИТ.
Подводные камни
Как показывает практика некоторых компаний, внедрения вышеуказанной связки тем не менее недостаточно для достижения быстрой победы. Пользователи зачастую считают, что их заявки рассматриваются слишком долго. При этом четкая, но не доведенная до них схема определения приоритетов для различных инцидентов эффективно работает лишь внутри ИТ-департамента, поскольку каждый пользователь будет уверен, что любая его заявка получит высший приоритет. А это может привести к негативной реакции и, как следствие, к ухудшению репутации ИТ-департамента.
Для того чтобы вызвать у пользователей доверие к службе технической поддержки, прежде всего необходимо ознакомить их с тем, на какие сроки по устранению возникших инцидентов они могут рассчитывать. А определение таких сроков - это уже часть процесса управления уровнем услуг (Service Level Management, SLM).
SLM на ранней стадии. Как это возможно?
Обычно управление уровнем услуг рассматривается как процесс, внедряемый уже в зрелой - с точки зрения выстраивания бизнес-процессов - организации. SLM - это процесс, обеспечивающий регламентную базу для предоставления ИТ-сервисов на заранее согласованном уровне качества и включающий в себя разработку, поддержку и постоянную корректировку "соглашений об уровне услуг" (Service Level Agreement, SLA).
SLA представляет собой формальный договор между потребителем ИТ-услуги (бизнесом) и ее поставщиком (департаментом ИТ), содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.
Для того чтобы иметь возможность "измерять" уровень качества ИТ-услуг, они характеризуются набором показателей - так называемых метрик сервиса, таких, как часы доступности, уровень доступности (т. е. доля времени, в течение которого услуга должна быть физически доступна, в сравнении с максимально возможным временем доступности), время реакции на обращение, время устранения инцидентов, связанных с этим сервисом, и т. д. Под уровнем качества услуги подразумевается набор согласованных значений метрик. Заключая SLA с бизнес-структурой, ИТ-департамент гарантирует предоставление услуги с уровнем качества не ниже согласованного.
Введение четко регламентированного времени реакции/устранения инцидента является частью масштабного процесса SLM, однако это возможно только в том случае, если в ИТ-департаменте уже налажены более элементарные процессы. Как же в этом случае построить эффективный процесс управления уровнем сервиса?
(Предлагаемый ниже подход был удачно реализован компанией КРОК в "Ингосстрахе" в рамках построения службы технической поддержки с измеряемым качеством обслуживания пользователей.) В процессе управления уровнем сервиса достаточно определить один-единственный ИТ-сервис - техническую поддержку - и классифицировать его как профессиональный*1 (то есть представляющий собой дополнительные действия, производимые ИТ-персоналом).
_____
*1 Defining, Modeling & Costing IT Services, v2.4. Pink Elephant.
Далее необходимо обозначить ИТ-системы, которые существуют в департаменте (если такая работа не была проделана ранее). Например, ими могут быть MS Exchange, Lotus Domino, LAN, системы хранения данных и т. д. Обычно каждую такую систему поддерживает отдельная ИТ-служба или рабочая группа инженеров. Собственно говоря, определение ИТ-систем и поддерживающих их рабочих групп - это фундамент для формирования будущей схемы эскалации (схемы маршрутизации инцидента внутри ИТ-департамента), которая определяется в процессе управления инцидентами.
После того как в рамках сервиса технической поддержки будут определены поддерживаемые ИТ-системы, необходимо рассчитать время реакции/устранения инцидентов, связанных с каждой из этих систем, в зависимости от приоритета инцидента. В отсутствие статистики по инцидентам это обычно делается на основе широкомасштабного опроса рабочих групп технической поддержки.
Полученные метрики необходимо включить в SLA для единственно определенного сервиса - сервиса технической поддержки. В SLA можно также включить время доступности сервиса (то есть службы Service Desk), долю устраненных операторами Service Desk инцидентов и т. д.
Конечно, выявленные при опросе метрики (время реакции/устранения инцидентов) могут не соответствовать картине, полученной после первой обработки статистических данных, собранных в процессе управления инцидентами. В этом случае включаются механизмы корректировки согласованных в SLA метрик сервиса, которые являются частью процесса управления уровнем услуг. Корректировка согласованных метрик - задача менеджера по управлению уровнем услуг.
Вначале роли менеджера процесса управления инцидентами и менеджера процесса управления уровнем услуг можно эффективно совмещать в одном лице. Однако в перспективе после оптимизации процесса технической поддержки мы рекомендуем эти роли разделить для последующей формализации каталога услуг, согласования метрик и заключения новых SLA.
После определения метрик сервиса технической поддержки и формализации корректирующих процедур операторы службы Service Desk - в случае задержек исполнения - получат контроль над работой прочих ИТ-служб, имеющих отношение к этой деятельности. В то же время у пользователей появится информация об ожидаемых сроках устранения инцидентов. Мы настоятельно рекомендуем сделать SLA по технической поддержке доступной пользователям, а также довести до сведения сотрудников информацию о том, что означает каждый из установленных в ИТ-департаменте приоритетов инцидента. Это можно сделать через информационные бюллетени или поместив соответствующие сведения на внутренний портал.
Еще одно преимущество построения SLM вместе с Service Desk и Incident Management - это более удобная формализация каталога ИТ-услуг при уже установленном времени реакции и устранения инцидентов для каждой ИТ-системы. Например, предположим, что департамент ИТ пришел к выводу, что в каталог услуг необходимо ввести новый сервис - "Предоставление электронной почты", связав его с соответствующими ИТ-технологиями. Этот сервис имеет смысл классифицировать как бизнес-услугу.
(Обычно под бизнес-услугой подразумевают такую ИТ-услугу, которая либо воспринимается пользователями как отдельный сервис, либо явным образом поддерживает бизнес-процессы. Такого рода услуги декларируются департаментом ИТ, и для каждой из них заключается SLA. В противоположность им технологические услуги "скрыты" от бизнеса.) Имея на руках метрики из SLA для технической поддержки, не трудно составить метрики для новой услуги. Сервис "Предоставление электронной почты" основан на нескольких технологических составляющих, таких, как MS Exchange, локальная сеть и т. д. Если, скажем, время, необходимое для устранения инцидента, связанного с MS Exchange, в зависимости от приоритета составляет от 20 до 60 мин, срок устранения инцидентов, вызванных отказами в электропитании или локальной сети, варьируется в пределах от 10 до 90 мин, а инциденты, возникающие из-за сбоев клиентского ПО, устраняются за временной интервал от 35 до 60 мин, то на устранение инцидентов по сервису "Предоставление электронной почты" уйдет 35-90 мин.
Выделив новую услугу "Предоставление электронной почты" и связав ее явным образом с бизнес-процессами компании, директор ИТ-департамента совместно с финансовым департаментом подсчитал стоимость минуты простоя данного сервиса и пришел к выводу, что ранее регламентированный нижний предел в 35 мин, необходимый для устранения инцидентов минимального приоритета, сопряжен с непомерными для компании расходами. Допустим, что в связи с таким выводом было принято решение сократить срок устранения инцидента до 20 мин. Это, в свою очередь, потребовало привлечения новых сотрудников в группу поддержки клиентского ПО электронной почты. А в таком случае неоценимую помощь окажет статистика обращений в службу Service Desk, которая позволит эффективно перераспределить персонал внутри ИТ-департамента.
Финансовые выгоды
Безусловно, достижение быстрой победы не должно ограничиваться простым повышением удовлетворенности сотрудников и руководства компании от использования ИТ. Не менее важна и финансовая сторона вопроса. Руководство компании должно увидеть, какие доходы принесет построение тех или иных процессов ITSM. Здесь мы излагаем метод грубого вычисления прибыли, получаемой в результате построения одного процесса. В приведенных ниже примерах подсчета сделаны следующие предположения:
- каждый сотрудник (включая ИТ-персонал) обходится компании в 20 долл. в час (зарплата и инфраструктурные расходы);
- общее количество инцидентов - 15 000 в год (60 в день);
- общее число сотрудников - 500 человек;
- в году - 250 рабочих дней.
Если затраты на содержание каждого сотрудника представить непрерывным во времени процессом, то минута его простоя будет означать потерю в 0,33 долл. (20х1/60). К этому надо прибавить убытки компании, связанные с тем, что данный сотрудник не внес своего вклада в основной бизнес компании.
Построение процесса управления инцидентами уменьшает среднесуточное время простоя каждого сотрудника. Если эта величина снизится на 1 минуту в сутки, то общее уменьшение затрат составит: 1х0,33х500х250=41 250 долл. в год.
Экономию средств можно оценить следующим образом. Предположим, что время устранения инцидентов с максимальным приоритетом после построения процесса уменьшилось на 30 минут, инцидентов со средним приоритетом - на 15 мин, а время устранения инцидентов с минимальным приоритетом в среднем на 5 мин увеличилось. Причем количество инцидентов с максимальным приоритетом составляет 20% от общего числа инцидентов, а со средним и минимальным приоритетом - 30 и 50% соответственно. Таким образом, снижение затрат составит: 0,33х15 000х(30х0,20+15х0,30-5х0,50)=39 600 долл. в год.
Кроме того, полученная от процесса статистика обращений поможет более эффективно распределить ресурсы внутри ИТ-подразделения. Сокращение штата хотя бы на одного инженера будет означать прибавку в 40 000 долл. в год (20х8х250).
Построение процесса управления уровнем сервиса на начальном этапе позволит уменьшить количество звонков с запросами на информацию о сроках устранения инцидентов. Уменьшение количества звонков длительностью в 1 минуту на 30% будет означать, что компания за год сэкономила на отсутствии лишних простоев в работе сотрудников 5000 мин (1х0,30х15000), что эквивалентно 1666 долл. (0,33х5000). Вместе с тем служба Service Desk сможет обработать на 30% больше обращений, а это даст компании дополнительный доход за счет уменьшения числа операторов службы Service Desk и времени простоя пользователей.
Приведенные здесь методы не стоит воспринимать как инструментарий для точного расчета. Мы приводим самую грубую оценку возможной прибыли. Конечно, нельзя подсчитать потенциальную выгоду, которая может быть получена от изменения статуса ИТ-департамента в компании, от возможного перехода к политике выставления счетов за предоставленные сервисы и т. д. Однако, опираясь на статистику внедрения процессов ITSM в крупных корпорациях, можно сказать, что только экономия ИТ-бюджета может составлять от 10 до 80%, не говоря уже об увеличении прибыли самой компании.
Связка Incident Management - Service Desk - SLM может стать неплохим фундаментом для развития будущих процессов ITSM, открыв ИТ-департаменту возможность перерасти в движущую бизнес силу, превратиться из затратного подразделения в центр получения прибыли, а в более отдаленной перспективе - стать самостоятельным поставщиком услуг на российском ИТ-рынке.
Об авторе: Алексей Авакян, руководитель направления консалтинга по построению процессов ITIL/ITSM компании КРОК
