В контексте управления изменениями по ITIL V3 термин 'Практик' (Practitioner) относится к роли ответственного за координацию работ по отдельным изменениям, в том числе относящимся к определенной области. Из перечисленных в ITIL V3 ролей (владелец и менеджер процесса, инициатор, практик, авторизующий, участник и председатель CAB) именно практик выполняет функции, которые похожи на обязанности менеджера изменений. В более мелких организациях одна и та же роль 'практик' часто объединяла в себе функции менеджера процесса, владельца процесса, администратора изменений и председателя CAB.

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

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

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

Совместимость и правильную компоновку компонентов RBAC регулирует стандарт INCITS 459-2011 «Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control». Этот стандарт описывает допустимые сочетания компонентов (функциональных наборов) и интерфейсы, что обеспечивает правильную интеграцию различных элементов системы RBAC. В то время как INCITS 359-2012 определяет референтную модель и INCITS 494-2012 расширяет её возможностями по обработке динамических ограничений, INCITS 459-2011 отвечает за то, чтобы все эти компоненты могли работать вместе корректно и обеспечивать совместимость между различными реализациями систем управления доступом на базе RBAC.

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

BMC Remedy ITSM Suite оказалась единственным лидером в магическом квадрате Гартнера за 2010 год благодаря оценке ее как надежного и стратегически стабильного партнера, способного поддерживать долгосрочные отношения с корпоративными клиентами. Гартнер оценивает не только технические характеристики продукта, но и способность компании внедрять продукт на предприятиях, поддерживать его развитие и обеспечивать уверенность клиентов в долгосрочной перспективе. В то время как другие компании, такие как HP, IBM и CA, потеряли позиции из-за оценки их маркетинговой и продажной активности, а также стратегического видения развития продукта.

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

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

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