Библиотека ITIL определяет основные процессы эффективной организации ИТ-службы, однако не выделяет среди них приоритетных. ИТ-департамент, решивший поставить свою работу на сервисные «рельсы», волен выбирать с чего начать. Как показывает практика, в большинстве случаев первым реализованным процессом становится процесс управления инцидентами. Эффективная реализация его основного инструмента, службы технической поддержки пользователей, или Service Desk, может стать хорошей отправной точкой для перехода к управлению ИТ-сервисами — причем даже в случае, когда в организации изначально не было осознанного стремления строго следовать принципам ITIL. Примером может служить проект создания центральной службы технической поддержки в страховой компании «Ингосстрах».
Служба технической поддержки — первая точка контакта пользователей информационных систем со структурой, которая предоставляет и поддерживает эти системы, поэтому от успеха ее реализации во многом зависит успех взаимоотношений ИТ-департамента с бизнес-подразделениями компании. Эффективный механизм Service Desk может стать хорошей отправной точкой для перехода к управлению ИТ как услугой для бизнеса, причем даже в том случае, когда в организации изначально не было осознанного стремления строго следовать принципам ITIL.
«Ингосстрах» — старейшая отечественная страховая компания. ИТ-департамент компании численностью около 80 человек отвечает за информационное обслуживание распределенной структуры «Ингосстраха», охватывающей центральные офисы, региональные центры и филиальную сеть. Для автоматизации в компании используется система собственной разработки АИС «Ингосстрах», развитием и поддержкой которой занимается специальное управление ИТ-департамента. Помимо него в этот департамент входит управление системотехнического обеспечения, сотрудники которого отвечают за администрирование всех информационных систем компании и поддержку сетевой инфраструктуры, а также отделы технологов, информационной безопасности и телекоммуникаций.
Функции поддержки пользователей выполнял специальный отдел в составе управления системотехнического обеспечения, однако к его работе в компании накопилось много претензий. Для заявок пользователей о тех или иных неисправностях, которые поступали к инженерам отдела в основном по телефону или в форме личного общения, не существовало процедур регистрации, мониторинга их выполнения, четких критериев разрешения проблемных ситуаций, механизмов обратной связи. При этом заявки могли поступать и в другие отделы ИТ-департамента, при полном отсутствии координации действий разных его структурных подразделений. Часто возникали ситуации, когда обращения пользователей не получали адекватной реакции — заявки поступали не к тем специалистам, застревали не в том отделе, где для них могли бы найти решение, терялись. Результатом отсутствия единой точки контакта, потери обращений, рассогласованности и некоординированности действий по решению проблем пользователей становилась их растущая неудовлетворенность работой службы поддержки, снижение эффективности работы с информационными системами, все более частые простои в ИТ-инфраструктуре компании, нередко приводящие к значительным финансовым потерям.
По словам первого заместителя ИТ-департамента компании «Ингосстрах» Андрея Линькова, в начале 2004 года руководство департамента поставило вопрос о полной перестройке работы службы технической поддержки: «Рассматривалось два варианта. Первый — реализация такой службы собственными силами, приобретение соответствующего инструментария и обучение инженеров. Второй — приглашение внешней фирмы, которая с помощью наших инженеров правильно выстроит необходимые процессы технической поддержки, определит измеряемые критерии выполнения различных заявок и сможет представлять достоверные статистические данные по поводу поступающих заявок, решения инцидентов и удовлетворенности пользователей».
В «Ингосстрахе» сделали выбор в пользу второго варианта, остановившись на компании «Крок».
Уже первое знакомство с ситуацией в «Ингосстрахе» показало, что основной причиной плачевного состояния службы технической поддержки являлся низкий уровень зрелости процесса управления инцидентами, точнее, его фактическое отсутствие. Необходимо было построить такой процесс в виде последовательности действий, охватывающей различные отделы ИТ-департамента и характеризующейся определенными измеряемыми показателями эффективности. Процессом должен управлять менеджер, ответственный за получение этих показателей.
Реализация проекта
По словам руководителя направления консалтинга по построению процессов ITIL/ITSM компании «Крок» Алексея Авакяна, который возглавил работы по проекту в «Ингосстрахе», необходимость быстрой замены неэффективного отдела техподдержки новой службой заставила действовать сразу по нескольким направлениям. Прежде всего, это был аудит ИТ-инфраструктуры и выстраивание процессов ITIL применительно к конкретной информационной среде. Параллельно велась установка инструментальной системы для реализации службы технической поддержки, а также набор и подготовка персонала для работы в этой службе. Специалисты компании «Крок» в режиме «мозгового штурма» разработали процессы управления инцидентами и управления качеством службы технической поддержки. Весьма краткие сроки, отпущенные на эту деятельность, отвечали потребностям «Ингосстраха», где были заинтересованы в как можно более быстром включении в работу новой структуры.
Подобные проекты связаны с большими рисками; чтобы уменьшить их, еще до начала работ стороны подписали документ, озаглавленный «Определение охвата проекта». Это классическое для теории управления проектами соглашение в данном случае было несколько видоизменено, включив в себя описание не только тех работ, которые компания-подрядчик обязывалась выполнить, но и тех аспектов, которые в проекте затрагивать не предполагалось. Тем самым были четко ограничены рамки проекта, благодаря чему снизился риск сопротивления сотрудников ИТ-департамента планируемым переменам. Также заранее исключались ситуации изменения требований заказчика в ходе выполнения проекта, что, по наблюдениям специалистов «Крок», в отечественных компаниях происходит довольно часто и почти неминуемо приводит к краху проекта, поскольку связано с коренным изменением определенных в начале сроков, содержания и бюджета проекта. Кроме того, внедрение новой службы неизбежно связано с определенными изменениями в ИТ-инфраструктуре заказчика, поэтому надо было позаботиться о том, чтобы эти изменения не затронули критичных для бизнеса компании функций и не вызвали проблем в работе пользователей.
Аудит ИТ-инфраструктуры выявил слабые места и позволил наметить пути их устранения. В ходе создания операционной модели процесса управления инцидентами была сформирована логика взаимодействия групп технической поддержки, распределены роли и ответственности, выработаны соответствующие процедуры. Но для построения полноценной картины необходимо было понимать степень влияния различных инцидентов на бизнес заказчика, а для этого, прежде всего, нужно было определить, какие информационные сервисы существуют в компании «Ингосстрах», из каких компонентов они состоят, для каких целей используются. До начала проекта самого понятия «информационный сервис» в компании не существовало, поэтому в ходе реализации проекта сотрудники «Крок» помогли ИТ-департаменту «Ингосстраха» формализовать каталог своих сервисов и определить параметры их технической поддержки исходя из приоритетности для основного бизнеса.
Вслед за этим была создана модель контроля и саморазвития процесса управления инцидентами, определены основные показатели его эффективности, введена роль менеджера процесса, отслеживающего эти показатели, продуманы способы разрешения ситуаций нарушения регламентов и то, каким образом менеджер процесса сможет выполнять корректирующие действия для улучшения процесса. Была создана схема ежемесячного составления отчетов для руководства и выдачи рекомендаций управленческого характера по результатам анализа работы Централизованной службы технической поддержки (ЦСТП). Таким образом, создавался инструмент изменения конфигурации сервиса технической поддержки в случае изменения бизнес-требований, например, открытия новых офисов, необходимости поддержки в круглосуточном режиме, без принципиальной перестройки процесса управления инцидентами.
Андрей Линьков: «В начале прошлого года руководство ИТ-департамента ?Ингосстрах? поставило вопрос о полной перестройке работы службы технической поддержки» |
Часто процесс определения основных процедур, информационных сервисов и метрик их технической поддержки был подобен деловой игре, в которой ИТ-специалисты компании «Ингосстрах» отрабатывали различные варианты по принципу «что будет, если...» и помогали исполнителям проекта находить оптимальные варианты. Законченная картина процесса управления инцидентами формировалась путем последовательного обсуждения предложений специалистов «Крок» на различных уровнях, от инженеров и руководителей отделов, которых непосредственно затронут различные процедуры процесса, до руководства департамента, в компетенции которого было согласование метрик поддержки основных сервисов. Тем самым в «Крок» застраховали себя от формирования нереальных сервисов, задания недостижимых параметров разрешения инцидентов, определения нереализуемых способов обработки заявок и т.д.
Другое направление реализации проекта касалось установки инструментария для автоматизации работы службы технической поддержки; в таком качестве заказчик выбрал систему HP OpenView Service Desk. По словам Линькова, на решение о выборе программного инструментария повлияла как репутация продукта, так и оценки коллег по финансовой отрасли, уже имевших опыт работы с этой системой. Service Desk был синхронизирован с АИС «Ингосстрах». Затем система была настроена на процедуры процесса управления инцидентами и уровнем обслуживания, заданные на этапе консалтинга. Параллельно с этим шел набор и обучение персонала первой линии службы технической поддержки. Поскольку служба была полностью передана на аутсорсинг, в ней работают только сотрудники компании «Крок», однако ее штат частично был сформирован из бывших специалистов отдела техподдержки ИТ-департамента «Ингосстрах» — носителей уникального опыта работы с ИТ-инфраструктурой заказчика. В начале работы персонал службы был обучен основам ITIL, а затем и работе с программным инструментарием Service Desk.
После завершения этапов консалтинга, внедрения инструментария и набора сотрудников службы технической поддержки, новая структура была запущена в эксплуатацию. Все пользователи в «Ингосстрахе» получили уведомление о том, что теперь их обращения о проблемах при работе с оборудованием принимаются по новому единому телефону и единому адресу электронной почты. Можно было ожидать, что переключение пользователей в огромной компании на новую схему обслуживания, причем полностью зависящую от внешней организации, была связана с определенными рисками.
ЦСТП — как это работает
В результате реализации проекта в ИТ-департаменте «Ингосстрах» было создано новое функциональное звено — центральная служба технической поддержки пользователей, деятельность которой и была передана на аутсорсинг. ЦСТП решает все вопросы обслуживания рабочих мест пользователей в трех московских офисах «Ингосстраха» и разбросанных по городу отделах массового страхования по ОСАГО, а также принимает обращения и из региональных офисов. Формально услугами ЦСТП пользуется 1180 человек в центральных подразделениях компании, однако вместе с пользователями в регионах оно вдвое больше. В структуру ЦСТП входят десять специалистов «Крок»; пять из них, включая менеджера процесса, составляют первую линию поддержки, а пять работают на второй. Первая линия реализует единую точку контакта для приема и первичной обработки пользовательских заявок. В случае невозможности разрешения инцидента силами инженеров первой линии, заявки передаются на вторую, которая частично находится на аутсорсинге у «Крок», а частично реализуется силами специалистов функциональных подразделений ИТ-департамента «Ингосстрах». ЦСТП, сохраняя принцип предоставления единой точки контакта в виде одного телефона и одного электронного адреса, на деле является распределенной структурой, поскольку сотрудники службы размещаются во всех трех московских офисах «Ингосстраха». Как отмечает Линьков, это позволяет гибко реагировать на изменение ситуации в ИТ-инфраструктуре компании и перераспределять инженеров поддержки по тем точкам, где возрастает потребность в их непосредственном вмешательстве в работу пользователей.
Для пользователей «Ингосстрах» определена и третья линия — сервисная поддержка оборудования силами внешних организаций (как производителей, так и системных интеграторов). Скажем, техническим обслуживанием рабочих станций занимается сервисный центр «Крок», но решение о необходимости подключения специалистов третьей линии и контроль последовательности действий между отделами и внешними фирмами являются формальными компонентами процесса управления инцидентами и находятся в компетенции ЦСТП.
Рис. 1. График распределения заявок ЦСТП |
ЦСТП обрабатывает 120-150 заявок ежедневно. Их колебание в разные периоды и распределение по часам рабочего дня иллюстрирует график на рис. 1. Анализ такого распределения позволяет спланировать расписание работы операторов первой линии поддержки таким образом, чтобы не только не возникало периодов их полного отсутствия на рабочем месте, но и исключались очереди звонков или обращений пользователей в любой другой форме. Всплески количества заявок возникают во время проведения крупных изменений в ИТ-инфраструктуре «Ингосстрах», таких, например, как перевод компании в новый домен, переход к новой почтовой системе Microsoft Exchange, совпавший по времени с миграцией значительной части сотрудников компании на другую территорию. В такие периоды количество ежедневно принимаемых заявок может возрасти до 200-250, поскольку постоянно возникает необходимость вмешательства инженеров службы поддержки в процессы настройки новых систем на рабочих местах, их реконфигурации, выстраивания заново инфраструктуры печати, виртуальных локальных сетей и т.д.
Рис. 2. Каталог информационных услуг в компании «Ингосстрах» |
Создание процесса управления инцидентами и определение каталога информационных сервисов, которые предоставляет ИТ-департамент «Ингосстрах» позволили четко определить, что такое инцидент в ИТ-инфраструктуре, каков его жизненный цикл, какие отделы департамента будут задействованы на каждом этапе разрешения проблемной ситуации, кто несет ответственность за решение инцидента и т.д. Каждый из высокоуровневых сервисов в каталоге (рис. 2) может быть представлен как дерево сервисов, его образующих. Например, сервис телефонии может включать в себя сервисы телефонной станции, контакт-центра, голосовой почты, системы записи разговоров и т.д. Сервис рабочих станций состоит из сервисов электронной почты, печати, администрирования операционной системы; почтовый сервис, в свою очередь, можно представить как совокупность таких подсервисов, как серверный и клиентский компоненты Microsoft Exchange, антиспамерское программное обеспечение и др. Как поясняет Авакян, выделение подсервисов в каждой услуге дает возможность правильно маршрутизировать обработку инцидентов, а также задавать метрики ИТ-сервисов при заключении контрактов с внешними субподрядчиками.
Решение проблемы
Инцидентом считается либо полное прекращение предоставления ИТ-сервиса (например, разрыв канала связи и, как следствие, невозможность обмениваться электронной почтой), либо падение качества обслуживания ниже допустимого уровня, приводящее к последствиям, критичным для основного бизнеса (например, из-за технической неисправности резко снижается производительность канала связи). Основное назначение службы технической поддержки состоит в контроле процесса возвращения сервиса к его работоспособному состоянию, то есть решении инцидента. В случае если инцидент не может быть разрешен силами инженеров первой линии поддержки, вступают в силу маршруты эскалации, то есть обработка заявки пользователя передается конкретным специалистам второй линии. В ЦСТП компании «Ингосстрах», в соответствии с процессом управления инцидентами, четко определены группы ответственности по решению инцидентов для разных сервисов. В частности, решение всех инцидентов, связанных с неисправностями пользовательских рабочих станций, находится на аутсорсинге у специалистов «Крок» как на первой, так и на второй линии поддержки, в то время как решением инцидентов для всех остальных сервисов занимаются сотрудники подразделений ИТ-департамента «Ингосстрах». Поэтому сообщения о сбоях, связанные, например, с серверным оборудованием, телефонией или нарушением политик информационной безопасности, будучи зафиксированы на первой линии поддержки ЦСТП, сразу же передаются на вторую линию.
Каждый инцидент имеет определенный жизненный цикл, управление которым осуществляет ЦСТП. Обращение пользователя в службу поддержки является сигналом для регистрации инцидента. Понятно, что при этом между реальным возникновением причины сбоя, например, перегревом элемента электропитания, приведшим к отключению рабочей станции, и моментом регистрации инцидента, проходит какое-то время. Этот временной зазор сводится к нулю, если существует автоматизированная система мониторинга ИТ-инфраструктуры, в реальном времени фиксирующая сбои и передающая информацию в систему Service Desk. Однако в компании «Ингосстрах» пока еще только задумываются о возможности использования такого решения. С момента регистрации инцидента до момента назначения лица, ответственного за его решение, заявка пользователя находится в статусе «зарегистрирована». В службе поддержки ей присваивается уникальный идентификатор, а пользователь получает сообщение о регистрации своей заявки.
Следующий этап жизненного цикла — назначение сотрудника ЦСТП, ответственного за обработку заявки. Пользователь вновь получает сообщение об этом, а также об ориентировочном времени решения инцидента. Ответственный сотрудник устраняет причину инцидента собственными силами или передает обработку заявки специалистам второй линии. Пройдя все этапы решения, заявка возвращается к ответственному лицу в ЦСТП, после чего он переводит ее в статус «ожидания разрешения на закрытие». Принципиальным моментом правильной работы службы технической поддержки является то, что инженер, работавший над решением инцидента, не может сам закрыть этот процесс. Только ответственный сотрудник первой линии поддержки, после получения подтверждения пользователя, что неисправность устранена, переводит заявку в статус «закрытой». Для старой службы техподдержки в компании «Ингосстрах» типичной была ситуация, когда кто-либо из инженеров, поработав над обращением пользователя, закрывал заявку, не получив его удовлетворительной реакции. И лишь спустя некоторое время выяснялось, что на деле неисправность не была устранена, а пользователь по-прежнему находится в состоянии ожидания. В ЦСТП, следующей строгим правилам процесса управления инцидентами, такая ситуация исключена.
Поскольку есть большая вероятность, что пользователь, удовлетворенный решением проблемы, просто пропустит момент формального подтверждения этого решения, предусмотрено автоматическое закрытие заявки через определенное время. Сообщение о закрытии заявки также по какой-либо причине может вызвать неудовлетворительную реакцию пользователя. В этом случае обработка заявки возвращается в начало жизненного цикла.
Качество поддержки
Специалисты «Крок» помогли «Ингосстраху» формализовать свои информационные сервисы, однако пока это единственный шаг ИТ-департамента страховой компании к реализации принципов ITSM собственными силами. Об управлении качеством этих сервисов, заключении соглашений об уровне обслуживания с бизнес-подразделениями «Ингосстрах» речь еще не идет. Однако переданный на аутсорсинг процесс управления инцидентами имеет, согласно методологии ITIL, свои измеряемые показатели эффективности, а техническая поддержка, рассматриваемая в «Ингосстрахе» как внешний ИТ-сервис, имеет свои собственные критерии качества. Между компаниями «Крок» и «Ингосстрах» заключено соответствующее соглашение об уровне обслуживания (service level Agreement, SLA).
Для управления качеством обслуживания пользователей используются четыре базовые метрики.
1. Решение инцидента при первом обращении (First Contact Resolution, FCR). Определяется как процент заявок, которые удается обрабатывать силами персонала первой линии поддержки без последующей эскалации инцидента на вторую линию. Это один из наиболее важных с финансовой точки зрения параметров, поскольку он отображает вполне понятное для бизнеса соотношение деньги/время. Стоимость работы инженера службы поддержки и время решения инцидента растут от линии к линии, поэтому заказчик сервиса заинтересован в скорейшем устранении инцидента. Кроме того, этот показатель важен с психологической точки зрения, так как он демонстрирует, насколько комфортно чувствует себя пользователь в общении со службой технической поддержки. В ЦСТП на первой линии работают квалифицированные инженеры, а не просто операторы, принимающие заявки, поэтому FCR составляет сейчас 60-65%. Существует определенная методика управления этим показателем. Через некоторый период работы службы его значение достигает стабильного уровня, и тогда менеджер службы может продумать возможность повышения FCR. Для этого он анализирует причины, по которым те или иные заявки не удается обработать на первой линии поддержки. Среди них могут быть, например, отсутствие прав доступа к базе данных или недостаток компетенции по определенному продукту. Если затраты на предоставление соответствующих прав или на небольшой тренинг оказываются меньше тех сумм, в которые выливается передача решения инцидента на вторую линию поддержки, менеджер службы может предложить ИТ-директору сделать дополнительные вложения, которые позволят поднять уровень FCR. Такие базовые пороговые значения FCR фиксируются в соглашениях об уровне обслуживания. В силу того, что период работы ЦСТП «Ингосстрах» еще не достаточен для накопления статистики для подобного анализа FCR, этот показатель пока не фиксируется в SLA, но фигурирует в регулярных отчетах менеджера службы и анализируется руководством ИТ-департамента.
2. Доступность службы поддержки. Рассматривается как совокупность показателей доступности для каждого конкретного оператора службы. В ЦСТП «Ингосстрах» сегодня под доступностью понимается физическое присутствие инженеров на своих рабочих местах. Задача менеджера службы — с учетом квалификации своих сотрудников подбирать количество людей в сменах и составлять график их работы таким образом, чтобы показатель доступности приближался к 100%. Дополнительные возможности для оптимизации распределения ресурсов службы предоставляет анализ графика частоты заявок в разные часы рабочего дня.
3. Согласованное время реакции. Понимается как время с момента регистрации инцидента до момента назначения сотрудника службы поддержки, ответственного за его решение.
4. Согласованное время решения инцидента. Варьируется от 15 минут до нескольких суток в зависимости от приоритета инцидента. Обязательным элементом процесса управления инцидентами в ITSM является их классификация в зависимости от степени влияния на бизнес. В SLA заданы три возможных приоритета инцидентов: максимальный, средний и минимальный. Наиболее приоритетными считаются инциденты, связанные с нарушением работы сервисов антивирусной защиты и поддержки сетевой печати. На время решения влияет также приоритет пользователя, от которого получена заявка. Так, очевидно, наиболее оперативно служба должна среагировать на обращения топ-менеджеров компании.
Как пояснил руководитель направления технической поддержки компании «Крок» Александр Сапронов, в компании следовали одной из важных, но не самых популярных у отечественных специалистов рекомендаций ITIL — сделали соглашение об уровне обслуживания ЦСТП открытым для пользователей. Любой из них может получить на внутреннем портале компании информацию о том, на какие сроки восстановления своей системы он может рассчитывать. В компании запущен не только процесс управления инцидентами, но и процесс совершенствования его качества, за который отвечает менеджер процесса, он же менеджер ЦСТП. На ежемесячных встречах с руководством ИТ-департамента анализируется работа службы, причины неудач в обработке заявок в срок, тенденции в распределении инцидентов по разным информационным сервисам и функциональным отделам ИТ-департамента. Изучаются также слабые места инфраструктуры и распределение нагрузки по рабочим группам технической поддержки. Такой анализ позволяет менеджеру службы принимать решения об изменении тех или иных параметров работы службы, например, схем эскалации или времени реакции на инциденты, а руководителям ИТ-департамента — выделять требующие повышенного внимания зоны своей ИТ-инфраструктуры.
Перспективы
По прошествии нескольких месяцев работы ЦСТП и исполнитель, и заказчик проекта положительно оценивают его первые итоги. Сегодня сотрудники «Ингосстраха» уверены: обратившись со своими проблемами по телефону 3333, они получат оперативный ответ и квалифицированную помощь. Успех в передаче на аутсорсинг одного их важнейших функциональных звеньев ИТ-структуры компании заставил руководство ИТ-департамента всерьез задуматься о расширении этой инициативы. Дело в том, что до сегодняшнего дня вне компетенции ЦСТП остается поддержка наиболее критичного для бизнеса «Ингосстрах» информационного сервиса — системы АИС «Ингосстрах», обслуживанием которой занимаются специалисты ИТ-департамента. Однако эффективность работы централизованной службы технической поддержки и неоправданность опасений по поводу возможных рисков аутсорсинга побудили компанию инициировать новый проект, в результате реализации которого «Ингосстрах» должен получить единую точку входа для обращений пользователей по всему спектру проблем, связанных с их компьютерными системами, включая систему автоматизации основного бизнеса.
Не исключено, что результаты работы ЦСТП дадут старт для более глубокого внедрения в компании «Ингосстрах» принципов ITSM. Во всяком случае, уже сейчас в ИТ-департаменте думают над возможностью реализации таких ключевых процессов ITIL, как управление конфигурациями и изменениями. Логичным шагом было бы и внедрение процесса управления проблемами, позволяющего выявлять корневые причины инцидентов.