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

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

Критерий «R» (relevant – релевантный) чаще всего вызывает трудности в практическом применении. Основная проблема заключается в том, что люди склонны включать в систему измерения показатели, которые легко или привычно измерять, но не обязательно соответствуют реальным управленческим задачам. Нередко встречаются случаи «отчётности ради отчётности», когда собираются данные, но на их основе не принимаются решения. Ещё хуже, когда метрики мотивируют действия, противоположные изначальным целям, как это происходит в так называемой «палочной системе». Это происходит из-за того, что систему формируют под имеющиеся измерения, а не под реальные потребности.

Отчётность ради отчётности не соответствует критерию «R» (relevant), так как данные собираются и предоставляются без использования их для принятия решений или изменений в управлении. Наличие измеримых показателей («M») не компенсирует отсутствие релевантности. Это приводит к трате ресурсов на создание отчётов без реальной пользы для организации.

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

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

Метрика продуктивности процесса управления проблемами рассчитывается по формуле, где в числитель включаются только проблемы, закрытые с кодом решения из группы 'а' (проблема решена, процесс обработки принес пользу, ресурсы потрачены не зря), а в знаменатель – проблемы из групп 'а' (решенные) и 'б' (закрытые без решения, но с непродуктивной тратой ресурсов). Проблемы из группы 'в' (закрытые без решения, но без вреда и пользы, например, дубли) исключаются из обоих частей формулы. Это позволяет минимизировать влияние непродуктивной активности на метрику.

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

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

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