При совмещении управления безопасностью и непрерывностью в одном процессе могут возникнуть проблемы, связанные с противоречивыми требованиями и приоритетами. Меры безопасности зачастую предполагают ограничения доступа, дополнительные проверки и протоколы, что может замедлять восстановление системы после сбоя и снижать ее непрерывность. С другой стороны, акцент на непрерывность может привести к ослаблению мер безопасности ради быстрого восстановления сервиса. Это создает дилемму: чрезмерные меры безопасности могут угрожать непрерывности работы, а чрезмерный акцент на непрерывности — компрометировать безопасность системы.

В ITIL4 Foundation отсутствует детальное описание ролей, участвующих в практиках, поскольку ITIL4 представляет собой более гибкий и принципиально иной подход по сравнению с ITIL V3. Вместо фиксированных ролей и процессов ITIL4 фокусируется на практиках, которые могут быть адаптированы под конкретные потребности организации. Полное описание ролей и ответственностей в ITIL4, вероятно, содержится в более углубленных модулях или материалах, выходящих за рамки базового уровня Foundation. В статье упоминается, что следует ждать более подробного описания в соответствующих модулях ITIL4.

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

Risk Scenarios Using COBIT 5 for Risk является расширенной версией основного документа COBIT5 for Risk и тесно связана с процессной моделью из COBIT5 Enabling Processes. Основная ценность этого документа – невероятное количество деталей, структурированно представленных в табличном формате и раскрывающих риск-сценарии, упомянутые в основной публикации. Документ предоставляет подробные описания, которые трудно найти в других источниках, и бережно раскрывает специфику каждого риск-сценария в контексте процессов управления. Такой структурированный подход позволяет глубже понять практическое применение риск-менеджмента в ИТ-среде.

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

Принцип "Отталкивайтесь от текущей ситуации" (Start where you are) присутствует в обоих изданиях и по смыслу практически идентичен. Он гласит, что организации не следует стремиться строить всё с нуля, а должны максимально использовать существующие процессы, процедуры и средства автоматизации, даже если они не соответствуют идеальным моделям. В частности, в ITIL 4 подчеркивается важность прямого наблюдения за текущим состоянием и рекомендуется отдавать предпочтение непосредственным наблюдениям перед другими методами сбора данных. Таким образом, элементы принципа "Приоритет прямого наблюдения" (Observe directly) из ITIL Practitioner Guidance 2016 года находят свое отражение в рекомендациях по применению принципа "Отталкивайтесь от текущей ситуации" в ITIL 4.

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

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

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

Методологии Six Sigma и Lean можно использовать на совещании для создания формального заголовка или введения абстрактных целей, таких как «уменьшить разрыв между нашей стратегией и нашими целями». Это создает видимость профессионализма и использования современных подходов, но не приводит к конкретным действиям или результатам, делая совещание бесполезным с точки зрения реальных улучшений.