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

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

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

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

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

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

При опросе с 10000 пользователями и пятибалльной шкалой необходимый размер выборки для достижения достаточной точности остается тем же - 40-50 ответов. Это связано с тем, что необходимый размер выборки для обеспечения заданной точности (ширины доверительного интервала) при нормальном распределении данных не зависит от общего размера генеральной совокупности, если эта популяция достаточно велика (примерно больше 1000 человек). Таким образом, даже при увеличении числа пользователей в 10 раз (с 1000 до 10000) необходимая выборка для статистической точности не меняется.

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

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

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