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

Потребности (Север) в модели Compass Model представляют собой основные причины и цели, по которым потребитель обращается к определённой услуге или продукту. Чтобы определить потребности, следует ответить на вопрос: "Что клиент НЕОБХОДИМО должен получить от этой услуги?" Например, для человека, использующего такси при поездке в командировку, основной потребностью будет: "добраться из аэропорта в пункт назначения". Потребности обычно представляют собой базовые, обязательные к выполнению требования, без которых услуга теряет свой смысл. Они формируют фундаментальные ожидания клиента и определяют, будет ли услуга вообще им восприниматься как полезная.

Идея предоставления доступа на основе ролей возникла из необходимости группировки наборов прав в отдельные понятные сущности, которые упрощают управление доступом при изменении положения пользователей в организации или при изменении их набора прав. Первые приложения, реализующие ролевое управление доступом, появились еще в 1970-х годах, однако они были достаточно простыми и не имели единой модели или стандарта. Универсальную модель ролевого управления доступом впервые предложили Дэвид Феррайоло и Ричард Кун из Национального Института Стандартов и Технологий США (NIST) в 1992 году. Впоследствии эта модель была доработана и сегодня оформлена в виде международного стандарта INCITS 359-2012.

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

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

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

В условиях слабой матрицы у исходного координатора (например, у специалиста app-саппорта) часто недостаточно ресурсов и полномочий для влияния на смежные отделы. Это приводит к частым эскалациям, проблемам с мотивацией координаторов и замедлению процесса решения. В таких случаях передача проблемы напрямую в смежный отдел также может привести к потере связи с исходной проблемой и снижению качества проверки решения.

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

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

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