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

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

Основное преимущество метода ORBIT заключается в том, что он меняет подход к планированию ITSM-проектов с фокуса на процессах на фокус на результатах. Традиционный подход часто заключается в формулировании целей как «внедрение процесса такого-то», что не дает четкого понимания реальной ценности для бизнеса. ORBIT же заставляет четко определить конкретные результаты, их ценность для бизнеса и ИТ-департамента, а также возможные риски. Это позволяет избежать ситуации, когда проект «живет своей жизнью» отдельно от бизнес-целей и делает результаты проекта измеримыми и понятными всем заинтересованным сторонам.

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

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

Предложение об изменении (Change proposal) является первичным документом. Оно создается на стратегическом уровне в рамках процесса управления портфелем услуг. RFC появляется уже после утверждения Change proposal и служит инструментом для реализации конкретных технических изменений, определенных в высоком уровне планирования.

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

В ITIL4 произошел переход к более гибкой модели классификации услуг через призму парадигмы ресурсы-продукты-услуги. Вместо жесткого разделения на бизнес-услуги и поддерживающие услуги (как в ITIL V3), ITIL4 рассматривает видимость ресурсов для потребителя. Услуги могут иметь разную степень видимости в зависимости от контекста их использования. ITIL4 уделяет меньше внимания терминам 'бизнес-услуга' и 'информационная технологическая услуга', упоминая их лишь раз в описании практики Service Design в контексте SIAM (Service Integration and Management).

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

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