Microsoft Operations Framework. - Service Desk-Microsoft

Служба поддержки
Функция управления сервисом
опубликовано: Октябрь 2002

переформатировано: Январь 2005
Последнюю информацию можно получить на http://www.microsoft.com/mof
Информация, содержащаяся в данном документе, представляет современный взгляд Корпорации Microsoft
на вопросы, обсуждаемые на дату публикации. Поскольку Microsoft должна реагировать на изменяющиеся
рыночные условия, ее не следует интерпретировать как обязательство со стороны Microsoft, и Microsoft не
может гарантировать точность какой-либо информации, представленной после даты опубликования.
Данный документ предназначен только для информационных целей. MICROSOFT НЕ ДАЕТ НИКАКИХ
ГАРАНТИЙ, ЯВНЫХ, ПОДРАЗУМЕВАЕМЫХ ИЛИ ПРЕДПИСАННЫХ ЗАКОНОМ, В ОТНОШЕНИИ ИНФОРМАЦИИ,
СОДЕРЖАЩЕЙСЯ В ДАННОМ ДОКУМЕНТЕ.
За соответствие использования документа со всеми применимыми законами об охране авторского права

отвечает пользователь. Без ограничения авторских прав данный документ может воспроизводиться,
храниться в информационно-поисковой системе или вводиться в нее, или передаваться в любой форме
или с применением любых средств (электронных, механических, фотокопирования, записи и прочих), но
только в целях, предусмотренных в четко сформулированном письменном разрешении Корпорации
Microsoft.
Компания Microsoft может иметь патенты, заявки на патент, торговые марки, авторские права или другие
права на интеллектуальную собственность, которые распространяются на предмет данного документа. За
исключением случаев, когда это четко предусмотрено в письменном лицензионном соглашении с
компанией Microsoft, предоставление данного документа не дает Вам никакой лицензии на эти патенты,
торговые марки, авторские права или другую интеллектуальную собственность.
Если не отмечено иначе, примеры компаний, организаций, изделий, имена доменов, адреса e-mail,
логотипы, люди, места и события, описанные здесь - вымышленные и у авторов не было намерения
никоим образом связывать их с какими-либо реальными компаниями, организациями, изделиями,
именами доменов, адресами e-mail, логотипами, людьми, местами или событиями, или подразумевать их.
 2005 Microsoft Corporation. Авторские права защищены.
Microsoft, Visio, Windows, Windows NT, и Windows Server – это или зарегистрированные торговые марки,
или торговые марки Корпорации Microsoft в Соединенных Штатах и/или в других странах.
Названия реально существующих компаний и изделий, упомянутые здесь, могут быть торговыми марками
их соответствующих владельцев.
Аннотация.....................................................................................................3
Введение......................................................................................................4
Служба поддержки: Обзор...........................................................................5
Цели и Задачи...........................................................................................5
Основные определения...............................................................................6
Структура службы поддержки.....................................................................7
Служба поддержки в небольших организациях......................................12
Масштабирование службы поддержки для большой организации.............12
Роль службы поддержки внутри IT организации....................................12
Сфера службы поддержки.........................................................................13
Кого поддерживает служба поддержки?................................................14
Что делает служба поддержки?............................................................15
Benefits of a Service Desk...........................................................................15
Процессы и виды деятельности..................................................................17
Обзор диаграммы процессов......................................................................17
Функционирование службы поддержки.......................................................17
Управление персоналом и ресурсами....................................................19
Взаимодействие с клиентами................................................................31
Работа службы поддержки...................................................................36
Продвижение и маркетинг службы поддержки.......................................42
Управление затратами и возврат вложений...........................................45
Обзор производительности службы поддержки......................................49
Приготовление отчетов........................................................................59
Оптимизация Службы Поддержки...............................................................60
Reviewing Service Desk Operation..........................................................63
Оптимизация процессов.......................................................................64
Определение требований к аутсорсингу................................................66
Оптимизация персонала......................................................................72
Оптимизация навыков персонала.........................................................97
Оптимизация физического пространства.............................................100
Оптимизация технологии...................................................................102
Пересмотр и оптимизация контроля и отчетности.................................106
Роли и ответственность............................................................................108
Менеджер службы поддержки..................................................................108
Аналитик или техник службы поддержки..................................................109
Связь с другими SMF.................................................................................110
Управление конфигурациями...................................................................110
Управление релизами..............................................................................111
Управление изменениями........................................................................111
Управление безопасностью......................................................................111
Управление хранения данных..................................................................111
Управление директориями сервисов.........................................................111
Управление заданиями............................................................................112
Управление инцидентами........................................................................112
Управление проблемами..........................................................................112
Финансовое управление..........................................................................112
Управление мощностями..........................................................................112
Управление доступности..........................................................................113
Управление непрерывностью ИТ сервисов.................................................113
Управление уровнем сервиса...................................................................113
1
Аннотация
Обеспечение высокого уровня сервиса дорого и занимает много времени. Важной
задачей является не только эффективная помощь своим клиентам, но и
реализация собственных экономических стратегий. Лидеры бизнеса требуют от
службы поддержки результативности и эффективности. Когда у клиента возникает
проблема, или вопрос, лучшие компании дают быстрые ответы, ясные решения и
точные результаты.
Службы поддержки это первая точка соприкосновения с компанией; результативные
и эффективные ответы на запросы пользователей могут сделать многое для
улучшения репутации компании. Кроме того, служба поддержки обеспечивает
организованную и скоординированную среду для сотрудников, занятых в поддержке
пользователей и работающих независимо в различных географических местах.
2
Введение
Эта инструкция предоставляет детальную информацию о SMF «Служба
поддержки» для организаций разворачивающих, либо планирующих развертывание
технологий Microsoft® в дата-центрах или других видах промышленных
вычислительных сред. Это одна из более чем 20 SMF, определенных или
описанных в Microsoft Operations Framework (MOF). Это описание предполагает, что
читатель знаком с предназначением и фундаментальными понятиями MOF, так же
как и с описываемыми технологиями.
Обзор MOF и связанного с ним Microsoft Solutions Framework (MSF), можно найти в
MOF Service Management Function Overview guide. Этот обзор также предоставляет
краткое описание каждой из сервисных функций SMF, определенных MOF.
Детальная информация содержится в технических описаниях на сайте
http://www.microsoft.com/mof.
3
Служба поддержки: Обзор
Главное преимущество службы поддержки состоит в том, что служба является
единственным контактом между пользователями и техническими специалистами
компании. Служба предоставляет быстрые решения возникших проблем для
пользователей во всех точках земного шара, так что качество службы поддержки
может иметь самое решающее значение для успеха компании.
Служба поддержки обеспечивает связь, информацию, и решения вопросов для
пользователей, обнаруживших проблемы в своей IT - инфраструктуре. Среди
причин, в результате которых компания может не обеспечить требуемый уровень
сервиса перечислим следующие:
 Отсутствие структурированного механизма службы поддержки.
 Отсутствия доверия пользователей к службе поддержки.
 Организация перерастает свою службу поддержки.
 Плохое управление службой поддержки.
 Сотрудники службы поддержки постоянно решают незначительные проблемы
или делают одно и тоже.
 Сотрудники часто прерываются.
 Слишком много зависит от ключевых сотрудников.
 IT-службы недостаточно сфокусированы на данном проекте.
 Много нескоординированных или недокументированных изменений в проекте.
 Менеджеры и/или сотрудники не справляются с изменениями.
 Неясные требования к персоналу и затратам.
 Недостаточное качество телефонного общения или долгое время ожидания
ответа на запрос.
 Недостаток информации для менеджеров для принятия решений.
Выделение процессов поддержки (включая определение ролей и ответственностей)
и внедрение консолидированного подхода к службе поддержки клиентов и
пользователей позволяет организациям преодолеть эти трудности и улучшить виды
на успех.
Цели и Задачи
Определение целей и задач службы поддержки чрезвычайно важно. Одним из
способов сделать это может быть либо разработка документа о миссии, либо
широкое определение задач, которые четко определяют подход к оказанию
поддержки.
Определение задач на ранней стадии планирования позволяет всем членам
команды соответствовать поставлены задачам. В зависимости от типа услуг,
которые компания собирается предоставлять через службу поддержки, эти цели
будут основываться на нескольких факторах, таких как размер организации и
определенная сфера функций службы поддержки.
8 Service Desk
Простые задачи могут включать в себя:

 Обеспечение главного контакта между пользователями и IT-службами.
 Обеспечение интерфейса между пользователями и другими SMF, такими как
Управление Изменениями, Управление Проблемами, Управление
Конфигурациями, Управление Релизами и др.
 Обеспечение качественной поддержки является необходимым условием для
достижения бизнес целей.
 Определений и снижение полной стоимости обслуживания IT-сервисов.
 Поддержка изменений на стыке бизнеса, технологий и процессов.
 Улучшение удовлетворения клиентов.
 Удержание клиентов.
 Определение дополнительных бизнес-возможностей.
Основные определения
Используются следующие основные понятия.
Запрос. Запрос это любая форма связи между пользователем и службой
поддержки, независимо от способа коммуникации (телефон, электронная почта и
др.).
Инцидент. Инцидентом называется любое событие, которое не является частью
нормальной работы сервиса и способное вызвать прерывание или снижение
качества сервиса.
Группа первого реагирования. Группа первого реагирования обеспечивает
обработку инцидентов и запросов «на первой линии». В задачи команды входит
попытка разрешить возникшую проблему при первом контакте, либо используя
известные обходные решения, либо собственные опыт и знания. Во многих
организациях служба поддержки и выступает в качестве такой первоначальной
команды поддержки.
Известная ошибка. Известная ошибка это инцидент или проблема, для которой
причина известна и либо временное, либо окончательное решение уже известно. В
случае если бизнес сценарий уже есть, создается RFC; однако, в любом случае,
ошибка сохраняется до тех пор пока не будет исправлена окончательно.
Существенный инцидент. Инцидент называется существенным, если связан с
высоким, или потенциально высоким, уровнем ущерба и требует ответа на уровне
превышающем или выходящем за рамки обычных процедур. Обычно существенные
инциденты требуют координации внутри компании, повышения уровня
руководящего вмешательства, мобилизации дополнительных ресурсов и
взаимодействия.
Проблема. Проблемой называется невыясненная причина одного или нескольких
инцидентов.
Группа реагирования. Группы реагирования это специальные команды, которые
реагируют на инциденты и запросы на поддержку, такие, что группа первого
реагирования не в состоянии разрешить. Структуры службы поддержки могут
различаться между организациями, и организованы либо по уровням, либо по
платформам и приложениям (например, группа серверов, десктопов, сетей или баз
данных).
Service Management Function 9
Запрос сервиса. Запрос сервиса это запрос на создание нового или

видоизмененного сервиса. Виды таких запросов различаются в разных
организациях, однако в общем случае сводятся к запросам на изменения (RFC),
запросам информации (RFI), либо запросам на расширение сервисов.
Решение/Исправление. Решение/исправление это такой способ исправления
инцидента или проблемы, который обеспечивает окончательное исключение
причины, лежащей в основе решаемой проблемы.
Обходное решение. Обходным решением называют такой способ решения
инцидента, который обеспечивает возобновление требуемого сервиса, но не
устраняет причины вызывающей данный инцидент проблемы.
Структура службы поддержки

Существует несколько способов организовать службу поддержки. Решение о
структуре службы должно приниматься на этапе планирования. (Другие документы
описывают формирование службы поддержки; однако, краткое объяснение
приводится здесь, так как некоторые соображения ниже могут зависеть от
выбранной структуры службы.) Следующая таблица поясняет возможные формы
службы поддержки.
Table 1. Структура службы поддержки
Вид службы Требования Средства Преимущества
поддержки
Централизованная Четкое лидерство Телефонная Пользователи

и контроль. система, знают, куда
Централизованная
Внимание: даже
позволяющая звонить за
служба поддержки
централизованная пользователям поддержкой.
поддерживает всех
служба поддержки звонить на
пользователей вне Требуется
должна единый номер
зависимости от их использовать меньше
службы
географического группы персонала, что
поддержки.
положения реагирования, снижает затраты
которые Это средство на подготовку,
децентрализованы может включать оборудование и
и/или работают там,
где находятся
интерактивный размещение.
пользователи. автоответчик
Консолидированн
(IVR),
ое управление.
автоматическое
распределение
звонков (ACD), и
интегрированные
компьютеры и
телефонию(CTI)
для обработки
входящих
звонков.
e-mail
используется
службой
поддержки для
получения e-mail
запросов от
10 Service Desk

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

поддержки
Децентрализованн В случае, когда Возможно, что Обеспечивается

ая нужды бизнеса различные индивидуальная
требуют средства будут поддержка для
Децентрализованна
присутствия в использоваться в определенных
я служба поддержки
нескольких разных местах; групп
состоит из
географических рекомендуется, пользователей в
нескольких служб,
положениях, однако, что все зависимости от их
расположенных в
представляется пункты поддержки положения.
различных
эффективным используют один
географических Персонал в
создать одну и тот же набор
местах. состоянии
службы базисных средств,
развивать
поддержки для для того чтобы
углубленный
обслуживания упростить
уровень
общих задач чрезвычайные
экспертизы в
нескольких процедуры, когда
определенной
представительств. один из пунктов
местности.
Важно, чтобы поддержки
существовали временно берет Обеспечение
четкие каналы на себя функции поддержки на
связи между другого в случае разных языках
каждым из аварии. проще, если
пунктов каждый из
поддержки. пунктов
Местные навыки поддержки,
должны быть поддерживающий
известны и определенную
распространяться языковую группу
на прочие пункты может быть
поддержки. Такой набран из
подход позволят местного
охватить персонала.
пользователей,
Каждый из
располагающихся
пунктов системы
в разных
временных зонах.
поддержки
Оборудование и
обеспечивает
программное
бэкап для
обеспечение
остальных в
должно быть
случае, когда
совместимо.
один из пунктов
Необходимо
окажется
использовать
неработоспособн
общие процедуры
ым (авария и т.д.).
управления и
оповещения. Распределенные
Каждый из службы
пунктов позволяют
поддержки должен продвигать
иметь доступ к большее число
общей сотрудников.
документации.
The ability to pass
12 Service Desk

поддержки
Виртуальная Необходимо Необходима Такая структура

служба использовать телефонная позволяет
технической общие системы система, использовать
поддержки записи и позволяющая подход «следуй-
сопровождения пользователям за-солнцем»,
Виртуальная служба
запросов, таких получать доступ к когда служба
чтобы службе работает все 24
поддержки
поступившие поддержки часа, в то время
основывается на
запросы могли независимо от их как каждый из
развитии качества
быть географического пунктов
сетей и
одновременно положения. поддержки
телекоммуникаций- Внимание: Это
доступны для работает
физическое или вовсе не означает,
каждого из нормальные
географическое что один и тот же
пунктов системы. телефонный номер
офисные часы в
положение
должен быть данной
становится Для того чтобы
использован во всех местности.
несущественным. обеспечит
географических
однородность положениях, так По мере того как
Виртуальная служба
службы, все как каждый из
пункты поддержки предпочтительнее пунктов
поддержки использовать
должны поддержки
объединяет местные номера.
использовать заканчивает
элементы Это означает, что в
одинаковые случае когда один
работу, запросы
одновременно и
процедуры. пункт технической переправляются в
централизованной и
поддержки другие пункты в
децентрализованной Эти моменты еще передает другой временной
моделей, таким более важны для пользователя зоне, где
образом, что виртуальной другому,
персонал только
пользователи службы пользователи не
должны начинает свой
получают удобный технической
использовать день.
доступ к службе, в поддержки, чем
другой номер для
то время как их для контакта со
запросы могут быть децентрализованн службой поддержки
переправлены в ой структуры, так (каждый
каждый из как все пункты пользователь
нескольких пунктов системы располагает
единственным
поддержки, в поддерживают номером), так
зависимости от ряда одних и тех же чтобы знание
факторов (время пользователей, а реального маршрута
суток, местные запросы обработки запроса
праздники, переправляются не требовалось.
количество запросов от одного пункта к Телефонная
и т.д.). другому. Важно, система должна
каждый запрос быть в состоянии
сохранял своего переправлять все
«владельца», для запросы
обеспечения сделанные в
общих стандартов каждый из
во всех пунктах локальных
системы. пунктов через
Если виртуальная работающие в
служба поддержки данный момент

поддержки
покрывает пункты системы.

несколько Должно быть
языковых возможным
территорий, сменить пункт
необходимо обработки
выбрать общий запроса либо
язык, для записи вручную, либо
запросов. автоматически,
основываясь на
таких условиях,
как текущее
время суток.
Если больше чем
одна служба
поддержки
активна в данный
момент,
телефонная
система должна
быть способна
перемаршрутизир
овать запрос в
наиболее
подходящее
место,
основываясь,
например, на
местоположении
запроса, длине
очереди и т.д.
Все пункты
поддержки
должны
использовать
одинаковые
средства.
Запросы,
записанные в
одном из пунктов,
должны быть
доступны всем
для ссылок и
обработки. Это
скорее всего
потребует
адекватных
сетевых
подключений в
каждом из
пунктов и
14 Service Desk

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

Меньшие организации могут не имеют отдельной сервисной службы, в то время как
техническая поддержка обеспечивается штатом, который обеспечивает поддержку
второй линии.
Центральная точка контакта могла бы быть единственным телефонным номером
отдела поддержки и/или адреса электронной почты для посланных по электронной
почте запросов. Ответственность за то, чтобы собирать запросы (телефон или
электронная почта) должна быть передана сотрудникам штата поддержки по
очереди. Есть вероятность, что высокий процент от запросов будет обработан уже
при первом контакте, так как люди, принимающее запросы обычно и являются
специалистами по поддержке.
Масштабирование службы поддержки для большой

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

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

Как уже упоминалось, одной из целей службы поддержки является обеспечение
точки контакта для ИТ организации. Ниже мы иллюстрируем, кто получает такой
контакт и типы взаимодействий.
16 Service Desk
Кого поддерживает служба поддержки?

Многие организации поддерживают разные формы центральных точек контакта для
взаимодействия с клиентами и пользователями. Эта функция известна под разными
именами, такими как служба помощи или сервисный центр. Следующая таблица
перечисляет различные названия и описания.
Table 2. Центральные точки контакта
Функция Описание
Центр обработки Центр обработки запросов - это чаще всего термин,
запросов используемый для функции, которая имеет дело с большим
объемом телефонных запросов от внешних клиентов
организации, например, банков, сервисных компаний,
компаний почтового перевода. Как правило, есть два типа
центров запросов: связанных с приходящими или
исходящими запросами. Центры обработки входящих
запросов обычно получают запросы от клиентов в ответ на
печатные, радио-, или телевизионные рекламные
объявления.
Центры исходящих запросов обычно связываются с
клиентами с целью прямых продаж или теле-маркетинга.
Некоторые центры обработки запросов фактически
объединяют два типа, так что представители центров делят
свое время между входящими и исходящими запросами.
Горячая линия Горячая линия для клиентов чаще всего получает запросы
от внешних клиентов: возможно, жалобы, запросы
продуктов, заказы помощь и советы.
Служба помощи Служба помощи обеспечивает поддержку пользователям
(Help desk) или клиентам, внутренним по отношению к данной
организации. Персонал службы управляет, координирует, и
максимально быстро решает возникшие проблемы и
вопросы, а так же проводит необходимый учет.
Сервисная служба Сервисная служба прежде всего нацелена на

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

Существуют два основных типа контактов: инциденты и запросы сервисов.
Следующая таблица объясняет каждый из них.
Table 3. Типы контактов
Категория Описание Функция
Инцидент Инцидент это единовременные Функция службы поддержки в
ситуация, которая выходит за этом случае состоит в
рамки нормального данном случае в
функционирования сервиса. восстановлении работы
Инцидент может вызывать сервиса для всех
приостановку нормальной пострадавших пользователей
работы сервиса или снижение за минимальное время.
качества работы этого сервисам.
Запрос сервиса Запрос сервиса может быть Функция службы поддержки в
любым из приведенных ниже этом случае состоит в
примеров: данном случае в обработке
запроса с целью обеспечить
 Требование о внесении
изменений. удовлетворение
пользователя, либо
 Запрос информации. обработав запрос
 Запрос на проведение непосредственно, либо
работы. переправив запрос в
соответствующую группу
 Запрос о приобретении. реагирования.
 Любое взаимодействие
между сотрудником ИТ
компании и клиентом
(например, жалоба, похвала,
комментарий или
предложение).
Выгоды от службы сервиса

Служба поддержки обеспечивает жизненно важные каждодневные контакты между
клиентами, пользователями, ИТ сервисами. Для клиентов служба поддержки очень
важна, потому что для них она - единственная возможность судить об уровне
обслуживания и профессионализма организации.
Служба поддержки это мост между пользователями и техническим штатом,
поддерживающим услуги. Целями службы являются:
 Управление инфраструктурой с целью учета и поддержки всех изменений с
фокусом на проблемных областях.
 Положительный опыт и восприятие возможностей ИТ служб.
 Проактивный подход к обеспечению предоставляемых сервисов.
 Минимальное прерывание бизнес-функций.
 Улучшение продуктивности.
18 Service Desk
Внедрение службы поддержки обеспечивает следующие преимущества для

организации:
 Улучшения обслуживания клиентов, увеличивающие представление
пользователей о потенциале ИТ организации и увеличение уровня
удовлетворения клиентов.
 Увеличение доступности функций ИТ службы через единый контакт для связи и
информации.
 Улучшенное качество реагирования и сокращение времени обработки запросов
пользователей.
 Улучшенная командная работа и связь, как внутри ИТ службы, так и между
пользователями и ИТ службой.
 Улучшенный фокус на требованиях поддержки.
 Проактивный поход к обеспечению сервиса.
 Лучшее понимание бизнес-процессов, поддерживаемых ИТ сервисами,
снижающее негативное влияние на бизнес.
 Лучшая управляемость ИТ инфраструктуры и лучший контроль над ее
развитием.
 Оптимальное использование ресурсов службы поддержки и улучшение
продуктивности бизнес-персонала.
 Основа, позволяющая определять выгоды, обеспечиваемые службой
поддержки.
Служба поддержки может обеспечить значимую информацию для менеджмента для
поддержки процессов принятия решений. Информация, предоставляемая службой
поддержки, включает в себя:
 Информацию об использовании персонала.
 Взаимозависимости сервисов.
 Производительность сервисов и соответствие целям.
 Необходимость подготовки персонала.
 Затраты.
В дополнение к важным выгодам, перечисленным выше, дополнительная важность
службы поддержки состоит в том, что служба:
 Выполняет стратегическую функцию идентификации и снижения стоимости
поддержки ИТ инфраструктуры.
 Поддерживает интеграцию и управление изменениями через границы
распределенного бизнеса, технологий и процессов.
 Снижает затраты, позволяя еще более эффективное использование ресурсов и
технологий.
 Поддерживает оптимизацию инвестиций и управление вспомогательных бизнес-
сервисов.
 Позволяет долгосрочно удерживать и поддерживать уровень удовлетворения
внешних клиентов.
 Помогает в выявлении бизнес-возможностей.
4
Процессы и виды деятельности
Эта глава обеспечивает подробное описание процессов и видов деятельности
внутри SMF службы поддержки.
Обзор диаграммы процессов

Важнейшими процессами SMF службы поддержки являются:
 Функционирование службы поддержки.
 Оптимизация службы поддержки.
Функционирование службы поддержки

Функционирование службы поддержки включает в себя следующие задачи,
необходимые для каждодневной деятельности, такой как:
 Каждодневное управление персоналом и ресурсами. Гарантирует, что
ожидаемые объемы запросов и профилей наблюдаются и отслеживаются на
должном уровне навыков и умений сотрудников.
 Взаимодействие с клиентами. Построение одновременно и реактивных и
проактивных отношений с клиентами.
 Выполнение процессов поддержки. Обеспечивает информацию и контроль,
требуемую другими SMF и управляет интерфейсами между службой поддержки
и др. SMF.
 Продвижение и маркетинг службы поддержки. Стимулирует использование
службы поддержки и рекламирует ее возможности.
 Управление и компенсация затрат. Записывает и отслеживает затраты,
связанные с работой службы поддержки, и компенсирует затраты, собирая
выплаты с пользователей и клиентов.
 Наблюдение за производительностью службы поддержки. Наблюдает за
ресурсами, процессами, средствами, третьими лицами и уровнем
удовлетворенности клиентов.
 Подготовка отчетов. Готовит отчеты по требованию руководства.
20 Service Desk
Figure 2 описывает задачи, которые должны выполняться ежедневно для

управления службой поддержки.
Figure 2. Каждодневные задачи службы поддержки

Управление персоналом и ресурсами

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

Два нижеследующих способа определения сроков и расписаний описаны в таблице.
Table 4. Модели определения расписаний
Типы Описание Основы расписаний
расписаний
Группы со сроком Используется для определения Необходимость
окончания работ распорядка сотрудников, выполнения
которые сосредоточены на определенных сценариев,
разработке программного а не работы в
обеспечения или обслуживании определенное время или
аппаратных средств. Такая день
группа имеет ряд продуктов или
задач, которые должны быть
закончены к определенной дате
или времени.
Для того чтобы наметить эти
вехи, обычно используются
системы руководства проектом.
Модель работы по Используется для управления Способность отвечать на
требованию ресурсами службы поддержки. запросы пользователей в
тот момент, когда
Требует точных предсказаний
возникают вопросы, что
потребностей пользователей;
обычно происходит в
обычно для этого используется
рабочие часы.
данные за прошлый период, а
так же известные события и
вопросы, как например новые
релизы, выполнение обновлений
или новых бизнес инициатив.
В то время как пользователи могут терпеть определенное число автоматических

отвечающих систем, важно иметь возможность быстро соединять с живым голосом,
который может оперативно отвечать на возникшие проблемы. Такой живой голос
улучшает уверенность и, обычно, снижает разочарование. Оба описанных метода
требуют, чтобы живой голос принимал запрос. Если большая часть персонала
службы поддержки не находится на месте и запросы пользователей остаются без
ответа долгое время, эффективность и репутация службы поддержки снижается.
Гибкая и эффективная, ориентированная на пользователей система планирования
необходима для предоставления качественных услуг. Служба поддержки обычно
снижает затраты компании следующим образом:
 Снижая время неработоспособности системы.
22 Service Desk
 Снижая время обучения пользователей.

 Снижая зависимости и затраты, связанные с требованиями дополнительной
поддержки, связанной с привлечением внешней поддержки от поставщиков
оборудования, программного обеспечения и консультантов.
До тех пор, пока нет гарантий того, что ресурсы службы поддержки доступны в
критические моменты работы, другие отделы компании могут нести
дополнительные издержки, что может свести на нет выгоды, связанные с работой
Создание расписания
Количество сотрудников, необходимое для работы службы поддержки обычно
определятся на стадии планирования. При назначении сотрудников на
определенные участки работ имеются два важнейших соображения:
 В какие часы служба будет открыта?
 Как много сотрудников будут работать в эти часы?
Выработать расписание работы очень важно. Служба поддержки может работать в
определенное время в рабочее время, или услуги службы могут оказаться
необходимыми 24 часа в сутки, 7 дней в неделю (часто пишется 24×7). Эта
информация должна быть определена на стадии планирования.
Как только часы работы службы определены, становится возможным назначить
сотрудников работать в определенные смены, чтобы обеспечить работу службы на
протяжении требуемого времени.
Другая возможность - рассмотреть индивидуальные предпочтения сотрудников.
Если служба поддержки должна работать дольше, чем обычные офисные часы с
9:00 до 18:00, можно составить расписание следующим образом:
 Сотрудники могут работать в несколько смен.
 Сотрудники могут работать 10 часов в день, в отличии от обычных 8.
Модели планирования
Существует множество теорий и методов для составления расписания. Ниже
перечислены пять подходов, пригодных для организации работы службы
поддержки:
 Ключ. Относится к заголовкам колонок в обзоре методов планирования работы,
где каждый из методов показан в заголовке ряда и детализирован.
 Персонал. Разбит на три категории в соответствии с числом необходимых
сотрудников.
 Опыт. Разделен на три категории: новые или временные сотрудники,
постоянные и ведущие, или очень опытные специалисты.
 Тип. Показывает два типа предоставляемой поддержки: общая и
специализированная.
 Менеджер. Показывает как много времени необходимо для управления. Время
менеджмента необходимого для реализации данной стратегии разбито на двое:
время на начальной стадии изменений и на требуемое время на стадии
нормальной эксплуатации.
Внимание Имеется в виду не время, необходимое для разработки расписания, а время
необходимое в процессе каждодневной эксплуатации.
Не существует одного метода одинаково подходящего для любой организации;

обзор каждого из них приведен в таблице внизу.
Figure 3. Обзор моделей планирования

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

получасовыми расписаниями.
Table 5. Получасовые расписания
Преимущества Риски Зависимости
Сотрудники точно знают, Система требует Ответственный сотрудник
когда они принимают серьёзных временных должен создать заранее
запросы затрат на свою расписания для всех
реализацию. групп в службе
поддержки.
Менеджеры точно знают, Требует точного Такая модель
кто и когда находится на следования расписанию, применяется только для
телефонах или уровень сервиса поддержки по телефону
может снизиться или непосредственно.
Хороший прогноз, вместе Изменения в Где применимо,
со знанием ежедневных существующем кооперация между
образцов запросов, расписании должны сайтами и соглашения о
может сделать отражаться в новом процедурах необходимы
получасовую модель расписании либо для гладкого исполнения.
чрезвычайно компенсироваться каким-
эффективной для то другим способом. Эти
очередей большого изменения могут
объема. существенно увеличить
затраты на
планирование.
Чем короче интервал Такой подход не Расписание должно
планирования, тем позволяет сотрудникам принимать во внимание
дешевле точное отойти от телефонов без установленные
соответствие SLA. специальной перерывы, требуемые
договоренности. Такой трудовым
уровень доступности законодательством.
может поддерживаться
только если существуют
соответствующие
процедуры.
Рекомендации
Такая система больше всего подходит в случае флуктуирующего потока запросов
большого объема, когда соблюдение уровня сервиса очень важно. Эта схема
трудозатратна и жестка, что может быть как преимуществом, так и недостатком.
Она лучшим образом подходит для очередей, в которых пребывание и наполнение
относительно предсказуемы и не сильно меняются. Это не лучшее решение для
небольших групп с небольшими запросами на обслуживание, так как в этом случае
уровень запросов испытывает самые сильные флуктуации (в процентах)—это
явление называется синдромом малой очереди. Также такая модель не
рекомендуется для поддержки по электронной почте.
Самоуправляемые команды (Pods)

Несмотря на то, что самоуправляемая стратегия является самой амбициозной из
всех стратегий, представленных в этом руководстве, именно она потенциально
ведет к максимальной отдаче.
Каждая из команд (иногда называемая pod) обычно обрабатывает запросы уровней

1 и 2 (иногда 3), так что члены команды исполняют разные роли по мере
необходимости.
Работа такой группы происходит либо вовсе без расписания—команда обслуживает
смену (например, с 8 A.M. до 5 P.M.) с одним обеденным перерывом, а в
остальном члены группы обрабатывают запросы по мере необходимости— или
группа разрабатывает свое расписание в зависимости от факторов спроса и
требуемого уровня сервиса. Персонал службы поддержки в такой модели может не
иметь определенных рамок. Это отклонение от большинства моделей, а так же
смена философии не должна недооцениваться. Эта схема оправдала себя в
некоторых организациях, однако требует очень зрелой группы для достижения
успеха. Следующая таблица показывает преимущества, риски и зависимости,
связанные с самоуправляемыми группами.
Table 6. Самоуправляемые группы
Усилия, необходимые для Без должного отношений Система зависит от
составление расписания, и некоторого наблюдения существования культуры
уменьшаются. система уязвима по сервиса у персонала и от
Планирование отношению к людей, внутренне
распространяется только злоупотреблениям. нацеленных на
на смены и обеденные правильную работу. Это
перерывы (хотя и может быть работа,
обеденные перерывы нацеленная на
тоже могут быть отданы обеспечение сервиса или
на усмотрение команды), другие задачи, однако то
управление службой каким образом эти цели
поддержки фокусируется достигаются, остается на
на анализе усмотрение членов
продуктивности. группы.
Подготовка персонала
мыслить в категориях
что хорошо для бизнеса
в дополнению к как
выполнить мои
персональные и
фиксированные задачи
требует времени и усилий
и может привести к
изменениям в системе
оплаты и отчетности.
26 Service Desk

Сотрудники службы Службы поддержки с Должны быть
поддержки могут принять длинными очередями установлены очень четкие
такое же чисто запросов, могут найти эту систему правила работы, и
распределенное на более более сложной, так как установлена
длительный промежуток средств контроля ответственность.
времени (если меньше.
Менеджеры обязаны
укомплектованы
обеспечить знание
правильно). Число
каждым членом группы
сотрудников,
задач группы, должны
принимающих запросы
учить их брать
может быть подобрано
ответственность и
так, что все запросы
принимать решения. Без
отрабатываются в
этого стратегия
течении оговоренного
самоуправляемых групп
промежутка времени и
обречена.
так, что сотрудникам не
приходится ждать новых
звонков. Такая ситуация
чаще всего возникает
утром и вечером, когда
все сотрудники еще на
местах, а количество
запросов еще не пиковое.
Сотрудники службы Менеджеры, Политика управления
поддержки, имеющие контролирующие работу должна быть четкая,
непосредственное большого числа хорошо разъяснена и
отношение к временных, новых или поддержана на всех
принимаемым звонкам, неопытных сотрудников уровнях. Если поддержка
решают сами, какого рода могут испытывать менеджеров не видна или
задачи они должны трудности с не сильна, стратегия с
выполнять: когда самоуправлением. самоуправлением
назначать встречи, провалится.
перезванивать, проводить
исследования и т.д.
Резкие повышения Расписание должно
частоты запросов могут принимать во внимание
обрабатываться более юридические тонкости
успешно, так как относительно перерывов
существующий персонал в работе временного
может полностью персонала.
перестроить работу на их
обработку. Это приводит к
улучшению работы
сервиса.
Потенциальные выигрыши в командах с самоуправлением состоят в том, что такие
группы требуют меньше ресурсов для планирования работ и используют более
гибкое рабочее расписание, также как и большую вовлеченность сотрудников в
бизнес наряду с поддержкой высокого уровня сервиса. Самоуправляемые команды
хорошо подходят для организации службы поддержки с опытным персоналом и
небольшими очередями в специализированных группах с небольшим числом

сотрудников и подготовленными членами с хорошими коммуникациями.
Тройки (и похожие модели)

Модель троек похожа на модель с самоуправлением; однако, обычно они работают
на меньших масштабах с улучшенной отчетностью. Обычно, три человека, все в
одну смену, составляют тройку таким образом, что из них двое постоянно на
телефоне. Они меняются в течение дня так, чтобы каждый из них провел
определенное время, выполняя свои обязанности (например 6 часов сервисных и 2
часа не сервисных работ), в зависимости от задач.
Несмотря на то, что метод троек требует больше усилий по организации работы,
чем самоуправляемые команды, использование этой модели в нескольких местах и
временных зонах может сильно помочь удовлетворять запросы пользователей.
Тройки характеризуются постоянным уровнем сервиса и могут не справится с
запросами без вмешательства. Кроме того тройки требуют привлечений
специальных сотрудников, floaters, чтобы заполнять позиции в тройках, если
некоторые сотрудники отсутствуют.
Следующая таблица показывает преимущества, риски и зависимости, связанные с
тройкками
Table 7. Тройки
Менеджеры службы Некоторое и Необходимы планы,
поддержки могут снизить планирование и контроль задачи и рекомендации
нагрузку по необходимы для того, для неукоснительного
планированию, как на чтобы частота выполнения всеми
стадии составления поступления запросов участниками.
расписания, так и на соответствовала
изменения практически неизменной
существующей схемы. производительности
троек.
Сотрудники службы Менеджеры должны Все члены тройки должны
поддержки получают хорошо знать членов хорошо работать друг с
гибкость, не снижая троек, которых надо другом в команде.
уровня сервиса. В любой наблюдать. Необходимо
момент можно менять устанавливать такие
укомплектованность задачи, чтобы члены
смен. тройки, по крайней мере,
со временем, были
одинаково загружены.
Для маленьких очередей,
тройки могут быть
неэффективными в
случае большого
количества запросов
Тройки подходят для среднеразмерных очередей, однако для большой группы с
неопытными сотрудниками применение самоуправляемой схемы может быть
ограниченным. Тройки эффективны когда число запросов практически не меняется
в течение дня.
28 Service Desk
Смешанный подход
Многие службы поддержки находят чисто самоуправляемый подход неприменимым
для всех сотрудников или всех сценариев спроса. Альтернативой, позволяющей
покрыть спрос в критические моменты, является использование формальных
расписаний только в пиковые моменты. В нормальные часы служба поддержки
может функционировать либо на самоуправлении, либо триадами. Это
обеспечивает контроль в критические моменты и может служить хорошей
переходной ступенью на пути к самоуправлению.
Следующая таблица показывает преимущества, риски и зависимости, связанные со

смешанной моделью.
Table 8. Смешанная модель
Решается проблема Эта модель все еще Зависимости совпадают с
пиковых часов. требует усилий по зависимостями
планированию работы, самоуправления и троек
горизонт планирования
меньше чем у групп с
самоуправлением.
Некоторые из Риски совпадают с
преимуществ рисками модели с
самоуправляемых команд самоуправлением.
можно получить и здесь.
Смешанная модель и модель троек это хорошая промежуточная модель для групп
на пути к самоуправлению или для менеджеров, озабоченных проблемой пиковых
часов.
Смешанная схема Расписание/Самоуправление

Другой альтернативой, совмещающей некоторые преимущества модели с
самоуправлением, является использование формальной модели для части
сотрудников, позволяя остальным работать посменно с самоуправлением. Такими
схемами пользуются бизнесы с высоким объемом запросов, которые использует
только обратные звонки во 2м уровне поддержки. В случае, однако, поддержки 2го
уровня в реальном масштабе времени управление такой моделью затруднено, так
как сотрудники 1го уровня нуждаются в надежном уровне 2.
Следующая таблица показывает преимущества, риски и зависимости, связанные со
смешанной моделью Расписание/Самоуправление.
Table 9. Смешанная модель Расписание/Самоуправление
Еще раз, некоторые Если часть организации Зависимости совпадают с
преимущества модели с работает в режиме зависимостями
самоуправлением можно самоуправления, она самоуправления
использовать и тут. должна
самоорганизоваться так,
чтобы соответствовать
требованиям
несамоуправляемых
отделов. Ответственность
за уровень сервиса
должна лежать на
самоуправляемой
команде.
Контроль и гибкость могут Эта гибридная схема все
меняться в зависимости же требует планирования
от текущих требований работы
30 Service Desk
Менеджеры должны
постоянно быть в курсе
кто работает на каких
условиях
Эта модель может быть эффективной для больших очередей, где одновременно
гибкость и контроль требуются для удовлетворения потребностей клиентов.
Поддержка первого уровня может потребовать полу-часового расписания, в то
время как поддержка 2го уровня может потребовать большей гибкости, чтобы
помочь инженерам поддержки помочь сотрудникам 1го уровня в пиковые моменты,
концентрируясь на своей работе, исследованиях и обратных запросах в другой
время. В этом случае самоуправление не значит неуправляемость.
Самоуправляемая команда должна сформировать такое расписание, что
поддержка доступна 1му уровню, когда необходима. Такая модель может также
быть эффективной, если применяется к модели смешанного спроса, когда
поддержка осуществляется и моментально, и в режиме ответов на запросы.
Выбор расписания зависит от ряда факторов, включая размер группы,
преференций сотрудников и всего коллектива, уровня сотрудников и т.д. Не
существует лучшей модели сразу для всех, некоторые коллективы должны чаще
переосмысливать свои модели работы для достижения максимальной
эффективности.
Отсутствие Сотрудников
Расписание должно принять во внимание отсутствие сотрудников (и плановое и
неплановое). Оно должно учитывать неожиданные пики и спады активности
службы поддержки. Неожиданные периоды малой активности могу приводить к
временному избытку персонала, так что необходимо заранее обеспечить
избыточных сотрудников дополнительными обязанностями.
Техническая заметка Управление персоналом может осуществляться вручную, если
служба поддержки сама по себе невелика. Для более крупных служб, необходимо
использовать специальные средства. Средства управления ресурсами могут быть
различными: от Microsoft Excel и таких планировщиков как Microsoft Project, до
специализированных приложений для управления и распределений ресурсов. Возможно
применение системы записи и сопровождения запросов в системе управления ресурсами.
Удовлетворение и удержание сотрудников

Удовлетворение сотрудников не менее важно для организации, чем удовлетворение
запросов клиентов. Ответы на запросы пользователей на протяжении долгого
времени может быть утомительным и психологически изматывающим, так как
многие обращаются по случаю проблемы или жалоб. Одним из способов снятия
стресса у сотрудников является периодическая смена обязанностей.
Для организации выгодно оставлять технически грамотных и тренированных
сотрудников на работе в службе поддержки. Это выгодно и организации, и
менеджерам службы поддержки и клиентам.
Замечание Мотивированные сотрудники чаще не будут искать возможности на стороне;
это позволяет удерживать опыт и экспертизу в службе поддержки, снижает затраты на
подготовку и обеспечивает непрерывность сервиса для клиентов.
Люди стремятся работать там, где имеется вызов, открытые коммуникации и

командная работа, обеспечивается успех. Удовлетворенность сотрудников влияет
на удовлетворенность клиентов. Необходимо стимулировать стремление
сотрудников к совершенству. Важно регулярно изучать уровень удовлетворения

сотрудников и быстро решать возникающие проблемы.
Предполагается, что организация фокусируется на 3х компонентах, определяющих
отношения сотрудника и организации:
 Сотрудник и выполняемая работа. Удовлетворение сотрудника от его или ее
работы может быть характеризовано в результате ответа на следующие
вопросы:
 Содержится ли вызов в данной работе?
 В чем миссия группы?
 Нравится ли то, что вы делаете?
Необходимо сфокусироваться на том, насколько работа удовлетворят
потребности сотрудника. Надо идентифицировать, какие аспекты работы
нравятся, а какие являются проблемными. Определить, насколько работа
отвечает ожиданиям сотрудника и его личным целям, которые могут включать
рост в текущей позиции или перемещение на следующий уровень или к новым
вызовам.
 Сотрудник и менеджер. Эти вопросы относятся к стилю управления
руководства или менеджеров:
 Установили ли вы и ваш менеджер цели?
 Комфортно ли вам разговаривать с вашим менеджером о проблемах?
 Если менеджер дает вам поручение, насколько оно ясное?
Это хороший момент узнать, как менеджер помогает сотрудникам, обеспечивает
обратную связь, выполняет текущие дела и работает в условиях ограниченного
времени.
 Сотрудник и коллега. Уровень удовлетворения от работы в команде
измеряется по ответам на следующие вопросы:
 Насколько хорошо взаимодействие в команде?
 Действительно ли дела делаются быстрее, если делаются командой?
 Есть ли вещи, которые можно и надо улучшить?
 Насколько просто членам команды справляться со своими обязанностями?
 Помогают ли другие сотрудники вашему успеху в текущей позиции?
Организации, которые эффективно оценивают удовлетворенность сотрудников,
находятся в наилучшем положении для улучшений. Виды улучшений с
необходимостью различаются; однако, сбор информации это хорошее место для
начала. Как только проблемы идентифицированы, проще их разрешить.
Использование 2й линии поддержки

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

инцидентов по мене отправления этой информации в группы разрешения
проблем, создавая, таким образом, понимание между 1й и 2й линиями
поддержки.
 Навыки и знания распространяются среди сотрудников первой линии, повышая
количество решаемых ими инцидентов.
 Сотрудники могут идентифицировать и устранить проблемы коммуникации
между линиями поддержки.
Взаимодействие с клиентами
Служба поддержки обеспечивает канал связи между пользователями и ИТ-
отделом. Следует помнить, что это контакт в обе стороны, обеспечивающий
механизмы для ИТ отдела снабжать информацией пользователей, а также получать
информацию от них.
Единая точка контакта

Одно из главных преимуществ службы поддержки - она обеспечивает единую точку
контакта клиентам для всех взаимодействий, которые они имеют с группой
поддержки и всем отделом IT. Единая точка контакта дает клиенту ощущение
гарантии, что его проблема обрабатывается. Это также позволяет службе
поддержки строить отношения с клиентом, которые не были бы возможны, если бы
клиент должен был иметь дело со всем разнообразием отделов. Единая точка
контакта также существенна в исходящих связях между отделом IT и
пользователями.
Виды связи
Служба поддержки обеспечивает множество способов взаимодействия.
Традиционно, контакт осуществляется через прямую телефонную связь. Среди
альтернатив используется факс и электронная почта. Эти три способа общения
позволяют клиенту регистрировать запрос без прямого контакта со специалистом.
Использование систем автоматического распределения звонков, направляющих
клиента к самому подходящему сотруднику службы поддержки, экономят деньги и
время.
В зависимости от физического местоположения службы поддержки, пользователи
могут посетить службу поддержки лично. Это иногда называют walk-up contact.
Возможно, однако, что этот тип взаимодействия будет препятствовать штату
службы поддержки обеспечивать услуги другим. Должно быть разъяснено, что такие
клиенты не должны получить преимущества льготной обработки своих запросов
только в силу своего физического присутствия.
Также важно обеспечивать услуги для слабослышащих, слабовидящих, или людей
с другими типами физических увечий. Много пользователи-инвалиды используют
специализированное программное обеспечение и аппаратные средства. Штат
службы поддержки должен знать об этих компонентах и обучаться в их
использовании.
Средства и технологии связи

Существуют множество средств и технологий для улучшения связи между
пользователями и службой поддержки:
Телефон
Наиболее распространенным, зачастую самым простым и знакомым способом
связи со службой поддержки остается телефон. Он предоставляет хорошие
возможности определения и объяснения проблем.
Наряду с телефоном используются следующие средства:
 Автоматический ответ на запрос. Система отвечает на запрос клиента и
проигрывает записанное заранее записанное сообщение и/или музыку, в то
время как запрос помещен в очередь, и ждет доступного сотрудника службы
поддержки. Преимущество метода состоит в том, что пользователь не остается
один на один с длинными гудками, что должно уменьшить число брошенных
запросов.
К недостаткам относится:
 Записанные сообщения могут показаться неискренними, особенно если
пользователь вынужден удерживаться на линии долгое время и
прослушивать сообщение несколько раз.
 Если пользователь не звонит по внутренней или бесплатной линии,
стоимость звонка определяется временем с начала соединения.
 Интерактивный Голосовой Ответ (IVR). IVR представляет собой расширение
автоматического ответа на запрос и позволяет прослушать заранее
подготовленные меню и выбрать подходящие опции, используя телефонную
клавиатуру или, в некоторых системах, голосом. Используя эти опции,
пользователь переводится либо на приглашение оставить сообщение, либо к
наиболее подходящему специалисту.
 Автоматическое распределение запросов (ACD). Когда звонок принят, система
ACD может быть использована для передачи звонка наиболее подходящему
сотруднику поддержки. Выбор может быть сделан, исходя из специализации
сотрудника, языка, загрузки т.п. Или, например, некоторые сотрудники должны
отвечать на запросы определенных клиентов или групп.
 Автоматическое определение номера (CLI). Эта функция предоставляется
телефонными компаниями (или внутренним оборудованием для звонков внутри
организации), которая информирует получателя звонка о номере телефона
вызывающего абонента. Обычно телефонный номер высвечивается на
телефонном аппарате адресата. Внутренние телефонные системы могут так же
высвечивать имя человека, совершающего звонок (предполагая, что абонент
звонит из своего офиса). Эта услуга позволяет сотрудникам службы поддержки
знать, кто позвонил.
 Интеграция телефонов и компьютеров (CTI). Это позволяет использовать
телефонную систему как интерфейс к компьютерной системе. Такая система
может быть интегрирована в средства службы поддержки так, что как только
запрос принят, система определяет пользователя, используя телефонный номер
абонента, и высвечивает информацию о клиенте, хранимую в системе. Такая
схема полезна только в том случае, если пользователи звонят из одних и тех
же мест. Более продвинутое использование CTI состоит в проведении
автоматических транзакций так, чтобы запрос от пользователя мог быть
34 Service Desk
обработан без ссылок на специалиста службы поддержки, или для сбора

информации от клиента еще до того как запрос попадает специалисту.
Примером такой транзакции может послужить получение баланса счета в банке.
Пользователь выбирает необходимую транзакцию, используя клавиши на
телефоне, после чего получает запрос на авторизацию при помощи
персонального идентификационного номера (PIN). После этого баланс счета
сообщается пользователю. Примером сбора данных перед передачей запроса
специалисту может быть требование к пользователю сообщить его или ее
идентификатор или код проблемного оборудования.
 Голосовая почта. Почта голоса может использоваться в качестве альтернативы
стоящим в очереди пользователям, в случае если сотрудники службы
поддержки заняты и не могут принять запрос. Если голосовая почта
используется, то необходимо назначить ответственного сотрудника службы
поддержки для сбора голосовых сообщений и формирования ответов на них в
пределах разумного времени. Опасность состоит в том, что, если служба
поддержки постоянно занята поступающими запросами, приоритет останется за
ними, и сообщениями голосовой почты останутся необработанными.
Подача запросов Online
Существует множество альтернативных способов отправить запрос в службу
поддержки, включая следующие:
 E-mail. Электронная почта - все более и более распространенный метод
сообщения со службой поддержки. Вездесущность электронной почты облегчит
клиентам подачу запросов. Этот метод может использоваться вместо телефона
для менее срочных запросов.
Самый большой недостаток к электронной почте состоит в том, что она
отправляется по существу в свободном формате; поэтому, посланный по
электронной почте запрос, возможно, не содержит структурированного
сообщения со всеми признаками проблемы или деталями запроса. Однако,
существует возможность разработать специальные формы электронной почты
чтобы принудить отправителя ввести всю нужную информацию.
Системы электронной почты можно сконфигурировать на автоматический ответ
на поступающие электронные письма. Так пользователь будет извещен об
успешном получении запроса.
 Интернет, HTML и электронные формы (e-forms). Использование этих

инструментов поощряет клиентов детально записывать признаки проблем и
детали запросов обслуживания структурированным способом при помощи
шаблона, который клиент заполняет. Структурированные формы требуют, чтобы
клиент предоставил такую информацию, которую потребовали бы в типичной
телефонной беседе. Использование форм также устраняет большую часть
потребности в повторных запросах за дополнительной информацией от
клиента, уменьшая, таким образом, полное время, требуемое для разрешения
инцидента или исполнения запроса. Структурированная форма запросов также
облегчает анализ запросов.
В идеале система подачи онлайновых запросов должна быть соединена с
системой управления запросами. Информация, полученная из электронной
формы подачи запроса, может использоваться, чтобы автоматически
перенаправить инцидент к соответствующей группе поддержки.
Однако, как и в случае с голосовой почтой, кто-то в службе поддержки должен
взять ответственность за то, чтобы контролировать поступающие электронные
письма или формы с запросами и отвечать на них.
 Новостные группы, BBS форумы, и публичные e-mail директории.

Использование этих средств позволяет пользователям разрешать проблемы, не
обращаясь в службу поддержки и не создавая запроса. Как и HTML и
электронные формы, сообщения в новостные форумы и публичные папки
создает мгновенную электронную запись о транзакции. Когда статья отправлена
на форум, другие пользователи с подобным запросом могут прочитать ее и
увидеть, как разрешить проблему.
 HTML запросы через Интернет. Это средство позволяет соединить клиента с
Интернет-ресурсами службы поддержки, показать статус системы, и напомнить
о заплатах и обновлениях. Такие ресурсы помогают пользователям без прямого
обращения в службу поддержки.
Факс
Использование факса для взаимодействия со службой поддержки становится все
менее распространено по мере увеличения использования электронной почты.
Однако рано еще сбрасывать этот механизм со счетов. Единственное его
преимущество - чрезвычайно быстрая передача документов и письменной
корреспонденции.
Как с электронными письмами, служба поддержки может определить стандартные
формы, которые используются для получения запросов по факсу. Если такая
стандартная форма обеспечивается заранее и представляется вместе с
соответствующей информацией, факсы могут быть приемлемым способом для
сообщения о проблемах или представления запросов. Однако, ценность факсов
ограниченна, так как обычно требуются ручное копирование информации в систему
регистрации запросов.
Факсы полезны для того, чтобы получить письменное одобрение определенных
диагностических процессов. К сожалению, качество передачи часто делает
содержание трудным для чтения и менее точным, чем другие механизмы подачи
запросов онлайн. Для обработки запросов можно использовать сканирующие
системы.
Как с голосовой и электронной почтой, кто-то в службе поддержки должен взять
ответственность за то, чтобы контролировать поступающие факсы или формы с
запросами и отвечать на них
Внимание: Использование интеллектуальных телефонных систем, голосовой и
электронной почты, форм, и т.д. дает много выгод службе поддержки. Они не
должны, однако, использоваться как электронный барьер. Необходима осторожная
установка автоматических диалоговых систем, чтобы избежать передачи
пользователя из одного отдела службы поддержки в другой. Если используются
голосовая и электронная почта, необходимо устраивать регулярные проверки, а
ответы системы должны быстро отсылаться клиенту. Необходимо договориться об
уровне сервиса, чтобы оптимизировать использование этих технологий и
гарантировать последовательное и высококачественное обслуживание.
Приемлемость использования таких телефонных функций системы, как
автоответчик, голосовая почта, и автоматическое распределение звонков может
также меняться в зависимости от культурных различий конкретной страны/области.
Техническое замечание Многие системные средства управления обеспечивают
способность обнаружить проблемы или потенциальные проблемы с системами, которые они
контролируют. Они также позволяют отправлять уведомления об этих событиях в
специальные системам управления в соответствии с SNMP или другими протоколами.
36 Service Desk
Такие системы сбора информации могут контролироваться штатом службы поддержки,

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

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

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

В случае возникновения серьезного инцидента (серьезный инцидент это инцидент,
который создает серьезное воздействие, так как затрагивает критические сервисы
и/или затрагивает большое количество пользователей), чрезвычайно важна роль
службы поддержки в качестве канала связи.
Штат службы поддержки ответственен за следующие задачи:
 Определение масштаба инцидента.
 Описание, какие пользователи затронуты.
 Отслеживание продвижения к решению инцидента.
 Обеспечение информацией о предполагаемом времени решения
 Описаний действия для восстановления сервиса, которые будут необходимы
после того, как инцидент будет разрешен.
Эту информацию нужно довести до пользователей максимально эффективным
образом. Такие данные должны поставляться в тот момент, когда пользователи
обращаются в службу поддержки, а также через описанные выше превентивные

механизмы.
Когда происходит серьезный инцидент, менеджеры и технический штат должны

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

Первичная цель службы поддержки состоит в том, чтобы действовать как
последовательный интерфейс между пользователями и отделом IT. Эта глава
описывает пути, следуя которыми служба поддержки должна взаимодействовать и
общаться с функциями IT организации.
Многие из функций, выполняемых службой поддержки, исполняются от имени
других SMF, что особенно касается функции Управления Инцидентами и
Управления Изменениями. Затронуто также несколько других SMF (см. раздел
Отношения с другими SMF для дополнительной информации).
Техническое замечание Интерфейсы между SMF могут быть сделаны более
эффективными, если средства, используемые для поддержания этих функции, могут быть
объединены.
Существуют инструменты, которые может поддержать множество SMF, включая службу
поддержки. В случае если используются различные инструменты, требуется определенное
усилие некоторое усилие для достижения желательного уровня интеграции. Большинство
инструментов имеет своего рода внешний интерфейс, часто в форме API или поддерживают
стандартные интерфейсы, типа XML.
Получение и запись запросов

Служба поддержки получает запросы от пользователей, собирает необходимую
информацию, и затем регистрирует запросы. Это - элементы процессов
обнаружения, регистрации и самообслуживания в рамках SMF Управление
инцидентами. Для выполнения этой функции необходимо принять во внимание
несколько моментов:
 Телефонный протокол. Персоналу службы поддержки необходимо дать
руководство о том, как иметь дело с клиентами, используя телефон. Могут быть
определены стандартные приветствия, типа "Доброе утро, служба поддержки.
Говорит Борис. Как я могу помочь Вам?"
Когда служба поддержки получает запросы от множества различных клиентов,
приветствие может измениться, в зависимости от того, какой клиент обращается.
Важно отметить, что манера телефонного общения также очень важна. Персонал
службы поддержки должен всегда быть вежливым, даже когда пользователь сердит,
расстроен, или оскорбляет. Персонал должен обучаться обращаться со всеми
типами запросов, включая экстремальные случаи, типа чрезмерно оскорбительных
пользователей. В последнем случае, сотрудник должен спокойно закончить запрос
и сообщить о проблеме менеджеру службы поддержки.
Должны быть определены стандартные сценарии (опросники) для выполнения
сотрудниками первой линии. Это гарантирует получение необходимой информации
от пользователя и уменьшает шанс, что последующее расследование и диагностика
будут требовать связи с клиентом во второй раз.
38 Service Desk
 Управление очередями запросов. Современные интеллектуальные

телефонные системы позволяют направлять запросы соответствующему
человеку, доступному в данный момент. Эти же системы позволяют
сотрудникам указать их готовность к обработке запросов в течение дня.
Сотрудник начинает работу к телефонной системе в начале его или её рабочего
дня и выходит из системы в конце дня. В течение дня, сотрудник может указать,
когда он или она оказывается вдали от телефона, например, на обеде, на
перерыве, или выполняя административную функцию, типа обработки
документации от предыдущего запроса. Это означает, что в любое время
несколько людей, которые являются номинально доступными для обработки
запросов, могут указать, что они недоступны. Это может привести к ситуации,
когда число поступающих запросов больше, чем число сотрудников, способных
принять запросы и клиенты стоят в очереди в ожидании следующего свободного
представителя поддержки. Если это произошло, немедленно проинформируйте
об этом руководство, так как клиент в очереди может прервать звонок, не
удовлетворив, таким образом, свои потребности.
 Поддержание точной информации о клиентах. Уточняйте информацию о
пользователях в момент обращения в службу поддержки.
 Защита информации. Помните, что некоторая информация, предоставленная
клиентом, может быть или личной или конфиденциальной. Есть юридические
требования относительно личной информации, которые различаются в разных
странах и территориях. Будьте осторожны и обращайтесь за юридическими
советами относительно информации, которая сохраняется в системе, времени её
хранения, и целей, в которых она используется.
 Мониторинг запросов. Много организаций записывают некоторые или все

принимаемые запросы. Иногда эта информация используется в целях
обучения, чтобы новые сотрудники могли услышать типы получаемых
запросов, типы пользователей, делающих запросы, и как каждый тип запросов
обрабатывается опытным специалистом. Иногда запросы регистрируются в
целях защитить службу поддержки от возможных требований клиентов
относительно переданной информации или процедур, использованных при
обработке этих запросов. Юридические требования относительно регистрации
запросов изменяются от одной страны/области к другой. Получите юридический
совет, планируя этот процесс.
 Руководящий надзор. Существуют телефонные системы, позволяющие
руководству слышать, как запросы пользователей обрабатываются каждым из
сотрудников. Это может быть использовано для надзора и поощрения
персонала.
 Сохранение информации. Информация, оставленная в системе записи, должна
быть адекватной и достаточной для обработки запросов. Этого можно достичь,
следуя заранее определенным правилам, или используя экспертные системы,
направляющие сотрудников через структурированные наборы вопросов.
Служба поддержки должна подтвердить получение каждого запроса, отдавая
пользователю уникальную ссылку, которая может использоваться, для
идентификации запроса, если пользователь обращается с целью проверить
продвижение или если инженер поддержки должен связаться с пользователем для
получения информации. Для запросов, полученных по телефону, идентификатор
запроса нужно выдать пользователю в течение телефонной беседы. Для запросов,
полученных другими методами, идентификатор запроса должен быть передан
пользователю наиболее подходящим методом, например, для запросов, которые
приходят по электронной почте или через Веб-страницы, идентификатор запроса

может быть передан пользователю по электронной почте.
Когда запрос получен службой поддержки, сотрудник должен определить, является
ли этот запрос инцидентом или запросом на обслуживание.
Инциденты
Инцидент - любое событие, которое не является частью стандартной эксплуатации
сервиса, и вызвало или может вызвать прерывание или снижение качества
сервиса.
Если запрос определен как инцидент, персонал службы поддержки должен
получить и записать информацию, которая используется в процессе управления
инцидентами.
Категория инцидента идентифицирует тип проблемы, которую испытывает
пользователь; примерами категорий инцидентов могут быть:
 Проблемы с приложениями, такие как:
 Сервис не доступен.
 Существует проблема в приложении не позволяющая осуществить
транзакцию.
 База данных заполнена.
 Проблема с оборудованием, такая как:
 Пользователь не может соединиться с сетью.
 Принтер не работает.
 Недоступен сервер файлов.
Для дополнительной информации относительно категорий инцидентов, см.
руководство MOF SMF Управление Инцидентами.
Категории инцидентами
Категории используются:
 При генерации отчетов.
 Для выделения областей IT инфраструктуры, вызывающих проблемы.
Решение, какие из категорий использовать, зависит от требований организации.
На этой стадии обработки инцидентов, служба поддержки должна определить:
 Какие сервисы затронуты инцидентом?
 Какие SLA (соглашения об уровне сервиса) могут быть нарушены?
 Каков первоначальный приоритет данного инцидента?
Приоритет вычисляется, исходя из:
 Влияния инцидента на бизнес
 Срочности разрешения или выработки обходного решения.
Замечание Определение приоритета инцидентов связанно со временем разрешения
инцидентов, прописанным в SLA.
Начальная поддержка
40 Service Desk
Эта часть процесса управления инцидентами проверяет наличие известных

решений или обходных решений, уже созданных для данного инцидента.
Каждый инцидент должен быть проверен на счет связи со всеми известными
ошибками. Если средства службы поддержки объединены со средствами
управления проблемами, то это может быть сделано автоматически. Если
совпадение найдено, решение может быть применено.
Персонал службы поддержки могли бы использовать следующие предложения:
 Дайте детали решения пользователю, для самостоятельного применения.
 Наметьте встречу между пользователем и специалистом.
 Примените исправления на рабочем компьютере пользователя. Персонал
службы поддержки может сделать это используя инструменты удаленной
поддержки, если такие установлены.
 Инициируйте запрос на изменения, в случае если другие сотрудники должны
быть вовлечены для решения проблемы, например, если необходимо перегрузить
сервер.
Замечание Как можно скорее переведите инцидент к соответствующей группе
решения, так как необходимые действия, возможно, потребуют тщательного
планирования.
 Спросите пользователя, который сделал запрос, успешно ли было применено
решение. Если так, закройте инцидент; в случае, если решение не найдено,
возобновите процесс.
 Установите связи новых инцидентов, которые соответствуют известным
ошибкам, и отметьте их в записи ошибок.
Отметьте, что инциденты, которые не соответствуют известным ошибкам,
необходимо проверить также против существующих проблем, находящимся в
обработке.
Проблемы
Проблема это состояние, которое создает существенное воздействие, причина
которого, однако, не известна. Проблема может быть создана в результате
единственного существенного инцидента или множества отдельных инцидентов,
которые показывают общие признаки. Если инцидент соответствует текущей
проблеме, тот инцидент должен быть связан с записями о этой проблеме. Это
указывает серьезность проблемы и позволяет всем связанным инцидентам быть
разрешенными, когда решение найдено.
Если инцидент не соответствует известной ошибке или текущей проблеме,
персонал службы поддержки должен изучить прежние инциденты, чтобы видеть,
встречалась ли эта проблема раньше. Если такое совпадение найдено, и
предыдущий инцидент был разрешен, необходимо использовать то же самое
решение. Если предыдущий инцидент не разрешен, следует связать эти инциденты
и сообщить в управление решения проблем.
Если никакие совпадения с проблемами в прошлом не найдены, персонал службы
поддержки должен попытаться решить проблему. Если штат службы поддержки
имеет соответствующий уровень технической экспертизы, может оказаться
возможным идентифицировать причину инцидента и решить проблему. Если
решение сразу не доступно, но имеются инструменты удаленной поддержки, может
оказаться возможным диагностировать причину инцидента и воспроизвести его,

чтобы получить дополнительную информацию.
Если персонал службы поддержки не в состоянии предложить решение

пользователю, инцидент должен быть передан в соответствующую группу решения.
Эта группа исследует инцидент далее и диагностирует решение.
Запросы сервисов
Если запрос, полученный службы поддержки не является инцидентом, то он
рассматривается как запрос обслуживания. Есть несколько типов запросов
обслуживания; некоторые из общих типов:
 Запрос об изменении.
 Запрос об информации.
 Запрос о необходимой работа, которую нужно проделать.
 Жалоба/комплимент/предложение.
Типы запросов обслуживания, обрабатываемые данной службой поддержки,
зависят от типа, размера организации и от сферы работы данной службы
поддержки.
В некоторых случаях, службы поддержки может сама выполнить запрос
обслуживания. Если это не возможно, персонал службы поддержки должен
обеспечить такое количество необходимой информации, насколько возможно и
инициировать соответствующий интерфейс для запроса обслуживания.
Рекомендуется, предоставить сотрудникам сценарии и шаблоны для каждого типа
запросов обслуживания.
См. Руководство MOF Incident Management Service Management Function для

дополнительной информации о данном виде запросов.
Ответственность наблюдение и отслеживание

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

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

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

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

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

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

что им особенно ценно в работе службы поддержки.
Определение целевых клиентов

Важно ясно идентифицировать и понимать требования клиентов. В зависимости от
размера и природы клиентской базы, некоторые клиенты могут разделять одни и те
же самые базовые потребности. Необходимо, однако, понимать уникальные
деловые требования каждого клиента. Это позволяет сотрудникам посылать
индивидуализированные сообщения относительно предложений службы
поддержки, улучшая опыт и увеличивая удовлетворенность клиента. Целевой рынок
может быть разделен на следующие группы:
 Уровень экспертизы (новичок, средний пользователь, эксперт),
 Требования живого отклика
 Аппаратные средства, программное обеспечение, или сетевые потребности
обслуживания систем
 Ведомственная функция
 Географическая область
 Используемые приложения (офисные программы, вертикальные приложения,
средства разработки, серверные системы)
Определение принципов для разделения клиентской базы, особенно выделение
высоко-приоритетного отдела, является критической. Например, отдел заказов,
который обычно требует 24×7 работы, отличается от менее критического отдела,
типа отдела кадров, работа которого ограничена промежутком от 8 утра к 5 после
полудня.
Определение запросов пользователей

Еще до построения службы поддержки, важно идентифицировать требования
клиентов. Для этого обычно требуется исследование.
Есть несколько подходов к определению этого типа информации. Один подход
состоит в том, чтобы провести обзор оценки потребностей с представителями
целевого рынка, чтобы изучить их непосредственные, ежедневные проблемы.
Обзор, проведенный со всеми потенциальными пользователями службы поддержки,
может обеспечить осуществление выборки основных проблем. В обзоре должны
задаться широкие вопросы о самых важных ежедневных вызовах поддержки
клиентов. В этом случае, планировщики службы поддержки могут наметить цели
службы, чтобы удовлетворить ожиданиям клиентов.
Другой подход исследования состоит в том, чтобы поговорить с ключевыми
пользователями и руководителями отделов, чтобы идентифицировать тенденции
компании в требованиях поддержки и то, как эти потребности могут измениться в
будущем.
Эта стратегия помогает строить твердую информационную базу о потребностях
клиентов для использования в планах. Кроме того, такая стратегия обеспечивает
основание для того, чтобы установить ожидания и справляться с
пользовательскими восприятием и требованиями на протяжении времени. Эти
исследования должны стать непрерывной деятельностью, чтобы реагировать на
сиюминутные изменения настроения клиентов.
44 Service Desk
Позиционирование сервисов
Для позиционирования службы поддержки, основная задача состоит в том, чтобы
ясно очертить функции, обеспечиваемые службой поддержки и увязать их с
требованиями клиента. Установление соответствующих ожиданий обеспечивает
пользователям понимание работы службы, которое, в конечном счете, экономит их
время.
Могло бы быть полезно создать рабочий лист возможности/функции/выгоды,
который соотносит функции службы поддержки и требования клиента. Подготовьте
быстрый информационный лист, который описывает какие услуги предлагаются
службой поддержки, включая, процедуры и формы запросов. Можно также
включить секцию с названием "Что Не обеспечивает Стол Обслуживания", которая
препятствует клиентам тратить впустую их время и усилия и направляет их к
соответствующему отделу. Если возможно, включите списки других ресурсов и
услуг, не покрываемых службой поддержки.
Доведение информации до пользователей

Как только аудитория службы поддержки определена, а обязанности службы
поддержки прописаны, следующий шаг должен установить пути передачи
информации клиентам.
Каков лучший метод для того, чтобы передать информацию клиентам? Имеются
разные способы в зависимости от того, кто ваши кленты и где они находятся.
Следующий список содержит несколько предложений, в зависимости от
получателя:
 Внутренний персонал:
 Коммюнике интранета
 Электронная почта или сообщения по факсу
 Представления на встречах штата
 Персональная или групповая ориентировка для нового персонала
 Внешний персонал:
 Электронная почта (электронная почта или факс)

 Флайеры или брошюры в местах скопления людей
 Литература службы поддержки для новых сотрудников
Презентации на встречах высокого уровня
Какая информация должна передаваться?
Как описано в главе о позиционировании, важно рассказать клиентам, что именно
служба поддержки может сделать для них. Внизу предлагается список возможных
тем для общения клиентом:
 Диапазон продуктов поддержки службы поддержки.
 Тип предоставленной помощи (только телефон, обычный и внутренний,
электронная почта, и так далее).
 Обязательства времени ответа.
 Как сделать запросы обслуживания.
 Где сначала искать ответы перед запросом.
 Номер телефона, чтобы звонить и определить, какая информация требуется

для запроса.
 Процедуры эскалации (как привлекать внимание к проблемам, которые не
решены).
 Часы работы (что сделать в критических ситуациях в нерабочее время).
 Где получить самую последнюю информацию о:
 Статус систем.
 Информация статуса службы поддержки.
 Изменения или новые дополнения в услугах службы (например, новые
продукты, новые локальные услуги, и так далее).
Чтобы предать гласности выгоды службы поддержки, публикуйте информацию об
успехах сотрудников, показывайте, что службы поддержки делает, чтобы улучшить
их жизнь на работе. Демонстрируйте, как службы поддержки помогла снизить
затраты, улучшил решения о закупках, отношения с внешними поставщиками,
удовлетворение клиентов, и так далее.
Опишите области, которые требуют усовершенствований, что было сделано и
каковы будущие планы.
Когда взаимодействовать?
Важно помнить, что пользователи зачастую считают услуги службы поддержки само
собой разумеющимися. Это происходит, несмотря на критическую роль службы
поддержки. Продолжайте продвигать службу поддержки, рассказывая
пользователям о ее успехах и услугах, которые она предлагает, чтобы, в конечном
счете, повысить уровень пользовательского удовлетворения.
Всякий раз, когда создается новая служба поддержки, или изменен любой из
сервисов, важно немедленно сообщить об этом пользователям.
Непрерывная коммуникация с пользователями важна, особенно в следующих двух
областях:
 Регулярная обратная связь на еженедельном или ежемесячном основании с
упором на инциденты. Эта информация позволяет клиентам знать, что службы
поддержки посвящает себя им и помогает им быть превентивными, избегая
известных проблем, а не реактивными в решении таких проблем как модернизация
системы или обучение.
 Рассказывай клиентам, как хорошо службы поддержки отвечает его целям
(время удержания, удовлетворение клиента, живой отклик) а также, помогает
клиентам видеть службу поддержки своим партнером, обеспечивая их успех.
Конечный продукт не должен быть дорогой, полноцветной брошюрой. Простая
программа настольной издательской системы может создать дешевую,
привлекательную брошюру или флайер, чтобы рассказать об услугах и обучить
клиентов.
Когда взаимодействовать
Есть различные способы сообщить информацию клиенту. Организации используют
презентации на выездах, напечатанные материалы, электронную почту,
корпоративный интранет, информационные бюллетени компании, и презентации (от
формальных семинаров и симпозиумов до рабочих завтраков). Материал можно
обеспечить через эмблемы, коврики для мыши, screensavers, ручки - любой тип
46 Service Desk
рекламных материалов. Самое важное это удостовериться, что все это доступно
для клиента.
Обучающие семинары и классы обеспечивают превосходный форум для того,
чтобы говорить о службе поддержки и о том, как наиболее эффективно
использовать ее ресурсы. Усилия, проведенные, обучая пользователей, вносят свой
вклад в улучшение их самостоятельности.
Управление затратами и возврат вложений

Планируя и развивая службу поддержки, необходимо рассмотреть затраты и
продумать как компенсировать эти затраты. Этот раздел кратко описывает
рекомендации высокого уровня относительно затрат службы поддержки.
Дополнительная информация относительно ценообразования для услуг IT
(включая службу поддержки) описана в MOF Financial Management Service
Management Function guide.
Вообще говоря, организации поддержки, типа службы поддержки должны
определять количественно контрольные затраты и демонстрировать разумное
возврат инвестиций (ROI). В конечном счете, необходимо ответить на следующие
вопросы:
 Экономит или производит ли службы поддержки больше денег для компании,
чем она стоит?
 Обеспечивает ли служба поддержки необходимый уровень поддержки при
наименьшем объеме инвестиций?
 Может другая организация (например, outsourcer) обеспечить часть или всю
поддержку также эффективно, но с меньшими затратами?
Во многих случаях, служба поддержки находятся в сложном положении, находясь в
центре затрат. Они стоят деньги для своих компаний и не производят доход, а если
и производят доход, то часто меньше чем собственные затраты.
Возможно организовать службу поддержки так, чтобы обеспечить необходимую
поддержку и производить прибыль. Независимо от того, является ли служба
поддержки центром стоимости или прибыли, контролируя и отслеживая любые
затраты для обеспечения сервисов требует внимания старшего руководства.
Анализ затрат
Имеется несколько шагов для анализа затрат службы поддержки, см. таблицу.
Table 10. Анализ затрат
Шаг Задача Комментарий
1 Изолировать конкретные Организуйте категории в логические
категории затрат, группы и подгруппы. Обычно, это можно
связанные с работой сделать, приписывая стандартные
службы поддержки. идентификаторы отделов.
2 Организовать все Обычно бывают прямые затраты
затраты в соответствии с (зарплаты, премии и т.д.) в процессе
найденными работы службы поддержки, а так же
категориями. непрямые затраты (обычные бизнес
расходы, такие как оборудование и
утилиты).
Как только необходимые данные собраны, можно начинать анализ. Чтобы быть
эффективным, информация должна быть представлена таким способом, который
поможет старшими менеджерам понимать ситуацию и принять решения. Есть
множество способов проанализировать данные. Обычно используются следующие
две категории:
 анализ стоимости на человека
 Анализ по видам деятельности
The following figure is a sample Cost Estimating Worksheet that might be used by a
service desk when starting a cost analysis.
48 Service Desk
Figure 4. Sample cost estimating worksheet

Затраты на человека
Целесообразно оценить стоимость службы поддержки из расчета на человека, так
как затраты на персонал определяют большинство затрат службы поддержки.
Прямая стоимость на человека включает только людей, обеспечивающих
поддержку пользователей и расходы, связанные с ними, типа зарплаты, выгод,
поставок, и так далее. Эта мера помогает компании управлять расходами на
человека и дает основание для того, чтобы оценить другие, потенциально менее -
затратные, варианты работы, типа временного привлечения третьих лиц для
выполнения работ. Прямая стоимость на человека и полностью обремененная
стоимость на человека должны оцениваться регулярно (или ежемесячно или
ежеквартально), чтобы идентифицировать и объяснить возникающие изменения.
Полностью обремененная стоимость на человека включает все прямые затраты на
человека плюс затраты для всего остального штата и управления. Полностью
обремененная стоимость на человека измеряет полную стоимость службы
поддержки на человека и помогает идентифицировать увеличения дополнительных
расходов. Типовой рабочий лист оценки затрат, показанный выше, обеспечивает
пример крупноформатной таблицы, которая может использоваться, чтобы
организовать информацию о затратах.
Анализ по видам деятельности

Распределения затрат по видам деятельности связывают стоимость обеспечения
услуг службы поддержки (деятельность) с отделами, использующими ресурс и/или с
предлагаемым типом поддержки. Главная цель анализа затрат на основе типов
деятельности состоит в том, чтобы связать затраты с деятельностью, для того,
чтобы облегчить принятие решения. Этот тип анализа затрат может обеспечить
большое количество ценной информации. В зависимости от уровня необходимых
деталей, однако, может потребоваться больше времени и усилий.
Затраты на основе видов деятельности службы поддержки можно распределить по
соответствующим отделам. Методы распределения (используемый индивидуально
или все вместе, с целью создать метод оплаты, определенный для конкретной
организации) включают:
 Стоимость на запрос, в зависимости от типа инцидента или обслуживания.
Некоторые примеры:
 десктоп услуги (то есть, обработка текстов).
 приложения.
 Запрос установки/модернизации.
 Деловое обслуживание (то есть, платежная ведомость).
 Стоимость времени и материалов, израсходованных штатом поддержки,
например:
 Стоимость единицы времени (то есть, минуты).
 Фиксированная цена.
 Комбинация предыдущих двух примеров: фиксированная цена для
формирования запроса в службу поддержки плюс переменная стоимость, на основе
израсходованного времени после того, как запрос переведен в группу поддержки.
 Выкупленное время поддержки.
 Право обслуживания, основанное на контракте обслуживания:
50 Service Desk
 Золотой, серебряный, или бронзовый уровни обслуживания.

 Стоимость, распределенная на пользовательские отделы как часть
дополнительных корпоративных расходов по обеспечению услуг IT. Иначе говоря,
служба поддержки может работать "бесплатно" и финансироваться из
корпоративного центра.
 Время (в минутах) проведенное на получение поддержки от службы поддержки
вообще говоря является справедливым основанием для формирования цены
обслуживания, потому как время одинаково ценно для всех отделов.
Цены на основе числа обработанных инцидентов, могут вызвать некоторые
проблемы, потому что отрезок времени и усилия, вовлеченное в разрешение
каждого инцидента могут быть разными. Это может привести к очевидно
непоследовательному распределению затрат. Также имейте в виду, что цены из
расчета на запрос могут помешать клиентам использовать службу поддержки и
привести к попыткам обойти службу поддержки, решая инциденты самостоятельно
без создания запроса. Это может привести к увеличенным временам диагностики
решения проблем в службе поддержки.
Техническое замечание Планируя службу поддержки, примите во внимание данные,
требуемым определения затрат на основе видов деятельности. Это важно для определения
информации, которая должна быть зарегистрирована средствами службы поддержки. Если
Вы добавляете еще одно поле в форме записи инцидента, которая отмечает отдел, из
которого исходит инцидент, сразу назначайте затраты в соответствующий отдел.
В дополнение к обеспечению метода для того, чтобы выставлять счета в другие

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

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

Для того чтобы выделить моменты, требующие наблюдения, полезно ответить на
вопросы в таблице.
Table 11. Мониторинг службы поддержки
Вопрос Разъяснения
Что составляет основные Если служба поддержки обеспечивает поддержку
средства обеспечения используя телефон, может быть полезно
сервиса, и каковы контролировать время ожидания клиента и отрезок
критические факторы времени, который требуется, чтобы разрешить
успеха для каждого из них? инцидент. Другая метрика могла бы включить объем
и частоту запросов, количества ресурсов, требуемых
для решения проблемы.
Полезная метрика меняться в случае поддержке с
обратной связью, запросов, предоставляемых в
электронном виде (по электронной почте, интранету,
или другому инструменту онлайн), личным запросам,
и так далее. Исследуйте требования обслуживания
для каждого тип поддержки и создайте
соответствующие метрики для их оценки.
Что определяет спрос на Как объем инцидентов зависит от количества
поддержку? компьютеров в пределах организации или от
изменений, возникающих от введения новых
продуктов? Как на счет воздействия определенного
продукта или изменения политики? Какая
информация об этих проблемах является важной, и
как это может быть определена количественно? Для
анализа можно использовать количество инцидентов,
время, примеры времени-прибытия, типы клиентов,
распространенность проблем этого типа, и так далее.
52 Service Desk
Существуют ли требования Такие цели могут быть упомянуты в соглашениях
предоставления службы уровня обслуживания (SLAs). Поскольку различные
или к производительности службы поддержки полагаются на эти цели для того,
каждого вида чтобы измерять производительность группы, эти
предоставляемой цели должны быть определены заранее. Примером
поддержки? может служить решение 90 процентов инцидентов
через один час или меньше, ответ на все
телефонные звонки в среднем через 20 секунд или
меньше, или ответы на все с электронные запросы
менее чем четыре часа.
Цели обслуживания - баланс того, в чем нуждается и
хотел бы клиент, и того, что может разумно
обеспечить служба поддержки. В то время как
возможно обеспечить, уровень обслуживания с
ответом на 100 процентов запросов по телефону
через 10 секунд или меньше, это могло бы стоить
значительно больше, чем уровень обслуживания 90
процентов через 30 секунд или меньше. Кроме того,
это маленькое различие в уровне обслуживания,
одновременно является существенным требованием
к организации службы поддержки, что может иметь
небольшое реальное воздействие на клиентов.
Определяя соответствующий уровень обслуживания,
возрастающая стоимость увеличенного
обслуживания должна быть соотнесена с выгодой,
которую клиент получил бы, будучи обслуживаемым
более быстро. Поскольку эта выгода может
измениться в зависимости от типа клиента или типа
проблемы, возможно определить различные уровни
обслуживания в зависимости от приоритета каждого
инцидента.
Как суммировать Часто, это означает необходимость сообщать о
собранные данные и средних числах и процентах, а не индивидуальных
представить в легко деталях фактической информации, связанной с
понимаемом формате для инцидентами. Например, многие службы поддержки
последующего анализа? отчитываются о проценте инцидентов, которые были
разрешены в пределах определенного времени.
Будьте осторожны, однако, в надежде полагаться
исключительно на статистические данные, которые
говорят лишь о средних числах. Одинаково важно
иметь представление об обычных (или
распределение) инцидентах, а так же знать о
необычных случаях. Статистическое резюме могло
бы сообщить, что ответы на 90 процентам всех
запросов приходят в течение 60 секунд.
Как можно отслеживать Многие службы поддержки используют учет
выполненную работу, трудоемкости по видам оказываемой поддержки
основной затратный (используя такие категории, как работа на телефоне,
фактор работы службы выезд к клиенту или дозвон), чтобы облегчить анализ
поддержки? стоимости и выяснить затраты, связанные с
решением различных типов инцидентов. Где только
возможно, полезно работать в контакте с
бухгалтерией, чтобы гарантировать законченность и
последовательность собираемых данных.
Имеются ли у сотрудников Идентифицируйте все личные меры

индивидуальные цели по производительности, которые можно использовать
продуктивности и для оценки и помощи сотрудникам службы
существуют ли метрики поддержки. Удостоверьтесь, что цели соответствуют
для их оценки? SLA. Так всегда, будьте осторожными, применяя
метрики в качестве метода оценки.
Какую информацию надо Использование сотрудников для отслеживания
отслеживать вручную и дополнительной информации вручную уменьшает
когда это может ресурсы, доступные для обеспечения функций
случиться? поддержки. Удостоверьтесь, что собранные данные
более ценны, чем усилия, израсходованные на их
сбор.
Большинство компаний требует, чтобы их службы
поддержки контролировали затраты для того, чтобы
планировать бюджеты и распределять ресурсы
настолько эффективно насколько это возможно.
Также требуются данные о спросе на услуги службы
поддержки, данные времени отклика службы и об
удовлетворении этого спроса, а также о
производительности службы поддержки. Наконец,
часто бывает, что сбор информации о типах проблем,
решенных службой поддержки, может помочь в
анализе других типов собранных данных.
Потребности службы поддержки в данных на самом
деле отличаются. Определяя ожидания управления
компании, потребности управления службы
поддержки, потребности оценки сотрудников, и
ощущения клиентов - все вместе может быть
использовано для выработки необходимого набора
метрик.
Отслеживание спроса
Несмотря на то, что отслеживание затрат обеспечивает информацию о финансовом
аспекте службы поддержки, также важно смотреть на услуги, обеспеченные
клиентам (выгоды). Один из способов смотреть на выгоды стола обслуживания
состоит в том, чтобы смотреть на спрос на услуги службы поддержки - сколько
клиентов приходит в службу поддержки.
Прослеживание спроса обеспечивает информацию о том, когда, и как часто ищется
помощь в службе поддержки. Для определения спроса полезно ответить на
следующие вопросы:
 Сколько запросов было получено в течение определенного интервала (один
день или один месяц, например)?
 Как распределялись запросы в течение того интервала?
54 Service Desk
 Каково среднее усилие, которое требуется, чтобы разрешить инцидент данного

типа?
 Сколько контактов со службой поддержки требуется, чтобы разрешить данный
инцидент?
Данные спроса могут быть проанализированы, чтобы обнаружить тенденции
использования службы поддержки. Например, большая часть инцидентов
происходит в определенное время дня (например после обеда), в определенный
день недели (например утром понедельника), или во время событий, уникальных
для компании (например конец месяца или конец бюджетного года)? Сравнение
текущих тенденций с исторической метрикой спроса может помочь планировать
всплески активности, как например при выпуске нового продукта или при
пополнении штата. Простой отчет, показывающий частоту прибытия запросов от
времени может служить резюме этого типа информации.
Представленная как диаграмма, статистика прибытия запросов на протяжении
долгого времени может быть легко рассмотрена, а области проблем легко
идентифицированы. Вооруженный этой информацией, менеджер службы
поддержки может лучше оценить спрос на ресурсы и планировать распределение
ресурсов. Будучи в состоянии предсказывать, как спрос изменится в течение дня,
менеджер службы поддержки может принять соответствующие решения по набору
персонала. С другой стороны, предсказание периодов малой активности позволяет
службе поддержки уменьшать штат или переориентировать сотрудников на другие
задачи. Знание частоты запросов, так же как ожидаемая продолжительность
запросов, позволяет менеджеру службы поддержки более эффективно
использовать сотрудников, обеспечивая производительность службы поддержки,
при минимальных затратах. При определении тенденций спроса различайте
настоящие тренды и незначительные вариации.
В дополнение к определению тенденций, важно анализировать изменения спроса.
Изменяющийся спрос может указать на потребность увеличить, уменьшать, или
перераспределять штат; обеспечить дополнительное обучение; или определить
проблемы продукта. Раннее внимание к проблемам этого типа может иметь
большую пользу для компании. Это - часть отношений между SMF службы
поддержки и SMF разрешения проблем. Спрос должен также отслеживаться по типу
предоставленной поддержки. Если есть несколько способов посылать запросы в
службу поддержки, например онлайн через интранет или электронную почту,
непосредственно телефонным звонком или лично в офисе, спрос может
перемещаться от одного типа поддержки к другому.
Измеренные уровни спроса должны использоваться, чтобы подтвердить
предположения и расчеты, используемые для предсказания спроса на
обслуживание. Прогнозы никогда не будут абсолютно точны, но любое
существенное отклонение от прогноза должно вызвать пересмотр прогноза или
анализ в причины изменения спроса по отношению к ожидаемому.
Контроль реакции
Чтобы удовлетворять спрос, необходимо идентифицировать больше чем объем
спроса. В модели поддержки, типа телефонной поддержки, когда, куда клиенты
приходят и сразу готовы воспользоваться услугой или, вероятно, будут ждать
некоторое время, важно определить, насколько быстро приходит ответ от службы
поддержки. Отклик часто измеряется в терминах первичного времени ответа:
интервала между контактом со службой поддержки и получением поддержки.
Отметьте, что это отличается от времени, которое требуется, чтобы разрешить
запрос. Первичное время ответа это время, которое требуется для того, чтобы
взять телефон (в телефонной модели поддержки), признать получение

электронного запроса, или прибыть для личной встречи. Это - мера того, как быстро
штат службы поддержки отвечает на запросы поддержки - время, которое
требуется, чтобы фактически приступить к помощи.
Цели отклика типично определяются как часть соглашения обслуживания для
различных категорий проблем и используются для определения цели
обслуживания. Имейте в виду, что доступность может быть столь же важной для
репутации службы поддержки, как качество предоставленной поддержки. Долгое
ожидание расстраивает клиента, независимо от качества обслуживания,
фактически предоставленного после ожидания. Кроме того, время, клиент ждет с
нерешенной проблемой, может также быть связанно с затратами так как проблема
может препятствовать технологическому процессу клиента. Могут также быть и
другие побочные эффекты времени ожидания. Например, время разрешения
инцидента может увеличиться, потому что клиенты жалуются специалисту о том,
что они ждали, и они не счастливы этому. Они могут настаивать, чтобы сотрудник
провел больше времени с ними, разрешая инцидент из страха, что следующий
контакт потребует много времени. Это вызывает эффект снежного шара, поскольку
времена разрешения инцидента становятся еще длиннее чем ожидаемый, в то
время когда группа поддержка уже опаздывает.
Цели обслуживания должны принять во внимание стоимость обеспечения
непосредственного доступа, стоимость ожидания клиента, и насколько клиент
удовлетворен откликом. Обеспечение мгновенного ответа требует большего
доступного штата службы поддержки, который снижает уровень
производительности во времена спада спроса. Вообще говоря, высокие уровни
обслуживания соответствуют более низким нормам использования штата. Однако, в
случае внутренней службы поддержки, ожидание пользователей может стоить
компании прямо или косвенно, поскольку ожидание препятствуют выполнению их
работу.
Есть несколько способов измерить живой отклик, каждый с собственными
преимуществами и недостатками, как показано в следующей таблице.
Table 12. Измерение уровня отклика
Способ Описание Преимущество Недостаток
измерения
Уровень Определяет процент Легко измерять, и Не дает понимание
сервиса инцидентов дает некоторое об ощущениях
разрешенных в представление об пользователей за
определенный ощущениях пределами
временной интервал. пользователей. процентного
промежутка.
Среднее Определяет среднее Определят средний Не дает понимание
время время ожидания. опыт ожидания в об опыте
ожидания каждой очереди, но большинства.
не дает Среднее время
представление о само по себе
пропорциях. имеет
ограниченную
ценность.
Самое Определяет самый Полезна вместе с Может быть
большое плохой сценарий, метрикой уровня неудачной
время самой большое сервиса. метрикой если
56 Service Desk
ожидания время, которое только несколько

пришлось потратить инцидентов
на ожидание. характеризуются
длинным
ожиданием.
То как сформулирована цель по отклику, может зависеть от способа ведения

отчетности о проблемах. Например, в телефонной модели поддержки, цель живого
отклика могла бы соответствовать, ответу на 80 процентов запросов в пределах
двух тонов или в течение трех минут. В случае если пользователь зашел сам, цель
живого отклика могла бы определяться как встреча с 80 процентами пользователей
в течение одной минуты. Для запланированной поддержки, цель живого отклика
могла бы быть заявлена в терминах изменения от назначенного времени.
Сравнивая измерение живого отклика с целями обеспечения сервиса, особенно в
течение определенного времени дня, возможно идентифицировать времена, когда
штат изо всех сил пытается обеспечить уровни обслуживания, а также периоды,
когда служба поддержки переполнена. Когда отклик постоянно не соответствует
своей цели, это может указывать на недостаточные или неэффективные
используемые ресурсы поддержки. Вариации отклика, в отдельные времена
превышая, а в другие времена, падая ниже целей уровня сервиса, могут указывать
на то, что служба поддержки не использует сотрудников соразмерно спросу либо не
понимает причины спроса на поддержку. Постоянное превышение уровня
обслуживания могут быть следствием сверхукомплектованности.
Анализ данных отклика, может выявить тенденции , заставляющие развивать
альтернативы непосредственному ответу на запросы например, во время
неожиданного увеличения объема. Некоторые возможные альтернативы включают
переправку звонков в голосовую почту для более поздних отзывов вместо того,
чтобы оставить пользователей в ожидании; использование систему запроса, чтобы
направить вызывающих к ресурсам самоусовершенствования, и установка
приоритетов, для обслуживания в первую очередь самых важных запросов.
Контроль точности
Чтобы достигать максимальной эффективности службы поддержки или любой
группами решения, информация, которая получена и зарегистрирована службой
поддержки, должна быть столь полной и точной насколько возможно. Любая
погрешность в регистрации инцидента может неверно направить исследование и
диагноз инцидента.
Хотя погрешности могут возникать в службе поддержки, при записи ошибочных или
неполных данных, что может также включить регистрацию несоответствующих
данных, неправильную классификацию инцидента, назначение неправильного
приоритета к инциденту, использование неправильного кода закрытия, а также
неправильная запись деталей решения.
Гарантируйте, что существует процесс, посредством чего любые погрешности в
регистрации могут быть выдвинуты на первый план и сообщены. Можно также
проверять некоторые инциденты для проверки их точности.
Измерение продуктивности
Метрики производительности это те, которые показывают сделанный объем
работы, типа рабочих часов, число закрытых инцидентов, норма использования
ресурсов. Данные производительности могут указать, сколько поддержки
оказывается, сколько стоит поддержка, какие проблемы являются более, чтобы

решить, сколько времени сотрудника службы поддержки проведено в решении
специфической проблемы, и куда ресурсы идут вообще.
Для большинства служб поддержки важно отслеживать время, проведенное для
обеспечения поддержки по сравнению с полными часами работы. Измерение того,
сколько времени сотрудников фактически проведено на обеспечение
обслуживания, может быть полезным инструментом для определения того,
насколько эффективно используются ресурсы штата или вовлечено
дополнительных расходов. Затраты, связанные с сотрудниками, обычно являются
наибольшими расходами для организации службы поддержки. Это значит
измерения и контроль производительности, является ключевым к управлению
затратами.
Производительность сотрудников службы поддержки может сильно зависеть от
используемых инструментов поддержки. Контролируйте пригодность и доступность
инструментов - если система записи запросов или система телефонии выйдут из
строя, способность сотрудников службы поддержки исполнять свои обязанности
серьезно пострадает.
Конечно, для того чтобы измерить производительность, для начала надо
определить тип предоставленной поддержки. В случае службы поддержки, это
означает измерять что-то, что указывает, сколько обеспечивается обслуживания.
Для получения ответа надо отслеживать проблемы и инциденты.
58 Service Desk
Отслеживание по запросам
An issue is a problem that a user presents to the service desk to resolve. An incident, on
the other hand, is a contact or interaction concerning an issue. For example, several
users might call the service desk to report that a particular printer is not working. Each of
the users reporting the problem counts as a separate incident. The printer that isn't
working is the issue.
Отслеживание проблем облегчает сравнение данных, которые являются особенно
критическими для обоснования расходов и для определения области наибольших и
наименьших расходов. Часто, например, имеются очень ограниченные ресурсы,
чтобы вложить капитал в обучение. Отслеживая данные относительно типов
проблем для двух определенных продуктов, например, Microsoft® Windows® и
Microsoft Outlook®, возможно определить, какая тема была бы самой рентабельной
для обучения пользователей, с целью уменьшать число запросов, связанным с
этим продуктом.
Исследование определенных тем сообщений об инцидентах может также помочь с
планированием, как распределить ресурсы. Определяя количество инцидентов по
типам проблемы (например Microsoft Excel вопросы о финансовых функциях или
проблемы связи интранета), наряду с работой сотрудников по разрешению
инцидента, возможно идентифицировать типы проблемы, с которыми наиболее
часто сталкиваются, и соответствующие затраты всех сотрудников. Это позволяет
определить, как те проблемы являются менее или более трудо-затратными или те,
которые имеют высокое воздействие на производительность, хотя, возможно, и не
дают большого количества инцидентов. Более того, эти данные полезны для целей
комплектования и обучения.
Наконец, в случае если служба поддержки обеспечивает обратную связь к команде
разработки продукта, желательно сгруппировать информацию по определенными
проблемами. Это позволяет оценить серьезность или важность специфической
проблемы в свете числа запросов, затрат сотрудников, и области проблемы. Эта
информация может использоваться, чтобы рекомендовать изменения или решения,
которые имели бы самое большое воздействие.
Отслеживание по инцидентам
Другой вариант, который может быть полезен, состоит в том, чтобы отследить, кто
производит самое большое число сообщений об инциденте. Например, если есть
определенные группы, которые производят много инцидентов, можно подумать о
специальном режиме обслуживания этих пользовательских групп или
дополнительного обучения. Более того, можно идентифицировать группы,
специальные потребности которых были бы лучше всего удовлетворены группой
поддержки со стороны. Например, если одна группа - постоянна единственная
группа, которая нуждается в определенном типе поддержки, лучшее решение могло
бы состоять в том, чтобы найти специального местного инженера по поддержке.
Если отделы в пределах компании субсидируют стоимость службы поддержки,
отслеживание процента от рабочей силы, которая израсходована отделом, может
обеспечить основание для модели распределения стоимости.
Анализ и контроль удовлетворения клиентов

Достижение удовлетворения клиента это мера успеха для любой операции
поддержки. Не статистика доступности или операционные нормы, именно
восприятие клиентами обслуживания, которое они получают, и определяет,
удовлетворяет ли служба поддержки их потребности.
Обзоры удовлетворения это превосходный метод контроля восприятия и ожиданий

клиента, который можно также использовать как мощный маркетинговый
инструмент. Для того чтобы гарантировать успешный обзор клиентов, необходимо
обратиться к нескольким ключевым пунктам:
 Определите сферу обзора:
 Покроет ли он все услуги, обеспеченные службой поддержки или только
подмножество?
 Покроет ли он все признаки обслуживания, например, скорость ответа
запроса, любезность аналитика службы поддержки, своевременность
разрешения инцидента?
 Выберите потенциальных клиентов:
 Покроете ли вы всех клиентов или только отдельную компанию,
географическое местоположение, и так далее?
 Определите вопросы в обзоре так, чтобы избежать любой двусмысленности.
Гарантируйте, что вопросы, которые задаются, соответствуют потенциальным
клиентам.
 Сделайте обзор легким. Держите вопросы простыми и уменьшите риск
неоднозначных ответов, например: Да или нет, либо оценки в масштабе от 0 до 5.
 Удостоверьтесь, что клиенты понимают выгоды участия в обзоре.
 Опубликуйте результаты как можно скорее после обзора так, чтобы тема все
еще оставалась новой в умах клиентов
 Сообщите результаты обзора и трансформируйте результаты обзора в
действия.
 Обеспечьте доклады о достигнутых результатах. Если клиенты не будут видеть
никаких последствий обзора, то они откажутся участвовать в следующих обзорах.
Старшее руководство определяет частоту обзоров; решение должно быть основано
на скорости изменения в пределах организации и других бизнес параметрах. Можно
собирать данные о клиентах непрерывно, включив короткий анкетный опрос в
процедуру закрытия запроса; служба поддержки могла бы спросить клиента, было
ли решение успешным или был ли запрос обслуживания удовлетворен. Клиента
можно было бы попросить в то же самое время указать его или её удовлетворение
способом обработки запроса. Чтобы не обременять клиента слишком многими
вопросами, проверка удовлетворения должна выполняться только для маленького
процента от закрытых запросов.
Измеряя уровень удовлетворения клиента, гарантируйте, что любые
незапрашиваемые комментарии, поздравление, или жалобы от клиентов
учитываются, так же как и требуемые ответы.
Сертификация
Одной из возможных причин для того, чтобы требовать контроля и отчетности в
работе работы службы поддержки, состоит в том, чтобы позволить организации
поддержки пройти сертификацию соответствия против признанного стандарта в
промышленности. Это особенно имеет отношения к компаниям, продающие
оутсорсинговые услуги для выполнения работ по поддержке компаний-клиентов.
Многие компании требуют, чтобы поставщики услуг по поддержке были
сертифицированы. Если служба поддержки предлагает такие услуги, важно
60 Service Desk
определить каковы требования клиента по отношению к сертификации и каковы

стандарты, организации и сертификационные стандарты в тех районах, где
оперирует сервисная компания. Если организация работает интернационально,
может потребоваться сертификация по нескольким стандартам.
Каждый стандарт определяет критерии для того, чтобы достигнуть сертификации и
определяет, какие необходимые данные должны быть обеспечены и проверены для
сертификации. Скорее всего, что требования будут включать:
 Параметры операции службы поддержки.
 Параметры управления службой поддержки.
 Зрелость процессов поддержки.
Заключение
Контроль и измерение параметров службы поддержки, обеспечивает ли она
внутреннюю или внешнюю поддержку, являются критическими для эффективному
управлению службой. Каждому, кто создает или модифицирует существующую
службу поддержки, необходимо оценить:
 Каковы потребности?
 Какие имеются способы для измерения этих потребностей?
 Оправдывает ли фактор стоимости сбора и обработки данных ту выгоду,
которую он обеспечивает?
В дополнение к пониманию использования метрик, важно сохранить ясное
понимание того, что включает в себя каждое измерение. Эта информация помогает
службе поддержки анализировать произведенные данные.
Приготовление отчетов
Как только контрольные данные собраны, важно представить эту информацию в
удобочитаемом формат, который позволяет менеджерам рассматривать
информацию и использовать ее для принятия деловых решений. Обеспечение
высококачественных отчетов о контроле и измерении иллюстрирует важный
уровень зрелости организации поддержки.
На ранней стадии внедрения службы поддержки формальные отчеты обычно
неуместны. По мере роста службы поддержки появляются все более широкие
требования с целью ясно понимать истории запросов, тенденции, рабочие нагрузки
и быть в состоянии сообщить о полученных данных. Контроль информации это
часто единственный метод, доступный, чтобы оправдать дополнительные ресурсы
и расходы для этой функции.
Управление всеми собранными данными может быть серьезным вызовом в
управлении службой поддержки. Отчеты обеспечивают выделение и организацию
информации и оказываются превосходным инструментом для представления и
правления:
 бизнесом в целом (объем, израсходованный ресурс, и так далее).
 работой (как эффективный стол обслуживания находится в поставке решений).
 Изменения и тенденции со временем.
 Корреляции между парами измерений и моделей в поисках отношений

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

Этот процесс охватывает задачи, решаемые параллельно с каждодневными
эксплуатационными задачами, необходимыми для максимальной эффективности
работы службы поддержки. Более того, оптимизация работы службы поддержки
необходима для постоянного улучшения уровня ее сервиса. Необходимо обращать
внимание на следующие задачи:
 Обзор работы службы поддержки. Проверяйте информацию относительно
SLAs, OLAs, и имеющихся контрактов. Также пересматривайте поставленный
цели достижения удовлетворения пользователей.
 Оптимизируйте процессы. Включите интерфейсы к другим процессам.
Принимайте во внимание отзывы клиентов, практиков, и других SMF.
 Определение по привлечению третьих лиц для выполнения работ. Даже если
нет никаких непосредственных планов привлечений третих лиц для выполнения
работ для выполнения любой из функций службы поддержки, следует рассмотреть
такую возможность.
 Оптимизация количества сотрудников. Оптимизация укомплектования
персонала гарантирует, что имеется достаточное число сотрудников для того, чтобы
справляться с предсказанными рабочими нагрузками.
 Оптимизация навыков персонала. Оптимизация навыков персонала
гарантирует, что доступный штат имеет соответствующие навыки для выполнения
предсказанных работ.
 Оптимизация физического рабочего пространства. Оптимизируйте физическое
рабочее пространство так, чтобы гарантировать, адекватную вместимость и
технологии, физическое пространство способствует работе службы поддержки, а
так же имеется доступ к ссылочным материам и документации.
 Оптимизация технологии. Гарантируйте, что инструменты соответствуют
требованиям службы поддержки в терминах функциональных возможностей,
62 Service Desk
вместимости, и интерфейсов с другими инструментами, поддержкой, и навыками

сотрудников.
 Пересмотр и оптимизация. Гарантируйте, что проверяется правильность
данные и ключевые рабочие индикаторы (KPIs). Убедитесь, что используемые
метрики соответствуют приемлемым стандартам.
Рис. 5 показывает основные шаги по оптимизации службы поддержки.
Figure 5. Основные шаги по оптимизации службы поддержки

64 Service Desk
Reviewing Service Desk Operation

Постоянное рассмотрение работы службы поддержки необходимо для того, чтобы
проверить действительно ли обеспечивается соответствующий уровень
эффективного обслуживания для клиентов. Основываясь на отчетах, производимых
в процессе работы службы поддержки, можно регулярным образом тщательно
исследовать множество аспектов работы службы.
Рассматривая операции стола обслуживания, нужно выделить следующие
ориентируемые на клиента факторы:
 Понимают ли сотрудники службы поддержки требования клиентов и
пользователей? Есть ли какие-нибудь бизнес-планы, которые могли бы затронуть
потребности клиентов? Важно, что стол обслуживания знает о бизнес-планах; это
гарантирует, что услуги стола обслуживания и уровни укомплектования персоналом
продолжают отвечать требованиям.
 Отражают ли соглашения уровня обслуживания IT (SLA) требования клиентов?
 Поддерживают ли SLA эксплуатационные соглашения уровня (OLAs) со
службой поддержки? В противном случае эти соглашения должны быть
пересмотрены.
 Достигаются ли SLA? Если нет, то какие элементы не достигаются? Каковы
последствия этого? Не слишком ли амбициозны SLA? Можно ли улучшить уровни
обслуживания, чтобы удовлетворить SLAs? Оправдана ли стоимость
усовершенствования?
 Удовлетворены ли клиенты и пользователи службы поддержки полученным
обслуживанием? Какие аспекты обеспечиваемого обслуживания можно улучшить,
чтобы увеличить уровень удовлетворения клиента?
 Существует ли план улучшения услуг, предоставляемых службой поддержки?
Если да, то улучшается ли обслуживание согласно плану? Если это не так, то нужно
ли применить корректирующее воздействие?
 Изменялся ли план после последнего обзора? Если да, то какие новые
действия должны быть осуществлены, чтобы достигнуть запланированных целей?
 Если с клиентов собирают плату за использования службы поддержки,
действительно ли цены оправданы и разумны?
 Отражают ли цены стоимость обеспечения обслуживания? Адекватны ли
основания для формирования цены (например, плата за израсходованные
ресурсы, общая тарифная ставка)?
Среди факторов, которые затрагивают способность службы поддержки обеспечить
необходимое обслуживание, перечислим:
 Предусматривают ли операционные соглашения уровня (OLAs) уровни
обслуживания, необходимые выполнением службой поддержки ее собственных
обязательств? Нужно ли пересмотреть эти OLAs и контракты? Можно ли оправдать
затраты по улучшению условий контракта?
 Выполняются ли OLAs и подкрепляющие достигнутые контракты? Если нет, то
какие действия могут быть предприняты, чтобы гарантировать их достижение?
 Какие санкции можно применять против внешних поставщиков, которые не
обеспечивают законтрактованные уровни обслуживания? Разыскиваются ли
альтернативные поставщики?
Внутренние факторы службы поддержки включают:
 Достигаются ли внутренние цели? Можно ли улучшить работу?

 Имеется ли достаточное количество сотрудников, удерживаются ли они
достаточное время ?
 Соответствуют ли средства, используемые для поддержания функций службы
поддержки адекватными текущему уровню требований? Можно ли их улучшить, или
они должны быть заменены?
 Действительно ли затраты на обеспечение сервиса оправданны? Рентабельна
ли службы в том смысле, что экономит организации больше, чем тратит?
 Могли ли оптимизировать затраты? Можно ли минимизировать затраты,
привлекая третьих лиц для выполнения работ?
Оптимизация процессов
Примите во внимание следующие функции, оптимизируя работу службы поддержки.
Интерфейсы к другим SMFs

Функция службы поддержки тесно связаны с некоторыми другими SMF и их
процессами. Служба поддержки выполняет много задач, связанных SMF
Управлением Инцидентами и Изменениями, а также имеет связи с Управлению
Проблемами, Управлению Уровнем Обслуживания, и некоторыми другими SMF.
Они далее описаны в главе "Связь с другими SMF".
Интерфейсы между службой поддержки и этими SMFs очень важны, если
обслуживание, предоставляемое пользователям, должно достигнуть необходимых
стандартов. Менеджер стола обслуживания должен исследовать деятельность этих
интерфейсов, чтобы определить, можно ли сделать их более эффективными.
Рассмотрение интерфейсов может вовлечь ответственного за службу поддержки
для разработки рекомендации для изменений процессов, связанных с другими
SMF, а так же руководители других SMF могли бы предложить изменения
процессов службы поддержки.
Реакция на изменения
Все SMF быть приспосабливаться к изменениям в организации. Службы поддержки
никакие не исключение, и так как она обеспечивает мост между деловыми
функциями и отделом IT, изменения затрагивают службу поддержки больше, чем
другие SMF. Возможные изменения включают:
 Бизнес или организационные изменения. Введение новых деловых потоков,
приобретение или слияния компаний, перестройка компании, и так далее.
 Технологические изменения. Введение новой технологии к организации,
которая может затронуть компоненты, поддерживаемые службой поддержки, а
также технологии, которые используются в службе поддержки.
 Законодательное или регулирующее изменение.
Отзывы по применению
Запрашивайте предложения и мнения от сотрудников службы поддержки, так как
они вовлечены в ежедневную работу службы. Их обратная связь может обеспечить
жизненную информацию для того, чтобы оптимизировать процессы службы
поддержки.
66 Service Desk
Службы поддержки находится в центре коммуникаций клиента, и ее штат имеет

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

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

Аутсорсинг происходит, когда организация заключает контракт с другой компанией,
чтобы обеспечить услуги специалиста, вместо того чтобы выполнить те услуги
внутренне. Аутсорсинг обычно используется, когда организация становится более
сложной, особенно если происходит силяние или расширение сферы деятельности
компании. Существует много преимуществ аутсорсинга; имеются, однако, также
некоторые неудобства, как показано в следующей таблице.
Table 14. Преимущества и недостатки аутсорсинга
Преимущества Недостатки
Аутсорсинг позволяет организации Компания клиента обеспечивает
концентрироваться на ее основном ресурсы, чтобы контролировать
бизнесе. качество работы подрядчика.
Провайдеры услуг аутсорсинга могут В моменты пиковых нагрузок, когда
распространить их фиксированные может потребоваться дополнительный
расходы более чем несколько клиентов аутсорсенный персонал, навыки и
и, благодаря своей специализации, знания новых сотрудников могут быть
обеспечить лучшее качество недостаточными.
обслуживания по более низкой цене,
чем организация заказчик может
добиться собственными силами.
Специализированные поставщики услуг Поставщики имеют много клиентов и
могут объединить ресурсы получить могут испытать нехватку персонала для
доступ к большей базе навыков и каждого из них.
знаний.
Специализированные поставщики услуг Потеря контактов с клиентами.
могут обучать своих сотрудников
быстрее и более гибко.
Использование аутсорсинга для Уровень бизнеса может значительно во
выполнения работ дает организации время выполнения контракта, что
больше гибкости для того, чтобы значительно уменьшает выгоду. Без
удовлетворить пики спроса, пункта о минимального пороговом
одновременно сокращая большие ограничении уровня, организация может
капитальные расходы на быть заперта в дорогой контракт.
инфраструктуру.
68 Service Desk
Организации, которые рассматривают аутсорсинг, обычно делают это из-за

уменьшающих стоимость выгод. Однако, есть множество прочих потенциальных
преимуществ, так же как множество потенциальных рисков, которые необходимо
рассматривать.
Соображения стоимости
Чтобы определять рассмотрения затрат, жизненно важно идентифицировать
текущие и ожидаемые в будущем основания затрат обслуживания. Организация
должна сравнить затраты обеспечения внутренних функций службы поддержки
согласно спроектированной структуре, чтобы сформировать такое основание. Эти
затраты должны включить реалистический запас, чтобы покрыть ожидаемый рост,
вербовку и затраты по удержанию сотрудников, переквалификацию,
приспособления, обновление технологий, и так далее.
Как только эта информация установлена, необходимо проверить необходимые
затраты для того, чтобы управлять привлечением третьих лиц для выполнения
работ на основе контракта. Повторимся еще раз: рассмотрите реальную стоимость
контракта, зарплаты и нагрузку на полностью занятого менеджера контракта,
возможно, затраты на увеличение роли команды управления обслуживания,
которая возместит любую потерю прямого контакта с клиентами. Стоимость
возобновления контракта тоже должна быть принята во внимание, поскольку эти
затраты повторяются всякий раз, когда контракт должен быть возобновлен. Легко
ошибиться в выводе будет ли в конечном итого реализована экономия.
Передача рисков
Поддержание внутреннего обслуживания несет риски, которые должны
управляться. Обеспечение соответствующих ресурсов, и в количестве и в качестве,
является жизненно важным для эффективной поддержки. Поддержание баланса
между стоимостью и качеством не обязательно легко. Реальный риск состоит в
том, что ресурсы обеспечиваются чрезмерно, чтобы приспособиться к пиковым
нагрузкам. В то время как дополнительные ресурсы могут быть получены для
покрытия краткосрочные потребности через агентство или временные меры
укомплектования персоналом, временный штат вряд ли будет столь же
квалифицирован как постоянный штат или также знаком с проектом структуры
поддержки организации. В результате этих рисков обслуживание может ухудшиться
в течение определенного периода. Риск может только тогда быть эффективно
передан, если существуют открытые рабочие отношения между поставщиком
сервиса и клиентом, и это то, над чем надо работать всегда. Развитие
объединенной программы усовершенствования сервиса может быть эффективным
способом построить сильное партнерство, или как средство для того, чтобы
улучшить качество поставки сервиса.
Потеря контактов с клиентами

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

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

Когда служба поддержки отдана аутсорсинговоой компании, особенно важно
договориться о том, что включено в контракт. Обычно включается не вся поддержка
клиентов, а, более вероятно, аутсорсинг покрывает обработку запросов и до
некоторой степени начальную поддержку. Жизненно важно согласиться на счет
разграничения обязанностей. Внутренний оператор услуг, вероятно, сохранит
ответственность за оказание услуг 2го и 3го уровней, и, как часто случается, за
поддержку инструментов службы поддержки. В таких случаях, внутренний оператор
услуг сохраняет существенную ответственность, а так же имеется критическая
зависимость от аутсорсера на способность внутреннего оператора обеспечить
требуемый уровня обслуживания. Должны существовать операционные соглашения
уровня обслуживания, чтобы детализировать и документировать обязанности и
согласованные уровни обслуживания, которые будут обеспечены каждой стороной.
Инфраструктурные вопросы
Могут потребоваться изменения инфраструктуры, чтобы поддержать аутсорсинг,
например, возможности соединения сетей, технической совместимости, обучения,
инструментов, аппаратных средств, программного обеспечения, и так далее.
Например, если поставщик предлагает использовать свой собственный набор
инструмента, как это можно объединить с инфраструктурой клиента, какое
обучение требуется для штата поддержки клиента, окажет ли это какое-нибудь
70 Service Desk
воздействие на возможности сети, как это будет осуществлено на рабочих столах

клиентов?
Затраты на и последствия аутсорсинга

Затраты на аутсорсинг могут сильно меняться. Такие моменты, как отношения
между организацией и поставщиком, виды поддержки и объемы инцидентов -
очевидные факторы, не считая внутренних инфраструктурных затрат. Иногда
случается, что организация сохраняет собственность и затраты на инструменты
стола поддержки, в частности определяя, какой набор инструментов должен
использоваться поставщиком. На практике, в этой схеме клиент также сохраняет
значительный риск на протяжении всего времени контракта. Там, где применяется
такая договоренность, достижение согласованных уровней обслуживания зависит
от работы инструментов и качества их поддержки. Аутсорсер, вероятно, будет
обеспечивать всю инфраструктуру для собственного участка, вместе с затратами на
обеспечения деловой непрерывности. В случае использования инфраструктуры
клиента, однако, клиент сохраняет ответственность за то, чтобы обеспечить
физическую непрерывность.
В то время как относительно легко идентифицировать оценивать физические
объекты, затраты, связанные с данными менее очевидны. Традиционные затраты
на управление данными хорошо поняты и должны быть указаны в контракте, как
характеристика доступности сервисов. Собственность данных, также не сложно
определить, за исключением вариантов использования уже существующих данных.
Хочет ли клиент, чтобы поставщик взял ответственность за исторические данные? К
ним относятся любые данные, которые существуют на момент запуска контракта.
Большая часть таких данных относится к управлению инцидентами и не может
игнорироваться, другие будут использоваться для анализа и работы с трендами.
Обратите внимание, что случится с данными в конце контракта, особенно если
поставщик услуг имеет свой собственный набор инструментов и захочет удалить
данные?
В целях обеспечения непрерывности, компания может разместить многие из ее
собственных средств поддержки, прослеживания, и управления контрактами на
участке аутсорсера. Компания может направить инциденты прямо аутсорсеру,
обходя ее собственные внутренние механизмы. Все такие детали должны быть
явно выделены в аутсорсиноговом контракте.
Всегда важно оценить последствия аутсорсинга. Хотя аутсорсинг может быть
сэкономить средства, компания жертвует некоторым контролем над потенциально
важными взаимодействиями с клиентами. Если компания и аутсорсер расторгают
их деловые отношения, затраты на поиск нового партнера или перемещения
телекоммуникационной инфраструктуры могут быть высокими. В течение этого
перехода поддержка пользователей может быть сильно затруднена. Все это должно
стать частью анализа выгод и затрат любого проекта с аутсорсером.
Выбор аутсорсера
Выбрать аутсорсера легко, трудно выбрать правильного аутсорсера. Есть три
главных стадии заключения контракта на обслуживания:
1. Установка требований.
2. Торг с поставщиками в рамках предложенных требований.
3. Оценка предложений и, собственно, выбор.
Разработка требований
Есть два широких подхода к выработке требований; эти подходы известны как
основанные на требованиях входа и результата.
В требованиях на основе входа, клиент определяет то, что требуется и как это
должно быть обеспечено, например, требует применение ITIL или процессов MOF,
или настаивает на использовании какого-то набора инструментов.
В требованиях на основе коечного результата, разработка контракта
сосредотачивается результатах, а не на средствах их достижения.
В то время как подход на основе входных требований обеспечивает очень
определенные критерии разработки требований, также более вероятно, что от
клиента потребуется изменение рабочих процессов переквалификация сотрудников
поддержки второго ряда, и так далее. В обеих ситуациях, должны быть установлены
уровни обслуживания, операционные объемы, и профили роста.
Запрос предложений от поставщиков

Еще до формального запроса предложения (RFP) от аутсорсеров, полезно издать
запрос об информации (RFI), чтобы проверить рынок и увидеть, каким опытом
обладают претенденты. Это могло бы принять форму широкого утверждения о
требованиях, включая объемные данные, требования стандартов качества, и
широкие требования на обслуживания, что может послужить как ранний фильтр так,
чтобы полные предложения выбирались бы уже из более ограниченного диапазона
компаний. Это может упростить стадию детальной оценки и, что еще раньше
покажет любые трудности в достижении конкурентной заявки.
В лучшем случае, на этом этапе должен быть выбор между предполагаемыми
продавцами; если этого нет, то стоит серьезно задуматься над реализуемостью
проекта, или над пересмотром требований так, чтобы привлечь внимание
дополнительных продавцов. Каждая организация имеет собственный подход к
поиску предложений: правительственные организации часто вынуждены проводить
публичные тендеры. Организации частного сектора, с другой стороны, имеют
значительно больше свободы и могут принять более ограниченные предложения.
Как только список предполагаемых поставщиков установлен, рассылается более
детальный запрос о предложении (RFP) или приглашение на заявку (ITB).
Оценка заявок
Оценка предложений это одна из самых важных стадий процесса, так имеено в этот
момент принимается решение. Поставщик услуг отбирается исходя
предопределенных критериев, относящихся к различным требованиям, включая:
 Требования обслуживания.
 Затраты.
 Работа компании.
 Стабильность компании.
Можно использовать некоторые критерии высокого уровня:
 Смогут ли они удовлетворять установленным требованиям уровня качества?
 Показывают ли они требуемый уровень работы с существующими клиентами?
 Показывает ли поставщик услуг гибкий подход к изменениям?
 Действительно ли компания устойчива?
72 Service Desk
 Какие качественные стандарты они принимают?

 Удовлетворят ли компания модели оказания услуг?
 Как компания предлагает добавить ценность?
Контроль качества аутсорсинговой поддержки

Контроль качества обслуживания, предоставленного аутсорсером, очень важен для
успеха партнерства. Контракт, согласованный между компанией и аутсорсером
должен определить уровни обслуживания, стандарты обслуживания, ключевые
индикаторы работы, и/или диапазон метрики работы. Способ, которым определятся
метрика, должен быть согласован, также как и должен шаги, которые должны
предприниматься, если метрика падает ниже установленных стандартов.
Если поддержка предоставляется для внутренних клиентов, отзывы об уровне
обслуживания и формальные опросы клиентов обеспечивают готовый источник
информации, которую легко может быть собрать. Это может быть дополнено в
течение года выборочным обзором беспорядочно отобранных инцидентов или
анализируя записи инцидентов.
Отслеживание качества поддержки затруднено, если аутсорсер осуществлят
поддержку внешним клиентам компании. Неудовлетворенные клиенты, возможно, и
не пожалуются, они скорее просто прекратят использовать поддержку или покупать
продукты компании. Они могут также разделить свою неудовлетворенность с
другими, еще больше снижая возможности получения дохода. Это становится
более важным с появлением больших центров обработки запросов, имеющих дело
со многими клиентами.
Зачастую возможно контролировать инциденты по мере работ над ними, например,
контролируя телефонные звонки или читая отчеты об инцидентах. Это не простая
область, и любые такие меры должны быть разъяснены в контракте и
осуществляются под строгим контролем. Чаще всего используются проверочные
запросы для непосредственного контроля качества обслуживания, хотя и эта
методика должна быть проговорена в контракте. (Такой способ может работать
эффективно и для внутренних и для внешних клиентов службы поддержки.)
Необходимо устраивать регулярные и частые встречи для оценки работы между
продавцом и компанией так, чтобы любая деградация или нехватка в работе были
идентифицированы и исправлены как можно раньше. Это показывает
заинтересованность и может стать элементным компонентом программы
усовершенствования обслуживания. Не исключено, что в первые дни работы нового
аутсорсингового контракта, уровень сервиса упадет на некоторое время, перед тем
как восстановится до приемлемых уровней. Не стоит дожидаться ежегодной
встречи, чтобы обсудить это.
Если, несмотря на это, аутсорсер не может удовлетворить стандарты обслуживания
в течение согласованного по контракту периода измерения, то менеджер контракта
должен формально сообщить об этом аутсорсеру и развить план действия
относительно усовершенствования, согласно контракту. Если аутсорсер
продолжает терпеть неудачу, необходимо принять все меры, предусмотренные
контрактом. Ко всем проблемам, связанным с плохой работой надо обращаться
немедленно.
Как избежать общих проблемы с аутсорсингом?

Следующие предложения помогут избежать многих из общих ловушек в
аутсорсинге службы поддержки.
 Гарантируйте, что объемы инцидентов и требования уровня обслуживания
ясны. Обеспечьте, тем не менее, формальную процедуру изменения, которая
может использоваться, чтобы изменить требования, так как факторы, связанные с
бизнесом клиента, могут поменяться.
 Гарантируйте, что существует контрольная программа качества, а аутсорсер
понимает ее и соглашается с этим. Контракт должен ясно определить параметры,
которые будут измеряться и сроки этих измерений, согласованные уровни
обслуживания, и любые штрафы в случае, если сервис не предоставляется в
рамках руководящих принципов, так же как любые стимулы для
усовершенствования обслуживания.
 Роли и обязанности должны быть четко определены. Клиент имеет договорные
обязанности, как и поставщик услуг, должна быть полная ясность относительно и
того, и другого.
 Задержки и проблемы вероятны в первые дни любого контракта. Будьте
реалистичны о том, что является приемлемым, а что нет. Работа в тесном
сотрудничестве с поставщиком услуг минимизирует воздействие и укрепляет
товарищество в рамках работы по контракту.
 Будьте реалистичны о переходе поддержки; вполне вероятно, что потребуется
больше времени, чем ожидается.
 Гарантируйте, что клиенты понимают то, что и почему происходит; не
позволяйте им быть застигнутыми врасплох.
 Будьте реалистические о том, что ожидать от отношений с аутсорсерами и
любых ожидаемых сбережений. Могут ли они осуществиться, или являются только
теоретическими?
 Помните: самое низкое предложение - не обязательно оптимальное
предложение. Самое рентабельное не обязательно самое дешевое.
 Гарантируйте, что аутсорсер предоставляет все данные, которые компания
требует, чтобы управлять бизнесом эффективно.
 Гарантируйте, что существует четкий способ коммуникации, и для инцидентов, с
которыми не может справиться аутсорсер, и для административных проблем.
 Удостоверьтесь, что внутренняя техническая экспертиза не исчезает из-за
аутсорсинга.
 Вовлеките аутсорсера в планирование бизнеса так, чтобы он мог заранее
понимать возникающие новые требования.
Оптимизация персонала
Целью этой части процесса оптимизации службы поддержки является гарантия
того, что достаточный штат с соответствующими навыками всегда доступен, чтобы
справится со всеми запросами всех типов, получаемыми службой поддержки.
Обеспечение таких уровней укомплектования персонала должно произойти в
тесной связи достижением любых согласованных с клиентом уровней
обслуживания, одновременно минимизируя затраты на организацию.
74 Service Desk
Прогноз требований к персоналу

Для целей планирования, большинство служб поддержки старается предсказать,
какие необходимые ресурсы потребуются в будущем. Точное предсказание
необходимых ресурсов помогает отображение спроса на требования к
укомплектованию персонала. Этот процесс называется прогнозом и может
использоваться для того, чтобы оценить штат, рабочую силу, и другие ресурсы,
требуемые для обеспечения требуемого уровня обслуживания. Большие
организации поддержки обычно понимают, что точный прогноз жизненно важен для
поддержания рентабельности, распределение ресурсов поддержки, помощи в
финансовом процессе утверждения бюджета, и для поддержания согласованных
уровней обслуживания.
Методика для точного (но гибкого) прогноза это важный компонент придания
службе поддержки, производительности и эффективности, снижая ее затраты к
минимуму. Хотя прогноз может привлекать более сложную математику, статистику,
исследования вероятности, и теорию очередей (теория очередей служит для
математического исследования очередей, или линий ожидания), существуют более
простые подходы, которые могут послужить для решения задач типичной службы
поддержки. Чтобы обеспечивать отправную точку для того, чтобы понять
прогнозирование и обеспечивать понимание того, как эти прогнозы могут
использоваться, в дальнейшем представлена простая модель. Эта модель
основана на нескольких относительно простых формулах и может быть
приспособлена к службам поддержки разного размера и типов. Упрощение модели,
однако, не уменьшает важность процесса; точность прогноза может оказать
существенное влияние на успех или неудачу службы поддержки.
Несмотря на то, что эта модель адекватна расчета разумных оценок требований
штата, она может быть слишком упрощенной для некоторых функций стола
поддержки. Менеджеры очень больших служб, возможно, должны применять
передовые и более сложные методы для прогнозирования. И в этом случае,
принципы, описанные далее, применимы и к более сложным моделям.
В зависимости от доступных ресурсов и экспертизы, некоторые компании могут
привлечь внешнего консультанта, чтобы помочь с первоначальным сбором
информации и анализом для того, чтобы создать стол обслуживания. Вообще
говоря, этого не требуется, однако и эту возможность не стоит исключать.
Основы прогнозирования
Небольшие службы поддержки (укомплектованные несколькими сотрудниками) в
первую очередь найдут полезной эту модель прогноза в качестве руководства, хотя
она более полезна для больших служб. Существуют две причины для этого. Во-
первых, меньшие службы поддержки могут выделить меньше ресурсов, и может
обеспечить меньше полезную информацию, так как не существует свободы выбора.
Например, каждому сотрудников, вероятно, придется работать по одному и тому же
расписанию в течение недели, независимо от спроса. Во вторых, предсказывающие
модели вообще основаны на вероятности, и увеличивают точность одновременно с
увеличением объема поддержки. Это означает, что в ситуациях с очень маленькими
объемами поддержки, модель, возможно, не обеспечивает такой же точности, как в
случае большого объема поддержки. Обычно, ежедневный спрос на поддержку,
выраженный в процентах, изменяется значительнее для более низких, чем для
более высоких объемов.
Важно иметь в виду, что прогноз основан на вероятностях, и интерпретация
результатов (первоначально полученных математически) должна контролироваться
опытом со стороны аналитика, занятого прогнозом. Прогноз также полностью
зависит от точности входов и предположений, используемых для его

моделирования. Прогноз использует формулы, чтобы создания моделей для того,
чтобы предсказывать случайные события. Даже в случае большого спроса на
поддержку, когда все величины, используемые в формуле, точно представляют
описываемую ситуацию, результат предсказания, возможно, не соответствует точно
тому, что фактически происходит, но в этом природа случайных событий.
Кроме того, необходимо выполнить прогноз для каждого типа предоставленной
поддержки. Это означает, что необходимо идентифицировать каждый тип оказанной
поддержки. Можно сгруппировать типы поддержки в категории, основанные на
определенном продукте, например, программного обеспечения, Microsoft Word или
Microsoft Access. Альтернативно, можно организовать данные о поддержке по типу
клиента поддержки, виду операций (например, поддержки приложений, установки
программного обеспечения, проблем сети, или новых компьютерных сооружений),
или способа предоставления поддержки (например, по телефону, локальной сети,
или по электронной почте), или некоторую комбинацию всех отдельных способов.
Лучше делать отдельный классификатор для каждого типа поддержки при условии,
что четко выделяем, или имеет различные требования к укомплектования
персоналом.
Существует баланс, который будет найден между деталями, обеспечиваемый
введением множественных категорий и сложностью информации, которая должна
управляться. Больше различных категорий увеличивают сложность прогноза, но
могут дать большую точность, основанную на типе поддержки, и могут позволить
лучшее распределение сотрудников, хотя, как упомянуто выше, меньшие очереди
имеют тенденцию иметь более высокое естественное изменение и меньшую
эффективность. Это свойство должно быть уравновешено. Один из вариантов
состоит в том, чтобы начать с разумного числа категорий и, затем, вычислять
прогноз. Если полученные числа пригодны к использованию, категории разумны. С
другой стороны, если числа являются или слишком большими или слишком
маленькими, или иначе абсурдными (например, попытки назначить одну треть
служащего), придумывают другие категории.
Процесс прогнозирования
Выделяют четыре основных процесса, или шага, связанные с оптимизацией
уровней штата:
1. Основы спроса
2. Определение численности персонала
3. Определение нормы использования
4. Предсказание потребностей укомплектования персонала
Шаг 1. Основы спроса

Прежде, чем возможно оценить спрос, необходимо выяснить, какие факторы
определяют или влияют на спрос на услуги службы поддержки. В зависимости от
размера и типа службы, можно выделить следующее факторы:
 Число активных компьютеров и числа пользователей, которые, возможно,
нуждаются в поддержке службы поддержки (некоторые отделы могут быть более
сложными пользователями, чем другие).
 Компетентность, навыки, и уровни обучения пользователей.
 Поддерживаемая инфраструктура IT - ее архитектура, надежность, размер,
возраст компонентов.
76 Service Desk
 Услуги, поддерживаемые самостоятельно и сторонними разработчиками.

 Закупка новых аппаратных средств или продуктов программного обеспечения.
 Циклические или сезонные события, типа конца финансового периода.
 Выход новой версии программного продукта или обновления.
Может быть полезно прорисовать объемы спроса за доступное время и объяснить
изменения в запросах службы поддержки от одного периода к другому. В
зависимости от количества исторических доступных данных, можно использовать
ежемесячные, еженедельные, или ежедневные измерения. Этот процесс должен
подтвердить существование отношений между запросами службы поддержки и
прочими факторами. Следующий шаг должен проанализировать и определить
количество таких отношений. Microsoft использует линейные методы регрессии,
чтобы оценить эти отношения; однако, можно использовать и более простые
отношения, основанные на недавних исторических данных. Чтобы оценивать число
запросов, производимых группой пользователей специфического продукта, служба
поддержки, может исследовать выборки пользователей и затем применить
полученные результаты на всей организации в целом. Эта величина изменяется от
компании к компании, в зависимости от таких факторов как уровень использования,
опыт работы с продуктом, и так далее. Может также быть полезно рассчитать
предсказанные объемы запроса в течение исторического периода и сравнить
результаты с тем, что фактически произошло в течение той же самой единицы
времени. Это помогает проанализировать, насколько хорошо работает модель.
Прогноз зависит от нескольких выбранных метрик, которые формирует основания
для модели поддержки. Чтобы предсказывать потребности укомплектования
персоналом, менеджер службы поддержки должен быть в состоянии обеспечить
точные цифры, представляющие эту метрику. Это обычно не проблема для уже
существующей службы поддержки, в которой уже создана система отслеживания
запросов, и соответствующие метрики рассчитываются системой самостоятельно.
Для новой службы поддержки, или в случае, когда необходимая информация не
собрана, расчет метрик несколько сложнее и каждая из метрик может быть сначала
оценена, а потом вставлена по мере накопления информации. Имейте в виду, что
прогноз это эволюционный процесс, который требует периодической наладки и
должен улучшаться в течение долгого времени.
Следующая таблица показывает основные метрики, используемые для прогноза

требований к персоналу службы поддержки
Table 15. Метрики для прогноза
Метрика Описание
Среднее число запросов в Чаще всего, просто рассчитать (или оценить)
определенный интервал число запросов за один день; однако, можно
использовать и другие интервалы.
Средние затраты труда на Это время, которое необходимо сотруднику
обработку каждого запроса службы поддержки для реагирование на
единственный запрос. Оно может быть
вычислено, деля общее время работы
сотрудника, на число запросов, которые он
обработал. Например, может потребоваться в
среднем 12 минут, чтобы разрешить инцидент,
и каждый сотрудник службы поддержки
проводит в среднем 3 минуты между
запросами, документируя последний инцидент,
в общем получается 15 минут на запрос. Эта
величина меняется в зависимости от частоты
инцидентов и знакомства персонала с этим
типом инцидентов.
Чрезвычайно важно помнить, что эти
первоначальные оценки могут быть очень
неправдоподобными. Формулируя прогноз
службы поддержки (и укомплектование
персоналом), лучше использовать заниженные
ожидания и завышенные метрики. Планируйте
каждую из них как худший случай, ожидаемый,
и лучший сценарии и будьте готовы
корректировать каждый из них.
Шаг 2. Основы определений численности персонала

Как только установлены требования спроса, менеджер службы поддержки может
начать оценивать потребности укомплектования персоналом в каждом типе
поддержки. Как и в случае с цифрами, собранными для спроса, необходимо
собрать различные данные, и определенные решения должны быть приняты для
того, чтобы точно оценить необходимое количество сотрудников. Эти величины
должны быть определены из расчета на среднего сотрудника службы поддержки в
пределах каждой категории, используемой в расчетах на Шаге 1. Для того чтобы
определить потребности укомплектования персонала, необходимо:
 Определите число доступных часов. Это время, которое каждый аналитик
службы поддержки может по плану уделить поддержке в течение дня. Имейте в
виду, что это - среднее время, обеспечиваемое фактически одним человеком, а не
время, на протяжении которого обеспечивается работа службы поддержки (она
должна быть доступна все время типичного рабочего дня). Например, каждый
сотрудник службы поддержки может быть ответственным за ответы на запросы о
поддержке, телефонные звонки или отвечать на электронную почту, шесть - семь
часов в день, тратя другой один или два часа на косвенные действия, связанные с
работой службы.
78 Service Desk
 Оцените норму отсутствия штата поддержки. Это - процент от штата,

который быть больным, на каникулах, в обучении, или отсутствия по любой причине
в любой данный день (согласно оценке). Это - среднее число ресурсов, которые
могут быть недоступными для организации поддержки. Эта оценка необходима в
ситуациях, в которых обучение или каникулы не могут надежно планироваться.
Если Вы можете спланировать каникулы или обучение, предполагаемая норма
отсутствий штата поддержки не должна включаться в вычисление прогноза. Однако,
вообще говоря, включение отпусков и обучения зачастую упрощает вычисления.
Для большинства организаций, неплохой первоначальной оценкой может быть 15
процентов, но для разных организаций следует использовать разные цифры. Это
особенно верно для маленькой службы поддержки, которая испытывает более
высокое изменение в отсутствиях штата от ежедневного среднего, чем большая
организация. Например, если служба поддержки состоит из трех аналитиков, то за
каждого из сотрудников в отпуске служба поддержки теряет 33 процента ее штата.
Некоторые организации не желают учитывать такие пропуски в прогнозах.
Включение этих чисел в прогнозы затрудняет анализ прогнозов, потому что таким
образом они оказываются скрытыми в полной картине работы службы. Если
необходимо проанализировать затраты, связанные с тем, сколько аналитиков
находится в обучении или в отпуске в любое данное время, каждая из этих величин
должна быть учтена в отдельном плане.
Step 3. Определение процента использования

Исследуйте используемые категории и определитесь, какие из них обеспечивают
поддержку немедленно (например, телефонная поддержка) а какие из них
обозначаются в обработку, но в которых ответ не следует непосредственно за
запросом (например, отзывом, по электронной почте, или отправленным по факсу
ответом). После этого определите желательную норму использования, для каждой
категории обслуживания (эта величина, показывающая, сколько из времени,
доступного для службы поддержки, фактически используется для того, чтобы
обеспечить обслуживание). Например, в телефонной модели, обработка типичного
запроса может занять 12 минут со средним числом в 3 минуты праздного времени
между запросами, или в общей сложности 15 минутами на запрос. Норма
использования для этого типа поддержки - 12/15, или 80 процентов. Тип поддержки,
где запросы отправлены факсом, может иметь норму использования столь же
высокую как 100 процентов, потому что работа может быть расположена по
приоритетам, и сотрудники не должны ждать прибытия следующего инцидента.
Поддержка, которой управляют, основана на расписании службы поддержки, в
пределах руководящих принципов осуществления сервиса, соответствующей для
назначенной серьезности. Сюда могут входить ответы на запросы по электронной
почте, запланированные посещения клиентов, и любые другие методы, в котором
служба поддержки имеет полный контроль над доступностью сервиса. Нормы
использования для поддержки, которой управляют, как обычно предполагаются 100
процентными, потому что нет никакой потребности ждать, чтобы выполнить работу,
пользовательские запросы могут быть отобраны из уже-существующей группы
обрабатываемых запросов. Это означает, что все доступное время сотрудника
проведено, обеспечивая обслуживание. Когда имеется больше ресурсов чем
необходимо для разрешения всех запросов в очереди, то эта часть службы, по
видимому, имеет лишние ресурсы, которые могли быть перенаправлены в другое
место для снижения затрат и увеличения эффективности и производительности.
Непосредственное оказание помощи обеспечивается клиенту непосредственно во
время запроса, например, лично за столом обслуживания или по телефону. Ответ
на каждый запрос обслуживания не управляем столом обслуживания, и начинается
в момент прибытия запроса. Обычно, безотносительно от механизма сервиса,
непосредственную поддержку оказывают в рамках модели на основе очереди, где
люди могут ждать в очереди (в ожидании) на обслуживания. Нормы использования

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

распределения ресурсов в течение времени как единственную величину,
выраженную в процентах. С такой моделью, возможно, оценить норму
использования в терминах целевого уровня обслуживания. Например, норма
использования могла быть вычислена для целевого уровня обслуживания, при
котором 90 процентов всех запросов обработаны через одну минуту или меньше.
Этот тип нормы использования представляет время, в течение которого,
пользователю, вероятно, придется ждать.
Отметьте, что оказание поддержки непосредственно или под управлением
существенным образом различаются в требованиях укомплектования персоналом.
В случае поддержки, которой управляют, все доступное время сотрудников службы
поддержки может быть проведено, оказывая услугу, до тех пор, пока доступное
время не превышает спрос. С непосредственной поставкой поддержки, режим, в
который прибывают запросы, не может быть заранее известен, только предсказан.
Таким образом, оказание поддержки, которой управляют, вообще говоря, позволяет
более точные распределения сотрудников и требует меньшего их числа, так как
имеется значительно меньше непроизводительного времени в ожидании запросов.
Используя оказание поддержки, которой управляют, а не непосредственную
помощь, в случае если такая модель поддержки приемлема для удовлетворения
запросов клиента, уже само по себе может привести к снижению затрат.
Шаг 4. Прогноз потребностей комплектования

Используя собранную информацию, оцененную, или вычисленную на предыдущих
шагах, имеется возможность прогнозировать требования укомплектования
персоналом службы поддержки для каждой из категории поддержки.
Величины, которые необходимы для вычисления по формуле, объясняются в
следующей таблице
Table 16. Категория поддержки
Категория поддержки Требования к персоналу
Звонки Эта величина представляет число запросов за
определенный интервал (чаще всего один день ) и
вычисляется на основе спроса в Шаге 1. Интервал,
используемый для этой величины, определяет
интервал для результата. Другими словами, если
используются запросы в день, тогда и результатом
будет число сотрудников, необходимых в день.
Среднее время Это среднее время, проведенное отвечая на запрос,
также вычисленное в Шаге 1. Это характеристика
трудовых затрат, необходимых для обработки
единственного запроса и должно быть выражено в
часах.
Доступное время Это - время, в течение которого каждый сотрудник
службы поддержки назначен оказывать поддержку, и
которое определено в Шаге 2 как число доступных
часов. Единицей измерения для этой величины
совпадает с единицей, используемой для расчета
укомплектования персонала, чаще всего это один
сотрудник службы поддержки.
Время отсутствия (SVT Эта величина (называемая % SVT) представляет собой
%) предполагаемую норму отсутствия из-за болезни,

каникул, и обучения, как определено в Шаге 2.
Доля использования Эта величина вычислена на Шаге 3. Для модели
непосредственной поддержки, эта величина
представляет процент от времени, в течение которого
сотрудник службы поддержки фактически
взаимодействует с пользователем.
Эти величины подставляются в следующее уравнения:
Запросы × Среднее время
Доступное Время × Норма использования × (1 - % SVT)
Верхняя часть уравнения вычисляет предсказанное
время, необходимое для того, чтобы обработать все
запросы за данный интервал. Нижняя часть основания
вычисляет, среднее время, проведенное во
взаимодействии с пользователем. Полное доступное
время уменьшается нормой использования (чтобы
принять во внимание время, когда службы поддержки
ждет, чтобы ответить на запрос), и процентом от
времени, в течении которого сотрудник службы
поддержки, как ожидается, будет находиться на работе
(100 процентов минус процент от времени, согласно
оценку, будет потерянно из-за отсутствия).
Например, предположим, что служба поддержки Trey
Research обеспечивает поддержку Microsoft Excel по
телефону. Предполагается, что каждый запрос
занимает 15 минут (.25 в часах), чтобы обработать,
желательная норма использования для типичного
сотрудника - 65 процентов, и каждый специалист
службы поддержки, по плану, будет работать на
телефоне шесть часов в день. Служба поддержки
предполагает, что, в среднем, 15 процентов их
ресурсов поддержки будут потеряны из-за болезней,
каникул, и обучения каждый день. Ожидается в
среднем 100 запросов каждый день. В каком
количестве штата они нуждаются?
100 запросов × 0.25 часа
6 часов/дней x 65%-ое использование (1-15%SVT)
что равняется
25
39 × (85 %)
или
25/3.3 = 7.5
Подстановка рабочих предположений в уравнение для
прогноза показывает, что приблизительно будут
необходимы примерно 7.5 сотрудников, чтобы
удовлетворить предсказанный спрос с
82 Service Desk

вышеупомянутыми ограничениями и целями. В
действительности, это 7 или 8 специалистов, или кто-
то на неполный рабочий день.
Следующий рисунок показывает предполагаемое штатное расписание,

рассчитанное с вышеупомянутыми константами, но с переменными среднем
временем на запрос (Average Time) и количество инцидентов (Incidents).
Проектирование службы поддержки, основанного на этих рабочих предположениях
может быть очень полезным, особенно для первоначально планирования штатного
расписания для службы поддержки.
Figure 6. Ежедневная оценка числа сотрудников в зависимости от времени

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

Представленная модель прогноза обеспечивает информацию об общем
количестве сотрудников, необходимом для работы службы поддержки в течение
определенного интервала (обычно день). Остается распределить работу отдельных
сотрудников по часам в течении рабочего дня для того, чтобы служба поддержки
смогла обеспечивать обслуживание. Важно понимать, что процесс распределения
сотрудников по интервалам обслуживания может потребовать перевычисления
прогноза укомплектования персоналом. За дополнительной информацией о
планировании индивидуального штата, см. раздел Управление Штатом Службы
поддержки ранее в документе.
Фактическая попытка назначить людей может вскрыть проблемы, которые требуют
увеличения числа сотрудников. Когда дробное число сотрудников требуется в
разное время дня, надо принять решение об увеличении или уменьшении числа
сотрудников в этом интервале. Это особенно справедливо для маленьких служб
поддержки; потребности в частичной занятости теряют значение по мере
увеличения штата.
Как только спрос предсказан и понят, лучше всего сделать оценку исходя из
соображений здравого смысла. Есть ли что-нибудь очевидно неправильно или
непрактично для компании? Есть ли что-нибудь необычное, что может затронуть
количество или время обработки запросов? Следующая таблица включает список
предложений подобных предположений.
Table 17. Соображения для назначения персонала
События Описание
Выходные, Запланированный отпуск и периоды, когда компания имеет
отпуска необычно высокое или низкое число людей, берущих отпуска
(например, в праздники или дни школьных каникул).
События в События в компании, которые могут увеличить использование
компании службы поддержки, например, планирования бюджета,
реорганизации, регулярных встреч групп и так далее. Это
относится к временным, запланированным событиям, которые
могут иметь предсказуемые воздействия и могут заставить
регулировать ресурсы или изменять ожидания об уровне
поддержки.
Установка Новые продукты, аппаратные средства, или другие
нового поддерживаемые инструменты, могут потребовать времени для
программного установки, дополнительного обучения, или привносят новые
обеспечения, сложности или проблемы для пользователей. Если службы
оборудования поддержки отслеживала метрику поддержки в течение подобных
событий в прошлом, можно сделать квалифицированную оценку
воздействия на работу службы. Никогда не слишком поздно
начинать собирать информацию, до тех пор, пока стоимость сбора
информации оправдана прибылью.
Персонал Существенные количество новых сотрудников, скорее всего,
сделают запросы в службу поддержки. Как и раньше, в этом месте
может помочь опыт. Работа с отделами с большим количеством
новых сотрудников для того, чтобы помочь минимизировать
воздействия или оценить увеличение потребностей спроса на
услуги службы поддержки.
Новые Новым сотрудникам службы поддержки, первоначально
84 Service Desk
сотрудники потребуется больше времени, чтобы решить проблемы.

службы Увеличение среднего времени обработки запросов в течение этих
поддержки периодов может помочь принять это во внимание.
Сверхурочны Поддержка во внерабочее время, например, поддержка в течение
е часы 24 часов, поддержки в выходные, или непрерывная поддержки (7
дней в неделю, 24 часа в день). Такие предложения
обрабатываются и предсказываются точно регулярным прогнозом.
Может быть полезным сделать прогнозы отдельно на различные
периоды времени (стандартное рабочее время, вечерние часы,
выходные, и так далее), чтобы лучше всего определить
потребности укомплектования персоналом.
Если встречаются проблемы этого типа, опыт, управляемый интуицией может

помочь отрегулировать прогноз, ожидания обслуживания, и список
укомплектования персоналом. Ко многим из этих предположений можно обратиться
вне прогноза, включая план найма как шаг в процессе укомплектования
персоналом. План найма может также принимать во внимание другие аномалии,
которые являются трудными для предсказания, например, ограничений
пространства и административной работы. В этом документе имеется полное
обсуждение плана найма.
Текущий контроль
Контроль укомплектования персоналом, планирования, и оказания поддержки
является критическим, особенно для групп решения, в которых предположения,
затрагивающие прогноз укомплектования персоналом не основаны на исторических
данных. Критически важно определить, переукомплектована ли служба поддержки
или недоукомплектована, распределены ли должным образом ресурсы, или
правильны ли основные предположения. Службы поддержки должны собрать как
минимум следующую информацию для адекватного непрерывного прогноза (или
прогноза регулирования) потребностей укомплектования персоналом:
 Количество запросов за интервал (полчаса или час)
 Рабочие затраты на запрос
 Тип поддержки, связанный с запросом
 Уровень обслуживания
Дополнительная информация, которая может помочь последующему анализу,
полезна, но не абсолютно необходима для прогноза. Однако, она может позволить
точную дополнительную настройку организации службы поддержки или помочь
руководству.
Осуществляя контроль, необходимо избежать слишком острой реакции на
ежедневные изменения или различия. Сосредоточитесь на том, чтобы отличать
истинные тенденции от ежедневных вариаций и не спешить, чтобы точно настроить
модель или сделать незначительные изменения. Трудно определить, являются ли
метрики, полученные за несколько дней или за неделю, представительными, и
только лишь изучение ежедневных вариаций может занять несколько недель.
Службы поддержки с маленьким персоналом и маленькими требованиями к
обслуживанию, скорее всего, покажут наибольшие ежедневные вариации (в
процентах). Это явление, иногда называемое синдромом короткой очереди,
является нормальным и должно ожидаться. Хотя существуют статистические
методы для того, чтобы вычислить значение изменений или различий даже в этом
случае, они могут оказаться сложными и лучше всего работают как инструмент, для
очень больших служб или организаций поддержки.
С другой стороны, в случае если действительные данные последовательно
оказываются выше или ниже прогнозу, возможно, требуется некоторый анализ и
регулирование.
Следующие индикаторы могут указывать на необходимость изменений:
 Уровни обслуживания или необычно высокие задержки, которые
последовательно оказываются или значительно выше или ниже цели. Это - лучшая
мера того, как хорошо организация поставляет поддержку и говорит, поставляет ли
служба поддержки то, что обещает.
 Существенные различия или изменения в предсказанной рабочей силе на
инцидент или в объеме запроса. Когда бы ни было возможно, определите причину
изменения; это поможет выявить природу любых изменений, которые могут быть
необходимы для службы поддержки.
 Нормы использования, которые оказываются последовательно или значительно
выше или ниже цели. Они указывают, что штат может работать интенсивнее чем
(или не так интенсивно как) предсказано, чтобы удовлетворить спрос. Это может
также быть индикатором того, что цель должна быть переоценена или
укомплектование персоналом пересмотрено.
 Жалобы на обслуживания от клиентов, особенно те, которые являются в
течение определенных интервалов в течении дня. Это должно быть проверено
особенно тщательно в службе поддержки, управляемого как центр прибыли, где
быстрая реакция может быстро окупиться и позволить избежать риска
неудовлетворенных клиентов или нарушений контрактов поддержки.
 Внезапные или постепенные изменения в любой метрике, которые кажутся
существенными либо в наблюдениях, либо после статистической обработки. Всегда
помните, что маленькие выборки могут показать большие изменения при
нормальных обстоятельствах и вообще должны использоваться только с
осторожностью. Обычно лучше ждать большего объема данных, если
статистическая достоверность остается под вопросом.
При любых изменениях в прогнозе, работайте медленно до тех пор, пока не
идентифицированы реальные тенденции, и избегайте делать внезапные,
радикальные модификации. Применяйте изменения консервативно. Если
серьезные изменения делаются часто, будет трудно проанализировать
исторические данные для будущего использования или убедиться, которые из
изменений произвели желательный результат.
Что если реальность не похожа на прогноз?

После того как прогноз закончен, план найма успешно осуществлен, и внедрено
расписание из расчета на ожидаемый спрос, службы поддержки имеет возможность
увидеть, работает ли все как запланировано. Как и в любом сложном процессе,
основанный на оценках будущего, всегда есть шанс, что действительность не будет
соответствовать с тем, что получено в модели. Чаще чем нет, менеджер службы
поддержки должен внести коррективы по мере выявления расхождений.
Обычно одна из двух метрик быстро говорит менеджеру, что он или она имеет
проблему с уровнем обслуживания, или что заявленные цели оказания
обслуживания не удовлетворяются должным образом (или превышаются
решительно), или доля разговора выходит за пределы предсказанного диапазона. В
случае, если по расчетам службы поддержки любая из метрик расходится
86 Service Desk
приемлемыми пределами в ее уровня обслуживания, менеджер службы поддержки

должен обратиться к нескольким вариантам.
Прогнозы, наряду с получающимися из них планами и списками комплектования,
основаны на двух метриках, каждая из которых может только быть только известна
предположительно: это число запросов и продолжительность обработки запросов.
Если продолжительность обработки запроса и число запросов в реальном мире не
соответствуют величинам, заложенным в прогнозе, то, вероятно, прогноз является
неправильным, и, таким образом, план найма, полученный из этого прогноза, также
неправильны.
Проблемы также могут возникнуть с прогнозами, в которых вышеупомянутые
метрики и предположения прогноза приемлемо соотносятся с действительностью.
Следующий вопрос, на который надо ответить, это необходим ли персонал в
данном временном интервале по расписанию. Получает ли служба поддержки
число запросов, которое ожидалось в указанные интервалы? Например,
соответствует ли прогнозу число запросов, полученных между 9 утра и 10 утра?
Если продолжительность обработки запроса и ожидаемый объем запросов
правильны, но спрос все равно не удовлетворяется, значит, вероятно, имеется
проблема планирования. Если, однако, интервал прибытия и укомплектование
персоналом правильны, но уровень обслуживания все еще не соответствуют
прогнозу (обычно снизу), вероятно, что штат не развернут фактически так, как
планировалось. Это может потребовать усилий, подчеркивающих важность
нахождений назначенных сотрудников на соответствующих постах согласно плану.
Приверженность расписанию может иметь сильный эффект на способность
оказывать поддержку.
Увеличьте цели предоставления обслуживания штату сервиса. Это означает, что
если они, по плану, проводят на поддержке шесть часов в день, увеличьте это
время до семи. Это позволит иметь больше ресурсов для того, чтобы иметь дело с
более высоким спросом в течение короткого периода, не имея необходимости
искать, нанимать, и обучать штат. Это также не будет требовать никаких
дополнительных средств на обслуживания или капитальных вложений. Будьте
осторожны, однако: это может привести к выгоранию сотрудников, если такой
режим поддерживается в течении слишком долгого времени в то время как другие
обязанности также требуют внимания. Один способов справляться с увеличением
целей предоставления обслуживания состоит в том, чтобы сократить
вспомогательные обязанности до тех пор, пока кризис не пройдет, хотя это не
всегда оптимальное решение. Может потребоваться дополнительная оплата
сверхурочных часов.
Потребуйте от сотрудников службы поддержки четкого понимания того, как они
тратят свое время. В то же время как не рекомендуется, вмешиваться управлением
в те периоды, когда стол обслуживания занят с поступающими запросами. Иногда
может оказаться возможно перенести некритические задачи и встречи так, чтобы
немного сократить времена обработки запросов, давая службе поддержки большую
производительность.
Если в определенные моменты времени служба поддержки эффективно
удовлетворяет спрос, попробуйте перераспределение ресурсов для решения
проблем. Кроме того, служба поддержки может иметь сотрудников в других
областях, которые могут браться за дело и помогать в течение кризиса. Конечно,
это мешает им выполнять другие обязанности, однако это обеспечивает, быстрое
решение временной проблемы. Это должно делаться осторожно, так как решение
одной проблемы перемещением ресурсов, может внести свой вклад в разрешение
других проблем.
Поощрите пользователей использовать альтернативные варианты поддержки, такие

как базы знания, ресурсы Сети, помощь онлайн, руководства, ЧАСТО
ЗАДАВАЕМЫЕ ВОПРОСЫ, объявленные в легко-доступной части сайта, и так
далее. Понимание того, что служба поддержки имеет ограниченные ресурсы, может
временно помочь уменьшить количество запроса. Сосредоточитесь на критической
поддержке. Проблема средств обслуживания и самообслуживания для клиентов
обсуждена подробно в SMF Управлении Инцидентами.
Попробуйте на время снизить уровень сервиса. Может быть, что не рентабельно
поддержать высокий уровень обслуживания в течение некоторых событий или на
некоторых направлениях службы поддержки. К этому нужно относится очень
тщательно, поскольку это может легко раздражить клиентов, особенно клиенты со
стороны. Убедитесь, что это предлагаемые изменения находятся в пределах
обязательств обслуживания, данных клиентам. Внутренние службы поддержки
могут сообщить об изменениях руководству группами пользователей, которых они
поддерживает.
Некоторые телекоммуникационные системы позволяют выдать сигнал "занято". Это
можно настроить так, чтобы клиенты услышали занятый сигнал и не смогли войти в
очередь в том случае, когда определенное число клиентов уже ждет в одной
очереди, или после того, как среднее число времени ожидания достигло
определенного порога. Это решение должно быть последним средством,
позволяющим клиентам избежать долгого ожидания, особенно если они находятся
на платной телефонной линии.
Если службы поддержки использует аутсорсинг, можно провести дополнительные
переговоры относительно дополнительного штата аутсорсинга. Конечно, это
обслуживание имеет цену, потому что аутсорсеру, вероятно, тоже понадобится
иметь штат для этой цели.
Если службы поддержки имеет противоположную проблему и оказывается
временно с излишком штата для обеспечения желательного уровня обслуживания,
первичная проблема не связана со способностью службы поддержки предоставить
клиенту хороший опыт. Проблема состоит в том, что стоимость поддержки
повышается, потому что штат - обычно самый дорогой ресурс в работе службы
поддержки.
Имея дело с ситуацией избытка персонала, можно рассмотреть несколько
вариантов:
 Перераспределите дополнительных людей к тем участкам службы поддержки,
который может использовать этот штат. Это дает больше затратных выгод тем
сотрудникам, которые находятся в избытке, одновременно сохраняя инвестиции на
обучение сотрудников.
 Найдите другую добавляющая ценность или превентивная работу для
сотрудников, например, создания статей в базе знаний, обучающих материалов, и
Белых Книг; испытание программного обеспечения и оборудования; проведение
инвентаризации и так далее.
 Предложите некоторое дополнительное неоплаченное время отпуска.
 Наслаждайтесь перерывом. Иногда короткое затишье спроса случается, а
передислокация, возможно, не стоит усилия.
 Если контракты позволяют это, рассматривают сокращение аутсорсинга или
временного штата. Это может быть опасным для краткосрочного изменения, если
требование на поддержку начинает увеличиваться снова.
После того происходят проблемы спроса, типа описанных выше, требуется
некоторое долгосрочное планирование, чтобы гарантировать, что та же самая
88 Service Desk
проблема не возникает снова или что служба поддержки готова к ним, если их
невозможно предотвратить. Это является критически важным для построения
твердой модели прогноза для определенной службы поддержки. Среди ключевых
шагов, которые следует предпринять после того, как происходит проблема со
спросом:
 Изучите и поймите то, что случилось и почему это не было включено в прогноз.
Изучите то, какие изменения в деловом цикле, сезонные изменения, или выход
нового продукта могут изменить спрос на услуги службы поддержки. Встраивание
этих обстоятельств в модель прогноза непрерывно улучшает эконометрическое
моделирование.
 Приспособьте количество сотрудников уровню спроса. Это может включать
полный перепрогноз или только изменение укомплектования персоналом. Это
может включать корректировку текущего уровни укомплектования персоналом.
 Переоцените обязательства уровня обслуживания стола обслуживания.
Является ли они все еще соответствующими и рентабельными, и не существует ли
более приемлемых альтернатив, учитывая новые данные? К изменению
обязательств обслуживания нужно относиться с большой осторожностью.
Специальные вопросы прогнозирования для больших организаций

Чрезвычайно большие организации поддержки чаще требуют более детального
прогноза, который имеет дополнительные аспекты. Например:
 Большие организации, возможно, должны предсказать будущие расширения
поддержки, продажи и возобновления контрактов поддержки или воздействия
маркетинговых действий.
 Большие организации поддержки найдут модели поддержки на основе прямой
поставки более эффективными; нормы использования естественно увеличатся,
обеспечивая больше ресурсов, доступных для поддержки.
 Поддержка на основе контракта может требовать более детального
прослеживания запроса согласно срокам контракта, который обычно содержит
фиксированное число запросов, временных интервалов на обработку запросов,
привилегий доступа, и времена ответа. Поддержка на основе платы вовлечет
контроль составления счетов. Представители клиента, которые могут собрать и/Или
проверить большую часть этой информации, могут быть необходимы, добавляя
второй уровень персонала с собственными прогнозами потребностей.
 Формальные механизмы эскалации инцидента или многоуровневая поддержка
могут потребовать специализированного укомплектования персоналом и
отдельного прогноза.
 Потребностей обучения может отличаться от таковых для маленьких служб
поддержки, а воздействие обучения штата может быть более серьезным.
 Чаще будет проявляться истощение штата; необходимо учитывать время,
потерянное в результате отсутствия и переподготовки.
Кроме того, могут оказаться полезными учебники по исследованию операций,
статьи, и книги, касающиеся теории очередей и их качественного анализа. Многие
программ MBA, колледжи, и бизнес школы предлагают курсы в этих областях.
Чистые статистические курсы анализа несколько менее полезны для прогноза, но
обеспечивают полезные знания для того, чтобы управлять статистическими и
связанными с вероятностью аспектами работы службы поддержки.
Планирование новых рабочих нагрузок

Планируя требования укомплектования персоналом службы поддержки,
чрезвычайно важно, что любые бизнес-планы, которые имеются в организации, и
которые затрагивают требования службы поддержки, принимаются во внимание.
Элементы бизнес-планов организации, которые могут затрагивать службу
поддержки, включают:
 Новые деловые потоки, возможно связанные с вербовкой новых сотрудников
для существующей или для новой деловой единицы. Любой большой приток новых
сотрудников будет иметь эффект на число запросов, сделанных в службу
поддержки, в связи с тем, что новый персонал узнает систему и инфраструктуру в
пределах компании.
 Реорганизация компании, вовлекающие увеличение или уменьшение в числе
служащих, переселение пользователей, создание новых офисов, или закрытие
старых.
 Слияния компаний и приобретения могут увеличить число пользователей,
поддерживаемых службой поддержки. Это может также потребовать слияния двух
или большего числа служб поддержки. Это почти наверняка вовлечет
необходимость поддержки дополнительных аппаратных средств и компонентов
программного обеспечения, что потребует обучение персонала службы поддержки
для поддержки этих компонентов.
 Введение новых компонентов инфраструктуры или выпуск нового программного
обеспечения. Имеются два типа воздействия на службу поддержки: сперва это
означает, что сотрудники службы поддержки должны обучиться для поддержки
новых компонентов или программного обеспечения; и далее, есть вероятность, что
число запросов, полученных службой поддержки, увеличится, поскольку клиенты
начнут использовать новые компоненты и программное обеспечение.
Все эти проблемы подчеркивают, как важно держать службу поддержки
информированной относительно любых запланированных деловых изменений.
Кроме того, важно, что деловым планировщикам сообщают о потенциальном
воздействии этих изменений на работу службу поддержки так, чтобы это могло быть
включено в оценку бизнес-плана.
Поиск сотрудников
Фактический процесс поиска новых сотрудников, который включает рекламные
объявления, проведение интервью у кандидатов, предложения работы, и так далее,
описан в SMF Управлении Рабочей силой. Однако, Стол Обслуживания SMF
должна устанавливать требования по приему новых сотрудников и разработать
план найма, работая вместе с процессами управления рабочей силы.
План Найма
Прогноз предоставляет руководству службы поддержки план относительно прямой
поставки технической поддержки. Он говорит, что, для данного продукта в
определенный день, служба поддержки будет нуждаться в определенном числе
сотрудников, которые постоянно и непосредственно связанны с решением
индивидуальных проблем клиентов. Но стол обслуживания это намного больше,
чем инженеры, обрабатывающие поступающие запросы. Типичная служба
поддержки это концентрация экспертизы: хорошо осведомленные специалисты
службы поддержки, работают с клиентами и, в свою очередь, поддерживают
сложную инфраструктуру. В то время как сотрудники отвечают на телефоны, есть
сотрудники, непосредственно не связанные с оказанием поддержки, выполняющие
другие обязанности (например, исследования, администрация и разработка
90 Service Desk
инструментов), которые поддерживают текущую деятельность. В очень больших

организациях, могут быть специализированные группы маркетинга, анализ или
отчетности, которые должны заниматься оптимизации работы службы поддержки.
Большинство аналитиков стола обслуживания также выполняет или участвует в
регулярных действиях, которые не считаются прямой поддержкой. Написанте
статей в базы знаний, например, это деятельность аналитика, которая имеет
отношение к поддержке клиента, но считается косвенной, потому что аналитик в
этом случае не занят непосредственно в решении запроса специфического клиента.
Аналитик, однако, занят в деятельности, которая помогает клиенту в дальнейшей
перспективе. Могут быть другие функции, например, разработка и производство
обучения, которые отвлекают сотрудников от прямых обязанностей поддержки в
течение долгих периодов. План найма развивается после прогноза оказания
сервиса и принимает во внимание в том числе и косвенные функции штата.
Прогноз - количественный инструмент, который использует известные или
предсказанные данные для анализа и, сам по себе, должен принимать твердые
решения по укомплектованию персонала. В действительности, однако, менеджер
стола обслуживания не может увеличить или уменьшить штат поддержки, полагаясь
только на предсказанные числа, как обсуждается в главах "Постоянный контроль" и
"Что делать, когда действительность не соответствует прогнозу". Прежде, чем
можно действовать на основании прогноза, нужно принять во внимание другие
факторы (часть которых описана в план оказания поддержки), которые затрагивают
весь коллектив службы поддержки. План укомплектования персоналом, или "плана
найма" является мостом, который берет службу поддержки из теории (прогноз) к
практике и от требований поставки до полностью функционирующей службы
поддержки.
Построение простого плана найма: Виды деятельности
Прежде чем разрабатывать план найма, нужно рассмотреть такие условия как
время косвенной поддержки сотрудников, посвященное требованиям косвенной
деятельности, а также виды косвенной поддержки, которые участвуют в работе
службы поддержки. Прямые или косвенные виды поддержки различаются по видам
деятельности. Как только все относящиеся к делу условия приняты во внимание,
можно приступить к тонкой настройке плана и, затем, представить его руководству.
Будьте готовы, однако, проводить постоянные поправки в методологии
планирования, поскольку со временем добавляется дополнительная информация,
полученная из опыта. Следующие главы рассматривают виды проблем,
рассматриваемые в разработке эффективного плана найма.
Косвенное время
Косвенные обязанности, как обсуждено ранее, являются временем, которое
сотрудниками службы поддержки тратят на действия, не связанные с поддержкой.
Некоторые из этих действий могут быть достаточно предсказуемыми, чтобы быть
включенными в прогноз, например, время каникул. Необходимо будет также
рассмотреть возможность изменяющихся норм отпусков из месяца в месяц. Чтобы
составить список косвенных обязанностей, рассмотрите следующее:
 Определите, сколько времени, в среднем, служащий использует по болезни.
Рассмотрите политику отпусков компании и определите моменты когда большая
часть сотрудников уходит в отпуск одновременно. Две - три недели отпуска, плюс
несколько национальных праздников, могут составить в целом до 10 процентов
рабочего года.
 Работайте с управлением рабочей силы и человеческими ресурсов для того,
чтобы узнать, имеются ли статистические данные по нормам отпусков сотрудников
по всей компании.
 Удостоверьтесь, что имеется информация о длительном отсутствии вследствие,

например, материнства или отпуска отцовства, гражданской обязанности,
например, работы в качестве присяжного. Добавление этой информации в план
найма экономит время и деньги.
 Рассмотрите, как долго требуется, чтобы обучить нового сотрудника.
 Определите, сколько времени сотрудник стола обслуживания проводит,
разрабатывая специальные учебные материалы.
 Определите, сколько времени аналитик стола обслуживания проводит, изучая
новые технологии, формально и неофициально.
Непрямая поддержка
Косвенная поддержка это время, проведенное сотрудниками на действия,
связанные с оказанием поддержки, но не обязательно связанное с прямым
контактом с клиентом. Далее перечислены примеры косвенной поддержки:
 Обязанности специальных координаторов обслуживания клиентов или
дежурных менеджеров, назначающих поступающие запросы обслуживания.
Возможно эта роль выполняется неполный рабочий день или разделена среди
членов команды.
 Обязанности тренеров и наставников, чтобы обеспечить поддержку на выездах,
занятых частично или полностью, чье время не включено в прогнозы.
 Прочие услуги, которые часто обеспечивают сотрудники службы поддержки:
 Написание статей в базы знаний.
 Обеспечение локальной поддержки (включая время на поездки). Это - конечно
прямая поддержка, но часто слишком непредсказуемая, чтобы быть
включенным в прогноз.
 Работа с IT отделами разработки изделия, чтобы поддержки новых
инструментов.
 Обеспечение услуг или поддержки прочим организациям поддержки или
партнерам.
Штат поддержки
Включение косвенных сотрудников в плане найма это нормальная практика. Это
позволяет организации рассматривать на регулярном основании соотношение
отношение персонала, связанного с оказанием сервисов к косвенно занятым
сотрудникам. Это предоставляет возможность определить количество, а в
некоторых случаях, и эффективности добавления позиций в косвенный персонал.
Например, в большой организации, с малой историей и некоторым хорошим
хранением записей, можно рекомендовать определенному числу авторов статей в
базах знаний работу по поддержке новые выпусков продукта или оптимизировать
оказание поддержки в течение критического периода.
Здесь также, штат поддержки может быть назначен либо на полный рабочий
службы поддержки, или на неполный рабочий день. Маленький службы поддержки
могла бы разделить учебные ресурсы компании, но организовать специальную
сфокусированную команду деловых аналитиков. Встраивание этой информации в
план найма делает ее доступным, для определений полной обремененной
стоимости поддержки в определенный момент времени в будущем.
Определившись с условиями оказания поддержки, возможно начинать строить
план. Рассмотрим в качестве примера, План Найма A, показанный в следующей
таблице. Это часть плана найма, принимающего во внимание несколько из
92 Service Desk
упомянутых выше факторов. (В планах найма, показанных ниже, FTE означает

"полностью занятый эквивалент", то есть, одного сотрудника или эквивалент двух
частично занятых сотрудников.)
Table 18 План Найма A
Некоторые факторы могут быть определены с формулой, другие более точно

определены опытным менеджером службы поддержки. Отметьте, что времена для
собранные в колонках Болезни, Отпуска, Отгулы, и Обучение составляют проценты
от суммы "Прямых" и "Косвенных" полностью занятых эквивалентов (FTEs).
Сформулированные факторы не обязательно представляют отдельных индивидов,
но время в FTEs, который требуется, чтобы выполнить данную функцию. Они
действительно переводят в людей, однако, в заключительном анализе, и кто-то, кто
пишет статьи в базы знаний, столь же вероятно, возьмет отпуск как и тот, кто
непосредственно обрабатывает прибывающие запросы.
Когда бы ни было возможно, стройте шаблон плана найма с вложенными
формулами; это упрощает будущие изменения в плане и позволяет
экспериментировать со сценариями по типу "что если".
Тонкая настройка плана найма

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

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

План найма В Необходимые FTE
Тип Продукт FTE Jul Aug Sept Oct Nov Dec
достав
ки
Прямой База Прогноз 70 75 70 72 74 69
данных
Прямой База Планируема 70 70 72 72 74 74
данных я прямая
доставка
Косвенн База Планируема 33 33 32 31 27 26
ый данных я косвенная
доставка
Все База итого 103 105 104 103 101 100
данных
План Найма B, построенный из того же самого прогноза, как и План Найма A,

принимает во внимание постоянную интенсивность расходования ресурсов,
уравновешенную устойчивой нормой найма, за исключением августа и ноября,
когда деятельность по наему интенсифицируется. Этотплан более пригоден к
употреблению, так как не требует или не предполагает, что полностью занятые
служащие покинут службу поддержки. Отметьте, что косвенный штат меньше в
августе и выше в сентябре чем в Плана Найма А, благодаря их расчетной
зависимости от числа FTE прямой поставки. Самые существенные статистические
данные Плана Найма B суммированы ниже:
 Средняя предсказанная поставка (FTE) = 72
 Средняя запланированная поставка (FTE) = 72
 Средняя косвенная и непоставка (FTE) = 30
 Полные требования поддержки = 103
Table 20. План Найма С

План найма С Требуемые FTE
Тип Продукт FTE Jul Aug Sept Oct Nov Dec
достав Breakout
ки
Прямой База прогноз 70 75 70 72 74 69
94 Service Desk
данных
Прямой База Планируема 70 72 71 71 73 72
данных я прямая
доставка
Косвенн База Планируема 33 33 32 30 27 25
ый данных я косвенная
доставка
Все База Total 103 105 103 101 100 97
данных Support
Requirement
Плана Найма C также характеризуется постоянной интенсивностью расходования

ресурсов, но с меньшим количеством противодействующего найма чем в Плана
Найма B, позволяя службе поддержки быть немного неукомплектованнойв течение
трех месяцев.
Внизу - самая существенная статистика План Найма C:
 Средняя предсказанная поставка FTEs = 72
 Средняя запланированная поставка FTEs = 72
 Средняя косвенная и непоставка FTEs = 30
 Средние требование поддержки = 101
Оба плана найма предлагают очень агрессивный наем на август и предполагают,

что истощение, уравновешенное с деятельностью по найму, произведет
желательное уменьшение в укомплектовании персоналом в конце года. Второй
пример предлагает менее расходов за шестимесячный период, но немного больший
риск неудовлетворенности клиентов из-за пониженных уровней обслуживания на
более длинном промежутке времени. Отметьте, однако, что оба плана
поддерживают средний штат поставки 72. Если январь будет опять нормальным, то
исходя из средних 103 полностью занятых сотрудников, потребуется нанимать и
обучать меньше людей, в соответствии с Планом B. К январю, План B может
фактически оказаться более рентабельной моделью.
Если стол обслуживания укомплектован полностью или частично временными
сотрудниками или использует услуги аутсорсера, планировщик найма имеет еще
два фактора в его или её распоряжении, чтобы помочь сгладить пики и долины,
вызванные новыми выпусками продукта и зрелым знанием продукта. Имейте в
виду, однако, что контракты с аутсорсерами могут быть основанными на
минимальном числе запросов в день, требуя планировщика найма правильной
расстановки приоритетов.
Внизу перечислены другие факторы, которые надо иметь в виду, планируя
привлечение временных сотрудников или услуг аутсорсеров:
 Кто ответственен за обучение? Можно ли получить доступ к заранее обученной
рабочей силе.
 Как поступать если временный сотрудник болеет или выходит в отпуск, а
полностью обученная замена отсутствует. Вероятно, не будет практично заменить
временного сотрудника в случае краткосрочной болезни или каникул.
 Если используется смесь постоянного и временного штата, выполнит ли
частично занятый штат те же самые косвенные услуги, как и постоянные
служащие? Наоборот, можно нанять временный штат специально для того, чтобы
покрыть некоторые из косвенных (и непоследовательных) услуг?
В заключении рассмотрим хороший способ тонкой настройки плана найма,
называемый передней погрузкой. Передняя погрузка относится практике перемены
чисел плана найма перед прогнозом на два - три месяца, чтобы принимать во
внимание аналитиков, которые еще полностью не обучены. Если прогноз не
регулирует длину решения запроса, чтобы принять во внимание новых, еще не
полностью обученных, служащих, необходимо отразить это явление в плане найма.
Это время, которое требуется, чтобы определить позицию, найти кандидатов,
нанять новичка, и, затем, обучать его в сложной технической среде. Это дает более
точную картину того, на что организация должна быть похожа в режиме реального
времени. Для маленьких организаций, это, возможно, не нужно. Для больших
организаций, или организации, которые используют план найма для проведения
анализа затрат или финансовое планирование бюджета, эта практика, очень
полезна.
Следующая таблица показывает пример передней погрузки.
Table 21. Hiring Plan D
В этом передне-нагруженном плане, среднее FTE прямой поставки будет выше, чем
предсказанное среднее число. Полное требование поддержки выше, чем в Планах
B и C, потому что в январе, и феврале потребуется увеличенная поддержка.
Ежемесячный анализ затрат, основанный на этом плане будет значительно
отличаться от предыдущих примеров.
План найма как проверка предположений

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

информация не является количественной, посмотрите на работу других групп
решения, чтобы видеть, хорошо ли они работают с меньшим уровнем косвенной
поддержкой. Это хорошая идея, чтобы отследить эту и прочую статистику плана
найма, чтобы создать точку отсчета, против которой могут быть сделаны будущие
суждения.
Консультируйтесь с управлением рабочей силы и человеческими отделами
ресурсов, чтобы определить, имеются ли квалифицированные кандидаты на месте,
или они должны быть приняты на работу национально. В процессе, можно
обнаружить, что отдел кадров, возможно, не в состоянии удовлетворить
потребностям найма. Если оказывается, что можно нанять только двух - четырех
служащих в месяц в местном масштабе, и если Вы не имеете возможности
пополнения за пределами данной области, то следует рассмотреть обучение
неопытных людей, нанятых в местном масштабе. Это увеличивает требования
фронтальной загрузки. Можно также выбрать плана найма, в котором условие
неукомплектованности заложено как предположение вместе с фронтальной
загрузкой, как предложено в обсуждении Плана Найма D выше.
Если план найма состоит в том, чтобы использоваться как инструмент чтобы судить
о работу организации, то есть, для того, чтобы сравнить "план" с "фактическим"
состоянием дел, то тогда части плана найма являются более критическими чем
другие. Менеджер команды, который имеет годы опыта с новыми релизами
продукта, может не согласиться с прогнозом и просить дополнительный штат
поставки. Если этот менеджер ответственен за удовлетворение клиента и затраты,
опыт менеджера нужно тщательно рассмотреть.
Очевидное соображение для планировщика найма состоит в том, имеет ли
компания место, чтобы приспособиться к росту. В противном случае этот фактор
должен быть встроен в план в самом начале, чтобы не устанавливать ложные
ожидания для других, вовлеченных в процесс плана найма.
Убедитесь, что план найма не находится в противоречии с полным видением
компании. Не может случиться так, что старшее руководство ожидает, что размер
компании выровняется или уменьшится, в то время как план найма относительно
стола обслуживания следует за образцом роста?
Если план найма проходит проверку действительностью, его можно использовать в
нескольких частях компании.
План найма как инструмент
План наема должен быть надежным инструментом для многих видов анализа
затрат: по продуктам, группе решения, FTE, месту действия, типу поставки, и так
далее. Это также полезно для анализа роста, планирования пространства, и
планирования обучения. Эти различные функции требуют, чтобы данные были
показаны в различных конфигурациях. Команды, которые специализируются в
различных продуктах, могут требовать более или менее обучающегося времени,
чем их коллеги, что может быть отражены в плане найма, в той части, которая
обеспечивает детали на уровне продукта. Команды, которые выполняют различные
услуги, например, команда, принимающая запросы, против команды эскалации -
будут иметь различные учебные требования и различные обязанности поставки,
которые обнаружились бы ясно в плане найма, детализированном по типу
обслуживания.
Перед развитием шаблона плана найма, подумайте, какое ожидается
представление данных. Будет ли менеджер средств обслуживания нуждаться в той
же самой информации как менеджеры команды службы поддержки? Менеджер
средств обслуживания интересуется тем, кто займет какое место. Менеджер

команды хочет знать, сколько ресурсов может быть применено к определенной
доле продуктов или клиентской базе. Какую информацию нужно обеспечить для
старшего руководства или менеджеру человеческих ресурсов?
План найма - инструмент с потенциалом большой гибкости. Он может
использоваться для того, чтобы проиграть "что, если" сценарии во время
планирования бюджета. Гибкость, однако, может также быть и проблемой. Чем
более интенсивно план найма будет использоваться для того, чтобы определить
цели организации службы поддержки по укомплектованию персоналом, затрат,
планирования пространства, и обучения, тем более тщательно надо определить
элементы, отраженные в плане. Поскольку служба поддержки это центральная
часть организации, затрагивая много других частей, многие сотрудники смогут
использовать план как фонд для их собственного организационного планирования.
Осторожные определения становятся бессмысленными, а широко
распространенная зависимость от плана, становится реальной проблемой, в случае
если план часто меняется часто после того, как одобрен. Определите политику
или, еще лучше, определите контроль изменения и политику коммуникаций для
этого плана заранее, так, что если изменения необходимы, их выполнением можно
было бы управлять. Если важен анализ, нужно спланировать стандартное число
пересмотров, которыми управляют, ежегодно, основанное на способности
предсказать ожидаемые выпуски продукта, изменения в политике поддержки, и так
далее. Если план будет пересматриваться всякий раз, как это покажется
необходимым, то план перестанет быть эффективный инструментом для измерения
и, даже в этом случае, изменения все еще должны быть переданы всем
заинтересованным лицам.
Если установлен процесс контроля над изменениями, то в нем должны быть
определены основания для изменений, о чем можно договариваться, а о чем нет,
после того как что-то одобрено, и кто имеет полномочия отвергнуть план. Общее
понимание требований для изменений уменьшит число изменений, сделанных по
неправильным причинам. Нельзя сказать, что план найма может, или должен
исполняться с точностью до буквы. Политики управления устанавливается вовсе на
для того, чтобы поместить организацию в смирительную рубашку; скорее это
должно помочь в использовании плана найма в качестве точки отсчета для
принятия решений.
Определяя план, продумайте, как и кем он будет использоваться. Все эти факторы
вносят свой вклад в проект и уровень гибкости окончательного плана найма.
Оптимизация навыков персонала

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

обслуживания, который в случае необходимости, получает необходимую
техническую подготовку.
Основные навыки службы поддержки

Детали обязанностей каждого из сотрудников службы поддержки описаны в главе
Ролях и Обязанностей данного документа. Для того чтобы достичь даже самого
базового уровня обслуживания, необходим минимальный набор личные навыков
персонала.
Профессионал службы поддержки должен обладать многими существенными
навыками соответствующим образом мышления. Некоторые из навыков и
признаков, которые должен иметь сотрудник службы поддержки, перечислены в
следующей таблице.
Table 22. Навыки сотрудников службы поддержки
Навык Описание
Коммуникации Способность выражать мысли и идеи способом, который
является легким для понимания, использовать язык и термины,
которые являются соответствующими для уровня опыта и
экспертизы клиентов. Могут потребоваться многоязычные
навыки. Способность предоставлять другим информацию, в
которой они нуждаются для выполнения своей работы, ясно и
кратко. Методический подход к решению проблем.
Самообладан Способность оставаться спокойным под давлением, без цинизма,
ие капризов, или враждебности в трудных ситуациях. Способность
эффективно справляться с напряжением, изменениями, риском, и
неуверенностью. Способность выполнять несколько задач
одновременно в быстро изменяющейся окружающей среде и
оставаться терпимым к другим, даже в случае провокаций.
Сочувствие Подлинное беспокойство о потребностях и благосостоянии
клиентов. Понимание делового воздействия проблем, о которых
говорит клиент. Способность хорошо слушать других людей и
смотреть на вещи с их точки зрения. Способность обеспечивать
эмоциональную и вербальную поддержку людям, имеющим
проблемы или трудности.
Прямота Готовность сообщать "плохие" новости так же, как и "хорошие".
Способность оставаться честным, даже в том случае, когда
другие могут быть расстроенными или разочарованными, а так же
способность обозначать свои намерения ясно и так, чтобы другие
знали точно, что ожидать.
Любезность Быстро отвечать в ответ на просьбы об информации или помощи.
Получать удовольствие поиска неисправностей и решения
проблем. Выполнение обязательств, даже если это занимает
больше времени или оказывается более трудным, чем
ожидалось. Доступная и легкая манера разговаривать, любезное
и понимающее обращение с другими.
Гибкость Способность и готовность быстро приспосабливаться к
изменениям. Открытость к новым и разным способам делать дела
и способность быстро менять приоритеты в меняющихся
Навык Описание
обстоятельствах.
Лояльность Всегда говорить хорошо о компании, команде, и других членах
команды. Составление благоприятного образа компании или
команды на публике, обеспечение более высокого приоритета
команде и целям компании, чем индивидуальные целям.
Страсть к Реальная страсть к компьютерной технологии и удовольствию
технологиям выяснения того, как вещи работают. Любовь к чтению технических
периодических изданий и публикаций и подлинного интереса от
пребывания на первом ряду последних и самых новых
технологий.
Желание Изобретательность и способность учиться под многими углами.
приобретать
новые знания
Оценивать знания и способности гораздо сложнее, чем навыки, однако

рассмотрение обоих качеств приводит к найму лучшего сотрудника. Навыки
приобретаются, этому можно научиться. В том темпе, в котором изменяется
технология, поддержанная службой поддержки, навыки и знания, с которыми
сотрудник приходит, вероятно, станут устаревшими за следующие два года.
Личные навыки развиваются, а не преподаются. Личные навыки штата стола
обслуживания могут быть развиты, обеспечивая обучение в таких областях как:
 Общая коммуникабельность.
 Телефонные методы.
 Письменные методы (письмо, электронная почта).
 Активное слушание и опрос.
 Управление стрессом и жалобами.
Культура сервиса
Использование и построение основных умений и навыков, требуемых для
сотрудника службы поддержки, приводят к развитию культуры обслуживания в
пределах коллектива службы поддержки.
Менеджер службы поддержки должен гарантировать, что сотрудники службы
работают как команда. Взаимодействие является критическим для успеха службы
поддержки. Команда службы должна быть сосредоточена на клиенте, понимать и
признавать что:
 Проблема клиента затрагивает бизнес.
 Без клиента, нет никакого службы поддержки.
 Клиент - эксперт в его или её собственной области.
Команда должна проецировать последовательный профессиональный образ
службы поддержки своим клиентам. Это помогает развивать доверие клиентов и
веру в возможности службы, которые улучшают клиентское восприятие и приводят к
более выгодным отношениям.
Команда службы поддержки должна принять на себя проблемы их клиентов и
рассмотреть проблемы клиентов так, как будто это их собственные проблемы.
100 Service Desk
Необходимо постоянно информировать клиентов относительно всего продвижения

с их проблемами. Это ясно демонстрирует, что проблемы клиентов важны для
службы поддержки, независимо от их простоты или сложности, служба поддержки
должна здесь помочь.
Персонал службы поддержки находится в наилучшем положении, чтобы
проанализировать или исправить процессы и процедуры службы поддержки.
Необходимо поощрять обратную связь о способах, в результате которых можно
улучшить обслуживание клиентов службы поддержки.
Технические навыки
Технические навыки, требуемые штатом службы поддержки, могут быть
определены, исходя из:
 Типов вопросов, задаваемых пользователями.
 Приложений и поддерживаемого оборудования.
 Уровня экспертизы поддерживаемого пользовательского сообщества.
 Уровня обслуживания, предлагаемого службой поддержки. Если сфера
деятельности службы поддержки ограничена простой регистрацией запросов и
передачей их в соответствующие группы решения, то сотрудники службы
поддержки не нуждаются во всесторонних технических знаниях. Если, с другой
стороны, цель службы поддержки состоит в том, чтобы решить большую часть
проблем при первом запросе, то штат службы поддержки будет требовать
значительных технических навыков.
Технические навыки могут быть приобретены сотрудниками службы поддержки
множеством способов. Самый очевидный метод, это посещение формальных
учебных курсов. Помимо улучшения навыков сотрудников службы поддержки, это
также вносит свой вклад в удовлетворение персонала, так как показывает
готовность вложить капитал в штат. Если нет возможности послать всех
сотрудников службы поддержки на курсы, либо из-за ограничений бюджета, либо
из-за проблем, связанных с отсутствием сотрудников, отдельных людей можно
было бы отправить на обучение и, затем, попросить передать наиболее важные
моменты учебного курса другим сотрудникам. Достижение профессиональных
квалификаций через обучение и экспертизы выгодно не только для личного
развития сотрудников, но также и для восприятия службы поддержки в глазах
клиентов. В случае если службы поддержки может обнародовать квалификации,
полученные ее сотрудниками, это, вероятно, увеличит веру клиентов и уважение к
службе поддержки.
Обучение по месту работы это способ передать навыки через практику, а не через
учебные курсы. Отправляя сотрудника службы поддержки в команду поддержки или
другой отдел на некоторое время, позволят узнать о технических проблемах и о
том, как эти проблемы решаются в контексте организации. Обучение по месту
работы также работает в противоположном направлении – там, где штат поддержки
или персонал компании работают вместе, можно удовлетворить одновременно
двум целям. Во-первых, определенные навыки служащих могут быть переданы
другим сотрудникам службы поддержки. Во-вторых, служащие видят, как работает
службы поддержки так, чтобы, когда они возвращаются к их регулярным рабочим
местам, они лучше понимают процессы и проблемы службы поддержки. Этот опыт
также уменьшит разделение на "нас и их" и улучшит коммуникации и отношения
между службой поддержки и другими единицами.
Наставничество может использоваться для того, чтобы передать навыки в пределах
службы поддержки. Опытного сотрудника службы поддержки или тех из них, с
определенными техническими навыками, можно попросить поработать

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

Проектируя или анализируя физическое рабочее пространства для работы службы
поддержки, учитывайте все необходимые регулирующие или законодательные
требования. Во многих странах/областях, особенно в пределах Европы, есть
законы, управляющие эргономическими требованиями рабочих мест, здоровья и
мер по обеспечению безопасности, которые должны быть приняты во внимание.
Физическое и логическое расположение рабочего пространства службы поддержки
зависит от возможностей услуг, которые будут обеспечиваться.
Рассматривая местоположение службы поддержки, проверьте надежный доступ к
электроэнергии, сетям связи и так далее. Требования к телефону и к оборудованию
могут потребовать дополнительного места для проводки и распределительных
щитов. Если функции службы поддержки включают испытания или наличие
диагностического оборудования, тщательно исследуйте меры для контроля
климата, чтобы минимизировать время простоя аппаратных средств.
Для маленькой организации, рассмотрите формирование сильно связанной
команды аналитиков службы поддержки, столы, кабины, или автоматизированные
рабочие места которых, физически расположены близко друг к другу. Такая
договоренность может экономить ценное время в течение сессий по разрешению
проблем, технических брифингов команды, и эскалации инцидента. В больших
организациях, может быть необходимо предусмотреть избыточную конфигурацию,
которая минимизирует избыточную деятельность и максимизирует распространение
Исследуйте, как организованно пространство для индивидуальных сотрудников
службы поддержки. Удостоверьтесь, что выбранного места достаточно для того,
чтобы разместить всё оборудование службы поддержки. Это может включать
автоматизированное рабочее место для каждого из сотрудников, дисплеи
отображения статуса, чтобы контролировать прохождение запроса, а так же
102 Service Desk
области с контролирующим оборудованием. Выбранная структура зависит от

характера предоставленных услуг.
Многие группы решения знают, что хорошо происходит работа в высокой,
окруженной стеной трехсторонней кабине так, что открытая сторона кабины
находится перед общей областью. Высокие стены приглушает звук и обеспечивает
место, где можно сделать много полок, необходимых для книг и обучающего
материала. Открытая общая область обеспечивает форум для взаимодействия
группы, позволяя аналитикам службы поддержки сидеть в их кабинах и все еще
говорить с каждым в коллективе. Эта физическая договоренность продвигает
открытое обсуждение проблем и может быть существенным элементом развития
навыков и построения команды.
Другие варианты для рассмотрения включают общую область с рабочим столом,
шкафами для хранения вещей, и комнатой для того, чтобы хранить
вспомогательные материалы. Сотрудники службы поддержки, вероятно, нуждается
в доступе к копировальному устройству, факсу, и принтеру. Подумайте о
приобретении маленькой доски для записей в каждой кабине и большой, в общей
области для использования в течение встреч и для того, чтобы объявить важную
информацию.
Обустраивая физическое пространство, убедитесь, что все проблемы доступа
приняты во внимание. В то время как для команды службы поддержки важно
находиться в открытой окружающей среде, чтобы облегчить разделение
информации, это же является и важнейшим фактором отвлечения. С другой
стороны, если служба поддержки обеспечивает поддержку для посетителей, то
обеспечение свободного прохода становится особенно важным. Важно, однако, что
бы только те сотрудники, которые назначены для выполнения этой функции были
доступными для посетителей, чтобы гарантировать, что персонал службы
поддержки, занятый на других темах, не затронут несоответствующим запросами.
Более того, ресурсы команды, аппаратные средства и программное обеспечение,
должны были управлять доступом так, чтобы предотвратить воровство или неудачи,
затрагивающие одного клиента или всю организацию. Ресурсы аппаратных средств
включают такие пункты как:
 Запасные части: Дисководы, жесткие диски, видео карты, мониторы, карты
интерфейса сети, запасные системные платы, и так далее.
 Расходные материалы: Дискеты, сетевые кабели, соединители, кабели,
расходные материалы для печати, и так далее.
 Испытательное оборудование: метры Ома, испытатели тока, и так далее.
Ресурсы программного обеспечения, которые должны управлять доступом, могут
включать:
 Диагностика: Жесткий диск, центральный процессор и система, карта сети,
видео карта и монитор, и так далее.
 Контроль и управление: Сервер, устройства сети (мосты, выключатели,
маршрутизаторы), и так далее.
Оптимизация технологии
Технология, используемая службой поддержки, зависит в большой степени от видов
предоставленных услуг. Независимо от того, какие технологии используются, важно
периодически пересматривать технологии, чтобы гарантировать, что они
продолжают соответствовать требованиям службы поддержки.
Телефонная система
Возможно самой важной часть технологии, используемой службой поддержки
является телефонная система. Это первое средство свзи клиентов с службой
поддержки.
В очень маленькой организации, требования к телефонной могут быть не более
сложными чем то, что можно получить от стандартной телефонной компании с
системой PABX. Скорее всего, однако, что требования службы поддержки будут
значительно превышать средства обслуживания, обеспечиваемые такой системой.
Особенности и конфигурация телефонной системы должны быть проверены так,
чтобы гарантировать, что все компоненты отвечают требованиям бизнеса (который,
возможно, уже изменился с тех пор, как система была первоначально установлена)
и определить, можно ли использовать какие-нибудь не использованные в
настоящее время возможности применяться в связи с назревающими функциями
службы поддержки. Среди моментов, нуждающихся в рассмотрении, упомянем:
 Достаточно ли линий подведено в службу поддержки, чтобы избежать ситуацию
когда клиенты получают сигнал занято, когда они звонят? Объем ожидаемых
запросов может сильно варьироваться в течение времени. Система должна быть
способной к обработке пиков поступающих запросов, если конечно не принято
политическое решение, позволяющее выдать клиенту сигнал "занято".
 Используются ли автоматические средства обслуживания, такие как
автоответчики, позволяющие выдать клиентам записанное сообщение, а не
звонящий сигнал? Это средство может использоваться для сообщений статуса
обслуживания, которые могут удовлетворить требования вызывающего прежде, чем
его или её запрос дойдет до сотрудника службы поддержки.
 Используется ли голосовая диалоговая служба (IVR) и автоматическое
распределение запросов (ACD)? Если используются, используются ли эффективно?
Помните, что эти средства обслуживания не должны создавать барьер между
клиентами и службой поддержки. Также имейте в виду, что эти возможности,
возможно, не могут быть использованы в некоторых областях по культурным
соображениям, так что их использование может отговорить людей обращаться в
службу поддержки.
 Действительно ли используются средства управления очередями?
 Используются ли службы наблюдения и контроля в телефонной системе для
того, чтобы идентифицировать какие-нибудь проблемы касающиеся частоты
прибытия запросов, времени обработки, живого отклика, и так далее?
Стандартная офисная технология

Любая службы поддержки требует некоторое стандартное оборудования для офиса.
По минимуму потребуется:
 Настольный компьютер с выходом в сеть для поддержки инструментов службы.
 Доступ к электронной почте.
 Доступ к принтеру.
Сотрудники могут также требовать доступа к Интернету, в том случае если

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

гарантировать, что оборудование офиса остается современным и соответствующим
задаче.
Средства диагностики и тестирования

Как часть исследования и диагноза проблемы клиента, может потребоваться
использовать некоторое диагностическое оборудование или попытаться
воспроизвести проблему в службе поддержки.
Для воспроизводства проблем клиента, главным соображением является то,
насколько ли оборудование службы поддержки подобно оборудованию
пользователя.
В зависимости от разнообразия используемых аппаратных средств, может
оказаться очень трудно гарантировать, что служба поддержки имеет компьютер,
подобный компьютеру каждого пользователя. Организационная стандартизация
связанных с компьютером закупок могла по крайней мере упростить ситуацию.
Лучшее решение состоит в том, чтобы договориться иметь по крайней мере
представительный набор аппаратных средств:
 Поддержанные платформы аппаратных средств: Макинтош, Альфа, Интел, PPC, и так далее.
 Требуемые типы центрального процессора.
 Количество RAM, необходимой для каждого компьютера: Наибольшая операционная система

и приложения, которые являются ключевыми к определения этого.
 Жесткие диски, типы и размер: Множественнык операционные системы с отдельной

загрузкой.
 Различные контроллеры.
 Кассетные накопители.
 Дисководы для компакт-дисков.
 Разные устройства, например средства бэкапа, питания, и так далее.
Еще больше усложняет проблему необходимость решить, какое программное

обеспечение должно быть установлено на компьютерах службы поддержки.
Различные пользователи могут использовать абсолютно различное программное
обеспечение. В дополнение к разнообразию коммерческих используемых
продуктов, пользователи могут управлять некоторыми программами, которые были
разработанны внутри компании. Если служба поддержки отвечает за поддержание
программного обеспечения, то необходимо чтобы члужба поддержки имеет доступ к
копиям каждой программы. Внизу некоторые необходимые соображения:
 Операционная система: можно использовать утилиты для множественной
загрузки.
 Сетевые операционные системы и протоколы: могут оказаться полезными
системы загрузки из меню.
 Установленные приложения.
 Приложения, установленные на сервере или на местном пользовательском
компьютере.
 Используемые файловые системы: например, [FAT].
 Требуемые инструменты программного обеспечения: Например, утилиты
ремонта диска, диагностика аппаратных средств.
 средства распространения: Например, дискета, компакт-диск, установка через

сеть.
 Большинство компаний также имеет сети, связывающие ее компьютерное
оборудованием. Поддержка сетей также относится к ответственности службы
поддержки, анализ которой включает следующие соображения:
 Тип карты сети
 Кабели
 Число и длина кабелей сети
 Стандарты топологии
 Стандарт на сетевую операционную систему
 Стандарты протокола
 Организация сети программного обеспечения
 Средства наблюдения за сетью
 Контроль необходимых инструментов, например Сервера Системы Управления
Microsoft.
В дополнение к основному оборудованию, необходимому для службы поддержки,
полезно собрать набор горячих запчастей обычно используемых дисководов,
видео карт, и других внутренних компонентов, которые будут сохранены в чулане
стола обслуживания. (Горячая запчасть это деталь, которая, как известно, работает,
и это может использоваться, чтобы быстро заменить работающий со сбоями
компонент) Это особенно важно для службы поддержки, которая обеспечивают
поддержку аппаратных средств, но также важно и для того, чтобы проверить
проблемы программного обеспечения. Чулан должен быть недалеко службы
поддержки и, для уменьшения риска воровства, должен иметь запираемую дверь.
Поскольку служба поддержки, возможно, нуждается в доступе к аппаратным
средствам и программному обеспечению всех типов и во всех обычно
используемых конфигурациях, часто удобно собрать все это оборудование на
испытательном стенде в лаборатории. Размер службы поддержки (и, собственно,
организации) определяет количество необходимого оборудования и требований
площади для размещения этого оборудование.
Для меньших организаций, где используется лишь небольшой набор оборудования,
"лаборатория" может быть централизована или рассеяна всюду по
производственным помещениям, в зависимости от структуры групп решения и
продуктов, которые они поддерживают.
Технические ресурсы
Персонал службы поддержки нуждается в доступе к последним техническим
ссылочным материалам, включая книги, копии программного обеспечения,
документации, и технических учебных материалов. Если компания не может
позволить себе специальных сотрудников для библиотеки, некоторые из наименее
используемых или более дорогих материалов могут быть сохранены в общей
области, одновременно с покупкой часто используемых материалов для каждого из
аналитиков службы поддержки.
В зависимости от широты и глубины поддержки, требований службы поддержки,
ссылочные материалы могут покрывать такие темы как:
 Компьютерные аппаратные средства и периферия: системы, дисководы,
принтеры, видео устройства, и так далее.
106 Service Desk
 Поиск неисправностей: аппаратные средства, операционная система, сеть,

заявления.
 Устройства сети и аппаратные средства: сетевые адаптеры, центры, мосты,
выключатели, маршрутизаторы, кабели, стандарты.
 Протоколы сети: поставляемые продавцом или третьими лицами для каждого
поддержанного протокола.
 Поиск неисправностей сети: для сетевых ОС, протокола, и вообще.
 Моделирование сети и планирование.
 Управление сети: утилиты, теория, и заявление.
 Операционные системы, включая руководства.
 Приложения и утилиты.
Много важной информации может быть доступно на компакт-дисках, поэтому важно
обеспечить непосредственный доступ к такой информации ля каждого сотрудника
Если определенные компакт-диски часто используются различными сотрудниками,
работающими в службе поддержки, закупка и использование музыкального
автомата CD-ROM может быть лучшей инвестицией, чем покупка многих
индивидуальных копий. Сервер CD-ROM может обеспечить доступ к его
содержанию для каждого участника местной сети, причем для многих инструментов
и программ можно получить сетевые лицензии.
Обеспечьте, что каждое хранилище материалов имеет систему контроля для того,
чтобы отслеживать цели использования и ограничивает отрезок времени, в течение
которого собрание остается вне библиотеки и недоступно для других.
Программные инструменты
Обычно, средства программного обеспечения для службы поддержки
определяются и обеспечиваются на стадии первичного наполнения службы
поддержки. Однако, в случае если служба поддержки развилась из других функций
поддержки, или ее возможности увеличились по мере роста бизнеса организации
или охвата дополнительных бизнес-областей, может возникнуть требование
разработать дополнительные средства программного обеспечения в существующей
среде службы поддержки.
Случается, что инструмент, купленный во время формирования службы поддержки,
перестал соответствовать требованиям службы поддержки и должен быть заменен.
(Спецификации требований для инструментов программного обеспечения и их
оценки, приобретения, и внедрения не раскрыты в этом документе).
Оптимизация существующих инструментов программного обеспечения использует
следующие соображения:
 Инструмент имеет необходимые функциональные возможности для текущих и
предсказанных потребностей стола обслуживания.
 Инструмент имеет достаточную способность для поддержания текущих и
предсказанных требований службы поддержки. Сюда входят требования на
размеры базы данных, пропускной способности, времен ответа, и других критериев
качества работы. Еще одним ограничением выступает число пользовательских
лицензий, которые были куплены для его использования.
 Имеется ли адекватная доступная поддержка, либо внутри компании, или от
поставщика?
 Имеет ли инструмент адекватные интерфейсы для других инструментов,

используемых в пределах организации? Например, интерфейсы к управлению
изменения или инструментам управления проблемами.
 Используется ли инструмент правильно штатом службы поддержки? Знают ли
они и используют ли все необходимые возможности инструмента? Обучен ли штат
службы поддержки в использовании инструмента?
Важно, чтобы люди, ответственные за управление и развитие функций службы
поддержки знали о событиях в области инструментов службы поддержки. Этого
можно достичь, читая промышленные журналы и информационные бюллетени,
посещая конференции, выставки, семинары, и симпозиумы, а так же через
членство в пользовательских группах и других организациях.
Пересмотр и оптимизация контроля и отчетности

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

Ответственный за процессы службы поддержки должен переодически
пересматривать мониторинг проводимых операций и производимые отчеты.
Исходя из предположения, что лучше иметь больше информации, чем меньше,
зачастую возникает тендеция измерять все, что только возможно измерять и
заносить результаты в детальные отчеты, независимо от степени полезности этой
На практике, если собирается слишком много информации, действительно важные
данные обычно теряются, с последующим риском того, что важные проблеиы не
удается идентифицировать и вовремя разрешить.
Поэтому важно гарантировать, что необходимая информация достигаетнужных
людей. Вопросы о том, что нуждается в контроле и кто должен получать эту
информацию, обсуждены ранее в этом документе в разделах Осуществление
Контроля Подготовка отчетности. Чтобы оптимизировать эти процессы, необходимо
ответить на следующие вопросы:
 Контролируется ли важнейшая информация? Важно контролировать
информацию, которая является полезной. В случае, если интерес в определенной
информации отсутствует, отмените контролирующий запрос. Если, однако, Вы не
отслеживаете определенную необходимую информацию, включите ее в
контрольный процесс. Получите обратную связь относительно того, какую
информацию считают полезной, а какую нет, какая дополнительная информация
была бы полезной, и так далее.
 Спросите клиентов, адекватны ли отчеты о предоставляемых услугах. Спросите
старшее руководство, обеспечивает ли информация, которую они получают, ясное
представление об информации, которую они требуют, например затраты на
использование штата, удовлетворения клиентов, и так далее.
 Спросите персонал службы поддержки, какого типа информацию спрашивают у
них вызывающие клиенты. Этот тип информации должен быть включен в контроль
постоянного клиента и сообщение. Кроме того, спросите персонал службы
поддержки, если они получают достаточную информацию об их собственной
работе, в том числе и о работе службы поддержки в целом.
 Остаются ли ключевые индикаторы работы (KPIs) все еще адекватными
способами контроля, или необходимо использовать другие индикаторы работы? KPI
108 Service Desk
это выработанные резюме, которые указывают на адекватность работы процессов

службы поддержки и могли бы использоваться дальнейшего обнаружения
потенциальных проблем. Старшее руководство рассматривает KPIs и действует на
основании полученной информации. KPI только в том случае полезны, если они
объективны и являются однозначной и точно вычисляемой мерой. Гарантируйте,
что KPI не манипулируются так, чтобы представить службу поддержки в наилучшем
свете.
 Правильна ли выбранная частота контроля? Например, подсчет числа
запросов, полученных за день полезен, но более полезным мог бы оказаться
подсчет числа запросов в другие интервалы времени, например,
продолжительностями в десять минут.
 Правильно детализирована представленная информация? Проверьте, что
уровень деталей является соответствующим для каждого из проверяемого
компонента.
 Правильна ли частота отчетов? Некоторые отчеты требуются на ежедневном
(или на еще более частом) основании; однако, другие могут требоваться каждый
месяц, квартал, год.
 Действительно ли контрольная информация, распределяемая среди
правильной аудитории? Часто хочется послать все и всем, так что в итоге от
большую часть разосланных сообщений игнорируют еще до того, как читают.
 Представлена ли информация в правильном формате? Стоит ли рассылать
большие объемы детализированной информации с простым резюме? Или лучше
представить информацию в виде таблиц, диаграмм, рисунков и так далее?
 Правильно ли выбран метод рассылки? Стоит ли рассылать печатные версии
отчетов, в то время как можно отправить отчеты по электронной почте или
разместить в локальной сети?
Требования для программ сертификации

Ранее в этом руководстве уже обсуждался вопрос сертификации службы
поддержки. Требования оптимизации контроля и отчетности службы поддержки
тесно связаны с требованиями любой программы сертификации.
Программа сертификации едва ли сводится к однократной подаче необходимой
информации в агентство сертификации. Более вероятно, что придется предъявить
свидетельство работы службы поддержки в течение расширенного периода
времени так, чтобы можно было выявить тенденции.
Получите обратную связь от агентства сертификации на счет конкретной
информации для участия в программе, уровня деталей, частоты контроля и
отчетности и способов отправки отчетов.
5
Роли и ответственность
MOF определяет основные роли и связанные с ними обязанности для службы
поддержки, в соответствии с лучшим методы промышленными методами
организации. Однако, некоторые организации, возможно, должны объединить
некоторые роли в зависимости от размера организации, структуры и основных
соглашений уровня обслуживания, существующих между отделом IT и бизнесом.

Важно помнить, что речь идет об описании ролей, а не позиций.
Процессы службы поддержки должны выполнять следующие роли:
 Менеджер стола обслуживания
 Аналитик стола обслуживания
Менеджер службы поддержки

Роль менеджера службы поддержки является критической, потому контролирует
задачи, связанные с ежедневной работой стола обслуживания, непрерывное
развитие функции службы и разрешение проблем. Эти задачи описаны ниже:
 Управление ежедневными действиями:
 Управление персоналом.
 Создание штатного расписания.
 Управление аналитиками службы поддержки.
 Оценка работы сотрудников.
 Создание и поддержание планов подготовки сотрудников.
 Пополнение персонала.
 Обеспечение совета и руководства клиентам и аналитикам службы
поддержки.
 Выработка управляющей отчетности.
 Представление службы поддержки, на встречах в качестве представителя
 Поддержание процессов, используемых в пределах службы поддержки.
 Развитие новых функций и процессов:
 Создание культуры обслуживания в пределах службы поддержки.
 Проведение компаний для разъяснения работы службы поддержки и услуг,
которые она обеспечивает.
 Развитие процессов и согласование интерфейсов с другими SMF.
 Посредничество между процессами управления инцидентами и проблемами
относительно любых изменений в коде систем.
 Планирование новых услуг и рабочих нагрузок.
 Информационное обеспечение переговоры о SLA и обзоры.
 Работа с другими SMF, чтобы гарантировать пригодность и непрерывность
функции службы поддержки.
 Работа с управлением ресурсами, чтобы гарантировать, что достаточная
ресурсы доступны для функции службы поддержки, чтобы выполнить
обязательства по обслуживанию.
 Выявление и внедрение новых или улучшенных рабочих методов.
 Поиск неисправностей и проблем:
 Прослушивание и разрешение случаев неудовлетворенности.
110 Service Desk
 Посредничество между клиентами и менеджерами на предмет уровня

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

Роль аналитика или техника службы поддержки ответственна за выполнение
ежедневных задач и процессов службы поддержки.
Эта роль, прежде всего, связана с выполнением процесса управления
инцидентами. В первые моменты цикла жизни инцидента, аналитики службы
поддержки ответственны должную регистрацию и классификацию инцидента и за
оказание начальной поддержки. На стадии начальной поддержки, они ответственны
за разрешение максимального количества инцидентов, насколько это возможно в
пределах определенных временных рамок. Эти действия напрямую связанны с
удовлетворением клиента и определяют дальнейшую судьбу инцидента в цепи
поддержки.
Аналитики/техники службы поддержки ответственны назначение инцидентов,
которые не были решены сразу. Однако, их ответственность в этом месте не
заканчивается, они продолжают сохранить ответственность за инцидент, чтобы
гарантировать, что все инциденты продолжают обрабатываться или наращиваться
в соответствии с целями обслуживания.
Аналитик/техник информирует клиента о прогрессе работ в течение всей жизни
инцидента. Как только инцидент разрешен, аналитик/техник должен убедиться что
клиент удовлетворен решением и только потом закрыть инцидент.
Эта золь также включает начальную обработку всех типов запросов обслуживания,
превентивная связь бизнесом и зачастую обслуживание средств обслуживания,
таких как списков ЧАСТО ЗАДАВАЕМЫХ ВОПРОСОВ. Эта роль ответственна за
следующие действия:
 Регистрация инцидента.
 Направление запросов в группы решения, в случае если инциденты не
разрешены во время начальной поддержки.
 Начальная поддержка и классификация.
 Контроль статуса и продвижения по разрешению всех открытых инцидентов.
 Информирование пользователей о продвижении запросов.
 Эскалация процесса в случае необходимости.
 Разрешение и инцидентов, не переданных в группы решения.
 Подтверждение разрешения и закрытие инцидентов.
 Обнаружение потенциальных тенденций и помощь управлению проблем, где

возможно.
6
Связь с другими SMF
Службы поддержки это важная SMF, которая взаимодействует с другими SMF.
Управление конфигурациями
Эта функция службы поддержки использует информацию из базы данных
управления конфигурациями (CMDB) для выполнения своих процессов.
Уже при получении запроса многие детали относительно клиента могут получены из
CMDB. Функция службы поддержки проверяет эту информацию с клиентом, чтобы
гарантировать, что все записи поддерживаются в надлежащем состоянии.
Обрабатывая инциденты и запросы обслуживания, функция эта службы поддержки
проверяет детали пунктов конфигурации (CI) против значений найденных в CMDB и
уведомляет управление конфигурации в тех случаях, когда найдены несоответствия
для того, чтобы они могли исправить ошибки и исследовать, почему несоответствия
возникли.
Эта функция службы поддержки также использует информацию в пределах CMDB
для того, чтобы точно обеспечения превентивных коммуникаций с клиентами.
Управление релизами
Управление релизами сообщает функции службы поддержки о новых релизах или
модернизациях (аппаратных средств и программного обеспечения) для того, чтобы:
 Гарантировать, что штат службы поддержки обеспечивает или поддерживает
соответствующее уровень обучения, позволяющий обработать все запросы,
относящиеся к новому релизу или модернизации.
 Гарантировать, что новый релиз принимается во внимание при формировании
нового штатного расписания.
 Гарантировать разработку диагностических скриптов.
 Гарантировать, что служба поддержки оповестит пользователей о новых
выпусках.
 Гарантировать, что служба поддержки сообщает управлению выпусками о
любых проблемах внедрения.
Управление изменениями
Управление изменениями сообщает службе поддержки о любых наступающих
изменениях, чтобы гарантировать, что службы проделает все необходимые
приготовления.
112 Service Desk
Служба поддержки должна быть представлена на встречах CAB, чтобы дать свою
перспективу на оценку изменений и в отчетах о выполнении, чтобы дать свою
перспективу на успехи изменений.
Как часть своей роли в превентивных коммуникациях, служба поддержки может
распространять Передовой Список Изменений (FSC) и Спроектированная
Пригодность Обслуживания (PSA) клиентам.
Управление безопасностью
SMF Управления Безопасности связана с урегулированием политики относительно
того, каким образом службы поддержки реагирует на запросы
безопасности/доступа, такие как установка пароля, открытие новых акаунтов,
доступ к приложениям, и удалению старых акаунтов.
Управление хранения данных

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

SMF Управления директориями сервисов, в сотрудничестве с SMF управления
безопасностью, должен провозгласить политику согласно которой, служба
поддержки обращается с акаунтами запросами о паролях.
Управление заданиями
SMF управления заданиями взаимодействует со службой поддержки для того,
чтобы обработать запросы и изменить списки заданий или исследование
неудавшиеся задачи.
Управление инцидентами
Служба поддержки действует как начальные ворота во многие из процессов IT,
включая процесс управления инцидентами. Служба поддержки действует как
интерфейс между бизнесом и IT и, в этом случае, между бизнесом и процессом
управления инцидентами.
Служба поддержки отвечает за координацию процесса управления инцидента.
Служба выполняет регистрацию, классификацию, и начальные фазы поддержки
управления инцидентами. Когда инциденты переданы группам решения, служба
поддержки сохраняет ответственность за контроль, и отслеживание всех
инцидентов.
Если стол обслуживания функционирует успешно, много запросов и инцидентов
могут быть обработаны и решены, не выходя за пределы функции службы
поддержки.
Управление проблемами
Стол обслуживания, с его ответственностью за координацию процесса управления
инцидентами, идеально подходит для того, чтобы идентифицировать текущие или
многократные инциденты, которые указывают на существующую проблему.
Одновременно службы поддержки является важным источником информации для
разрешения проблемы.
В свою очередь, управление проблемами работает, чтобы идентифицировать и
документировать обходные варианты и решения проблем, которые службы
поддержки может использовать для оказания начальной поддержки для новых
инцидентах.
Когда решения идентифицированы управлением проблемами, информация
передается пользователям через службу поддержки.
Управление проблемами также стремится идентифицировать информацию,
которую служба поддержки может проактивно сообщить пользователям. В конечном
счете, эффективное управление проблемами должно уменьшить число инцидентов,
о которых сообщают в службу поддержки.
Финансовое управление
Функция финансового управления обеспечивает детали относительно затрат на
управления службы поддержки и, если необходимо, обеспечивает механизм для
сбора денег за услуги службы поддержки.
Управление мощностями
Управление ресурсами помогает службе поддержки, обеспечивать достаточные
мощности для инструментов службы поддержки, инструментов диагностики
инцидентов, и средств обслуживания клиентов.
Управление доступности
Служба поддержки помогает управлению доступности получать детальную
информацию о прерываниях обслуживания, точно регистрируя детали инцидентов.
Управление доступности работает с руководством службы поддержки, чтобы
планировать доступность службы поддержки.
Управление непрерывностью ИТ сервисов

Управление непрерывности обслуживания IT работает с руководством службы
поддержки, чтобы планировать непрерывность функции службы поддержки.
Управление непрерывности обслуживания IT планирует и согласует роль, которую
должна играть служба поддержки в экстремальных ситуациях.
Управление уровнем сервиса

Как точка контакта между клиентами и организацией IT, служба поддержки
использует информацию от Управления Уровня Обслуживания для того, чтобы
определить какие согласованные уровни обслуживания должны быть обеспечены, и
114 Service Desk
работает в координации с управлением уровня обслуживания в случаях, когда цели

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

Microsoft Operations Framework. - Service Desk-Microsoft

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microsoft Operations Framework. - Service Desk-Microsoft

Uploaded by

Copyright:

Available Formats

Служба поддержки

Функция управления сервисом

опубликовано: Октябрь 2002

За соответствие использования документа со всеми применимыми законами об охране авторского права

 2005 Microsoft Corporation. Авторские права защищены.

Простые задачи могут включать в себя:

Запрос сервиса. Запрос сервиса это запрос на создание нового или

Структура службы поддержки

Централизованная Четкое лидерство Телефонная Пользователи

Вид службы Требования Средства Преимущества

Вид службы Требования Средства Преимущества

Децентрализованн В случае, когда Возможно, что Обеспечивается

Вид службы Требования Средства Преимущества

Виртуальная Необходимо Необходима Такая структура

Вид службы Требования Средства Преимущества

покрывает пункты системы.

Вид службы Требования Средства Преимущества

Служба поддержки в небольших организациях

Масштабирование службы поддержки для большой

Роль службы поддержки внутри IT организации

Figure 1. Взаимодействия Службы Поддержки

Сфера службы поддержки

Кого поддерживает служба поддержки?

Сервисная служба Сервисная служба прежде всего нацелена на

Что делает служба поддержки?

Выгоды от службы сервиса

Внедрение службы поддержки обеспечивает следующие преимущества для

Обзор диаграммы процессов

Функционирование службы поддержки

Figure 2 описывает задачи, которые должны выполняться ежедневно для

Figure 2. Каждодневные задачи службы поддержки

Управление персоналом и ресурсами

Определение сроков и расписаний

В то время как пользователи могут терпеть определенное число автоматических

 Снижая время обучения пользователей.

Не существует одного метода одинаково подходящего для любой организации;

Figure 3. Обзор моделей планирования

Следующая таблица показывает преимущества, риски и зависимости, связанные с

Самоуправляемые команды (Pods)

Каждая из команд (иногда называемая pod) обычно обрабатывает запросы уровней

Преимущества Риски Зависимости

небольшими очередями в специализированных группах с небольшим числом

Тройки (и похожие модели)

Следующая таблица показывает преимущества, риски и зависимости, связанные со

Смешанная схема Расписание/Самоуправление

Удовлетворение и удержание сотрудников

Люди стремятся работать там, где имеется вызов, открытые коммуникации и

сотрудников к совершенству. Важно регулярно изучать уровень удовлетворения

Использование 2й линии поддержки

 Специалисты поддержки видят процессы получения и отслеживания

Единая точка контакта

Средства и технологии связи

обработан без ссылок на специалиста службы поддержки, или для сбора

 Интернет, HTML и электронные формы (e-forms). Использование этих

 Новостные группы, BBS форумы, и публичные e-mail директории.

Такие системы сбора информации могут контролироваться штатом службы поддержки,

Если для функционирования службы поддержки используются подходящие

Доступ к информации о запросах

Роль службы поддержки в серьезных инцидентах

обращаются в службу поддержки, а также через описанные выше превентивные

Когда происходит серьезный инцидент, менеджеры и технический штат должны

Работа службы поддержки

Получение и запись запросов