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

Доступность как компонент Warranty означает, насколько часто услуга доступна для использования пользователями, когда в ней возникает необходимость. Это включает в себя минимальное время простоя, регламентные работы, время восстановления после сбоев. Например, для электрического света доступность определяет, может ли пользователь зажечь свет, когда захочет, и как часто происходят отключения электричества. Высокая доступность означает, что услуга постоянно или почти постоянно доступна в соответствии с ожиданиями пользователя. Доступность часто измеряется в процентах (например, 99,9% времени) и является критическим компонентом при определении уровня качества услуги и составлении SLA.

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

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

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

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

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

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

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

После внедрения ITSM ресурсное планирование становится более сложным, так как определение потребностей уже учитывает не только выполнение новых проектов и внедрений, но и изменение объёма потребления ИТ-услуг. Это требует более точного прогнозирования потребностей и гибкого регулирования ресурсов в зависимости от спроса на услуги.