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

Примером несовместимых разрешений в RBAC может служить ситуация с платежами в банковской системе. Например, разрешение на проведение платежа в сторону контрагента и разрешение на одобрение такого платежа не могут быть назначены одному и тому же сотруднику, так как это нарушает принцип разделения обязанностей. В этом случае создается отдельная роль "Операционист", которая имеет право проводить платежи, и роль "Контролёр", которая может одобрять платежи. Эти роли не могут быть назначены одному и тому же сотруднику одновременно. Аналогичные примеры могут быть в других областях, например, в системе бухгалтерского учета не может быть одного лица, которое одновременно создает документы и утверждает их к оплате.

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

Широкое определение термина «деловая игра» приводит к тому, что под ним подразумеваются мероприятия совершенно разных масштабов и форматов — от коротких двухчасовых сессий для небольших групп до многочасовых мероприятий на сотни человек. Это затрудняет понимание целей, ожидаемых результатов и особенностей подготовки для конкретной игры. Кроме того, трудно выделить общие принципы и стандарты организации такой деятельности, что может снизить её воспринимаемую ценность и эффективность в глазах руководства и участников.

Ценности «полезности» (основная разработка) и «гарантии» не суммируются, а перемножаются. То есть, даже при высокой ценности «полезности» (эффективное развитие продукта), если «гарантия» (стабильность, доступность) близка к нулю, общий результат будет нулевым. Например, идеальный продукт, который постоянно падает, не приносит ценности пользователям. Таким образом, обе составляющие должны поддерживаться равномерно.

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

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

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

В COBIT 5 for Risk риски разделены на 20 категорий, охватывающих различные аспекты управления ИТ. Это включает категории, связанные с управлением ИТ-инвестициями, программами и проектами, рисками, связанными с поставщиками, вредоносным ПО, атаками, регуляторами и другими областями. Каждая категория содержит подробные описания типовых ИТ-рисков с рекомендациями по их снижению, основанными на семи факторах влияния, что позволяет применять эти рекомендации в различных сценариях управления рисками.

Если консультанты при составлении RACI-матрицы не предусмотрели механизмы контроля для ответственных (A), необходимо: 1. До окончательного утверждения матрицы определить, какие конкретно инструменты контроля нужны для каждой позиции с символом A. 2. Требовать от консультантов или внутренней команды разработать и внедрить эти механизмы контроля. 3. В случае если консультанты отказываются это делать, настаивать на внесении в матрицу примечаний о необходимых механизмах контроля с указанием ответственных за их создание. 4. При отсутствии возможности привлечь консультантов - самостоятельно разработать простые, но эффективные механизмы отслеживания выполнения задач (регулярные отчеты, контрольные точки, проверочные встречи). Механизмы контроля являются неотъемлемой частью ответственности, и без них система распределения ролей теряет смысл, так как ответственный не сможет влиять на результат, за который несет ответственность.