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

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

Для повышения защищенности метрики от непродуктивной активности был уточнен операнд C, определяющий, какие проблемы учитываются в расчете. Теперь в числитель формулы попадают только проблемы из группы 'а' (решенные, с явной пользой), в знаменатель – проблемы из групп 'а' и 'б' (с непродуктивными затратами), а проблемы из группы 'в' исключаются полностью. Это изменение делает метрику более устойчивой к искажению.

Чтобы избежать ошибок в выборе показателей, необходимо пройти через каскад целей: от общей стратегической задачи до конкретных измеримых показателей, на каждом этапе проверяя их соответствие исходной цели. Также важно всегда задавать вопрос: «Зачем это измеряется?», и как на основе полученных данных будут приниматься решения. Это поможет отсеять лишнее и сохранить только те метрики, которые реально влияют на управление и достижение результатов.

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

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

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

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

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

Использование статических весов не решает проблему игнорирования отдельных областей ответственности, потому что даже при больших весах отклонений от статического веса, если у сотрудника много KPI, частичное невыполнение по одной метрике снизит общую оценку пропорционально её весу, но не достаточно критично. Например, при 10 равнозначных KPI (вес 10% для каждого) полный провал одного показателя снижает средний результат всего на 10%. Поэтому работник может решить: "Черт с ними с 10%, я не буду делать эту работу и сосредоточусь на остальных". Статические веса не усиливают значимость провала по какому-то конкретному показателю в зависимости от ситуации.