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

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

Да, количество аспектов управления проектами может отличаться от шести, рекомендованных в PRINCE2®. Хотя методология определяет конкретный набор из шести аспектов (Сроки, Затраты, Охват, Качество, Выгоды, Риск), это не означает, что других аспектов быть не может. Если для конкретной организации важна дополнительная характеристика проекта и есть (или необходим) соответствующий механизм управления этой характеристикой, то можно выделить дополнительный аспект. Главное, чтобы каждый аспект представлял собой независимый параметр, имеющий свою методику измерения и контроля, и вносил значимый вклад в общее управление проектом.

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

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

PIR (Process Improvement Report) – это процесс оценки результатов внедренных изменений и их влияния на процессы или услуги. В контексте управления ИТ-услугами PIR используется для анализа успешности реализованных изменений, определения достигнутых улучшений и выявления возможных проблем. Это помогает в дальнейшем совершенствовать процессы управления и повышать качество ИТ-услуг.

CMDB (Configuration Management Database) необходима для хранения точной и надёжной информации о конфигурационных элементах, которые требуются для предоставления ИТ-услуг. Её основное назначение — обеспечить контроль над активами, задействованными в сервисах, и предоставлять актуальные данные о них в нужное время и в нужном месте. Это позволяет поддерживать согласованность инфраструктуры, минимизировать ошибки при проведении изменений и ускорять процессы восстановления работоспособности систем.

Основное отличие заключается в том, как определяется следующий шаг в обработке инцидента. При произвольном маршруте специалист самостоятельно принимает решение о дальнейшем направлении инцидента на основе результатов диагностики. Например, инцидент, связанный с отказом информационной системы, может быть направлен администраторам ЦОД или в сетевую группу в зависимости от выявленной причины. При фиксированном маршруте для каждой услуги заранее установлена четкая последовательность линий поддержки и их ответственность. Это означает, что инцидент последовательно передается от L2 к L3 и затем к L4, без возможности отклонения от установленного маршрута, даже если требуется привлечь смежные специалисты. В таком случае привлечение смежников происходит через отдельный инцидент или задание.

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

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