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

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

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

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

На этапе стратегического планирования BRM (Business Relationship Management) выполняет несколько ключевых функций. BRM должен держать руку на пульсе изменений в бизнесе заказчика и знать его текущую деятельность, задачи и структуру спроса на услуги. Это позволяет ИТ-функции своевременно реагировать на изменения. BRM выступает представителем сервис-провайдера в ключевых дискуссиях по стратегии заказчика. Задачи BRM на этом этапе включают коммуникацию стратегических целей заказчика ИТ-специалистам, что позволяет переоценить ИТ-стратегию, проанализировать возможности и риски, а также пересмотреть портфель услуг. BRM обеспечивает постоянную связь между бизнес-требованиями и ИТ-планами, учитывая, что бизнес-потребности меняются в зависимости от внутренних и внешних факторов.

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

В DevOps автоматизация всего процесса (сборки, тестирования, развертывания) важна не менее, чем сама работа кода в продуктиве, потому что: 1) Ручные процессы являются узким местом и источником ошибок; 2) Автоматизация обеспечивает регулярность и предсказуемость релизов; 3) Позволяет быстро и безопасно реагировать на изменения; 4) Минимизирует время между написанием кода и его развертыванием в продукт; 5) Делает процесс прозрачным и контролируемым; 6) Позволяет часто и малыми шагами обновлять продукт, что снижает риски. Без полной автоматизации даже идеально работающий в продуктиве код не может считаться действительно завершенным в контексте DevOps-философии.

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

Процесс SLM (Service Level Management) - это процесс управления уровнем сервиса, который обеспечивает согласование ожиданий потребителей ИТ-услуг с реальными возможностями ИТ-организации. SLM помогает в управлении качеством ИТ-сервисов, определяя ключевые показатели производительности (KPI), устанавливая целевые значения для этих показателей и отслеживая их выполнение через регулярные отчеты. Этот процесс обеспечивает постоянное взаимодействие между ИТ-организацией и бизнес-подразделениями, позволяет выявлять расхождения между ожиданиями пользователей и реальностью, а также формировать предложения по улучшению сервисов. В ходе SLM разрабатываются и поддерживаются SLA (соглашения об уровне сервиса), которые фиксируют обязательства ИТ-организации по предоставлению сервисов и соответствующие показатели качества. Это создает основу для объективной оценки качества ИТ-услуг с точки зрения бизнеса.

В ITIL 4 назначение практики управления инцидентами формулируется следующим образом: «Минимизировать негативное влияние инцидентов, восстанавливая нормальную работу услуг как можно быстрее». Основной недостаток этой формулировки заключается в том, что она акцентирует внимание преимущественно на скорости восстановления услуги, тогда как в действительности удовлетворённость пользователей зависит от множества других факторов, таких как качество коммуникаций, количество контактов с поддержкой и окончательность решения. Хотя в более подробном описании практики в ITIL 4 упоминается важность удовлетворённости пользователей, в самой формулировке назначения эта цель не отражена явно, что может приводить к тому, что организации сосредотачиваются только на скорости решения инцидентов, упуская из виду другие значимые аспекты.