Для организации реагирования на инциденты существуют такие стандарты как ГОСТ Р ИСО/МЭК 18044-2007 (Информационная технология - Методы и средства обеспечения безопасности - Менеджмент инцидентов информационной безопасности) и E.409 (Организация по реагированию на инциденты и обработка инцидентов безопасности: Руководство для организаций электросвязи). Эти документы содержат рекомендации по управлению инцидентами и организации реагирования.

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

Эффективная работа с поставщиками услуг в рамках ITIL строится на четком определении ожиданий и метрик успеха. Сначала создайте каталог услуг, описывающий все услуги, предоставляемые как внутренними, так и внешними поставщиками, с четкими SLA и OLAs. Тщательно проработайте договоры с поставщиками, включив в них измеримые KPI и последствия за их невыполнение. Установите регулярные встречи с ключевыми поставщиками (не реже раза в месяц) для обсуждения выполнения SLA, выявления проблем и планирования улучшений. Создайте единую систему управления инцидентами, которая включает как внутренние, так и внешние поставщики, чтобы обеспечить сквозное отслеживание проблем. Внедрите процесс управления поставщиками (Supplier Management), который включает оценку, выбор, управление отношениями и выход из отношений. Обеспечьте прозрачность затрат поставщиков через регулярные финансовые отчеты и анализ стоимости услуг. Для критически важных поставщиков создайте совместные планы непрерывности бизнеса. Проводите регулярные аудиты поставщиков для проверки соответствия требованиям безопасности и качества. Внедрите систему оценки поставщиков на основе их вклада в бизнес-результаты компании, а не только технических показателей.

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

Книга рекомендует даже в ситуациях, когда ИТ-подразделение находится внутри компании, рассчитывать стоимость услуг и управлять ИТ-подразделением почти как бизнесом (more like a business), даже если фактических взаиморасчетов с бизнес-подразделениями нет. Это позволяет ИТ-руководству более четко обосновывать затраты, выстраивать сервисные отношения с бизнесом, определять приоритеты развития и доказывать ценность ИТ для компании. Учет стоимости услуг помогает в принятии решений о развитии или закрытии тех или иных сервисов и делает ИТ-менеджмент более прозрачным и понятным для бизнес-руководства.

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

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

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

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

'Человек процесса' должен обладать волей, упорством и готовностью работать в условиях организационной инерции. Он должен уметь преодолевать сопротивление, внедрять изменения и поддерживать процессы в актуальном состоянии. Это требует многолетних усилий, так как результаты такой работы проявляются не сразу, но со временем становятся основой стабильности и эффективности организации.