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

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

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

Метрика рассчитывается по формуле: коэффициент обновления = (N + C) / (N + C + O), где N - количество новых проблем, зарегистрированных за период и не закрытых на момент его окончания (используется для нормировки); C - количество проблем, закрытых за период; O - количество проблем, открытых по итогам периода. Метрика нормирована и изменяется в диапазоне значений от 0 до 1.

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

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

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

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

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

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