Модель RBAC имеет ряд преимуществ перед другими моделями управления доступом, такими как DAC (Discretionary Access Control) и MAC (Mandatory Access Control). Во-первых, RBAC обеспечивает более высокую масштабируемость, что особенно важно для организаций с большим количеством сотрудников. Во-вторых, она повышает прозрачность управления доступом, так как права привязаны к ролям, соответствующим должностям и бизнес-процессам. В-третьих, RBAC обеспечивает легкость администрирования - добавление или удаление пользователей не требует перенастройки всего механизма доступа, достаточно назначить или отозвать соответствующую роль. Также RBAC позволяет лучше соблюдать принцип разделения обязанностей, что повышает информационную безопасность организации.

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

Чтобы избежать искажения статистики при сборе обратной связи, необходимо сделать процесс оценки максимально простым, быстрым и понятным для всех пользователей, а не только для тех, кто испытывает сильные эмоции (крайнюю удовлетворенность или недовольство). Например, вместо требования регистрации на стороннем сайте следует обеспечить возможность оценки прямо в приложении или через SMS с четкими условиями (бесплатность подтверждена). Система должна минимизировать количество шагов и избегать неожиданных условий, таких как внезапная плата за SMS. Это повысит долю обратной связи от пользователей с нейтральной или умеренной удовлетворенностью, что обеспечит более объективную картину.

Структура сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (Actor), который определяется как внутренний или внешний; тип угрозы (Threat Type), такой как злоумышленные действия, ошибки или природные катаклизмы; событие (Event), включающее раскрытие информации, модификацию, кражу или уничтожение; связанные активы (Asset/Resource), относящиеся к людям, организационным структурам, процессам и ИТ-инфраструктуре; и временной аспект (Time), учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от времени суток или календарного периода.

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

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

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

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

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

Факторы успеха практик (PSF) в ITIL 4 напрямую связаны с потоками создания ценности. Ключевые показатели эффективности (KPI) формулируются на основе PSF для измерения эффективности практики именно в контексте её вклада в эти потоки creation ценности. Каждая практика, для которой определены PSF, участвует в определенных потоках создания ценности, и успешность её работы оценивается по тому, насколько её выполнение способствует достижению целей этих потоков. Таким образом, PSF помогают связать конкретные действия в рамках практики с более широкими организационными целями создания ценности для клиента.