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

Роли менеджера изменений в ITIL часто вызывают неоднозначность, потому что в ITIL V3 эта роль не была описана как отдельная, а вместо нее упоминались другие роли, такие как владелец процесса и практик. В зависимости от контекста и организации роль 'менеджера изменений' могла включать в себя различные функции, иногда совмещая обязанности менеджера процесса, администратора изменений и председателя CAB. Даже в ITIL4, где роль менеджера изменений стала официальной, остается гибкость в распределении обязанностей: менеджер изменений может выступать как универсальный ролевой игрок, объединяющий несколько функций, или его обязанности могут быть распределены между менеджером изменений и координаторами, в зависимости от масштаба организации и сложности изменений.

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

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

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

Увеличение размера внедрения (Release size) приводит к нескольким негативным эффектам. Во-первых, большие релизы сложнее планировать, контролировать и тестировать, что повышает Change Risk (риск неудачного внедрения). Во-вторых, крупные изменения чаще приводят к ошибкам и сбоям, требующим дополнительных изменений для их исправления, что увеличивает Backlog Size (размер очереди изменений). В-третьих, когда Backlog Size становится большим, это приводит к усилению стремления 'укрупнять' последующие внедрения, создавая замкнутый цикл. Крупные релизы также увеличивают Process Time (время работы над изменением) и Queue Time (время ожидания), что в совокупности приводит к росту Time to market. Таким образом, увеличение Release size запускает несколько негативных усиливающих петлей обратной связи, которые со временем усугубляют проблемы в ИТ-системе и могут привести к нисходящей спирали, описанной как Core Chronic Conflict.

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

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

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

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