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

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

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

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

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

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

Фраза 'Целое больше суммы его частей', приписанная Аристотелю, является основой целостного подхода, подчеркивающего, что никакая услуга, практика, процесс, отдел или поставщик не существуют в одиночку. Это означает, что организация должна работать интегрированным образом, управляя своей деятельностью в целом, а не отдельными ее частями. Данный принцип отражен в руководящих принципах ITIL 4, в частности в принципе 'Используйте целостный подход' (Think and work holistically). При таком подходе важно понимать, как все части организации работают вместе интегрированным образом, а услуги предоставляются посредством координации всех необходимых компонентов без выборочного внимания к отдельным элементам системы.

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

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

С управлением сервисными активами и конфигурациями тесно связаны следующие разделы процесса управления изменениями: идентификация конфигураций, управление версиями, управление интерфейсами, управление поставщиками, управление релизами и развертыванием, управление сборками ПО, создание и поддержка базовых состояний, сопровождение CMDB, закупка и списание конфигурационных единиц, верификация и аудит CMS. Кроме того, существует тесная связь с такими процессами как управление основными средствами, управление проектами, управление разработкой и тестированием, управление взаимоотношениями с поставщиками и подрядчиками. Эффективное управление изменениями невозможно без корректного отображения конфигурационных единиц и их взаимосвязей в CMDB.