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

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

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

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

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

В HP OpenView Service Desk используется, по мнению автора, более рациональное деление по сравнению с HP SM или BMC Remedy ITSM Suite. В OpenView деление сделано по принципу различия между инфраструктурными инцидентами и обращениями пользователей, в то время как в других системах деление чаще проводится между инцидентами и сервисными запросами. В реальной практике разница в обработке инцидента, поданного пользователем, и сервисного запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя. Это подразумевает разную классификацию, разные процедуры выявления/регистрации и разные процедуры закрытия для этих двух основных типов случаев.

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

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

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

Для расчета общего интегрального показателя при большом числе KPI рекомендуется применять многоступенчатый подход. Сначала разбивают все KPI на логические группы, для каждой из которых рассчитывают отдельный интегральный показатель (используя подходящий метод агрегирования). Затем полученные групповые показатели объединяют для формирования общего интегрального показателя. Например, при оценке качества множества услуг можно создать три группы: mission-critical, business-critical и обычные услуги. Для каждой категории рассчитывают свой интегральный показатель, после чего общий результат получают через среднее арифметическое или геометрическое (с возможным применением весовых коэффициентов, отражающих важность каждой группы).