Отсутствие такой структуры приводит к тому, что матрица ролей перестаёт отражать реальные процессы бизнеса, так как изменения в задачах сотрудников не фиксируются и не внедряются в систему управления доступом. Например, при запуске новой системы доступ к ней может быть предоставлен хаотично, без привязки к ролям, что создаёт путаницу и повышает риск выдачи избыточных прав. Со временем это увеличивает сложность аудитов и вероятность нарушения политик безопасности из-за несоответствия прав должностным обязанностям.

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

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

Функциональная эскалация инцидентов — это процесс передачи заявки от одного уровня поддержки к следующему по иерархии (например, с L1 на L2 или с L2 на L3) при необходимости более глубокой диагностики или решения сложной проблемы. Она отличается от временной эскалации, которая связана с нарушением сроков SLA и требует вмешательства менеджмента, и от персональной эскалации, когда заявка передается конкретному специалисту или руководителю по содержательным вопросам. Функциональная эскалация определяется сложностью проблемы и необходимостью привлечения специалистов с более высоким уровнем компетенции, тогда как другие виды эскалации могут быть связаны с организационными или временными аспектами обработки заявок.

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

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

ITIL 4 изменяет традиционное понимание управления услугами, представляя ценность как результат совместного создания поставщиком и потребителем, а не как одностороннюю поставку от организации к клиенту. В отличие от предыдущих версий, где фокус был преимущественно на внутренних процессах организации, ITIL 4 подчеркивает необходимость учета роли потребителя в создании ценности. Это выражается в четком разделении деятельности на предоставление (service provision) и потребление услуг (service consumption), признании что обе эти деятельности необходимы для достижения результата. Такой подход требует пересмотра традиционных моделей ИТ-управления и интеграции пользовательского опыта в основные процессы.

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

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

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