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

Основные аргументы против разделения включают: рациональность организации управления (поскольку обработка сбоев инфраструктуры и сервисных запросов часто схожа); вероятные конфликты в определении границ между инцидентом и сервисным запросом, превращающие технические вопросы в организационные споры о том, кто за что отвечает; рациональность автоматизации (в реальной практике разница в обработке инцидента, поданного пользователем, и сервисного запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя). Также отмечается, что в ITIL v2 прямо указано, что практика показывает схожесть в обработке как сбоев, так и сервисных запросов, поэтому они включались в один процесс.

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

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

Принцип "Сотрудничайте" (Collaborate), который существовал в ITIL Practitioner Guidance 2016 года, был объединен с принципом "Будьте прозрачны" (Be transparent) в один принцип в ITIL 4 2019 года под названием "Сотрудничайте и поощряйте прозрачность" (Collaborate and promote visibility). Это объединение отражает важность не только сотрудничества между различными участниками процессов, но и открытости информации как неотъемлемой части эффективного взаимодействия. Авторы ITIL 4 видят эти два аспекта взаимосвязанными и считают, что прозрачность способствует более продуктивному сотрудничеству.

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

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

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

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

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