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

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

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

Триггером для процесса управления изменениями может выступить либо запрос на новый или изменененный сервис, полученный от бизнес-заказчика через процесс управления взаимоотношениями с бизнесом (BRM), либо предложение об изменении (Change proposal), переданное из процесса управления портфелем услуг. Для каждого изменения важно определить его масштаб и значимость, чтобы выбрать соответствующий процесс обработки.

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

Российские компании демонстрируют более низкий уровень операционных затрат (55-60%) по сравнению с западными (73% и выше), что связано с меньшей долей аутсорсинга и особенностями инвестиционной активности. Однако в условиях кризиса российские компании сокращают капитальные вложения, что приводит к увеличению доли операционных затрат. Западные компании более активно используют аутсорсинг и автоматизацию, снижая таким образом долю затрат на персонал.

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

В 1990-х годах на рынках России популярные рекламные надписи включали такие фразы, как «Золото, доллары куплю» или «Доллары куплю / продам». Один из ярких примеров — надпись «Рассмотрю любые предложения» на лобовом стекле автомобиля около Горбушки, демонстрирующая гибкость и открытость предпринимателя к потребностям клиентов.

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

Для успешного внедрения анализа по модели Compass Model в организации необходимо предпринять следующие шаги: 1) Обучение персонала принципам модели и её применению в рамках customer journey. 2) Выбор ключевых услуг или процессов для первоначального анализа. 3) Сбор данных о клиентах через интервью, опросы, анализ существующей обратной связи. 4) Проведение анализа по четырём аспектам (Север, Запад, Юг, Восток) для каждой выбранной услуги. 5) Разработка рекомендаций по улучшению на основе выявленных аспектов. 6) Внедрение пилотных изменений и измерение их эффективности. 7) Интеграция Compass Model в регулярные процессы анализа и улучшения клиентского опыта. 8) Создание системы постоянного отслеживания изменений в потребностях, желаниях, стереотипах и эмоциях клиентов. Важно помнить, что практическое применение требует определенной тренировки, и первые анализы могут быть неточными, но с опытом качество анализа будет возрастать.