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

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

Disaster Recovery Institute International (DRII) выделяет 10 компонентов управления непрерывностью: запуск программы и управление, управление рисками и контроль, анализ влияния на бизнес-процессы, стратегии непрерывности бизнеса, реагирование в случае нештатной ситуации, внедрение плана и документирование, обучение и поддержание осведомленности, испытания, аудит и оценка плана, кризисные коммуникации, взаимодействие с внешними сторонами.

ITIL 4 расширил применение четырех аспектов управления на всю систему создания ценности потому, что услуги не ограничиваются только этапом проектирования, а создают ценность на протяжении всего своего жизненного цикла через взаимодействие всех компонентов организации. В ITIL v3 2011 концепция, похожая на четыре аспекта (4P: Продукты, Процессы, Персонал, Партнеры), применялась преимущественно к этапу проектирования услуг. Однако в современных условиях, с развитием гибких методологий и усложнением ИТ-экосистем, стало очевидно, что эти компоненты влияют на все этапы создания и предоставления услуг. Расширение применения четырех аспектов на всю систему создания ценности отражает более глубокое понимание того, что организация должна интегрированно управлять услугами на всех стадиях их жизненного цикла. Это позволяет более гибко реагировать на изменения, обеспечивать согласованность между стратегией и операционной деятельностью и лучше удовлетворять потребности пользователей через согласованные потоки создания ценности.

Для отслеживания прогресса в снижении Time to Market должны использоваться следующие ключевые метрики: непосредственно время от формирования идеи до выхода на рынок (Time to Market) в абсолютных значениях и относительном сравнении периода к периоду; процент задач, взятых в работу и успешно завершённых (для оценки эффективности процесса); объём выполненной работы, измеряемый количеством завершённых задач за фиксированный период; циклическое время (cycle time) - среднее время выполнения одной задачи; и обратная связь о влиянии выпущенного функционала на бизнес-показатели (доход, удовлетворённость пользователей, рост показателей использования). Важно, чтобы метрики фокусировались на конечных результатах, а не на процессных активностях, таких как количество спринтов или поставленных в задачу часов.

Важно получать обратную связь от пользователей с умеренной удовлетворенностью, так как именно они составляют большую часть аудитории и их опыт наиболее близок к среднему уровню качества обслуживания. Если система обратной связи настроена так, что собирает только крайние оценки (очень довольные или очень недовольные), организация не сможет понять, насколько ее услуги удовлетворяют основную массу клиентов. Это приведет к искаженной картине и неправильным решениям при улучшении услуг. Баланс всех типов отзывов дает более полное представление о реальном состоянии дел.

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

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

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

Для эффективного управления проблемами необходимо: 1) Четко отличать проблемы от инцидентов и не смешивать эти понятия; 2) Сформулировать бизнес-ценность управления проблемами и оценить негативное влияние от инцидентов; 3) Сфокусироваться на проактивной деятельности, а не только на реактивной; 4) Обеспечить доступ сервисных команд к базе известных ошибок (KEDB); 5) Регулярно измерять эффективность работы в управлении проблемами; 6) Инвестировать в устойчивость систем и обучение персонала; 7) Постоянно анализировать эффективность обходных решений и оценивать целесообразность применения постоянных решений.