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

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

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

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

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

При практическом применении метрик FLR и FCR часто возникают две основные проблемы. Первая связана с излишней задержкой обращения на первой линии – сотрудники могут удерживать звонок слишком долго в попытке разрешить максимальное количество обращений. Вторая и более сложная проблема заключается в правильном определении значения N для расчёта – общего количества релевантных обращений, так как часть заявок физически невозможно решить на первой линии из-за ограничений регламентов, политик или отсутствия необходимого уровня доступа у сотрудников первой линии.

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

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

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

Владелец услуги (service owner) отвечает за сквозное управление конкретной ИТ-услугой, тогда как менеджер уровня услуг фокусируется на достижении и соблюдении договоренностей об уровне услуги между поставщиком и заказчиком. В ITILv3 есть таблица сравнения этих ролей (Table 6.8 Comparison of CSI manager, service level manager, service owner and business relationship manager roles), но эта таблица скорее порождает вопросы, чем дает четкие ответы о границах ответственности между этими ролями. На практике в большинстве организаций найти достаточно убедительный ответ на вопрос о проведении границы ответственности между этими ролями сложно.