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

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

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

Небольшие улучшения отличаются от масштабных организационных изменений по нескольким ключевым признакам: 1) Масштаб воздействия - небольшие улучшения затрагивают отдельные процессы или небольшую группу сотрудников (например, добавление нового способа взаимодействия с Service Desk), тогда как масштабные изменения влияют на всю организацию или её существенную часть и часто серьёзно затрагивают внешних контрагентов. 2) Сложность реализации - небольшие улучшения, как правило, не очень сложно реализовать на практике, в то время как масштабные инициативы во многих случаях даются непросто. 3) Ресурсные требования - крупные изменения требуют задействования более половины ИТ-сотрудников и затрагивают сотрудников бизнес-подразделений, тогда как небольшие улучшения могут быть реализованы небольшой командой. 4) Уровень сопротивления - масштабные изменения сталкиваются с более сильным индивидуальным и системным сопротивлением, поскольку затрагивают больше людей и процессов. 5) Требования к руководству - небольшие улучшения могут быть успешно реализованы менеджерами, работающими по установленным процессам, тогда как масштабные преобразования требуют лидеров, способных работать в условиях неопределенности и риска.

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

Для выражения эмпатии клиенту у сотрудника должны быть развиты следующие навыки: активное слушание (умение слушать без перебивания, давая клиенту возможность высказаться), признание чувств клиента (выражение понимания того, что он чувствует, например, «Я понимаю, как это может быть неприятно»), контроль собственных эмоций (способность сохранять спокойствие даже в стрессовых ситуациях), корректность в обращении (использование имени клиента, уважительный тон), умение признавать ошибки и извиняться от имени компании, задавание уточняющих вопросов вместо поспешных решений. Также важно умение проявлять искренний интерес к проблеме клиента и демонстрировать готовность помочь. Навыки выражения эмпатии включают в себя также способность искать общие интересы и вовлекать клиента в процесс решения проблемы, чтобы он чувствовал себя частью решения, а не оппонентом.

В ITIL v3 определение инцидента включало два предложения: «Незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования». В ITIL 4 второе предложение отсутствует, и определение стало короче: «Незапланированное прерывание или снижение качества услуги». Однако в руководстве по управлению инцидентами ITIL 4 указано, что практика все равно включает в себя восстановление нормальной работы ресурсов даже если их сбой не виден пользователям. Таким образом, ключевые смыслы остались прежними, различие скорее терминологическое.

Неравномерное поступление инцидентов увеличивает среднее время их решения из-за эффекта очереди. Типичное распределение инцидентов похоже на 'верблюда' - с пиками нагрузки в определенные часы дня (обычно в первой половине). Когда инциденты приходят неравномерно, они попадают в очередь и вынуждены ждать своей очереди, даже если производительность персонала остается неизменной. В наихудшем случае, когда все инциденты приходят одновременно (например, утром), среднее время решения может возрасти в разы. Например, при 24 инцидентах, решаемых персоналом с производительностью 20 минут на инцидент, среднее время решения увеличивается с теоретических 20 минут до 4 часов 10 минут просто из-за эффекта последовательной обработки очереди.

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

Продуктовым командам помогают принципы Site Reliability Engineering (SRE), методики разработки, повышающие надёжность, такие как Test-Driven Development (TDD), сквозное автоматизированное тестирование на всех этапах разработки, интеграции и доставки, а также своевременный контроль и устранение технического долга. Эти подходы позволяют минимизировать риски сбоев при внесении изменений, поддерживать эксплуатационные характеристики приложений и сокращать время поставки за счёт автоматизации и строгого контроля качества на каждом этапе.