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

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

Укрупнённые схемы ИТ-систем, показывающие только общие компоненты (например, «ERP-система»), недостаточны для расчёта себестоимости услуг, потому что не учитывают различия в потреблении ресурсов различными группами пользователей. Например, одни пользователи могут постоянно работать в системе, другие использовать её редко для отчётов, третьи — обрабатывать большие объёмы данных. Себестоимость услуг зависит от профиля использования, который определяется бизнес-процессами. Для точного расчёта необходима детализация до уровня подсистем, отражающая, как именно разные пользователи потребляют ресурсы.

При замене системы необходимо: 1) Составить перечень архивируемых системных ролей из старой системы и новых ролей из новой. 2) Создать таблицу соответствия 'старая-новая' роль для выявления аналогов. 3) Архивировать роли старой системы после перехода и обновить бизнес-роли (которые включали старые системные роли), заменив их на новые. 4) Назначить пользователям обновлённые бизнес-роли через новые записи доступа. Например, если в старой системе роль 'Кассир' соответствует новой роли 'Оператор кассы', бизнес-роль 'Финансовый сотрудник' будет перестроена под новый набор системных прав.

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

При индивидуальном обслуживании вместо использования формальных количественных показателей можно напрямую оценивать удовлетворенность заказчика через регулярные опросы, поскольку услуги адаптируются под конкретного потребителя. Это позволяет учитывать субъективное восприятие качества и не ограничиваться только параметрами, зафиксированными в SLA. В отличие от массового производства, где основное внимание уделяется количественным показателям и стандартизации, при индивидуальном подходе можно учитывать как гарантийные показатели (warranty), так и полезность услуги (utility) с позиции конкретного заказчика.

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

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

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

Неожиданные бонусы от поставщика услуг значительно влияют на формирование личного восприятия качества сервиса, поскольку они нарушают стереотипы, сформированные у клиента на основе предыдущего опыта. Эти мелкие приятные сюрпризы становятся яркими точками в общем впечатлении, заставляя клиента пересмотреть своё мнение о качестве обслуживания. Даже если основные услуги оказаны на удовлетворительном уровне, дополнительные бонусы могут создать впечатление исключительно высокого качества сервиса и повысить вероятность повторного обращения.