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

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

Роль "Практик изменений" в ITIL V3 частично соответствует понятию "Координатор изменений", используемому на практике, но не в полной мере. В описании обязанностей практика изменений упоминаются мониторинг и проверка (reviewing) корректности выполнения работ по изменению, но не прямо указана задача по координации действий участников. Координация изменений упоминается в ITIL не в разделе про роли, а в описании активностей процесса, и её выполнение может быть возложено на разные лица: менеджера процесса, практика изменений или участников CAB. Поэтому многие организации на практике выделяют отдельную роль координатора изменений для обеспечения сквозной ответственности, что не формализовано в самом стандарте ITIL.

Для определения, какие метрики следует измерять с учетом их важности, помогает метод анализа через Causal Loop Diagram (CLD), который отображает причинно-следственные связи между элементами системы управления. Анализируя CLD, можно определить относительную важность разных показателей по силе их влияния на конечный результат. Это позволяет принимать обоснованное решение о том, на какие метрики стоит тратить ресурсы для измерения, а какие могут быть опущены из-за низкого влияния на общий результат или чрезмерной сложности измерения.

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

В традиционной системе KPI, где оценка основана только на соблюдении максимального времени Tmax, решение инцидента сразу перед истечением срока (например, за 3 часа 55 минут при Tmax = 4 часа) дает полный балл. Это создает обратную мотивацию — исполнители могут откладывать решение до последнего момента, не стремясь к оперативному восстановлению сервисов, что приводит к ненужным простоям и ущербу для бизнеса, хотя формально все нормативы соблюдены.

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

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

Быструю реализацию улучшений в ITSM можно достичь через внедрение небольших, но эффективных изменений в рамках текущей работы, подобно подходу CSI (Continual Service Improvement). Как показывает пример, не требуются масштабные и длительные проекты для достижения значимых результатов - сокращение времени решения инцидентов на 40% за полгода было реализовано собственными силами в режиме текущей деятельности. Успешное внедрение включает в себя четкое определение проблемы, разработку простого и понятного решения, постепенное внедрение с учетом пользовательского опыта и постоянную обратную связь. Ключевые факторы успеха - фокус на решении конкретной задачи (в данном случае сокращение времени на сбор информации и маршрутизацию), простота реализации и внимание к удобству конечных пользователей, что приводит к естественному принятию новой системы.

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