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

При анализе связи «Человеческий фактор» в системном подходе к ITSM следует задавать такие вопросы: насколько инструмент полезен и удобен для пользователей, учитывает ли он их особенности, привычки и пожелания, могут ли сотрудники использовать новую технологию для работы (достаточно ли у них знаний и навыков, есть ли необходимость в обучении), чем обеспечено надлежащее использование инструмента и контроль ошибок. Эти вопросы помогают оценить, насколько хорошо технологические решения учитывают поведение и потребности людей, что критически важно для успешного внедрения любых изменений в системе управления ИТ-услугами.

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

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

Основные причины следующие: 1. Дочерним аутсорсерам не разрешают получать адекватную прибыль или применяется схема cost plus (1-2%), что мотивирует руководство аутсорсера на снижение эффективности для формирования запасов ресурсов. 2. Отсутствие жестких планов коммерческой деятельности на открытом рынке, что лишает аутсорсера стимулов к повышению качества и развития бизнеса, делая его инертным. 3. Вывод в аутсорсинг уникальных услуг, связанных с глубоким пониманием бизнес-процессов материнской компании. Это создает монополию на специализированные и базовые услуги, позволяя манипулировать ценами.

Структура сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (Actor), который определяется как внутренний или внешний; тип угрозы (Threat Type), такой как злоумышленные действия, ошибки или природные катаклизмы; событие (Event), включающее раскрытие информации, модификацию, кражу или уничтожение; связанные активы (Asset/Resource), относящиеся к людям, организационным структурам, процессам и ИТ-инфраструктуре; и временной аспект (Time), учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от времени суток или календарного периода.

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

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

Факторы успеха практик (PSF) в ITIL 4 напрямую связаны с потоками создания ценности. Ключевые показатели эффективности (KPI) формулируются на основе PSF для измерения эффективности практики именно в контексте её вклада в эти потоки creation ценности. Каждая практика, для которой определены PSF, участвует в определенных потоках создания ценности, и успешность её работы оценивается по тому, насколько её выполнение способствует достижению целей этих потоков. Таким образом, PSF помогают связать конкретные действия в рамках практики с более широкими организационными целями создания ценности для клиента.

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