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

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

В основе парадигмы ITSM лежат такие стандарты и фреймворки, как ITIL (Information Technology Infrastructure Library), COBIT (Control Objectives for Information and Related Technologies), ISO/IEC 20000 (международный стандарт для управления ИТ-услугами), MOF (Microsoft Operations Framework) и другие. ITIL является наиболее распространённым подходом и определяет набор лучших практик по управлению ИТ-услугами, охватывающий все аспекты жизненного цикла сервисов. Эти стандарты предоставляют общую основу для построения процессов ITSM, определяя цели, процессы, функции и метрики для эффективного управления ИТ-услугами.

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

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

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

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

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

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

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