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

Google использовала несколько методов для анализа эффективности менеджеров в рамках Project Oxygen: интервью с сотрудниками, анализ данных по методу «360 градусов» за несколько лет, специальные опросы уходящих из компании сотрудников, оценку поставленных KPI – оценку эффективности деятельности и оценку менеджера сотрудниками. Эти методы позволили получить комплексное представление о том, какие качества руководителей влияют на результаты команды, а какие приводят к снижению эффективности. Многократные проверки данных помогли определить восемь ключевых компетенций, которые теперь используются при обучении и оценке менеджеров в Google.

Когда обе метрики равны (K1 = K2 = X%), геометрическое среднее дает K = X%, что логично: достигнутый баланс оценивается на уровне его качества. Например, при X=90% K=90% показывает, что высокая своевременность и результативность приводят к высокому общему показателю. При X=50% K=50% отражает средний уровень выполнения задач. Эта линейная зависимость сохраняется только при балансе, тогда как дисбаланс резко снижает K, что усиливает стимул к устранению перекосов.

Tmin определяется как время, в течение которого простои не оказывают измеримого влияния на бизнес-процессы, и устанавливается совместно с заказчиком на основе анализа критичности сервисов. Tmax формируется как компромисс между максимально допустимым простоем для бизнеса (часто близким к Tmin) и реальными возможностями ИТ-подразделения с запасом (как правило, значительно дольше). Например, бизнес может требовать восстановления за 30 минут (Tmin), тогда Tmax устанавливается в 4 часа, учитывая текущие возможности ИТ.

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

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

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

Наличие буквы A (Accountable) в RACI-матрице означает, что человек является ответственным за конечный результат работы, что подразумевает наличие не только полномочий, но и реальных механизмов контроля. Без таких механизмов ответственность становится формальной, так как невозможно гарантировать качество и своевременность выполнения задачи. Поэтому при обнаружении символа A важно сразу определить, какими конкретными инструментами и ресурсами будет обеспечиваться контроль. Это может быть отдельная система отчетности, регулярные встречи, специальные программные инструменты мониторинга или другие методы. Если консультанты при составлении матрицы не предусмотрели эти механизмы, у руководителя есть возможность потребовать их предоставления до окончательного утверждения матрицы.

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

Основная особенность применения цепочки создания ценности в ITIL версии 4 заключается в том, что она становится центральным элементом общей концепции управления услугами, тогда как в ITIL v3 такой концепции не существовало. В ITIL v4 введены 34 управленческие практики, которые организованы вокруг цепочки создания ценности (Service Value Chain), состоящей из шести ключевых компонентов: планирование, улучшение, участие, получение заказа, построение и доставка, а также управление. Эта архитектура позволяет рассматривать все ИТ-деятельность как связанный процесс создания ценности для клиента. По сравнению с ITIL v3, где акцент делался на отдельные процессы и их оптимизацию, ITIL v4 предоставляет более целостный взгляд на то, как различные практики работают совместно для создания ценности, что делает его концептуально ближе к IT4IT, который с самого начала был построен на основе Value Chain.