Нет, время ожидания ответа пользователя на дополнительные вопросы ИТ-специалиста не должно учитываться в расчете времени выполнения SLA. Поскольку пользователь может отвечать на вопросы с задержкой по разным причинам (совещания, отпуск и другие приоритеты), это время следует исключать из общего срока устранения инцидента. Однако для предотвращения злоупотребления этим механизмом важно контролировать периоды ожидания ответа пользователя и не давать специалистам необоснованно долго задавать уточняющие вопросы.

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

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

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

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

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

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

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

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

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