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

Управление доступностью фокусируется на поддержании согласованного уровня операционной доступности ИТ-услуг в обычных условиях, измеряемого как процент времени, когда услуга доступна и работает правильно. Основные мероприятия включают мониторинг, анализ трендов и профилактические работы для предотвращения простоев. Управление непрерывностью направлено на обеспечение восстановления ИТ-услуг после серьезных сбоев или катастроф в установленные сроки RTO и RPO. Оно включает разработку планов, тестирование и поддержание готовности к чрезвычайным ситуациям. Хотя эти процессы тесно связаны и часто объединены в стандартах (как в ISO/IEC 20000), их цели и методы различаются: доступность - это повседневная операционная характеристика, а непрерывность - это готовность к экстремальным ситуациям.

Термин OLA может быть избыточным, потому что содержательно OLA не отличается от SLA, а является всего лишь SLA с другой стороны. Если рассматривать цепочку создания ценности, то то, что для одного участника выглядит как OLA, для другого будет SLA. Примеры из ITIL Service Design показывают, что предлагаемые SLA и OLA очень похожи. Поэтому OLA как отдельная концепция не добавляет ценности и может только запутать при реализации, так как теряет четкое определение и аргументированное обоснование, что и приводит к путанице в практическом применении.

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

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

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

Customer Lead Time - это время ожидания, которое считается от момента принятия решения о реализации задачи (зеленый флажок) до момента поставки результата заказчику. Этот период зависит от количества задач, которые находятся в системе перед рассматриваемой задачей, а также от скорости обработки этих задач. Особенно комично выглядит попытка определить срок поставки задачи именно в момент принятия решения, так как зачастую очередь задач меняется, и точную дату завершения предсказать невозможно.

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

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

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