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

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

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

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

В разделе Risks (верхний правый квадрант) следует перечислить потенциальные сложности и угрозы, которые могут помешать достижению заявленных результатов. Риски нужно формулировать конкретно и детально, например: «Отсутствие средств мониторинга для контроля параметров предоставления услуг не позволит обеспечить достоверную отчетность», «Недостаточная квалификация персонала для работы с новыми инструментами», «Сопротивление сотрудников внедрению новых процессов». Чем более конкретно и понятно будут описаны риски, тем проще будет разработать стратегию их минимизации и подготовить запасные планы.

COBIT5 for Risk (ранее известный как Risk IT) предлагает строгий, структурированный подход к описанию и управлению рисками. Его отличительной особенностью является учет дополнительных параметров при оценке рисков, таких как прогнозируемая длительность негативного влияния, критичность события относительно календарного периода или времени суток. Документ содержит множество практических примеров, размещенных в виде плашек на полях, и включает сотни примеров рисков, классифицированных по 20 категориям – от управления ИТ-инвестициями и проектами до рисков, связанных с поставщиками, вредоносным ПО, атаками и регуляторами. Для каждого риска указаны соответствующие контрмеры.

Рост доли переоткрытых инцидентов в системе управления может служить признаком снижения качества работы процесса управления инцидентами. Это указывает на то, что решения, принимаемые при первичном обработке инцидентов, не всегда являются окончательными или достаточными, что приводит к необходимости повторной обработки. Такая ситуация говорит о снижении показателя First Time Resolution (FTR) и может отражать недостатки в процессе проверки решений или в первоначальной диагностике проблем, требуя обратной связи и улучшений в работе службы поддержки.

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

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

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