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

Для определения ПО, требующего лицензирования, необходимо составить список критически важных программ (например, Microsoft Suite, Adobe Photoshop), проанализировать правила лицензирования вендоров (особенно сложные, как у Oracle), и использовать сканеры сети для выявления фактически установленных продуктов. Затем данные следует сопоставить с купленными лицензиями. Важно сосредоточиться на тех продуктах, где наиболее высок риск нарушения лицензионных соглашений или штрафов (например, часто копируемый софт). Серверное ПО обычно менее приоритетно для первоначального учёта.

Новый подход стимулирует не только быстрое устранение инцидентов, но и профилактику их возникновения. Поскольку инциденты, влияющие на бизнес (te > Tmin), снижают общий рейтинг даже при соблюдении Tmax, поставщикам услуг становится невыгодно допускать сбои. Это приводит к повышению общей надежности ИТ-инфраструктуры и снижению количества инцидентов, что напрямую улучшает доступность сервисов и минимизирует риски для бизнес-операций.

Серверное ПО редко становится приоритетом, потому что его установка и настройка обычно централизованы и контролируются ИТ-отделом, что снижает риск неучтённых копий. В отличие от клиентского софта (например, Microsoft Office или Photoshop), который сотрудники могут устанавливать самостоятельно, серверные продукты часто имеют чёткие процедуры развёртывания и лицензирования. Поэтому основные проблемы и нарушения чаще возникают именно с «прикладным» ПО, которое люди копируют на рабочие станции без согласования.

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

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

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

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

Помимо USM (Universal Service Management) и eSCM-SP (eSourcing Capability Model for Service Providers), в тексте упоминается подход, аналогичный eTOM (Enhanced Telecom Operations Map), но адаптированный для более широкого спектра услуг. Автор полагает, что существует потребность в промежуточном варианте между USM и eSCM-SP - уровне сложности, близком к eTOM, но с обобщением на различные виды услуг. Такой подход должен сохранять простоту понимания, присущую USM, но иметь большую детализацию, чем это предлагается USM, и в то же время быть менее сложным, чем eSCM-SP.

Средний чек используется для вычисления количества транзакций, необходимых для выполнения плана продаж. Например, при плане на 1440 млн рублей и среднем чеке в 10 тысяч рублей потребуется выполнять 12 000 сделок в месяц. Зная, что каждый продавец обрабатывает в среднем 20 сделок в день, можно определить необходимое количество пользователей и спрогнозировать нагрузку на ИТ-системы. Это помогает планировать потребность в вычислительных ресурсах, сетевой инфраструктуре и поддержке со стороны Service Desk. На основании данных о количестве сделок и пользователей можно построить сервисно-ресурсную модель для оптимального распределения ИТ-ресурсов.