Service Desk своими руками

Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?

Денис Бобров

Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?» Вот каким может быть ответ.

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

В компаниях, где ведется регистрация и анализ обращений пользователей (там, где настроен процесс управления инцидентами и функционирует служба Service Desk), ответы на вопросы о том, сколько раз в месяц «зависает» (дает сбой) критически важная для бизнеса программная система, на каких рабочих местах это происходит, в чем причина каждого инцидента, находятся сами собой и могут существенно повлиять на планы развития компании в области ИТ.

Сколько это стоит?

Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk. Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-департамента план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-департамент стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?

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

Итак, если не удается построить Service Desk на средства компании, то можно попробовать развернуть службу самостоятельно, без привлечения сторонних консультантов и затрат на специализированное программное обеспечение.

С чего начать?

Многие скажут, что начинать надо с оформления проекта. Однако в случае построения службы Service Desk подобный подход нереализуем. Какие цели проекта следует указать? Какие сроки поставить? Какие риски проекта описать? Практика организаций, в которых работает Service Desk, показывает, что создать идеальную службу невозможно. Она постоянно изменяется и совершенствуется. Поэтому с большой вероятностью описанные грандиозные цели проекта по созданию Service Desk утратят свою актуальность еще в процессе их достижения. А между тем, срок такого проекта может исчисляться годами! Так нужен ли такой проект? С другой стороны, работать без четко описанных целей также невозможно. Необходимо понимать, в каком направлении двигаться и что должно получиться в итоге.

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

Шаг первый. Фиксируем регламенты

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

Допустим, вы купили новый телевизор. Как часто вы будете пользоваться инструкцией по эксплуатации? Наверное, не очень часто. Тем не менее ни у кого не возникает сомнения в полезности этого документа. То же самое можно сказать об описании функционирования службы Service Desk: оно обычно лежит на полке в одном из кабинетов ИТ-департамента до тех пор, пока не потребуется изменить или усовершенствовать процесс приема и обработки обращений пользователей.

Относительно объема данного документа, его полноты и развернутости четких рекомендаций не существует. Тем не менее нет смысла подробнейшим образом и максимально детально описывать все регламенты службы Service Desk. Документ получится слишком большим и нечитабельным. Однако создавать его излишне кратким также не стоит. В первом варианте документа на один регламент достаточно отвести одну-две страницы.

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

Количество линий поддержки службы Service Desk и распределение ИТ-сотрудников по линиям поддержки. Классика ITIL рекомендует развернуть три линии. К первой линии поддержки могут относиться операторы call-центра, ко второй - администраторы баз данных, системные администраторы, технические специалисты, к третьей - программисты, старшие системные администраторы. Ваши сторонние подрядчики, организации, которые предоставляют вам услуги по сопровождению ПО, провайдеры телекоммуникационных услуг и т. д. также могут быть отнесены к третьей линии поддержки.

Способы приема заявок пользователей. Вариантов достаточно много, начиная от официально оформленной служебной записки в бумажной форме и заканчивая дружеским общением с помощью ICQ. Но в первое время работы службы Service Desk стоит ограничиться одним или двумя способами поступления обращений пользователей. Перечислим наиболее распространенные.

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

Вторым способом обращений пользователей за поддержкой может быть электронная почта. В этом способе коммуникации с Service Desk есть свои преимущества и недостатки. Далеко не на всех предприятиях пользователи настолько грамотны в области применения ИТ, чтобы с первого раза кратко и понятно описать ситуацию (произошедший сбой). Неточное описание может повлечь за собой долгую переписку между оператором call-центра и пользователем. Результат - увеличение времени решения проблемы. Положительные стороны обращения пользователя в службу Service Desk при помощи электронной почты, разумеется, тоже есть. Например, пользователь направляет электронное письмо с описанием сбоя на определенный адрес. При поступлении нового сообщения в этот почтовый ящик происходит автоматическая регистрация обращения в предварительно настроенной системе службы Service Desk. В этом случае оператор первой линии поддержки не тратит время на регистрацию обращения, а может сразу же приступить к поиску решения инцидента.

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

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

Каждый сбой в ИТ-инфраструктуре влечет за собой остановку бизнес-процесса одного конкретного специалиста, и/или отдельного отдела, и/или целого предприятия. Следовательно, каждый сбой имеет различные степени влияния. Поломка принтера у одного человека влияет только на бизнес-процессы одного сотрудника предприятия, и то не на все. Если же принтер сетевой, то влияние сбоя усиливается, поскольку сбои в бизнес-процессах затрагивают нескольких сотрудников. Если же остановился сервер обмена сообщениями (например Exchange Server), то сбой, скорее всего, затрагивает большинство подразделений.

При определенном навыке оператор Service Desk может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.

26.09.2005г