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

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

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

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

В контексте процесса управления релизами релиз определяется по-разному в зависимости от организационной модели: если управление релизами осуществляется в подразделении разработки/сопровождения, то релиз представляет собой набор компонент, которые вместе тестируются и внедряются в продуктивную среду; если управление релизами функционирует в подразделении эксплуатации, то релиз определяется как набор изменений, которые вместе тестируются и внедряются в продуктивную среду. Общим является то, что релиз объединяет логически связанные изменения для совместного внедрения.

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

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

99,9% доступности может быть недостаточно для бизнес-процессов по нескольким причинам. Во-первых, этот показатель не учитывает распределение простоя: 0,1% от года составляет около 8,76 часов, что может быть критично, если эти часы приходятся на пиковую нагрузку. Во-вторых, для некоторых бизнес-процессов (например, финтех, здравоохранение) даже короткие простои могут привести к серьезным последствиям. В-третьих, бизнес зачастую зависит от непрерывности процессов: если 8,76 часов простоев приходятся на один раз, это может привести к утрате контрактов и репутационному ущербу, чего не отражает процентный показатель. В-четвертых, заказчик и поставщик услуг могут по-разному интерпретировать этот показатель (в год, месяц, неделю), что создает неопределенность.

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

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