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

Руководящие принципы ITIL Practitioner не являются проходным материалом, потому что они не только упрощают поиск правильных ответов при сдаче экзамена ITIL Practitioner, но и имеют практическое значение для решения реальных задач в ITSM. Они формируют правильный способ мышления, необходимый современным ITSM-профессионалам. Эти принципы позволяют структурировать подход к трансформациям и служат ориентиром в сложных ситуациях, когда необходимо принять важное решение.

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

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

Диагноз «сбой услуги» фокусируется на том, что пользователь перестал получать необходимую услугу, и определяет, какое именно повреждённое звено вызвало проблемы для конечного пользователя. Диагноз «сбой компонента» же касается поиска конкретного физического или программного компонента, который вышел из строя. Первый необходим для оперативного восстановления работы сервиса, второй — для устранения технической причины инцидента. Таким образом, на уровне процессов это различие помогает разделить управление инцидентами и управление проблемами.

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

Существует два основных подхода к управлению полномочиями по изменению сроков: первый — доступ к изменению сроков предоставляется любому ИТ-специалисту при обязательном указании причины переноса, что требует последующего контроля и анализа указанных причин; второй подход – предоставление таких полномочий узкому кругу специально уполномоченных лиц, которые не заинтересованы в искажении статистики и могут объективно оценить необходимость переноса. Второй подход считается более надежным, так как снижает риск произвольного изменения сроков и обеспечивает более качественный контроль.

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

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

Конфигурационная единица — это любой компонент, которым необходимо управлять для предоставления ИТ-услуги. Инцидент может быть связан с конфигурационной единицей, если ее сбой влияет на нормальную работу услуги или если этот сбой выходит за рамки определенной нормы работы. Однако не все сбои конфигурационных единиц являются инцидентами. Например, в случае с RAID-массивом, если система спроектирована так, что выход одного диска не влияет на работу массива, такой сбой не будет инцидентом. Важно понимать, какие компоненты включены в управление конфигурацией и как они влияют на конечную услугу.