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

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

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

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

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

Доля повторно открытых инцидентов может служить характеристикой качества работы процесса управления инцидентами. В идеале закрытие инцидента означает его полное решение и достаточную проверку эффективности решения. Рост доли инцидентов, которые потребовали переоткрытия, при прочих равных условиях свидетельствует об ухудшении качества работы процесса — снижается показатель First Time Resolution (FTR), что говорит о снижении рациональности процесса и увеличении необходимости переделок.

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

Компании часто совершают следующие ошибки при построении многоуровневой системы поддержки: неправильное распределение ответственности между уровнями, из-за чего задачи задерживаются на определенном уровне; недостаточное обучение сотрудников второго и третьего уровня специфике коммуникации с первым уровнем и пользователем; отсутствие четких SLA между уровнями поддержки и механизмов контроля соблюдения сроков; игнорирование важности человеческого фактора в работе первой линии и недостаточная инвестиция в развитие soft skills сотрудников; чрезмерная формализация процессов, которая замедляет реагирование на критические ситуации. Особенно часто ошибкой является создание сложной структуры без обеспечения ее внутренней согласованности и общих целей для всех участников процесса.

При публикации статистических данных о внедрении ITIL часто искажаются аспекты, связанные с реальными показателями эффективности. Например, увеличение эффективности персонала на 80% или снижение количества инцидентов на 40% могут быть неподтвержденными цифрами. Искажению подвергаются также цели и функции отдельных процессов, что приводит к неправильному пониманию их роли и значимости.

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