Связка стандартов RBAC (INCITS 359-2012, INCITS 494-2012 и INCITS 459-2011) устанавливает общую терминологию и определяет элементы, множества, интерфейсы, команды и модели, которые можно использовать при проектировании систем управления доступом. Это обеспечивает единообразие в подходах к реализации RBAC, позволяет создавать совместимые системы и облегчает процесс анализа их функциональных возможностей. Первый стандарт определяет базовую модель, второй добавляет гибкость за счет поддержки динамических ограничений, а третий обеспечивает корректную комбинацию всех компонентов и их взаимодействие. Совместное использование этих стандартов помогает создавать эффективные решения для управления доступом, которые соответствуют современным требованиям безопасности и бизнес-процессов.

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

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

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

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

Реактивная часть управления доступностью относится к учету и регистрации фактов и периодов недоступности услуги. Она включает мониторинг и измерение доступности через фиксацию инцидентов недоступности. Этот процесс позволяет отслеживать, когда и как долго услуга была недоступна, а также выявлять причины и последствия простоев. Особенно важно это при массовых инцидентах, которые имеют высокую вероятность стать инцидентами недоступности, так как они直接影响 точку потребления услуги и требуют коммуникации с пользователями.

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

Согласно COBIT, уровни зрелости процессов имеют исключительно иллюстративный смысл. Они используются для наглядного представления текущего состояния процесса или разницы между текущим и целевым состояниями, но не предназначены для точной количественной оценки. Уровень зрелости является побочным продуктом обследования, а не основной метрикой. Его не следует воспринимать чересчур серьезно, поскольку один и тот же процесс может проявлять признаки нескольких уровней зрелости одновременно, и разные аудиторы могут давать разные оценки одному процессу, даже используя одни и те же контрольные показатели.

Процесс Управления инцидентами обеспечивает прозрачность в работе за счёт своевременной и эффективной передачи информации об инцидентах и их статусах. Для этого процесс должен быть построен так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате через согласованные каналы. Это могут быть электронные письма, SMS, информация на портале самообслуживания (в личном кабинете), телефонные звонки или даже личные визиты в случае работы с VIP-пользователями. Процесс INC должен минимизировать количество повторных обращений пользователей по тем же инцидентам за счёт качественного информирования, что отражается в KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов».

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