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

Практические упражнения, помогающие понять разницу между товаром и услугой, включают в себя анализ примеров из реальной жизни с акцентом на выявление рисков и затрат, которые клиент перекладывает на поставщика. Например, участникам предлагают взять простой товар (шоколадку, автомобиль) и преобразовать его в услугу, определяя: 1) Какие риски и затраты клиент может переложить на поставщика; 2) Какие ресурсы необходимы для предоставления услуги; 3) Какие операции должен выполнять поставщик. Другой вариант упражнения - анализ существующих бизнес-моделей (каршеринг vs покупка автомобиля, аренда жилья vs покупка квартиры) и выделение компонентов услуги: товара, ресурса и операций. Эти упражнения помогают участникам глубже понять концепцию услуги в рамках ITIL4.

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

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

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

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

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

KPI из книг и других источников зачастую являются только примерами, взятыми для иллюстрации. Их нельзя просто скопировать в свой процесс, так как они не отвечают на конкретные цели измерения. Каждая организация должна разрабатывать собственные KPI, исходя из целей, назначения, ключевых практик. Механический заимствованных примеров без понимания назначения метрик приводит к тому, что они не помогают в принятии управленческих решений, так как не связаны с конкретными бизнес-целями и задачами процесса.

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

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