Существует три основных взаимосвязанных стандарта, регулирующих использование Role-Based Access Control: INCITS 359-2012 «Information Technology - Role Based Access Control», который содержит референтную модель ролевого управления доступом; INCITS 494-2012 «Information technology - Role Based Access Control - Policy Enhanced», являющийся дополнением к первому стандарту в части обработки динамических ограничений; и INCITS 459-2011 «Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control», описывающий допустимые сочетания компонентов и интерфейсы. Первые два стандарта определяют модель и функциональные возможности RBAC, а третий обеспечивает совместимость и правильную комбинацию компонентов.

Для создания каталога ИТ-услуг с применением PCF можно рекомендовать следующий алгоритм действий: сначала проанализировать список процессов в PCF и выделить те, которые явно выражены и имеют место в вашей организации, для чего необходимо глубоко понимать работу компании; затем определить и уточнить владельцев процессов; далее проанализировать вместе с ИТ-специалистами (бизнес-аналитиками, представителями подразделений, сопровождающих ИТ-системы) полученный список процессов и определить, для каких из них имеется специфичная деятельность, выполняемая ИТ-подразделениями; при необходимости объединить несколько процессов в рамках предоставления одной услуги; и, наконец, сконсолидировать полученную информацию и составить описание каждой из сервисов. В результате будет получен каталог ИТ-услуг, составленный "от бизнес-процессов".

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

Definition of Done (DoD) - это четкое определение критериев, которые должны быть выполнены, чтобы работа над элементом (историей, задачей) могла считаться завершенной. DoD важен для командной работы потому, что объекты в бэклоге должны иметь строгие границы, чтобы команда могла их осознать и работать с ними эффективно. Без четкого DoD команда не сможет точно определить, когда элемент работы завершен, что приведет к неопределенности, пересечениям в работе и задержкам. Для эпиков и инициатив отдельный DoD обычно не определяется, так как они представляют собой компиляции дочерних требований, а вот для пользовательских историй и задач DoD критически важен для обеспечения стабильности процесса разработки.

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

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

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

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

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

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