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

В методологии ITIL приоритет инцидента определяется на основе двух факторов: уровня влияния (impact) и уровня срочности (urgency). Уровень влияния измеряет, насколько сильно проблема влияет на работу бизнеса или конечных пользователей. Уровень срочности учитывает, насколько быстро необходимо решить проблему, исходя из времени, в течение которого может сохраняться негативное влияние. Результатом комбинации этих двух величин становится приоритет, который помогает правильно расставить последовательность действий при устранении инцидента.

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

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

Да, можно использовать CMDB для решения задач сервисной экономики. Основная задача CMDB — определение влияния одних элементов на другие, что по своей сути имеет экономический характер, поскольку влияние является производной от использования ресурсов. Например, сервер, использующий систему хранения данных для размещения информации, формирует взаимосвязь влияния, которая может быть использована при расчете TCO приложений. CMDB может содержать данные о всех необходимых ресурсах, включая виртуальные машины и логические диски, которые не учитываются в традиционном бухгалтерском учёте, но важны для расчёта стоимости услуг. При этом для решения экономических задач не требуется вводить специальные «экономические» связи, могут быть использованы существующие связи влияния.

Цикл Деминга, также известный как PDCA-цикл, представляет собой метод управления качеством, состоящий из четырех последовательных шагов: Планируй (Plan), Выполняй (Do), Проверяй (Check), Корректируй (Act). Он используется для постоянного улучшения процессов в различных областях бизнеса и управления. Каждый этап цикла выполняется последовательно для реализации улучшений и закрепления положительных изменений. Цикл может быть непрерывным, так как после завершения этапа 'Корректируй' процесс может начинаться заново с этапа 'Планируй' для дальнейшего совершенствования.

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

При правильно организованном процессе учета времени на саму процедуру учета тратится значительно меньше времени, чем многие предполагают. По приведенным данным, за весь 2014 год на учет времени ушло 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это означает, что даже при тщательном учете по множеству категорий временные затраты на ведение учета минимальны и составляют доли процента.

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

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