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

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

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

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

При переходе на продуктовый подход в организации появляются продуктовые роли: менеджеры, владельцы продуктов (product owners). Меняется структура отчётности и, возможно, подчинённости. Может быть проведена реорганизация структуры - например, создание продуктовых департаментов, где объединяются различные подразделения, работа которых ориентирована на конкретный продукт. В организации изменяется фокус управления: вместо оценки прибыльности отдельных проектов начинает учитываться жизненный цикл продукта и его общая прибыльность. Могут также появиться новые организационные механизмы, отвечающие за развитие продуктов.

Руководящие принципы ITIL тесно связаны с практикой постоянного совершенствования, так как они призваны поддерживать постоянное улучшение на всех уровнях организации. Принципы, такие как "Действуйте итерационно, используя обратную связь" и "Оптимизируйте и автоматизируйте", непосредственно способствуют постоянному совершенствованию процессов и услуг. Система принципов ITIL помогает организациям определять направления для улучшения, оценивать текущее состояние и принимать обоснованные решения по внесению изменений. В частности, ITIL 4 включает в себя обновленную модель постоянного совершенствования, которая использует эти руководящие принципы как основу для планирования и реализации улучшений, что позволяет организациям гибко реагировать на внутренние и внешние изменения и непрерывно повышать качество предоставляемых услуг.

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

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

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

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