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

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

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

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

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

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

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

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

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

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