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

Для практики управления инцидентами (Incident Management) в ITIL 4 примеры факторов успеха практик (PSF) и соответствующих ключевых показателей эффективности (KPI) включают: PSF «раннее выявление инцидентов» с KPI: время между возникновением и обнаружением инцидента, доля инцидентов, выявленных с помощью мониторинга. PSF «быстрое и эффективное решение инцидентов» с KPI: время, затраченное на диагностику, рейтинг устранения с первой попытки. Эти примеры демонстрируют связь между факторами успеха и конкретными измеряемыми показателями, используемыми для оценки эффективности практики.

Срочное изменение предполагает определённый временной приоритет, но допускает относительную градацию (например, «очень срочно» или «не так срочно»), что часто ведёт к злоупотреблению термином. Экстренное изменение (emergency) в ITIL — это категория, не подразумевающая градаций: оно требует немедленного выполнения без отлагательств, так как связано с критическими сбоями или угрозами безопасности. Например, если сервис полностью недоступен для клиентов, это emergency — все ресурсы переключаются на его исправление, тогда как «срочное» изменение может укладываться в запланированные сроки.

Информация о major-инциденте для первой линии поддержки должна включать: описание происшествия с указанием, что произошло и в какое время, ожидаемое время решения; уникальный идентификатор инцидента (ID) для установки связей с поступающими обращениями пользователей; оценку влияния на ИТ-услуги, опирающуюся на данные CMDB, чтобы понимать, каким пользователям и в какой степени оказывается влияние, а также уровень критичности проблемы. Эти данные позволяют первой линии давать точные ответы на вопросы пользователей и управлять потоком обращений.

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

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

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

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

CMDB (Configuration management data base) - это специализированная база данных, предназначенная для хранения информации о компонентах ИТ-инфраструктуры и их взаимосвязях. CMDB служит центральным хранилищем данных конфигурационных единиц (КЕ), включая их атрибуты, статусы и зависимости. Эта система позволяет ИТ-организациям получить единую точку зрения на все элементы инфраструктуры, что критически важно для эффективного управления изменениями, инцидентами и проблемами. CMDB обеспечивает прозрачность и понимание того, как различные компоненты взаимодействуют между собой и поддерживают конечные пользовательские услуги.

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