В качестве альтернативы подходу ITIL предлагаются три подпроцесса: Business Capacity Management (управление бизнес-мощностями), System Capacity Management (управление системной мощностью) и Resource Capacity Management (управление ресурсной мощностью). Это деление более точно отражает уровни, на которых происходит управление мощностями, в зависимости от того, как определены ИТ-услуги (через бизнес-процессы, ИТ-системы или ресурсы).

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

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

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

Для определения достаточного уровня полномочий владельца конкретного процесса нужно провести анализ каждой обязанности владельца процесса и оценить степень критичности выполнения этой обязанности для успешного функционирования процесса в конкретной организации. Можно использовать десятибалльную шкалу, где 10 соответствует самой критичной обязанности, без выполнения которой процесс не сможет работать. По результатам оценки выделяют обязанности с высоким баллом (8-10), которые определят минимально необходимый уровень полномочий. Например, если обеспечению ресурсов процесса присвоено 9 баллов, значит владелец должен иметь возможность влиять на все подразделения, участвующие в процессе. Если организации только начинает внедрять процессный подход, высокие оценки получат больше обязанностей, что потребует более высокого уровня полномочий владельца. В зрелых процессных организациях достаточно будет сконцентрироваться на нескольких ключевых обязанностях.

Доверительный интервал для результатов опроса можно рассчитать в MS Excel 2010 следующим образом: стандартное отклонение вычисляется с помощью функции СТАНДОТКЛОН.В(...), доверительный интервал получается вызовом функции ДОВЕРИТ.СТЬЮДЕНТ(a; S; n), где a - уровень значимости, S - стандартное отклонение, n - размер выборки, а коэффициент Стьюдента - функцией СТЬЮДЕНТ.ОБР.2Х(a; n-1). Это позволяет определить границы, в которых с заданной вероятностью будет находиться истинное среднее значение всей генеральной совокупности.

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

Принцип 'Работать «в полях»' означает необходимость непосредственного наблюдения за процессами для понимания реальной ситуации. Хотя измерения тоже важны, непосредственное наблюдение предпочтительнее, поскольку цифры могут искажаться в зависимости от метода расчета. Например, рекомендуется иногда работать пару дней на Service Desk, чтобы лучше понять проблемы и потребности клиентов из первых рук.

Основные причины путаницы: 1) Эффект лампы: измеряется то, что легко увидеть и посчитать (например, количество закрытых тикетов), вместо сложных для измерения бизнес-результатов; 2) Разрыв между ИТ и бизнесом: технические команды часто не понимают бизнес-целей, реализуя технически совершенные, но безрезультатные решения; 3) Культура отчетности вместо культуры создания ценности: фокус на достижении формальных KPI любыми средствами, например, стремление к 'зелёным' показателям без учета реального бизнес-влияния.

Фреймворк OKR (Objectives and Key Results) помогает в измерении результатов, так как Key Results всегда являются метриками результата, а не выхода. Например, цель может звучать как 'Стать №1 по удовлетворённости клиентов в отрасли', а ключевой результат - 'повысить NPS с 30 до 70 пунктов за год'. Это заставляет команду фокусироваться на конечной ценности для бизнеса, а не на промежуточных технических достижениях. OKR помогает связать ИТ-деятельность с бизнес-результатами и измерять реальный вклад ИТ в достижение стратегических целей компании.