При изменении ИТ-ландшафта (например, замене системы) связь между системными и бизнес-ролями определяется через: 1) Анализ архитектуры старой и новой систем — выявление функциональных аналогов (например, роль 'Менеджер проектов' в старой Jira может соответствовать роли 'Лид проекта' в новой системе). 2) Построение таблицы соответствия, где каждой старой системной роли ставится в соответствие новая. 3) Корректировку бизнес-ролей: если старая системная роль 'Кассир' входила в бизнес-роль 'Финансовый сотрудник', после замены её заменяют на новую роль 'Оператор кассы', но бизнес-роль сохраняет логику использования. Критически важно сохранить соответствие функций сотрудников, даже если названия системных ролей меняются.

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

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

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

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

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

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

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

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

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