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

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

ITIL предоставляет рекомендации по запросам на обслуживание, которые идентичны рекомендациям по управлению инцидентами. То есть организации должны предопределить правила относительно возможности повторного открытия запросов на обслуживание и условий, при которых это допустимо. Временные рамки и конкретные условия могут различаться в зависимости от особенностей организации и её требований к обслуживанию.

Для создания названия совещания, отражающего абстрактную и неэффективную суть обсуждений, рекомендуется использовать термины, не имеющие конкретного отношения к реальным задачам. Например, можно соединять методологии, такие как Six Sigma и Lean, с общими целями вроде снижения разрыва между стратегией и целями. Подобный заголовок будет звучать формально, но фактически не несёт содержательной нагрузки, что логично завершает процесс неэффективного совещания.

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

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

Оптимальный уровень детализации учета трудозатрат определяется через баланс между слишком мелкой и слишком крупной разбивкой работ, при котором сохраняется как достоверность данных, так и их аналитическая полезность. Многим организациям не требуется видеть трудозатраты по каждому единичному инциденту или заданию, достаточно фиксировать данные по основным направлениям деятельности. Идеальный каталог работ в организации с численностью 8-12 человек включает 10-20 позиций для обычной работы и 20-25 позиций с учетом проектов. При разработке такого каталога важно помнить, что слишком мелкое дробление работ приводит к потере достоверности учета, тогда как слишком крупная группировка делает данные малопригодными для анализа. В примере, описанном в тексте, общий каталог насчитывает 54 строки, организованные в семь групп: производство, продажи и account management, маркетинг, внутренняя работа, продукты и методики, партнеры, управление компанией. Поддерживать учет по таким 20-30 видам работ является реалистичной задачей, не требующей чрезмерно сложных инструментов или больших затрат времени.

Назначение процесса управления уровнем ИТ-услуг заключается в обеспечении качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий. SLM ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Такой подход зафиксирован в стандарте ISO 9001:2000.

Инцидент — это незапланированное прерывание или снижение качества услуги. В ITIL 4 определение звучит как «ан unplanned interruption to a service or reduction in the quality of a service». При этом важно отметить, что практика управления инцидентами не ограничивается только тем качеством услуги, которое воспринимают пользователи. Она также включает в себя восстановление нормальной работы услуг и ресурсов, даже когда их сбой или отклонение не видны потребителям услуг. Нормальная работа может быть определена в технических спецификациях услуг или конфигурационных единиц.

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