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

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

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

Определение оптимального количества стандартных изменений зависит от рационального баланса между охватом типовых задач и избежанием избыточной детализации. Стандартные изменения должны быть сформулированы максимально конкретно и представлять собой заранее определенные процедуры с минимальной степенью неопределенности. Число стандартных изменений не должно стремиться к максимальному, охватывая каждую возможную ситуацию, так как это может привести к увеличению сложности управления и снижению гибкости процесса. Целесообразно определить наиболее часто возникающие и повторяющиеся задачи, для которых можно разработать четкие инструкции, назначить исполнителей и установить сроки выполнения. Ключевые критерии выбора стандартных изменений включают: - Повторяемость и предсказуемость процесса, - Низкий уровень влияния на бизнес-процессы и ИТ-инфраструктуру, - Минимальное количество необходимых согласований, - Возможность нормирования по времени выполнения. При этом важно учитывать, что координаторы изменений должны иметь полномочия на корректировку стандартных процедур в рамках установленных границ, поскольку полное прописывание всех возможных ситуаций может быть неэффективным.

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

Для определения потоков, запускаемых на различных этапах путешествия заказчика, необходимо провести детальный анализ взаимодействия между этапами путешествия и видами деятельности потоков создания ценности. Нужно выявить, на каких этапах происходит предъявление спроса со стороны потребителя (заказчика или пользователя) и какие потоки при этом активируются. Например, на этапе Offer, когда собираются требования к услуге, запускается поток Engage. На этапе Co-create, когда пользователь обращается за решением инцидентов, запускаются соответствующие потоки предоставления услуги. Для точного определения таких связей требуется пошагово пройти путешествие заказчика и сопоставить каждый этап с соответствующими потоками.

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

Шаг Plan (Планируй) в цикле Деминга предполагает разработку плана улучшений, формулировку гипотез и определение метрик для измерения результатов. В то время как шаг Act (Корректируй) сосредоточен на принятии решений относительно дальнейших действий после анализа результатов проверки (Check). Act включает либо внедрение успешных улучшений в постоянную практику, либо игнорирование неудачных результатов, либо запуск цикла заново с учетом накопленного опыта. Таким образом, Plan направлен на планирование изменений, а Act — на определение дальнейшего развития процесса после реализации и оценки этих изменений.

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

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