Методика агрегирования с динамическими весами значительно усиливает мотивацию сотрудников работать во всех областях ответственности, так как она обеспечивает существенное снижение общей оценки при провале по любому одной метрике. Например, если MS установлен на уровне 50% для критичного показателя, полный провал по нему при 10 общих KPI приведет к падению общей оценки до 50% вместо 90% при среднем арифметическом. Это делает невыгодным стратегию игнорировать какие-то задачи ("Черт с ними, с 10%"). При этом, в отличие от метода произведения, где одно нулевое значение обнуляет всю оценку, в данной методике продолжение работы в других областях после первого провала остается экономически обоснованным, так как каждый следующий провал снижает оценку не катастрофически, а постепенно.

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

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

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

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

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

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

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

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

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