SLM (Service Level Management) - это процесс управления уровнем обслуживания, а SLA (Service Level Agreement) - это конкретное соглашение, которое фиксирует уровень предоставления услуг. При проектировании процесса SLM важно определить, как формируются и утверждаются SLA. В данном случае предложен метод, когда на этапе старта процесса SLM формируется базовое SLA 'AS IS', которое затем может корректироваться бизнесом через дополнительные соглашения, обеспечивая баланс между необходимостью запуска процесса и учетом потребностей заказчиков.

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

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

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

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

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

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

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

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

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