'Конечный заказчик' (end customer) - это внешний клиент компании, для которого создается основная ценность. Например, если ИТ предоставляет услуги бизнес-подразделению, а оно в свою очередь обслуживает внешних клиентов, то эти внешние клиенты и будут конечными заказчиками. Конечные заказчики могут не взаимодействовать напрямую с ИТ-службой, но испытывают косвенную выгоду от улучшений в ИТ-процессах, таких как ускорение внедрения изменений и снижение простоев.

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

Федеральный закон 44-ФЗ определяет ответственность Поставщика за неисполнение или ненадлежащее исполнение обязательств в размере от 0,5% до 2,5% от суммы контракта, при этом точный процент зависит от суммы самого контракта. Такой размер штрафов значительно ниже, чем обычно предлагается в коммерческих контрактах, где штрафные санкции могут составлять 20–30% от суммы договора. Это указывает на более мягкий подход государственного регулирования к применению штрафов по сравнению с частным сектором и может ограничивать возможности заказчиков для установления строгих финансовых санкций в государственных закупках.

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

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

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

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

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

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

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