Процесс Управления инцидентами обеспечивает прозрачность в работе за счёт своевременной и эффективной передачи информации об инцидентах и их статусах. Для этого процесс должен быть построен так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате через согласованные каналы. Это могут быть электронные письма, SMS, информация на портале самообслуживания (в личном кабинете), телефонные звонки или даже личные визиты в случае работы с VIP-пользователями. Процесс INC должен минимизировать количество повторных обращений пользователей по тем же инцидентам за счёт качественного информирования, что отражается в KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов».

Для непосредственной оценки удовлетворенности заказчика ИТ-услугами могут быть использованы вопросы, направленные на оценку ключевых аспектов услуги. Примерами таких вопросов могут служить: степень удовлетворенности достигаемой utility услуг, степень удовлетворенности достигаемой warranty услуг, степень соответствия показателей warranty реальным потребностям заказчика. Ответы на эти вопросы оцениваются по шкале от 0 до 1, где 0 означает полное несоответствие, а 1 – полное соответствие ожиданиям.

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

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

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

При наличии нескольких заказчиков у одной ИТ-услуги существуют три основных варианта решения: 1) Заключение SLA сразу с несколькими заказчиками, что может серьезно усложнить переговорный процесс и привести к размыванию ответственности бизнес-подразделений; 2) Рассмотрение одного подразделения как заказчика ИТ-услуги, а другого - как потребителя, с заключением SLA только с заказчиком, при этом предполагается, что договоренность с потребителем - это обязанность заказчика, однако это тоже может усложнить переговоры и не всегда устраивает бизнес; 3) Выделение для разных заказчиков отдельных ИТ-услуг, что приводит к росту каталога услуг и необходимости построения более сложных связей между ними, но обеспечивает большую ясность в аллокационной модели. Последний вариант, хотя и создает более сложный каталог ИТ-услуг, часто является наиболее предпочтительным с точки зрения четкого распределения ответственности и аллокации затрат.

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

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

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

Этапы управления рисками в процессах обеспечения качества ИТ-услуг включают: 1) выявление потенциальных угроз, связанных с обслуживанием услуг; 2) классификацию угроз по типам и степеням воздействия; 3) отбор наиболее значимых угроз, основанный на комбинации вероятности наступления и возможного ущерба; 4) разработка и внедрение контрмер для предотвращения или минимизации воздействия угроз; 5) мониторинг реализации угроз и эффективности контрмер, а также анализ инцидентов при возникновении проблем. Такой подход позволяет создавать устойчивые ИТ-услуги, готовые к критическим ситуациям.