Чтобы проверить систему на наличие ненужных показателей, необходимо убедиться, что каждый показатель напрямую связан с конкретной целью и используется для принятия решений. Если на вопрос «Зачем это измеряется?» нет чёткого ответа, такой показатель, вероятно, лишний. Также важно проверять, влияет ли показатель на поведение сотрудников в нужную сторону и можно ли его достаточно точно измерить без риска фальсификации.

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

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

Рекомендуется ввести следующие ограничения на использование статуса 'Ожидание': ограничить круг лиц, имеющих право перевода задач в этот статус (только руководители, только при наличии подтверждения от клиента/коллег); установить максимальный допустимый срок пребывания задачи в статусе (например, не более 3 рабочих дней без повторного согласования); требовать обязательного указания конкретной даты или условия выхода из статуса; разрешить использование статуса только после попытки решения задачи без ожидания (фиксация предпринятых действий); ввести автоматическое возвращение задачи в активный статус после истечения максимального срока ожидания с уведомлением ответственного. Такие ограничения предотвращают злоупотребление статусом и сохраняют его полезную функцию для объективных задержек.

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

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

Управление конфигурациями требует учета связей между элементами инфраструктуры (CI) и услугами, а также между самими услугами. Это критически важно для корректного понимания влияния изменений в инфраструктуре на конечные услуги и для обеспечения целостности сервисов при проведении изменений.

Использование расширенного жизненного цикла инцидента позволяет детально анализировать, на какие этапы уходит время при устранении инцидента. Например, если известно, что инцидент длился 1 час, но непосредственные работы заняли всего 5 минут, становится ясно, что 55 минут ушли на другие этапы — обнаружение, диагностику или восстановление. Это даёт возможность целенаправленно улучшать процессы в этих областях, сокращая общий простой и повышая качество обслуживания.

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

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