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

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

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

Time to market формируется из двух компонент: Process Time (время фактической работы над изменением) и Queue Time (время ожидания в очереди). Service Quality обратно пропорционально связана с Change Risk - чем выше риски, тем ниже качество услуг. Чем быстрее проводятся изменения (меньше Time to market), тем выше риски для качества услуг, и наоборот - увеличение требований к качеству (Service Quality) ведет к увеличению времени вывода решений. Release rate (частота внедрений) и Release size (размер релиза) также влияют на эту связь: высокая частота малых релизов снижает риски и способствует ускорению Time to market, тогда как редкие крупные релизы увеличивают риски и замедляют процесс. Также важны Change capability (способность команды проводить изменения) и Change Control Level (уровень контроля изменений), которые определяют, как эффективно и качественно проводятся изменения в системе.

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

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

Стандарт ISO/IEC 20000:2011, раздел 8.1, предъявляет следующие требования к управлению значительными инцидентами: поставщик услуг должен документировать и согласовать с заказчиком определение значительного инцидента; значительные инциденты должны классифицироваться и обрабатываться в соответствии с документированной процедурой; информация о значительных инцидентах должна доводиться до топ-менеджмента; топ-менеджмент должен назначить ответственного за управление каждым значительным инцидентом; после восстановления согласованного уровня услуг должен быть проведен анализ инцидента с целью определения возможностей по улучшению. Эти требования направлены на обеспечение четкого и эффективного управления кризисными ситуациями, которые существенно влияют на бизнес-процессы заказчика.

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

Кратного ускорения поставки задач можно достичь за счет нескольких мер: сокращение количества задач в системе (уменьшение работы в прогрессе), фокусировка на завершении текущих задач вместо начала новых, автоматизация этапов, не добавляющих ценность (например, тестирование), минимизация лишней работы. Эти изменения позволяют снизить время ожидания для задач с 95% до 70% и повысить эффективность потока с 3-10% до 30%, что приводит к трехкратному (и более) увеличению скорости поставки без увеличения числа разработчиков или рабочего времени.

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