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

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

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

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

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

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

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

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

Наиболее часто встречающиеся ошибки при расчёте Incident Rate — это неверный учёт пользователей (например, включение технических учётных записей или уволенных сотрудников), игнорирование сезонных колебаний при анализе данных за короткий период, а также включение в числитель инфраструктурных инцидентов или сервисных запросов. Чтобы избежать искажений, рекомендуется использовать годовые данные с разбивкой по месяцам и проверять качество данных в ITSM-системе.

Пользователь (user) - это тот, кто непосредственно пользуется ИТ-услугами в своей работе. Заказчик (customer) - это тот, кто определяет потребности, формирует задачи и, главное, оплачивает услуги. Заказчик может не использовать услугу напрямую, но влиять на формирование каталога услуг и бюджета. Например, руководитель подразделения может являться заказчиком для ИТ-службы, даже если он лично не использует все предоставляемые услуги.