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

Принцип постоянного совершенствования (Continuous Improvement) в DevOps проявляется в постоянной адаптации к изменяющимся обстоятельствам, таким как меняющиеся потребности заказчиков, требования законодательства и появление новых технологий. Он включает сокращение потерь, оптимизацию скорости и затрат, упрощение процесса поставки и непрерывное улучшение предлагаемых продуктов и услуг. Экспериментирование является ключевой деятельностью в этом процессе, что позволяет внедрять методы обучения на ошибках. Принцип также основывается на жизненном правиле — делать чаще то, что получается плохо, чтобы улучшить слабые места. Подход с постоянным совершенствованием создаёт культуру, где оценка текущих процессов и их улучшение становится непрерывной частью работы каждой команды.

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

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

Главные сложности возникают из-за необходимости обеспечения консистентности финансовой информации между различными системами: CMDB, системами учёта договоров, бухгалтерскими системами. ITSM-системы не являются первоисточниками финансовых данных, поэтому требуется интеграция с бухгалтерскими системами и системами управления договорами. К сложностям относятся различия в детализации учёта финансов: в системах учета договоров может отсутствовать спецификация с перечнем позиций, в бухгалтерских системах не учитываться нематериальные активы, инфраструктурные объекты могут группироваться в комплекты с описанием в комментариях. Для решения этих проблем нужны специальные инструменты для сверки финансовой информации и чётко прописанная ролевая модель ответственности за данные.

Типовой процесс, более точно называемый типовой моделью процесса, представляет собой еще не адаптированную к конкретной компании структуру, которую предстоит внедрить в работу. Модель процесса включает в себя: определение целей, задач и области охвата; описание последовательности действий и порядка взаимодействий (workflow); установление порядка контроля исполнения с механизмами его реализации (метрики, отчетность, аудит); распределение ролей с использованием RACI-матрицы; определение интерфейсов к другим процессам и видам деятельности. Существенно, что наличие типовой модели процесса не гарантирует уникальной компетенции команды внедрения и не обеспечивает автоматического достижения результата в виде организованной деятельности. Типовой процесс является, по сути, набором документов, который требует адаптации и практического применения для решения конкретных задач компании.

Различия в описании критических факторов успеха (CSF) между ITIL v3 и IT4IT заключаются в уровне детализации и фокусе. В ITIL v3 критические факторы успеха и ключевые показатели эффективности (KPI) определены для каждого из 26 процессов, что предоставляет очень детализированные рекомендации по управлению отдельными функциональными областями. В IT4IT же CSF и KPI описываются на уровне Value Streams (потоков создания ценности), а не на уровне отдельных функциональных компонентов. Это означает, что IT4IT делает акцент на том, что необходимо для успешного создания ценности через весь поток деятельности, а не только через его отдельные элементы. Хотя в ITIL v3 есть упоминания о критических факторах успеха для фаз жизненного цикла услуги (в последних главах каждой книги), это описание менее структурировано и детально по сравнению с фокусом IT4IT на Value Streams. Таким образом, ITIL v3 предоставляет более операционный, процессно-ориентированный взгляд на CSF, тогда как IT4IT предлагает более стратегический, потоко-ориентированный подход.

Для управления количеством проблем применяются различные методы, такие как Kanban с его ограничениями на текущую загрузку (work-in-progress limit), методика Top 5-10, которая фокусируется на самых приоритетных задачах, и принцип числа Миллера (7±2 элемента), учитывающий когнитивные способности человека. Также эффективны ежедневные планирования, постановка четких приоритетов и регулярный аудит текущих задач для своевременного закрытия незавершенных проблем. Эти подходы помогают сохранять баланс между загрузкой и производительностью.

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

Первый принцип DevOps по DASA — Деятельность должна быть ориентирована на заказчика (Customer-Centric Action). Этот принцип включает постоянные инвестиции в продукты и услуги, которые обеспечивают максимальную удовлетворённость заказчика. Также он подразумевает необходимость коротких циклов обратной связи с заказчиками и конечными пользователями. Кроме того, принцип включает деятельность в духе Lean-стартапов с постоянными инновациями, что помогает быстро адаптироваться к меняющимся потребностям клиентов и тестировать новые идеи в реальных условиях.