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

Низкой эффективности потока в командах разработки (3-10%) способствуют несколько факторов: большое количество задач в системе, нежелание делать сложный выбор между задачами, склонность брать новые, понятные задачи вместо решения уже начатых сложных задач, использование статуса 'отложено' для задач, требующих уточнений или участия отсутствующих сотрудников. Все это приводит к тому, что значительная часть трудозатрат превращается в простои и не добавляет ценности, а время ожидания для отдельных задач достигает 90-97% от общего времени нахождения в системе.

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

Автоматизация проверки CMDB включает использование сканеров обнаружения CI (например, ServiceNow Discovery, Lansweeper), интеграцию с системами мониторинга (Zabbix, Nagios) для сравнения реальных показателей с записями CMDB, и настройку триггеров на аномальные изменения (например, массовое обновление атрибутов за короткий срок). Для статических данных применяются скрипты сравнения с источниками доверенных данных (активы в финансовой системе). Ключевой элемент — регулярные сверки через API между CMDB и системами управления изменениями, чтобы отслеживать соответствие внесенных изменений утвержденным запросам.

Правило «расщепления» — это методика разбиения комплексного актива на отдельные учетные единицы для детализации затрат. Например, при постановке рабочей станции на учет по правилам «расщепления» системный блок, монитор и периферийные устройства регистрируются как самостоятельные активы с уникальными инвентарными номерами и сроками амортизации. Это позволяет ИТ-службам вести контроль за состоянием и заменой отдельных компонентов, а финансовым службам — более точно распределять расходы. Реализация требует четкого определения типов активов, подпадающих под такое расщепление.

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

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

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

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

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