Идентификационный номер инцидента
Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.
Статус
Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:
• новый;
• принят;
• запланирован;
• назначен;
• активный;
• отложен;
• разрешен;
• закрыт.
Привязка (сопоставление)
После классификации проводится проверка, не возникал ли аналогичный инцидент ранее и нет ли готового решения или обходного пути. Если инцидент имеет те же признаки, что и открытая проблема или известная ошибка, то может быть установлена связь с ними.
Расследование и диагностика
Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня.
В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника.
Решение и восстановление
После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.
Закрытие
После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне.
Мониторинг хода решения и отслеживание
В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.
Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например, раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются:
• общее количество инцидентов;
• среднее время разрешения инцидентов;
• среднее время разрешения инцидентов по приоритетам;
• процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);
• средняя стоимость поддержки на инцидент;
• число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;
• инциденты, решенные без посещения пользователя (удаленно);
• число (или процент) инцидентов с первоначально некорректной классификацией;
• число (или процент) инцидентов, неправильно распределенных в группы поддержки.
Функции и роли
Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.
Персонал групп поддержки
• Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.
• Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов.
Выводы к ГЛАВЕ 2.
1) Техническая поддержка любого сайта — это сложная многоуровневая система мониторинга и решения пользовательских задач, требующая грамотного построения своей структуры для увеличения качества взаимодействия со своими пользователями.
2) Качественная поддержка пользователей социальный сетей требует о из руководителей особого способа взаимодействия с пользователями для улучшения качества системы поддержки.
3) Поддержка Вконтакте ведется в отдельном интерфейсе, расположенном прямо на сайте, что позволяет избежать ненужной волокиты с отправкой писем через почтовые сервисы.
4) Служба технической поддержки устроена примерно по следующему принципу:
· Пользователь обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки (электронная почта, или специальные сервисы подачи заявок).
· Оператор (1-я линия поддержки) — регистрирует обращение, при возможности помогает пользователю самостоятельно, либо эскалирует (передаёт и контролирует выполнение) заявку на вторую линию поддержки.
· Вторая линия поддержки — получает заявки от первой линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из смежных отделов (например, системные администраторы, поддержка POS-терминалов, поддержка специального ПО, поддержка специального оборудования, администраторы биллинговой системы и т. д.)