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

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

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

Ключевые качества для агента изменений - гибкость для встраивания в общий поток изменений компании, умение осознать этот поток во всех его гранях и проявлениях как единое целое, и мотивация для проведения этого потока. Особое внимание уделяется soft skills: широта ума, открытость, чёткость, готовность к диалогу. Даже наличие знаний методологий и опыта является второстепенным, если специалист закрыт к диалогу, невнимателен к реалиям компании и не чуток к команде.

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

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

Выбор показателей доступности зависит от особенностей бизнес-процессов, которые поддерживаются данной ИТ-услугой. Необходимо проанализировать: 1) Как реагирует бизнес на простой - критичны ли для него кратковременные частые нарушения или только длительные простоя; 2) Насколько чувствительны бизнес-процессы к частоте прерываний (например, для вычислительных процессов каждое прерывание требует перезапуска); 3) Каковы финансовые и репутационные последствия простоев разной длительности. На основании этого формируется набор показателей: если бизнес чувствителен к частым простоям, включается показатель «количество нарушений»; если критичны длительные простои - показатель «максимального разового простоя» и так далее. Возможно, некоторые показатели будут иметь больший вес в агрегированной метрике.

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

Управление рисками присутствует в следующих процессах ITIL: 1. В группе процессов проектирования услуг - через управление доступностью, мощностями, непрерывностью и информационной безопасностью, где требуется анализ угроз и внедрение контрмер. 2. В управлении проблемами, особенно в проактивной его части, направленной на предотвращение инцидентов. 3. В постоянном совершенствовании услуг (CSI), где деятельность по улучшению часто приводит к идентификации рисков, а идентифицированные риски запускают новые циклы улучшений. 4. В управлении изменениями и релизами. 5. В управлении портфелем услуг. Все эти процессы содержат элементы идентификации, анализа и управления рисками, что делает управление рисками сквозной практикой в рамках ITIL.

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