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

В ITIL V3 ответственность за координацию изменений формально не закреплена за конкретной ролью. Вместо этого упоминается, что координация является частью процесса управления изменениями в целом и может быть возложена на различные лица в зависимости от ситуации. Это могут быть менеджер процесса, практик изменений или участники CAB (Change Advisory Board). Например, в главе 4.2.5 описываются активности по координации, но не уточняется, кто именно их выполняет. Таким образом, ITIL предоставляет гибкость в распределении ответственности, ориентируясь на особенности организации, но это может привести к неоднозначности при внедрении процесса.

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

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

В расширенном RBAC (стандарт INCITS 494-2012) атрибуты используются для создания динамических ограничений на основе внешних факторов. Атрибутами могут быть: определенный период времени в сутках, местоположение пользователя, цель использования системы, класс пользователя, значение определенного типа данных и тип учетной записи. Например, можно создать правило, которое запрещает доступ к финансовым операциям вне рабочего времени или ограничивает использование определенных ролей только в офисе компании. Атрибуты позволяют сделать систему управления доступом более гибкой и адаптированной к изменяющимся условиям, добавляя контекстную зависимость к правилам доступа, что преодолевает недостатки 'чистого' RBAC.

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

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

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

Характерными признаками процесса управления релизами в подразделении разработки/сопровождения являются: обработка только нестандартных запросов на изменения, самостоятельная авторизация изменений на CAB'е (без участия процесса управления изменениями), работа только с изменениями в приложениях (изменения в инфраструктуре обрабатывает процесс управления изменениями), и определение релиза как набора компонент, которые вместе тестируются и внедряются в продуктив. Такой подход соответствует описанию в BMC Service Management Process Model (SMPM).

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