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

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

SIAM (Service Integration and Management) представляет собой подход к управлению услугами в условиях множества поставщиков. Его основная концепция заключается во введении уровня управления, называемого «сервис-интегратор», который располагается между организацией-заказчиком и её поставщиками услуг. Сервисный интегратор отвечает за управление, интеграцию и координацию различных поставщиков, чтобы клиент получал наилучшее качество сервиса и сокращал накладные расходы на управление множеством поставщиков. SIAM описывается в документе «SIAM Foundation Body of Knowledge», который предоставляет методологию для организации потребления услуг в моделях с несколькими внешними и внутренними поставщиками.

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

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

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

Основные проблемы при попытке быстро внедрить SLM включают отсутствие подготовленного бизнес-ориентированного каталога услуг, неготовность формулировать работу в терминах ценности для заказчика и неспособность измерять эту ценность. Кроме того, без предварительного построения каталога услуг организация может столкнуться с несоответствием между заявленными обязательствами в SLA и реальными возможностями, что приведет к недоверию со стороны бизнеса и неэффективному управлению ресурсами.

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

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

Стандарт INCITS 494-2012 определяет три основных интерфейса: интерфейс правил внешней политики, интерфейс аудита и интерфейс унифицированных функций стандарта INCITS 459-2011. Интерфейс правил внешней политики позволяет ограничениям из внешней среды (бизнес-правилам, текущим значениям параметров и т.д.) поступать в движок RBAC. Этот интерфейс может также использовать результаты других точек принятия решений (PDP). Интерфейс аудита обеспечивает получение записей в результате работы движка RBAC, таких как использование прав доступа, отказы в доступе или применение ограничений. Интерфейс унифицированных функций стандарта INCITS 459-2011 обеспечивает синхронизацию движка RBAC и внешней системы в части используемых определений элементов и множеств.