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

Влияние на ресурсы напрямую связано с экономической моделью в CMDB, так как влияние является производной от использования ресурсов. Например, если одно устройство зависит от другого или использует его ресурсы, это влияние можно преобразовать в экономическую меру — часть стоимости ресурса, предоставляемого вторым устройством, может быть распределена на первое устройство. Таким образом, связи влияния, изначально предназначенные для отслеживания зависимостей в ИТ-инфраструктуре, автоматически становятся основой для распределения затрат и расчёта стоимости услуг.

В ITILv3 возникали проблемы из-за сложности ролевой модели, особенно в определении четких границ ответственности между ролью менеджера уровня услуг и владельцем услуги. Это приводило к бесплодным спорам о распределении задач между ролями и избыточному усложнению системы управления. Таблица сравнения ролей в книге 'Постоянное совершенствование услуг' (CSI, ITIL, 2011) скорее порождала дополнительные вопросы, чем давала ясные ответы. Эта неопределенность в распределении ролей затрудняла практическую реализацию фреймворка в организациях.

Референтная модель стандарта INCITS 359-2012 состоит из двух частей: референтная модель и административная функциональная спецификация. Референтная модель определяет множества элементов, которыми оперирует стандарт: пользователи, роли, права доступа, операции и объекты (доступа). В её состав входят четыре компонента: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро является обязательным компонентом при использовании подхода RBAC и определяет минимально необходимый набор элементов и связей для построения целостной системы.

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

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

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

Disaster Recovery Institute International (DRII) выделяет 10 компонентов управления непрерывностью: запуск программы и управление, управление рисками и контроль, анализ влияния на бизнес-процессы, стратегии непрерывности бизнеса, реагирование в случае нештатной ситуации, внедрение плана и документирование, обучение и поддержание осведомленности, испытания, аудит и оценка плана, кризисные коммуникации, взаимодействие с внешними сторонами.

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

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