Запрос на обслуживание — это официальный запрос пользователя на любую услугу, например установку нового ПО (программного обеспечения), замену оборудования или отдельного его компонента. Официальное определение запроса на обслуживание, данное в библиотеке ITIL ( IT Infrastructure Library), — « запрос пользователя на информацию, консультацию или доступ к услуге ». В этой статье рассмотрим различные аспекты выполнения запросов на обслуживание ITIL, такие как цели, сферы применения, процессы, подпроцессы и т. д.
Выполнение запросов на обслуживание ITIL
Запросы на обслуживание ITIL обычно относятся к небольшим и частым изменениям или дополнениям с низкой стоимостью и степенью риска. Поэтому было бы неразумно объединять эти запросы с запросами с высокой степенью риска. Их выделяют в отдельный процесс, которым занимается специальная команда. Процесс выполнения сделанных запросов называется выполнением запросов.
Задачи выполнения запросов на обслуживание
К таким задачам относятся:
Ошибки клиентского сервиса премиум-бренда, которые разрушат вашу компанию
- Информирование пользователей о доступности существующих услуг и процедуре их запроса.
- Создание отдельного канала, с помощью которого пользователи могут запрашивать и получать требуемые услуги, получившие предварительное одобрение.
- Своевременное получение и предоставление требуемых стандартных услуг.
- Помощь в обработке жалоб и запросов общей информации.
Сфера применения выполнения запросов на обслуживание
Обычно компании получают несколько сотен запросов на обслуживание в день. Довольно сложно управлять этим потоком без стандартизированной модели для описания и классификации запросов. Такая модель должна учитывать следующие параметры:
- Необходимо назначить сотрудника или целую команду, которые будут отвечать за обработку запросов.
- Следует определить процесс предоставления той или иной услуги.
- Запрос на обслуживание должен быть выполнен быстро и вовремя в соответствии с заранее установленным временным отрезком или соглашением об уровне обслуживания (SLA, Service Level Agreement).
- Если команда, отвечающая за обработку запросов, не может выполнить запрос на обслуживание, необходимо выбрать альтернативный путь решения проблемы.
Действия в рамках выполнения запросов на обслуживание
Меню с возможностью выбора
Как правило, компании используют службу поддержки для подачи запросов. Но сегодня в сфере управления услугами доступны технологии, которые позволяют пользователям самостоятельно обращаться с запросами. Интерфейс в виде меню удобен для выбора деталей запроса на обслуживание из заранее определенного списка.
Финансовое одобрение
Некоторые запросы на обслуживание требуют еще одного шага после подачи, а именно получения финансового одобрения руководства. Пользователь должен получить необходимое разрешение у соответствующих вышестоящих должностных лиц, которые отвечают за финансовую деятельность компании.
В чем секрет продаж на большой чек: как из бизнес-сегмента выйти в премиальный?
Прочие одобрения
Иногда пользователю могут понадобиться дополнительные разрешения от конкретного отдела, чтобы убедиться, что его запрос соответствует установленным стандартам или параметрам. Для правильного выполнения запросов на обслуживание необходимо предусмотреть возможность проверки таких согласований.
Выполнение
Выполнение запроса на обслуживание зависит от его типа. Некоторые запросы могут выполнить специалисты служб технической поддержки, в то время как другие запросы необходимо направить в конкретные департаменты.
Завершение
После завершения обслуживания запрос необходимо вернуть в службу поддержки, чтобы его можно было закрыть и пометить как решенный. Для этого специалисты службы поддержки должны убедиться, что пользователь удовлетворен выполнением запроса.
Метрики
Чтобы оценить эффективность и результативность выполнения запросов соответствующими департаментами и получить точную картину всего процесса, необходимо проанализировать следующие показатели:
- Общее количество запросов на обслуживание.
- Распределение запросов на обслуживание на каждом этапе.
- Актуальное число невыполненных запросов на обслуживание.
- Среднее время обработки каждого типа запроса.
- Процент и точное количество запросов, выполненных в согласованные сроки.
- Средняя стоимость каждого запроса.
- Уровень удовлетворенности пользователей.
Подпроцессы в рамках выполнения запросов на обслуживание
Поддержка выполнения запросов
Она нужна для того, чтобы предоставить необходимые инструменты, навыки и процессы. И поддерживать их для эффективного и результативного рассмотрения заявок на обслуживание.
Регистрация и категоризация запросов
Их цель состоит в том, чтобы регистрировать и тщательно классифицировать различные типы запросов на обслуживание. Это необходимо для их быстрой и эффективной обработки. Также в рамках этих подпроцессов проверяется разрешение пользователя на подачу конкретного запроса.
Реализация модели выполнения запросов
Ее цель — обработать запрос в заранее согласованные сроки.
Мониторинг запросов
Его цель состоит в том, чтобы постоянно отслеживать статус обработки запросов на обслуживание. Это позволяет быстро вносить изменения в случае возникновения каких-либо проблем, например нарушения уровня обслуживания.
Закрытие и оценка запросов
Цель этого подпроцесса — предоставление итоговых отчетов о запросах на обслуживание в отдел контроля качества для финальной проверки. Это необходимо для того, чтобы убедиться, что услуги предоставляются должным образом и вся необходимая информация о них представлена достаточно подробно.
Вывод
Таким образом, выполнение запросов на обслуживание ITIL информирует пользователей о доступности существующих услуг. А процедура их запроса создает отдельный канал, по которому пользователи могут запрашивать и получать необходимую услугу.
Оставайтесь в курсе событий
Подписывайтесь на рассылку новых материалов блога по почте
Источник: it-guild.com
В очередной раз об инцидентах и сервисных запросах
Привет всем хабражителям,
очень часто, по долгу процессной службы приходиться слышать от сотрудников больших и малых департаментов IT один очень популярный вопрос: в чем разница между запросом на обслуживание и инцидентом?
Дискуссии на эту тему стары, как все вместе взятые методологии управления IT, тем не менее, давайте обратимся к первоисточникам.
Что нам говорит ITIL (официальный перевод глоссария по третьей версии):
Запрос на обслуживание — запрос пользователя на информацию, или консультацию, или на стандартное изменение, доступ к ИТ-услуге.
Инцидент — незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.
Как обычно методология не лезет в глубь вещей и очень не любит отвечать на предметные вопросы сотрудников любого Сервис-деска, классифицирующих обращения пользователей. А меж тем, вопросов таких масса, вот несколько примеров:
1) Христоматийный звонок пользователя с просьбой сбросить пароль — как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?
2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»
Стоит ли говорить что первичная классификация очень важна, так как она определяет весь последующий жизненный цикл обращения, в т.ч. и сроки исполнения.
Мое понимание этого вопроса сводится к вопросу оценки прерывания сервиса для конечного потребителя, и таким образом:
Инцидент — это, в большинстве случаев, прерывание или частичное прерывание ИТ-услуги, которая ранее предоставлялась пользователю в утвержденном режиме (сервис доступен 24/7, либо 5/8).
Пример: у главного бухгалтера компании внезапно пропал доступ к системе финансовой отчетности. С одной стороны предоставление доступа это классический сервисный запрос, но в данном случае на лицо явное прерывание сервиса и, как следствие, частичная деградация бизнес-процесса.
Запрос на обслуживание — это обращение от пользователя, который заинтересован в подключении дополнительной услуги, либо доработке функционала существующих услуг.
Пример: особо любопытный пользователь попытался открыть один из модулей все той же системы финансовой отчетности, но получил сообщение об ошибке. С его т.з. это инцидент, так как он не достиг желаемой цели и не получил искомую информацию, но, с т.з. описанной выше — это классический запрос на обслуживание на предоставление доступа, требующий согласования и выполняемый по стандартной процедуре в согласованный срок.
При этом не стоит забывать про многообразие частных случаев которые вообще сложно поддаются классификации, точка зрения описанная выше не претендует на догму, а лишь стремиться помочь минимизировать количество неправильно классифицированных обращений и улучшить общее время реакции IT на потребности бизнеса.
Поделитесь своими соображениями на данную тему.
- ITIL
- incident management
- request fulfillment
Источник: habr.com
Что такое инциденты и запросы на обслуживание
Любой службе поддержки необходимо расставлять приоритеты и выстраивать очередность выполнения работ. Главным ориентиром при этом выступает риск возникшей проблемы для бизнеса. Исходя из этого критерия обращение в сервисное подразделение классифицируется как инцидент или запрос на обслуживание. В чем разница и почему управлять ими лучше при помощи системы автоматизации?
Что такое инцидент
Если оперировать терминами методологии ITIL, инцидент — это внеплановое прекращение предоставления сервиса или снижение его качества. Поскольку подобные сбои угрожают рабочему процессу, разбираться с ними нужно максимально оперативно. При популярном сегодня сервисном подходе к поддержке сроки устранения инцидентов прописываются в соглашениях SLA.
Инциденты всегда происходят неожиданно. Иногда такие проблемы парализуют деятельность целого подразделения или даже организации, что приводит к немалым материальным, репутационным и другим потерям. Например, из-за внезапного отключения интернет-соединения компания не может принять участие в электронные торгах и упускает выгодный контракт.
Чтобы минимизировать вред для бизнеса, при работе с инцидентами специалисты поддержки фокусируются на максимально быстром восстановлении сервиса. В критический момент нет времени разбираться с глубинными причинами сбоя — требуется как можно быстрее найти оптимальное решение и исправить ситуацию. Впрочем, дальнейший анализ системных проблем, которые привели к инциденту, необходим для предотвращения подобного в будущем.
Что такое запрос на обслуживание
Общепринятое определение звучит как «запрос пользователя на информацию, консультацию, стандартное изменение или доступ к ИТ-услуге». В отличие от инцидентов в этом случае нет опасности для бизнес-процессов и ничего не угрожает бесперебойному предоставлению сервисов.
Запросы на обслуживание направляются в службу поддержки, чтобы предотвратить снижение качества предоставляемых услуг, обеспечить нормальное функционирование ИТ-инфраструктуры. В конечном итоге все это тоже влияет на комфорт и результаты работы внутренних пользователей или клиентов.
Приоритет и срочность у подобных обращений всегда ниже, чем у инцидентов, в силу меньшей критичности для бизнеса. Однако это не значит, что выполнение запросов на обслуживание можно затягивать. Если на работу выходит новый специалист, а место для него не готово, компания вынуждена оплачивать простой и несет убытки. А медленно работающий компьютер хоть и не выключает сотрудника из процесса полностью, но по факту может ежедневно сокращать его продуктивное время на несколько часов. Поэтому регламент и сроки обработки запросов на обслуживание также фиксируются в соглашении SLA.
Почему необходимо системно управлять инцидентами и запросами на обслуживание
В службу поддержки постоянно поступает множество сервисных запросов, причем каждый из них может быть отмечен как срочный. Отсутствует ли доступ в базу данных или же информация загружается в нее слишком долго — пользователи далеко не всегда различают критичность таких проблем. И то, и другое вызывает сложности, а значит специалисты поддержки должны все исправить «вчера». Вот почему устанавливаются четкие правила работы с обращениями в зависимости от типа и приоритета.
Пользователям же бывает трудно сориентироваться, как корректно сформулировать и классифицировать свое обращение. Часто им неочевидна разница между инцидентом и запросом на обслуживание, сложно правильно выбрать необходимый сервис. Причем взятое в работу обращение не обязательно означает мгновенное решение вопроса, а получить актуальную информацию по статусу заявки у перегруженных сотрудников поддержки оказывается непросто. Решать все эти проблемы необходимо системно, с применением специальных инструментов.
Какой инструмент использовать для управления инцидентами и запросами на обслуживание
Сделать процесс работы с инцидентами и запросами на обслуживание эффективным помогают инструменты автоматизации, например, сервис деск. Вот только некоторые выгоды от применения таких решений.
Быстрая классификация обращений. В сервис деск можно настроить автоматическое определение типа поступившего обращения. Исходя из этого и условий SLA в системе назначаются сроки реагирования на запрос и его выполнения. Скажем, с инцидентом сервисная служба должна справиться за три часа, а с запросом на обслуживание — в течение рабочего дня.
Оперативное назначение ответственных. В зависимости от своей критичности и сложности вопрос направляется в системе либо диспетчеру первой линии поддержки, либо более квалифицированному техническому специалисту. Благодаря такому назначению ответственных обращение быстрее дойдет до непосредственного исполнителя.
Накопление опыта. Информацию о выполненных запросах на обслуживание и устраненных инцидентах можно сохранять в Базе знаний или другом хранилище, чтобы в будущем с помощью этих материалов проще ориентироваться в подобных ситуациях.
Прозрачность процессов. В системе автоматизации пользователь всегда может отследить, на каком этапе его заявка. Нет необходимости закидывать специалистов поддержки письмами или долго до них дозваниваться. Сервисные сотрудники вовремя узнают о появлении новых обращений и оперативнее приступят к их выполнению.
Профилактика инцидентов. В системе сохраняется вся информация по заявкам клиентов и выполненным работам. Это помогает выявлять причины возникновения инцидентов и проводить профилактические мероприятия заранее.
Оценка эффективности работы. Среди метрик эффективности сервисной службы — общее число инцидентов в месяц. Если такой показатель растет, то в работе подразделения, возможно, не все в порядке. Система автоматизации упрощает анализ показателя, поскольку в ней реализованы соответствующие автоматические отчеты.
К выводам: в чем разница инцидентов и запросов на обслуживание
Все поступающие в службу поддержки обращения делятся на инциденты и запросы на обслуживание. Первые — это «пожары», которые тормозят работу пользователей, поэтому должны устранятся максимально оперативно. Вторые — направлены на обеспечение нормальной работы инфраструктуры и предоставление стандартных услуг. Запросы на обслуживание не несут серьезной угрозы бизнесу, поэтому такие обращения обладают меньшей срочностью, чем инциденты.
Тем не менее, сроки и условия работы с подобными типами обращений должны четко регламентироваться в соглашении SLA. А для управления лучше всего использовать систему сервис деск, которая позволяет автоматизировать классификацию обращений, определение дедлайнов, назначение ответственных исполнителей и многие другие операции при выполнении таких запросов.
Источник: itsm365.com
