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

Быструю реализацию улучшений в ITSM можно достичь через внедрение небольших, но эффективных изменений в рамках текущей работы, подобно подходу CSI (Continual Service Improvement). Как показывает пример, не требуются масштабные и длительные проекты для достижения значимых результатов - сокращение времени решения инцидентов на 40% за полгода было реализовано собственными силами в режиме текущей деятельности. Успешное внедрение включает в себя четкое определение проблемы, разработку простого и понятного решения, постепенное внедрение с учетом пользовательского опыта и постоянную обратную связь. Ключевые факторы успеха - фокус на решении конкретной задачи (в данном случае сокращение времени на сбор информации и маршрутизацию), простота реализации и внимание к удобству конечных пользователей, что приводит к естественному принятию новой системы.

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

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

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

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

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

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

Основные аргументы против использования методики EVM для построения комплексной системы оценки проектов включают: 1) Некорректность показателя SPI для оценки соблюдения сроков завершённых проектов, так как он автоматически становится равным 1 после завершения работ, скрывая реальное отставание; 2) Отсутствие в классической методике EVM прямого показателя качества проекта, хотя этот недостаток относительно легко устраняется; 3) Система метрик EVM изначально разработана для текущего мониторинга хода проекта, а не для комплексной оценки эффективности завершённых проектов.

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