Обработка сервисных запросов

На приведенном ниже рисунке показана блок-схема обработки сервисных запросов.

Подписи к рисунку: Identify and record type of service request - Идентификация и тип сервисного запроса Record details relevant to service request type - Регистрация информации, относящейся к типу сервисного запроса Can initial support fulfill the request? - Может ли группа начальной поддержки удовлетворить запрос? No - Нет Yes - Да Initial support fulfills the request - Группа начальной поддержки удовлетворяет запрос Initiate interface appropriate to service request type - Начальный интерфейс, соответствующий сервисному запросу Pass details via appropriate interface - Прохождение информации через соответствующий интерфейс Monitor progress - Контроль прогресса Re-assign to appropriate team - Повторное назначение соответствующей группе Tracking required? - Требуется отслеживание? Ensure details fully updated - Гарантия полного обновления информации Close service request - Закрытие сервисного запроса Escalation or chase required? - Требуется эскалация или отслеживание? Assigned to correct team? - Назначен надлежащей группе? Update details and notify assigned team - Обновление информации и оповещение назначенной группы Customer confirms resolution? - Клиент подтверждает разрешение? Contact assigned team - Обращение в назначенную группу Update customer according to policy for service request type - Обновление клиента согласно политике для типа сервисного запроса Believe resolved? - Считается разрешенным? Update customer and confirm resolution - Обновление клиента и подтверждение разрешения End - Конец

Рисунок 6. Блок-схема обработки сервисных запросов

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

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

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

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

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

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

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

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

Подписи к рисунку: Business Unit - Подразделение организации Computer software install request - Запрос на установку программного обеспечения Obtain authorization - Получение разрешения Update service desk - Обновление службы поддержки Service Desk - Служба поддержки Record details, advise of request ID and costs - Регистрация информации, уведомление об идентификаторе запроса и расходах Confirm license availability - Подтверждение наличия лицензии Issue procurement request if required - Выдача запроса на приобретение, если требуется No - Нет Raise standard change and assign to desktop team - Стандартный запрос на изменение и назначение компьютерной группе Confirm customer satisfaction - Подтверждение удовлетворения заказчика Close service request - Закрытие сервисного запроса End - Конец Financial Team - Финансовая группа Yes - Да Process procurement request - Обработка запроса на приобретение Update charging information - Обновление информации о расходах Desktop Team - Компьютерная группа Install and test software - Установка и тестирование программного обеспечения Update CMDB - Обновление CMDB Close standard change - Закрытие стандартного запроса на изменение

Рисунок 7. Пример блок-схемы процедуры технологического процесса

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

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

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

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

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

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

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

На приведенном ниже рисунке показан пример инструмента по созданию запроса на изменение (RFC).

Рисунок 8. Пример специального инструмента по созданию RFC

Типы сервисных запросов, для которых нет определенного инструмента, должны регистрироваться и отслеживаться с использованием регистрационных записей инцидента. На приведенном ниже рисунке показан пример запроса пакетного задания, выполненный в этом формате.

Рисунок 9. Уникальный запрос пакетного задания, зарегистрированный в регистрационной записи инцидента

Дата добавления: 2015-10-29