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

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

Роль координатора изменений, хотя и не упомянута в официальной документации ITIL, широко используется в большинстве распространенных вендорских процессных моделях. Например, она присутствует в моделях компаний BMC, HP и IBM. В IBM Tivoli Unified Process эта роль называется 'Владелец изменений', что может вызывать терминологическую путаницу из-за многозначного использования слова 'Owner' в ИТ-управлении. Несмотря на отсутствие официального признания этой роли в ITIL, на практике внедрение управления изменениями в крупных компаниях практически всегда включает назначение координаторов изменений

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

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

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

Функциональные роли ресурсов, такие как СУБД, web-сервер, файл-сервер и другие, важны в модели CMDB потому, что именно с ними связаны специфичные единицы объёма потребления, затраты и зависимости мощности от обеспечивающих ресурсов. Например, СУБД может требовать определённого объёма вычислительных мощностей, памяти или дискового пространства, которые отличаются от требований простого сервера. Учёт этих ролей позволяет более точно планировать мощности и ресурсы, необходимые для обеспечения качества предоставляемых услуг, а также проводить анализ затрат на обслуживание каждой функциональной роли.

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

Цель использования метода 'Customer Journey' в ИТ-менеджменте — понять, как клиенты взаимодействуют с продуктом или услугой на всех этапах, выявить области для улучшения и оптимизировать процессы таким образом, чтобы повысить удовлетворенность и лояльность пользователей.

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