Привет всем хабражителям,
очень часто, по долгу процессной службы приходиться слышать от сотрудников больших и малых департаментов IT один очень популярный вопрос: в чем разница между запросом на обслуживание и инцидентом?
Дискуссии на эту тему стары, как все вместе взятые методологии управления IT, тем не менее, давайте обратимся к первоисточникам.
Что нам говорит ITIL (официальный перевод глоссария по третьей версии):
Запрос на обслуживание — запрос пользователя на информацию, или консультацию, или на стандартное изменение, доступ к ИТ-услуге.
Инцидент — незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.
Как обычно методология не лезет в глубь вещей и очень не любит отвечать на предметные вопросы сотрудников любого Сервис-деска, классифицирующих обращения пользователей. А меж тем, вопросов таких масса, вот несколько примеров:
1) Христоматийный звонок пользователя с просьбой сбросить пароль — как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?
2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»
Стоит ли говорить что первичная классификация очень важна, так как она определяет весь последующий жизненный цикл обращения, в т.ч. и сроки исполнения.
Мое понимание этого вопроса сводится к вопросу оценки прерывания сервиса для конечного потребителя, и таким образом:
Инцидент — это, в большинстве случаев, прерывание или частичное прерывание ИТ-услуги, которая ранее предоставлялась пользователю в утвержденном режиме (сервис доступен 24/7, либо 5/8).
Пример: у главного бухгалтера компании внезапно пропал доступ к системе финансовой отчетности. С одной стороны предоставление доступа это классический сервисный запрос, но в данном случае на лицо явное прерывание сервиса и, как следствие, частичная деградация бизнес-процесса.
Запрос на обслуживание — это обращение от пользователя, который заинтересован в подключении дополнительной услуги, либо доработке функционала существующих услуг.
Пример: особо любопытный пользователь попытался открыть один из модулей все той же системы финансовой отчетности, но получил сообщение об ошибке. С его т.з. это инцидент, так как он не достиг желаемой цели и не получил искомую информацию, но, с т.з. описанной выше — это классический запрос на обслуживание на предоставление доступа, требующий согласования и выполняемый по стандартной процедуре в согласованный срок.
При этом не стоит забывать про многообразие частных случаев которые вообще сложно поддаются классификации, точка зрения описанная выше не претендует на догму, а лишь стремиться помочь минимизировать количество неправильно классифицированных обращений и улучшить общее время реакции IT на потребности бизнеса.
Поделитесь своими соображениями на данную тему.
Ссылки:
1. Официальный перевод глоссария ITIL v.3
очень часто, по долгу процессной службы приходиться слышать от сотрудников больших и малых департаментов IT один очень популярный вопрос: в чем разница между запросом на обслуживание и инцидентом?
Дискуссии на эту тему стары, как все вместе взятые методологии управления IT, тем не менее, давайте обратимся к первоисточникам.
Что нам говорит ITIL (официальный перевод глоссария по третьей версии):
Запрос на обслуживание — запрос пользователя на информацию, или консультацию, или на стандартное изменение, доступ к ИТ-услуге.
Инцидент — незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.
Как обычно методология не лезет в глубь вещей и очень не любит отвечать на предметные вопросы сотрудников любого Сервис-деска, классифицирующих обращения пользователей. А меж тем, вопросов таких масса, вот несколько примеров:
1) Христоматийный звонок пользователя с просьбой сбросить пароль — как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?
2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»
Стоит ли говорить что первичная классификация очень важна, так как она определяет весь последующий жизненный цикл обращения, в т.ч. и сроки исполнения.
Мое понимание этого вопроса сводится к вопросу оценки прерывания сервиса для конечного потребителя, и таким образом:
Инцидент — это, в большинстве случаев, прерывание или частичное прерывание ИТ-услуги, которая ранее предоставлялась пользователю в утвержденном режиме (сервис доступен 24/7, либо 5/8).
Пример: у главного бухгалтера компании внезапно пропал доступ к системе финансовой отчетности. С одной стороны предоставление доступа это классический сервисный запрос, но в данном случае на лицо явное прерывание сервиса и, как следствие, частичная деградация бизнес-процесса.
Запрос на обслуживание — это обращение от пользователя, который заинтересован в подключении дополнительной услуги, либо доработке функционала существующих услуг.
Пример: особо любопытный пользователь попытался открыть один из модулей все той же системы финансовой отчетности, но получил сообщение об ошибке. С его т.з. это инцидент, так как он не достиг желаемой цели и не получил искомую информацию, но, с т.з. описанной выше — это классический запрос на обслуживание на предоставление доступа, требующий согласования и выполняемый по стандартной процедуре в согласованный срок.
При этом не стоит забывать про многообразие частных случаев которые вообще сложно поддаются классификации, точка зрения описанная выше не претендует на догму, а лишь стремиться помочь минимизировать количество неправильно классифицированных обращений и улучшить общее время реакции IT на потребности бизнеса.
Поделитесь своими соображениями на данную тему.
Ссылки:
1. Официальный перевод глоссария ITIL v.3