В IT4IT Reference Architecture определены четыре основных потока создания ценности (Value Streams): 1) Strategy to Portfolio (S2P) - охватывает процессы от определения бизнес-стратегии до формирования портфеля ИТ-услуг, включая управление портфелем, финансами и инвестициями; 2) Requirement to Deployment (R2D) - описывает процессы от определения требований к услуге до ее развертывания в эксплуатацию, включая разработку и тестирование; 3) Request to Fulfill (R2F) - охватывает предоставление услуг конечным пользователям, включая управление запросами, инцидентами и изменениями; 4) Detect to Correct (D2C) - отвечает за управление эксплуатацией, включая мониторинг, обнаружение проблем и их устранение. Каждый Value Stream представляет собой последовательность функциональных компонентов, которые вместе создают ценность для организации, начиная от бизнес-потребностей и заканчивая предоставлением работоспособных ИТ-услуг.

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

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

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

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

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

Определение значения N для расчёта метрик FLR и FCR является сложной задачей, потому что далеко не все обращения возможно разрешить на первой линии. Часть заявок физически невозможно решить удалённо, часть нельзя обрабатывать из-за ограничений регламентов или политик, а часть требует уровня доступа, которым не обладают сотрудники первой линии. Если учитывать все обращения в расчёте, это приведёт к искажению результатов, так как первая линия не может влиять на те обращения, которые технически не могут быть разрешены на её уровне. Это делает показатель плохо применимым для объективной оценки эффективности работы первой линии.

Метод «Пять Почему» используется в DevOps для выявления корневых причин проблем, что помогает не только оперативно устранять текущие дефекты, но и предотвращать повторение аналогичных ошибок. Этот метод заключается в многократном задавании вопроса «Почему?» после каждой выявленной причины проблемы, пока не будет найдена первопричина. Применение «Пяти Почему» в DevOps способствует формированию системы, где внимание уделяется не только внешним симптомам, но и внутренним процессам, что ведёт к более устойчивым и эффективным решениям во всей цепочке создания ценности.

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

При опросе с 10000 пользователями и пятибалльной шкалой необходимый размер выборки для достижения достаточной точности остается тем же - 40-50 ответов. Это связано с тем, что необходимый размер выборки для обеспечения заданной точности (ширины доверительного интервала) при нормальном распределении данных не зависит от общего размера генеральной совокупности, если эта популяция достаточно велика (примерно больше 1000 человек). Таким образом, даже при увеличении числа пользователей в 10 раз (с 1000 до 10000) необходимая выборка для статистической точности не меняется.