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

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

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

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

Для определения допустимого объема потери данных в случае аварии следует выполнить следующие шаги: - Провести анализ бизнес-процессов для определения критического времени, после которого потеря данных становится невосполнимой для бизнеса. - Оценить, сколько транзакций или операций может быть утеряно без серьезного воздействия на бизнес-операции. - Определить периодичность создания контрольных точек данных или моментов для восстановления. - Проанализировать исторические данные о частоте операций и объеме изменений данных в течение рабочего дня. - Согласовать с бизнес-владельцами максимальный допустимый период потери данных, выраженный в минутах, часах или количестве транзакций. - Учесть нормативные требования и обязательства перед клиентами, которые могут регламентировать допустимую потерю данных. - Рассмотреть финансовые последствия потери данных за различные временные интервалы. - Определить, какие данные являются критически важными и требуют более частого резервного копирования, а какие менее критичны и могут иметь больший допустимый период потери. - Фиксировать допустимый объем потери данных в качестве одного из ключевых показателей уровня обслуживания (RPO - Recovery Point Objective). Правильное определение этого показателя является критически важным для проектирования адекватной системы резервного копирования.

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

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

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

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

Выделяются две основные роли: менеджер изменений и координатор изменений. Менеджер изменений несет ответственность за общий контроль исполнения и организацию работ по проведению изменений в целом. Координаторы изменений отвечают за организацию обработки отдельных запросов на изменения. Координаторы обычно назначаются по функциональному или географическому признакам либо по обоим признакам одновременно. В некоторых моделях, например в IBM Tivoli Unified Process, роль координатора называется 'Владелец изменений'