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

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

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

Стандарт INCITS 494-2012 делит ограничения на статические и динамические. Динамические ограничения включают: Роль-роль (запрет на одновременное использование ролей в одной сессии), Пользователь-роль (запрет пользователям исполнять данную пару ролей параллельно) и Атрибут (запрет на использование роли или прав доступа в зависимости от значения атрибута, такого как время суток, местоположение, цель использования и другие). Статические ограничения включают: Роль-роль (запрет на назначение роли конкретному пользователю), Пользователь-роль (запрет определённым пользователям быть назначенными на пару ролей), Права доступа-права доступа (запрет на комбинации прав доступа в роли) и Права доступа-роль (запрет на использование конкретных прав доступа в определенной роли).

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

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

Уровень "категория процессов" представляет собой наивысший уровень процессов предприятия в структуре PCF. Категории обозначаются целыми числами с точкой после целого числа (5.0, 8.0, 11.0). Примеры категорий, приведенные в тексте: Управление обслуживанием клиентов, Управление финансовыми ресурсами, Управление внешними связями. Этот уровень является самым общим и охватывает широкие области деятельности предприятия.

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

ITIL рекомендует четко обозначать и устанавливать реалистичные сроки выполнения для инцидентов и запросов на обслуживание, отражая разную срочность и сложность этих категорий. Сроки для инцидентов должны быть определены исходя из уровня их влияния и важности для бизнеса, с акцентом на максимальное сокращение времени простоя. Для запросов на обслуживание сроки могут быть более предсказуемыми и стандартными, так как они представляют собой регулярные операции, которые можно запланировать. Важно, чтобы эти сроки были согласованы с заказчиком и отражены в SLA, обеспечивая прозрачность ожиданий для всех заинтересованных сторон и позволяя объективно измерять соблюдение этих сроков.

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