Под противопоставлением 'хочу делать vs. надо делать' имеется в виду конфликт между интересными задачами, которые человек сам хотел бы выполнять, и обязательными задачами, которые необходимо выполнить независимо от личных предпочтений. В тексте подчёркивается, что некоторые задачи приходится выполнять даже в том случае, если они не вызывают интереса или если человек не считает себя достаточно компетентным в этой области. В качестве примера приводится необходимость периодически заниматься вопросами бухгалтерского и налогового учёта, несмотря на то, что это не является любимым или приоритетным занятием автора.

Основные ошибки: 1) Сведение управления проблемами к 'медленному' устранению инцидентов без глубинного анализа причин; 2) Отсутствие отдельного потока для проактивного выявления проблем; 3) Непрожитие ролевой модели (например, игнорирование роли координатора проблем); 4) Использование метрик инцидент-менеджмента для оценки проблем; 5) Несоответствие настроек ITSM-системы процессным требованиям. Это приводит к формальному соблюдению процесса и сохранению повторяющихся инцидентов.

Заказчик играет ключевую роль в запуске потоков создания ценности. Заказчик предъявляет требования к услуге - новой или существующей, что запускает соответствующие потоки. При создании или изменении услуги заказчик запускает потоки, связанные с согласованием и фиксацией новых условий услуги и требований к уровню обслуживания (SLA) на этапах Offer и Agree. В рамках этих взаимодействий сбор требований осуществляется в виде деятельности потока Engage. Таким образом, заказчик является инициатором определенных потоков, когда предъявляет спрос на изменение или создание новых услуг.

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

Средний чек важен для финансового планирования ИТ-отдела, так как он позволяет перевести денежные цели продаж в количество операций, необходимых для их достижения. Это количество операций напрямую определяет объем необходимых ИТ-ресурсов: серверные мощности, лицензии, персонал технической поддержки. Зная, что при среднем чеке 10 000 рублей для выполнения годового плана в 1440 млн рублей потребуется обработать 120 000 сделок, ИТ-отдел может точнее запланировать бюджет на развитие и поддержание инфраструктуры, избегая как недостатка, так и избыточности ресурсов.

Субъективность восприятия существенно влияет на оценку производительности: один пользователь может считать нормальным ожидание в 5 минут, другой же будет недоволен уже через минуту. Это создает трудности при определении общепринятых стандартов работы системы. Чтобы минимизировать субъективность, важно перевести требования к производительности в четкие количественные показатели, понятные всем сторонам, и проверять их в реальных условиях использования системы конечными пользователями.

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

Доля экстренных изменений является одним из ключевых показателей эффективности (KPI) процесса управления изменениями. Высокая доля экстренных изменений указывает на недостаточное предварительное планирование, слабый контроль за процессом и увеличение рисков. Статистика подтверждает, что высокая доля экстренных изменений коррелирует с низким качеством их выполнения. Идеал — минимальная доля экстренных изменений, поскольку процесс управления изменениями по своей сути направлен на снижение рисков через соблюдение стандартных процедур.

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

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