Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:

• новый;

• принят;

• запланирован;

• назначен;

• активный;

• отложен;

• разрешен;

• закрыт.

Привязка (сопоставление)

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

Расследование и диагностика

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

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

Решение и восстановление

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

Закрытие

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

Мониторинг хода решения и отслеживание

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

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

• общее количество инцидентов;

• среднее время разрешения инцидентов;

• среднее время разрешения инцидентов по приоритетам;

• процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);

• средняя стоимость поддержки на инцидент;

• число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

• инциденты, решенные без посещения пользователя (удаленно);

• число (или процент) инцидентов с первоначально некорректной классификацией;

• число (или процент) инцидентов, неправильно распределенных в группы поддержки.

Функции и роли

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

Персонал групп поддержки

• Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.

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

 

Выводы к ГЛАВЕ 2.

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

2) Качественная поддержка пользователей социальный сетей требует о из руководителей особого способа взаимодействия с пользователями для улучшения качества системы поддержки.

3) Поддержка Вконтакте ведется в отдельном интерфейсе, расположенном прямо на сайте, что позволяет избежать ненужной волокиты с отправкой писем через почтовые сервисы.

4) Служба технической поддержки устроена примерно по следующему принципу:

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

· Оператор (1-я линия поддержки) — регистрирует обращение, при возможности помогает пользователю самостоятельно, либо эскалирует (передаёт и контролирует выполнение) заявку на вторую линию поддержки.

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