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

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

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

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

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

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

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

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

Удовлетворённость пользователей не всегда упоминается напрямую в назначении практики управления инцидентами, потому что традиционно основной целью этой практики считается оперативное восстановление работы услуг. Формулировки в ITIL и других стандартах зачастую фокусируются на минимизации негативного влияния инцидентов через быстрое восстановление. Это может приводить к тому, что организации сосредотачиваются преимущественно на скорости решения, упуская из виду другие важные аспекты, влияющие на удовлетворённость. Хотя в более подробных описаниях практик (например, в ITIL 4 Practice Guide) подчёркивается важность удовлетворённости, её отсутствие в краткой формулировке назначения может создавать дисбаланс в приоритетах при внедрении практики. Поэтому есть основания предполагать, что было бы полезно включить удовлетворённость пользователей в формулировку назначения явно.

Expanded Incident Lifecycle — это инструмент, который позволяет разбить время жизни инцидента на отдельные этапы для более детального анализа. При применении в цикле Деминга этот инструмент используется на этапе Планируй (Plan) для измерения средней продолжительности каждого этапа и выявления узких мест. Например, при анализе задержек в управлении инцидентами с помощью Expanded Incident Lifecycle можно обнаружить, что большое время занимает нахождение инцидентов в очереди. Это знание помогает сформулировать гипотезу решения проблемы (такую как немедленное решение простых инцидентов), которая затем проверяется в рамках полного цикла PDCA.