Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен 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 может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.
Задача на этапе составления документации – определить степени влияния и приоритеты и на их основе рассчитать время разрешения инцидента на первой, второй и третьей линиях поддержки.
Классификация обращений. Теория предлагает стандартную классификацию запросов: запрос на обслуживание, на изменение, на предоставление информации и т. д. Можно придумать свои классы или использовать только некоторые из известных. Вообще отказываться от классификации обращений не следует. В дальнейшем, при анализе обращений она сослужит добрую службу.
«Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы 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 может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.
Задача на этапе составления документации – определить степени влияния и приоритеты и на их основе рассчитать время разрешения инцидента на первой, второй и третьей линиях поддержки.
Классификация обращений. Теория предлагает стандартную классификацию запросов: запрос на обслуживание, на изменение, на предоставление информации и т. д. Можно придумать свои классы или использовать только некоторые из известных. Вообще отказываться от классификации обращений не следует. В дальнейшем, при анализе обращений она сослужит добрую службу.
«Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы Service Desk, можно однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько рекомендаций, которые помогут в построении грамотной схемы мотивации.
- Мотивация в большей степени должна быть построена на поощрении сотрудников, а не на наказании. Использовать штрафные санкции допустимо только в крайних случаях, например при нарушении сотрудником установленных регламентов.
- Материальная мотивация должна быть ощутимой. 5% от оклада специалиста – это пародия на мотивацию.
- Схема мотивации должна быть проста и понятна каждому сотруднику ИТ-департамента. Пять-шесть параметров, которые используются для расчета премий специалистов, можно считать пределом.
Шаг второй. Обучение
Для того чтобы служба Service Desk начала работать эффективно, недостаточно одной, пусть даже идеальной схемы мотивации сотрудников. Весь штат ИТ-департамента должен знать, а еще лучше – понимать, зачем нужен Service Desk, что такое управление инцидентами и т. д. Для этого необходимо обучить всех сотрудников ИТ-департамента основам ITIL. Затраты при этом будут неизбежны.
Нежелательно обучать специалистов самостоятельно, так как цена неверно понятого описания процесса или термина может оказаться слишком высокой. Наибольший эффект достигается при обучении сотрудников ИТ-отдела профессиональными тренерами. Можно совместить приятное с полезным. К примеру: проведите обучение в выходной день за городом. В этом случае бизнес не останется без поддержки в рабочие дни, а все сотрудники ИТ-департамента приобретут не только полезные знания, но и хорошее настроение. Отказавшись от обучения персонала основам ITIL, можно столкнуться с большой проблемой – саботажем. Выбираться из этой ситуации окажется дороже, чем заранее предотвратить ее, проведя обучение специалистов.
После того как все сотрудники прошли тренинг по основам ITIL/ITSM, следует ознакомить их с регламентами, которые уже составлены. И никак не раньше. Уже с обученными сотрудниками (или с некоторыми из них) можно и нужно проконсультироваться, узнать их мнение, выслушать предложения. Здесь может произойти первая корректировка процесса приема и обработки обращений пользователей.
Шаг третий. Организация call-центра
«Что может быть проще! – скажете вы. – Берем стол, стул, компьютер, телефон, принимаем на работу девушку с приятным голосом. И вот call-центр готов». Однако не все так просто. Существует как минимум два вопроса, которым требуется уделить особое внимание: какими качествами должен обладать оператор и где расположить его рабочее место.
Приятный голос – это далеко не самое главное, чем должен обладать человек, работающий на первой линии поддержки Service Desk. Стрессоустойчивость гораздо важнее для оператора, который в течение одного рабочего дня может несколько десятков раз слышать одну и ту же фразу: «У меня не работает компьютер!» — и при этом обязан всегда одинаково невозмутимо и доброжелательно выяснять у пользователя, что же действительно сломалось. Кроме того, сотрудник первой линии поддержки должен хорошо владеть русским языком. Грубые грамматические и синтаксические ошибки, допущенные оператором при регистрации обращения пользователя, могут неблагоприятно отразиться на понимании сути заявки другими специалистами. Наконец, оператор call-центра должен обладать общими ИТ-знаниями. Комментарии здесь излишни. Очевидно, что оператор, услышав слово «винчестер», должен представлять себе устройство долговременного хранения информации, а не огнестрельное оружие.
Практика показывает, что нахождение первой и третьей линий поддержки в одном помещении крайне негативно сказывается на результатах работы высококвалифицированных специалистов. Резко снижается эффективность системных администраторов. Количество ошибок в программном коде у программистов возрастает в несколько раз! Этот факт обусловлен тем, что сотрудники, работающие на третьей линии поддержки, решают, как правило, нетривиальные задачи, требующие высокой степени сосредоточенности. А как можно сосредоточиться, если рядом каждые десять минут звонит телефон, и оператор отвечает: «Добрый день, отдел ИТ слушает»?
Совсем другая обстановка возникает, если расположить рабочее место оператора call-центра рядом с рабочими местами сотрудников второй линии поддержки. Решение задач второй линии поддержки не требует особой сосредоточенности и, следовательно, общение оператора с пользователями не будет сильно их отвлекать. В то же время тесное общение специалистов первой линии поддержки с сотрудниками второй линии может дать положительные результаты: через некоторое время часть проблем, которые ранее решались на второй линии, смогут устраняться уже на первой. Этим можно улучшить один из главных показателей эффективности Service Desk – сократить среднее время решения проблем.
Шаг четвертый
Когда принципы функционирования службы Service Desk описаны (подготовлена документация), сотрудники знают и понимают основы ITIL/ITSM и определено рабочее место операторов call-центра, стоит задуматься об инструментарии. Для того чтобы контролировать процесс приема и обработки обращений пользователей, необходимо специализированное программное обеспечение. Наиболее распространенным инструментом сегодня является HP OpenView ServiceDesk. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.
Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт http://www.helpdesk.com, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб Help Desk, Service Desk и call-центров. Потратив немного времени, можно найти бесплатный и вполне достаточный по набору функций инструментарий. Если и этот вариант не устраивает по каким-либо причинам, то можно, наконец, использовать «подручные» средства – Microsoft Excel и Access. Потратив несколько часов рабочего времени, можно создать свой собственный уникальный инструмент для службы Service Desk.
Первые результаты
Теперь все готово для запуска в работу новой службы Service Desk. Конечно, нужно не забыть оповестить всех пользователей о новой услуге, сообщить единый телефонный номер отдела ИТ, по которому пользователи могут обратиться с любым вопросом.
Каких же результатов стоит ожидать? Если в первый день работы службы на телефон call-центра поступит более одного звонка от пользователей – это достижение. Если в первый месяц работы хотя бы один сотрудник компании скажет, что ему стало удобнее общаться с ИТ-департаментом, – это победа.
Можно выделить две основные проблемы, с которыми придется столкнуться в первое время работы службы Service Desk. Первая заключается в том, что большинство пользователей в первые месяцы будут продолжать «по старинке» звонить системным администраторам, программистам и т. д. Но если система мотивации сотрудников ИТ была выстроена достаточно грамотно и был проведен тренинг по основам ITIL, то об этом можно не беспокоиться. ИТ-руководитель не будет тратить массу своего времени на разъяснительные беседы с пользователями о полезности службы Service Desk. Системный администратор, которому в очередной раз позвонит пользователь, сам объяснит, куда и к кому надо обращаться с вопросами. Причем он найдет такие аргументы, о которых ни один ИТ-менеджер даже не догадывается. Такой путь — приучить пользователей звонить по одному определенному номеру —максимально эффективен.
Известно много случаев, когда руководители ИТ-служб пытались переучить сотрудников предприятия иными способами: воздействуя на пользователей через высшее руководство, меняя внутренние номера телефонов сотрудников ИТ-департамента, проводя массовую разъяснительную работу с пользователями. Но все эти варианты неэффективны и приводят, как правило, к длительному времени адаптации пользователей к работе в новых условиях. Нежелание пользователей взаимодействовать с ИТ-департаментом через единую точку контактов можно преодолеть только с помощью самих сотрудников отдела ИТ.
Вторая проблема, с которой придется столкнуться, – увеличение среднего времени обработки одного инцидента. Это плата за те статистические данные по обращениям, которые получит менеджер уже после первого месяца работы службы Service Desk. Увеличение времени решения инцидента, безусловно, будет заметно для пользователей, и именно с этим будут связаны основные негативные эмоции сотрудников предприятия. Ничего особенного в этом нет: служба только-только начала работать, процесс управления инцидентами еще слабо настроен, и сотрудники ИТ не привыкли действовать по новой схеме. Но уже через месяц после запуска Service Desk можно получить данные, из анализа которых видно, где в процессе слабое место, что и как нужно исправить, кто мешает нормальному ходу процесса. Начнется бесконечная настройка и модернизация службы Service Desk. В зависимости от скорости реагирования на выявленные проблемы и неточности в функционировании службы будет сокращаться среднее время решения инцидентов, повышаться удовлетворенность пользователей и т. д.
Пути развития
После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.
Дальнейшее развитие службы Service Desk может выражаться в замене того «бесплатного» инструмента регистрации и обработки запросов пользователей, который использовался в первое время работы, на более функциональный, специализированный. Новый инструмент может предоставить более детальную информацию о работе Service Desk, и тогда появится возможность проводить более тонкую настройку процесса управления инцидентами. При этом пользователи также получат дополнительные услуги, к примеру, автоматическое оповещение по электронной почте о решении инцидента. После того, как проявятся реальные положительные результаты работы службы Service Desk (а они проявятся обязательно), доказывать высшему руководству компании необходимость приобретения специализированного программного обеспечения будет намного проще. Не исключен даже вариант, когда руководство компании само предложит помощь и средства на развитие процесса обработки запросов пользователей.
Без рисков не обойтись
Конечно, при самостоятельном выстраивании процессного подхода в управлении ИТ-инфраструктурой не исключены риски, связанные с принятием ошибочных решений, что может нарушить сроки построения и настройки процесса управления инцидентами. Эти риски значительно снижаются, если воспользоваться услугами квалифицированных и опытных консультантов. Но какой бы путь вы ни избрали, стоит помнить: основой для любого процесса ITIL является информация, которую можно получить только имея грамотно построенную и работающую службу Service Desk. И именно с построения этой службы следует начинать работу по эффективному управлению ИТ-инфраструктурой предприятия.
Денис Бобров, заместитель руководителя ИТ-департамента ЗАО «Талосто», Bobrov_DA@talosto.ru
http://www.osp.ru
Читать далее...
