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

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

В психологическом контексте удовлетворённость определяется как субъективная оценка качества тех или иных объектов условий жизни и деятельности жизни в целом отношений с людьми самих людей включая самооценку. Это определение взято из Большого психологического словаря 2004 года которое подчеркивает субъективный характер данного понятия но не отменяет его важности в практических измерениях и бизнес-процессах.

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

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

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

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

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

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

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