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

Алгоритм, который эффективно работает с бóльшим числом метрик (до десяти), использует взвешенное среднее с динамическими весами. В этом методе вес каждого KPI зависит от его значения: чем ниже значение показателя (чем больше отклонение от целевого), тем выше его вес. Это позволяет значительно усиливать влияние проваленных показателей на общий результат, что решает проблему игнорирования отдельных областей ответственности. Такой подход избегает недостатков как среднего арифметического (малое влияние отдельных провалов), так и произведения (полная бесполезность остальных показателей при одном нуле).

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

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

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

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

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

Четыре основных типа реакции компаний: 1) Месячная премия фактически включена в зарплату, и можно только лишить ее, но не увеличить; 2) Корпоративная политика оплаты труда не позволяет легко встроить процессные метрики для поощрения, разовые премии требуют серьезного обоснования и выдаются за исключительные достижения, а не за стабильные результаты; 3) Отсутствует краткосрочное премирование, годовые премии зависят от общих успехов компании и слишком отдалены от текущих процессов; 4) Наличие системы месячного/квартального премирования, где руководитель может влиять на распределение премиального фонда и регулировать стимулирование сотрудников.

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

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