Наличие этапа 'Отложено' в потоке создания ценности приводит к нескольким негативным последствиям: 1) Не создается ценность на этом этапе, что противоречит самой сути потокового подхода; 2) Теряется фокус на завершении взятых обязательств, так как задачи могут оставаться отложенными неограниченное время; 3) Поток становится непредсказуемым, что вынуждает прибегать к жестким дедлайнам; 4) Снижается скорость работы, так как отложенные задачи занимают слоты в потоке; 5) Возникает неравномерность течения, замедляющая все задачи; 6) Задачи постепенно теряют актуальность, а команда забывает контекст работы над ними, что приводит к росту дефектов и необходимости управления ими.

Для эффективного CI/CD необходим переход от редких релизов к частым, возможно, даже непрерывным выпускам. Многие команды традиционно приучены выпускать обновления раз в месяц, квартал или 'как получится', что не совместимо с принципами непрерывной интеграции и доставки. Нужно изменить не только внутренние процессы, но и ожидания заказчиков, которые привыкли к такому режиму обновлений. Это требует пересмотра подхода к планированию и разбивке задач на более мелкие, которые могут быть доставлены независимо. Также необходимо создать инфраструктуру, поддерживающую частые релизы, включая автоматизированное тестирование, что позволяет быстро выявлять и исправлять ошибки. Важно отметить, что переход к частым релизам не возможен без изменения культуры работы команды и установления четких критериев готовности для каждого изменения.

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

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

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

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

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

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

Разница между ценностью отдельной истории и совокупной ценностью эпика заключается в том, что отдельные истории могут не обладать значимой ценностью до тех пор, пока не будет реализован весь эпик или его минимально жизнеспособная версия (MVP). Например, пока эпик (реализуемая в нем функция) не достиг состояния готовности к реальному использованию, составляющие его отдельные истории могут не представлять практической ценности для пользователя. Совокупная ценность эпика может превышать сумму ценностей отдельных историй, так как только при их совместной реализации достигается целостный функционал, удовлетворяющий потребности пользователя или бизнеса. Это важно учитывать при приоритизации работы и планировании релизов.

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