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

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

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

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

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

Базовое состояние (baseline) в управлении конфигурациями связано с V-моделью как 'семейный портрет на память' системы в определенный момент времени. На нисходящей ветке V-модели формируются проектируемые базовые состояния на разных уровнях детализации, от бизнес-требований до технических спецификаций. На восходящей ветке создаются фактические базовые состояния (реальные 'фотографии' системы). Сравнение текущего состояния системы с базовым позволяет определить, насколько проект отклонился от плана, и принимать решение о соответствии результатов требованиям. Простыми словами, базовое состояние — это эталон для сравнения, 'точка отсчета', зафиксированная в определенный момент времени

Критические факторы успеха (CSF) в ITILv3 представляют собой условия, которые должны выполняться, или действия, которые должны происходить, чтобы можно было утверждать, что процесс достигает успеха. Каждый процесс, описанный в пяти книгах ITILv3, имеет свои конкретные CSF и примеры ключевых показателей эффективности (KPI), которые формулируются на их основе. CSF служат основанием для определения, при каких условиях процесс можно считать успешным или неуспешным.

Для описания процесса работы с учетом разных типов участников необходимо создать общий регламент, состоящий из обязательных этапов, а затем для каждого типа участника определить, как они должны действовать на каждом этапе. Как в примере с лебедем, щукой и раком, общий регламент может быть: загружаем-впрягаемся-тянем-выгружаем. Но на этапе 'тянем' лебедь должен взлететь и лететь вдоль берега на определенной высоте, щука - нырнуть и двигаться под водой, а рак - ползти назад. То же самое применимо к ИТ-процессам, где общий процесс управления изменениями остается одинаковым, а модели изменений учитывают особенности выполнения этапов для разных систем.

Оценка 10-20% (100-200 ответов при 1000 пользователях) основана на здравом смысле и интуитивных предположениях, но с математической точки зрения эта оценка завышена. Анализ с использованием доверительных интервалов и распределения Стьюдента показывает, что даже при выборке в 40-50 человек достигается достаточная точность (ошибка 0.25-0.5 балла при 95% вероятности), и дальнейшее увеличение размера выборки приводит к незначительному повышению точности.

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