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

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

Частыми примерами недостоверных утверждений являются фразы вроде «внедрение ITSM-программы повысило эффективность персонала более чем на 80%» или «применение управления инцидентами сократило количество инцидентов на 40%». Такие данные не имеют четкой привязки к реальным случаям и противоречат целям самих процессов, указывая на возможную манипуляцию фактами в маркетинговых целях.

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

Стандарт INCITS 494-2012 представляет собой расширение основного стандарта INCITS 359-2012, разработанное для устранения критики 'чистого' RBAC за его негибкость в условиях изменчивого окружения. В то время как INCITS 359-2012 описывает базовую модель RBAC с её компонентами, INCITS 494-2012 расширяет возможности RBAC в части обработки динамических ограничений. Он позволяет внешним политикам и правилам создавать ограничения на уровне ядра RBAC, которые могут применяться к базовым множествам (пользователям, ролям, операциям, объектам и правам доступа). Стандарт 494-2012 вводит обработку не только разделения обязанностей, но и других типов ограничений, таких как время суток, местоположение и т.д.

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

Availability (Availability) представляет собой показатель, определяющий, насколько система, компонент или услуга могут быть использованы в заданное время. В технической надежности, согласно ГОСТ 27.002-89 (ГОСТ Р 53480-2009), этот термин переводится как «готовность». В ITIL и ISO/IEC 20000 он трактуется как «доступность». Разница кроется в контексте применения: «готовность» акцентирует внимание на технической способности системы функционировать, тогда как «доступность» в ИТ-управлении связана с предоставлением услуги пользователю. Термины отражают разные аспекты одной метрики и требуют уточнения в документах для избежания неоднозначности.

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

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

Для улучшения анализа зрелости процессов предлагается дополнить радар зрелости показателем результативности процессов. Результативность процессов измеряется по шкале от 0 до 100% и отражает фактическую пользу, которую процессы приносят организации. Зрелость также можно привести к этой шкале, что позволяет объединить обе оценки на одной диаграмме. На таком общем радаре линия результативности показывает текущую пользу процессов, а линия зрелости — степень уверенности в том, что эта польза будет достигаться стабильно в будущем, даже при изменяющихся условиях.