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

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

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

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

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

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

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

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

В ITIL проблема определяется как корневая причина одного или нескольких инцидентов, но не обязательно множественных. Даже единичный инцидент с высоким бизнес-воздействием (например, остановка платежной системы на час) требует анализа проблемы, так как его повторение недопустимо. Кроме того, управление проблемами включает работу с потенциальными рисками, выявленными без привязки к реальным инцидентам, например, через анализ тенденций в ИТ-инфраструктуре.

Процесс EDM01 «Обеспечение создания и обновления подхода к руководству» отвечает за управление системой руководства ИТ. Его задача заключается в обеспечении создания и поддержания практики руководства ИТ, то есть он обеспечивает формирование и обновление подхода к руководству. Объектом этого процесса выступают сами процессы руководства (EDM02–EDM04). Практики процесса EDM01 включают оценку текущего состояния системы руководства, определение направления её развития и мониторинг эффективности системы руководства.