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

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

При анализе рисков учитываются три уровня вероятности: 1) Вероятность появления источника риска или угрозы, которая определяется внешними факторами и средой, в которой функционирует организация. 2) Вероятность того, что появление угрозы приведет к наступлению нежелательного события, что зависит от уровня уязвимости системы. 3) Вероятность того, что произошедшее событие вызовет конкретные негативные последствия для организации, что может варьироваться в зависимости от эффективности системы реагирования и других внутренних факторов. Каждый уровень требует отдельной оценки для формирования комплексной картины риска.

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

В примерах политик процесса Управления инцидентами (INC) прямо указано: «Информация об инцидентах и их статусах должна своевременно и эффективно передаваться. Это предполагает наличие хорошего service desk для координации коммуникации информации об инцидентах тем, кто работает над инцидентами». Это означает, что процесс должен быть организован так, чтобы обеспечивать непрерывную и понятную коммуникацию между всеми участниками процесса: пользователем, Service Desk и группами, работающими над устранением инцидента. Service Desk выступает центральным звеном в координации этой коммуникации и несёт ответственность за передачу информации пользователю.

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

Согласно книге «ITSM. Руководство по измерению» коллег Дмитрия Исайченко и Романа Журавлева, для разработки процессных метрик следует придерживаться следующего подхода: установить назначение процесса, разработать метрики соответствия назначению, установить ключевые практики, разработать метрики ключевых практик. Шаги по установлению назначения процесса обычно не вызывают сложностей, тогда как определение ключевых практик и связанных с ними метрик может представлять трудности, несмотря на наличие рекомендаций в таких фреймворках, как ITIL и COBIT5.

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

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

Оценка удовлетворённости заказчика услугой проводится через регулярные опросы (формальные) и неформальные разговоры (например, 'у кулера'). Нужно прямо спрашивать заказчика, доволен ли он услугой, выявлять конкретные причины недовольства, если таковые имеются, и определять, что можно улучшить, даже если заказчик доволен. Важно получать как позитивную, так и негативную обратную связь, чтобы понимать, какие аспекты услуги ценятся, а какие требуют корректировки. Эта информация служит основой для выявления путей улучшения услуг через программу SIP.