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

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

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

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

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

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

ITIL 4 не упоминает приоритизацию в процессе решения инцидента (Incident handling and resolution), потому что она переквалифицирована из отдельного шага процесса в фактор успеха всей практики управления инцидентами. Приоритизация остается важной, но теперь рассматривается как более широкая концепция, которая необходима для достижения основной цели практики — минимизации негативного влияния инцидентов. Поскольку приоритизация может происходить многократно и на разных этапах работы с инцидентами, её нецелесообразно ограничивать одним отдельным шагом в процессе. Вместо этого она представляется как элемент, который требуется для эффективного выполнения всей практики в целом.

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

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

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