запрос на обслуживание и инцидент в чем разница
«Как близнецы»: 3 пары похожих терминов ITIL
Библиотека ITIL — подробный набор методов управления ИТ-услугами, который применяют с восьмидесятых годов. Но путаница в используемых терминах и их значении до сих пор преследует тех, кто только начинает внедряет у себя соответствующие методологии.
В этой статье мы попытаемся разграничить три пары похожих терминов:
Инцидент и проблема
IT-специалист и автор тренингов по ITIL Майкл Скарборо (Michael Scarborough) подчёркивает, что между терминами установлена следующая зависимость: проблема — причина, инцидент — следствие.
Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. Когда мы говорим «разрешили инцидент», это значит, что временно восстановили какую-то услугу (на 10 лет или всего на 1 минуту). То есть очень вероятно, что подобная ситуация повторится в будущем.
Проблема же, это причина возникновения инцидентов. Эксперт в области ITSM профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему», который вы задаёте себе.
Посмотрим на примеры, которые приводит директор по маркетингу компании Hornbill Питер Саммерс (Peter Summers).
Инцидент: пользователь звонит в службу поддержки и сообщает, что не может распечатать документ. Специалист, который принимает вызов, обнаруживает, что указанный файл вызвал ошибку в очереди печати. Чтобы можно было продолжить работу, специалист предлагает пользователю временно воспользоваться принтером в соседнем офисе.
Проблема: инцидент с принтером — признак глобальной проблемы. Этот пользователь — первый из многих, кто позвонит сегодня в службу поддержки. Допустим, удалось установить, что причиной инцидентов является обновление офисного ПО прошлой ночью. Если исправить баги апдейта, проблема будет решена и отказов в печати по этой причине больше не будет.
Для наглядности возьмём более приземлённый пример. Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.
Другой пример: вы едете на лысой резине — это проблема. Если вы продолжите её игнорировать, вероятность возникновения инцидента будет расти, покрышка, вероятно, лопнет.
Чтобы упростить вопрос с разграничением значений этих двух терминов, Филип Юсон (Philip Yuson), генеральный директор Concept Solutions Corporation, рекомендует задавать следующие вопросы:
Incident Management и Problem Management
Мы уже выяснили, чем отличаются инцидент и проблема, поэтому разграничить эти два процесса будет проще. ITIL определяет эти два термина следующим образом:
Управление инцидентами — управляет жизненным циклом всех инцидентов. Цель: скорейшее восстановление ИТ-услуги для пользователей.
Управление проблемами — управляет жизненным циклом всех проблем. Цель: предотвращение инцидентов в будущем.
Посмотрим на примеры от специалистов Microsoft. Представим сценарий: к специалисту техподдержки обратился пользователь, который не может просмотреть электронное письмо из-за ограничений. Саппорт создаёт новый инцидент с помощью шаблона e-mail incident, чтобы быстро разрешить ситуацию и обрабатывать похожие случаи в будущем.
В сценарии управления проблемами специалист техподдержки создаёт запрос на внесение изменений в код. Когда команда найдёт и устранит причину проблемы, это разрешит проблему и автоматически устранит инциденты с ней связанные.
Для большей ясности приведём пару примеров из жизни. Управление инцидентами похоже на работу пожарных. Они приходят на место происшествия и стараются максимально эффективно погасить огонь. То же самое происходит при управлении инцидентами. Возобновить работу инфраструктуры нужно быстро.
Далее начинается управление проблемами и детальное расследование происшествия. Этот процесс похож на работу эксперта или следователя. Он не был на месте, когда тушили пожар, но может определить причину возгорания и дать рекомендации, которые позволят избежать таких ситуаций в будущем.
Service desk и Helpdesk
Для начала вновь заглянем в официальную терминологию ITIL.
Service Desk — единая точка контакта (SPOC) между поставщиком услуг и клиентами. Функции: управляет инцидентами, запросами на обслуживание.
Help desk — точка контакта для пользователей. Функции: регистрирует инциденты.
Термин «служба поддержки» часто употребляется как синоним службы Service Desk, что является главной причиной путаницы в терминах. Крис Коффи (Cris Coffey), менеджер по маркетингу компании BMC Software, который работает на рыке Help Desk уже 20 лет, выделяет следующие различия между двумя этими службами.
Service Desk: полностью интегрируется с другими ITSM-процессами, помогает организации соответствовать соглашениям об управлении уровнем услуг, интегрируется с базой данных управления конфигурациями и процессом управления активами.
Help Desk: отслеживает все входящие инциденты, автоматически отслеживает уведомления по электронной почте, предлагает ограниченную интеграцию с другими ITSM-процессами, предоставляет услуги самообслуживания для конечных пользователей.
Посмотрим, как это выглядит на практике. Пример работы Help Desk: драйвер для принтера Джо сломался, а ему нужно распечатать копии документов до 10 часов. Help Desk поможет Джо восстановить работу принтера или найдёт другой способ получить распечатки вовремя. Задача службы — сделать так, чтобы распечатки были в руках у Джо до 10 часов.
В той же ситуации Service Desk заметит, что за прошедшую неделю несколько человек с этого этажа обратились в службу с той же проблемой. Это значит, что проблема — глубже, чем кажется. Service Desk отправляет специалиста, чтобы установить корень проблемы с принтером. Задача службы — устранить первопричину.
Напоследок кратко обобщим все разобранные моменты:
В очередной раз об инцидентах и сервисных запросах
Привет всем хабражителям,
очень часто, по долгу процессной службы приходиться слышать от сотрудников больших и малых департаментов IT один очень популярный вопрос: в чем разница между запросом на обслуживание и инцидентом? 
Дискуссии на эту тему стары, как все вместе взятые методологии управления IT, тем не менее, давайте обратимся к первоисточникам.
Что нам говорит ITIL (официальный перевод глоссария по третьей версии):
Запрос на обслуживание — запрос пользователя на информацию, или консультацию, или на стандартное изменение, доступ к ИТ-услуге.
Инцидент — незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.
Как обычно методология не лезет в глубь вещей и очень не любит отвечать на предметные вопросы сотрудников любого Сервис-деска, классифицирующих обращения пользователей. А меж тем, вопросов таких масса, вот несколько примеров:
1) Христоматийный звонок пользователя с просьбой сбросить пароль — как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?
2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»
Стоит ли говорить что первичная классификация очень важна, так как она определяет весь последующий жизненный цикл обращения, в т.ч. и сроки исполнения.
Мое понимание этого вопроса сводится к вопросу оценки прерывания сервиса для конечного потребителя, и таким образом:
Инцидент — это, в большинстве случаев, прерывание или частичное прерывание ИТ-услуги, которая ранее предоставлялась пользователю в утвержденном режиме (сервис доступен 24/7, либо 5/8).
Пример: у главного бухгалтера компании внезапно пропал доступ к системе финансовой отчетности. С одной стороны предоставление доступа это классический сервисный запрос, но в данном случае на лицо явное прерывание сервиса и, как следствие, частичная деградация бизнес-процесса.
Запрос на обслуживание — это обращение от пользователя, который заинтересован в подключении дополнительной услуги, либо доработке функционала существующих услуг.
Пример: особо любопытный пользователь попытался открыть один из модулей все той же системы финансовой отчетности, но получил сообщение об ошибке. С его т.з. это инцидент, так как он не достиг желаемой цели и не получил искомую информацию, но, с т.з. описанной выше — это классический запрос на обслуживание на предоставление доступа, требующий согласования и выполняемый по стандартной процедуре в согласованный срок.
При этом не стоит забывать про многообразие частных случаев которые вообще сложно поддаются классификации, точка зрения описанная выше не претендует на догму, а лишь стремиться помочь минимизировать количество неправильно классифицированных обращений и улучшить общее время реакции IT на потребности бизнеса.
Поделитесь своими соображениями на данную тему.
Портал №1 по управлению цифровыми
и информационными технологиями
Сначала зафиксируем очевидное.
Во-первых, источником информации (в т.ч. о текущем статусе) является, конечно же INC, поскольку именно в этом процессе происходи работа с инцидентом и в т.ч изменение статуса инцидента.
Во-вторых, ответственность за обеспечение прозрачности работы процесса лежит на INC, на что в ITIL явно указано — обеспечение прозрачности процесса включено в список задач (objectives) процесса [ITIL Service Operation (SO) 4.2.1.2]. Кроме того, в примерах критических факторов успеха (CSF) есть такой: «Улучшать прозрачность и коммуникации в работе процесса», по которому даже сформулирован соответствующий KPI из списка примеров: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов [SO 4.2.8].
Также в списке примеров политик процесса INC сказано [SO 4.2.4.1): «Информация об инцидентах и их статусах должна своевременно и эффективно передаваться. Это предполагает наличие хорошего service desk для координации коммуникации информации об инцидентах тем, кто работает над инцидентами».
Видятся возможными следующие два варианта.
Мы можем дополнить INC процедурой, согласно которой будем отвечать на запросы информации пользователей о том, что сейчас происходит с зарегистрированным ранее инцидентами.
А можем отрабатывать такие запросы в рамках процесса RFF, который и так занимается консультированием и предоставлением пользователям информации.
Во втором случае RFF используются как транспорт, как канал коммуникаций, обеспечивающий передачу информации пользователям (по запросу, т.е. помимо автоматического оповещения со стороны INC).
При этом ответственность за эффективное использование данного канала для обеспечения должного уровня прозрачности процесса лежит на INC.
Можно посмотреть на это под другим углом.
При построении процесса INC мы должны обеспечить не только решение инцидентов (быстро, качественно, рационально и т.п.) но и работать на удовлетворённость, которая обеспечивается в т.ч. согласованным уровнем прозрачности. Т.е. мы должны построить процесс так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате (по согласованным каналам). Это м.б. e-mail, СМС, информация на портале самообслуживания (в личном кабинете) или телефонный звонок (а в случае обработки инцидентов от VIP-пользователей, возможно, и личный визит). То, насколько качественно мы выполним эту работу (по построению процесса INC), можно в т.ч. оценивать через снижение расходов на реализацию процесса. В т.ч. расходов на информирование пользователей. И для достижения целей в этом направлении мы должны продумать и выбрать оптимальную комбинацию каналов коммуникаций (проактивные – автоматическое оповещение, реактивные –выдача информации по запросу). Т.е. качество коммуникаций с пользователем в рамках работы над инцидентом – это ответственность процесса INC. При этом RFF может использоваться как один из механизмов информирования.
Коллеги, а как у вас построена данная работа? В рамках какого процесса и почему?
ТеХнологические записки
суббота, 27 февраля 2010 г.
СервисДеск получает обращения типов Неудовлетворенность сервисом (Инцидент: «пожалуйста, выполняйте соглашение» или «восстановите сервис»), Изменения сервиса (мне нужно что-нибудь другое) и Запрос на обслуживание (мне нужно иное/больше чем в меню сервиса).
Запрос на обслуживание предопределен и согласован в сервисном контракте (СК). Это значит, что если клиент запрашивает структурное изменение согласованных уровней сервиса, подобно изменению типовых часов предоставления сервиса, это НЕ является Запросом на обслуживание. Вместо этого, должен быть изменен СК (SLA) и должны быть внедрены структурно новые спецификации сервиса.
Примерами регулярных запросов на обслуживание могут быть:
— Вопросы о функциональности
— Запрос о статусе
— Замена пароля
— Запрос на пакетное задание и авторизацию пароля
— Выборка из БД
— Запрос на обеспечение нового сотрудника соответствующими ИТ функциональностью/сервисами
Как можно видеть, этот список содержит действия, которые должны рассматриваться как изменение… Но на практике это не так, просто потому, что они были отнесены к запросам на обслуживание. И это потому, что организации решили сделать так, чтобы упростить усложненный процесс управления изменениями. Таким образом, процесс управления изменениями может быть зарезервирован для «настоящих» изменений, которые требуют сложного и тщательного управления в рамках процедуры изменений. Запросы на обслуживание тогда попадают в производственный процесс (production process): выборка из БД, предоставление запрашиваемой информации, изменение пароля и т.п.
Они могут быть перечислены в СК (SLA) с определенными уровнями сервиса(время исполнения, стоимость предоставления, другие параметры качества).Стандартизованные изменения проходят через другой поток работ (workflow): укороченную и упрощенную процедуру, но такую, которая включает запуск процесса управления конфигурациями. Они могут быть описаны в СК, но они также могут быть описаны только в руководстве по качеству ИТ организации.
Любые запросы на изменения (RFC), которые отнесены к таким стандартизованным изменениям, будут проще маршрутизироваться в стандартном потоке работ (workflow) (который называется «Change Model» in ITIL Service Support: параграф 8.3, страницы 170, 176)
Итак, запросы на обслуживание не являются изменениями и наоборот. Но каждый из них НЕ инцидент и НЕ может обрабатываться как инцидент. Они будут обрабатываться различными потоками работ.
Портал №1 по управлению цифровыми
и информационными технологиями
Использую на курсах аналогию, когда рассказываю о процессах управления инцидентами и выполнения запросов на обслуживание. Оцените и покритикуйте, коллеги.
ITIL® пишет о том, что эти два процесса могут быть одним (как, например, в ISO 20000:2011), но лучше их разделять, потому что:
Инцидент – это обычно событие неожиданное, в то время как запрос на обслуживание можно и нужно планировать… хотя «туманные» области всегда останутся…
© ITIL Service Operation, TSO, 2011
Представьте себя владельцем новенькой автомастерской. Вы решаете задачу: сколько потребуется автомехаников, чтобы обеспечить спрос на ваши услуги?
Решение должно отталкиваться от объёма и структуры этого спроса. Зачем люди приезжают в автосервис? Мне кажется, в трёх случаях:
Ради простоты предполагаем, что автомеханики без специализации, то есть механик сможет помочь клиенту во всех трёх случаях, как, например, сотрудник Service Desk, который может реагировать на самые разные вопросы, не привлекая специализированных ресурсов.
Тогда получается, что 1 – это инциденты, а 2 и 3, конечно же, запросы на обслуживание. Спрос на ваши услуги будет складываться, таким образом, из нормированных (тюнинг и ТО) и ненормированных (вот они, инциденты) работ.
Ура! Приступаем к планированию ресурсов.
Резюмирую: отделять обработку инцидентов от запросов на обслуживание нужно, прежде всего, если вы планируете ИТ-персонал на основе статистики. А в противном случае, какая разница? Всё равно в обоих процессах работают одни и те же механики.