Для определения принадлежности элемента к категории ИТ-актива или конфигурационной единицы необходимо ответить на ключевой вопрос: «Что конкретного мы будем делать с этим элементом как с ИТ-активом?». Если для элемента предусмотрены специфические процедуры учета, управления жизненным циклом, оценки стоимости, которые отличаются от процедур управления конфигурационными единицами, то его следует отнести к ИТ-активам. Если же отличий в процедурах работы нет, и элемент используется просто для отслеживания конфигурации, то он является конфигурационной единицей. Пределы понятий определяются практическими потребностями системы управления.

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

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

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

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

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

В тексте упомянуты четыре основные проблемы управления рабочим временем: 1. Объем работы: задач поступает больше, чем есть времени на их выполнение. После перехода из клиентской компании в консалтинг и запуска собственного бизнеса рабочая загрузка возросла до 120-160%, что создало острую нехватку времени. 2. Противоречие интересов: существует разница между тем, что хочется делать (интересная работа) и тем, что необходимо выполнять (обязательные задачи, например, бухгалтерский и налоговый учёт). 3. Приоритизация: рутинные оперативные вопросы занимают всё рабочее время, в то время как на стратегическое развитие компании и личностный рост времени не хватает. 4. Размытость границ: в современных условиях сложно отделить рабочее время от личной жизни. Гибкий график и постоянное погружение в работу приводят к тому, что приходится успевать и профессиональные, и семейные обязанности.

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

Definition of Done (DoD) - это концептуальное понятие в DevOps, которое определяет критерии завершения работы над задачей. Это согласованное понимание того, что работа считается выполненной. Согласно концепции DoD, важно иметь единообразное представление о том, что считается завершенной работой, чтобы избежать недопонимания между участниками процесса разработки и эксплуатации. В DevOps эта концепция получила развитие и дополнительное наполнение по сравнению с earlier практиками.

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