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

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

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

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

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

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

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

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

Методология формирования ИТ-бюджета по ITIL состоит из пяти основных этапов: получение бизнес-планов через Business Relationship Management (BRM) и Service Level Management (SLM), согласование планов потребления услуг с клиентами (SLM и управление емкостью сервисов), подготовка планов по ресурсному обеспечению включая персонал (Resource Capacity Management), вычисление стоимости ресурсов и услуг с аллокацией косвенных затрат (Financial Management for IT), и окончательный расчет стоимости услуг на основе потребления, приводящий к обоснованному операционному бюджету ИТ.

Согласно информации, приведенной в тексте, руководитель тратит от 50 до 90% своего рабочего времени на коммуникации. Это подчеркивает огромную значимость коммуникационных процессов в работе руководителя и управлении организацией. Большой объем времени, затрачиваемый на коммуникации, объясняется необходимостью взаимодействия с различными заинтересованными сторонами, передачи информации, получения обратной связи, разрешения конфликтов и согласования решений. Также это объясняет, почему проблемы с коммуникациями становятся одной из главных препятствий в достижении организационной эффективности, поскольку даже небольшие улучшения в коммуникационных процессах могут значительно повысить производительность руководителя и всей организации в целом.