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

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

Чтобы понять, есть ли в вашем потоке проблема с отложенными задачами, достаточно провести упражнение по картированию потока. Необходимо детально пройтись по каждому этапу потока, определить, какие из них создают ценность, а какие только создают задержки. Если в вашем потоке есть этапы, аналогичные 'Отложено' или 'Заблокировано', которые не добавляют ценности и позволяют задачам простаивать, это указывает на проблему. Также можно оценить, как много задач зависает на определенных этапах, какое время они там проводят и какие причины объявляются для задержек. В результате такого анализа станет понятно, превратился ли ваш поток в обычный бизнес-процесс.

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

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

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

Вместо показателя SPI из EVM предлагается применять показатель, рассчитываемый как средневзвешенный рейтинг своевременности выполнения проектных задач. В этом методе рейтинг Ri можно рассчитывать как отношение плановой длительности выполнения задачи к фактической длительности, чтобы выровнять целевую динамику с Cost Performance Index (CPI). В качестве веса Wi может использоваться, например, трудоёмкость задачи. Альтернативно, можно оценивать сроки по отклонению от даты прохождения последней контрольной точки проекта, что даёт более точное представление о реальном соблюдении временных рамок.

Рекомендуется применять график, аналогичный японским свечам в биржевой аналитике. На нём среднее значение отображается как центральная точка, а минимальное — как нижняя граница интервала. Например, для каждого месяца строится вертикальный отрезок от минимального показателя до среднего, что визуализирует диапазон стабильности. Дополнительно можно добавить цветовую индикацию (зелёный при среднем >90%, жёлтый при 70-90%, красный при <70%) для быстрой оценки. Такой формат позволяет увидеть долгосрочные тренды и единичные сбои за несколько кликов.

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

При работе на стороне заказчика задачи поступали главным образом из четырёх источников: 1. Руководство 2. Подчинённые 3. Клиенты (автор упоминает, что их тогда называли пользователями ИТ, но по сути это были клиенты) 4. Собственные инициативы и усилия автора