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

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

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

Для повышения эффективности анализа проблем метод «Пять «Почему?» часто используется в сочетании с другими техниками. Диаграмма Ишикавы («рыбий скелет») помогает визуализировать ветвление причинно-следственных связей. Метод Кепнера-Трего (включая его описание в ITIL) систематизирует анализ через этапы описания и определения проблемы. Дерево текущей/будущей реальности из теории ограничений Э. Голдратта позволяет структурировать причинно-следственные отношения. Эти методы помогают упорядочить процесс формулирования вопросов и минимизировать риски одностороннего анализа.

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

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

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

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

Традиционная схема оценки влияния инцидентов имеет несколько существенных недостатков: 1) Сотрудник может не знать, испытывают ли его коллеги аналогичные проблемы, что затрудняет оценку масштаба инцидента. 2) Не существует четкой границы между 'совсем не работает' и 'частично не работает' - пользователь, столкнувшийся с проблемой печати отчета, вряд ли согласится, что эта проблема малозначительна, даже если остальные функции работают нормально. 3) Базовая схема не учитывает критичность определенных ИТ-услуг в конкретные периоды времени или для определенных групп пользователей.

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