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

CLD предлагает способ агрегирования показателей для управления изменениями, позволяя сгруппировать метрики по ключевым областям управления. Например, для контроля своевременности реализации (Time to Market) можно использовать метрики Lead Time и Percentage of changes timely implemented. Для управления затратами (Cost per change) подходят Process Time и Standard Change Rate. Для оценки негативного влияния от изменений (Change Risk) можно использовать как прямые метрики (Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases), так и опережающие индикаторы (Release size, Emergency change rate). Такое структурирование помогает формировать комплексную картину эффективности процесса изменений.

Да, кратное ускорение возможно без смены персонала, включая программистов, аналитиков, тимлидов и руководителей. Ключевым является фокус на изменении системных аспектов работы, а не на замене людей. Необходимо сосредоточиться на четырёх направлениях: перестроить организацию ресурсов от иерархии к более самостоятельным командам; провести архитектурные изменения для поддержки быстрого цикла разработки; наладить приоритизацию входящих задач с фокусом на бизнес-ценные инициативы; внедрить систему организации производства с управлением потоком создания ценности и ограничениями на текущую работу. Пример деловой игры 'Проект Феникс' показывает, что те же люди, изменив подход к работе, могут ускориться в 15-25 раз без изменения состава команды.

Компании часто совершают следующие ошибки при построении многоуровневой системы поддержки: неправильное распределение ответственности между уровнями, из-за чего задачи задерживаются на определенном уровне; недостаточное обучение сотрудников второго и третьего уровня специфике коммуникации с первым уровнем и пользователем; отсутствие четких SLA между уровнями поддержки и механизмов контроля соблюдения сроков; игнорирование важности человеческого фактора в работе первой линии и недостаточная инвестиция в развитие soft skills сотрудников; чрезмерная формализация процессов, которая замедляет реагирование на критические ситуации. Особенно часто ошибкой является создание сложной структуры без обеспечения ее внутренней согласованности и общих целей для всех участников процесса.

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

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

Четыре аспекта управления ИТ-услугами в ITIL 4 являются эволюцией концепции 4P (Продукты, Процессы, Персонал, Партнеры/Поставщики), описанных в ITIL v3 2011 в книге 'Service Design'. Однако в ITIL 4 эти аспекты расширены и применены не только к этапу проектирования услуг, но ко всей системе создания ценности, включая потоки создания ценности и практики. Вместо продуктов, процессов, персонала и партнеров ITIL 4 предлагает рассматривать: организации и людей (включая персонал и стейкхолдеров), информацию и технологии (заменяя узкое понимание продуктов), партнеров и поставщиков, а также потоки создания ценности и процессы. Это расширение отражает более целостный подход, где аспекты часто перекрываются и не имеют четких границ, и они применимы ко всему жизненному циклу услуг, а не только к их проектированию.

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

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

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