В тексте приведены три основных примера неправильного поведения менеджеров. Первый пример: ИТ-руководитель в игре 'Grab@Pizza', который слишком долго пытается полностью разобраться в сценарии и предсказать будущее вместо того, чтобы начать работу. Второй пример: менеджер инцидентов в 'Apollo 13', который решает, что все инциденты должны проходить через него, и он будет всё регистрировать лично, что оказывается неэффективным уже ко второму раунду. Третий пример: менеджер проекта в 'The Challenge of Egypt', который основное время проводит на стройплощадке, командуя рабочими напрямую, игнорируя важные аспекты проекта вроде бюджета и сроков.

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

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

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

Автоматизация проверки CMDB включает использование сканеров обнаружения CI (например, ServiceNow Discovery, Lansweeper), интеграцию с системами мониторинга (Zabbix, Nagios) для сравнения реальных показателей с записями CMDB, и настройку триггеров на аномальные изменения (например, массовое обновление атрибутов за короткий срок). Для статических данных применяются скрипты сравнения с источниками доверенных данных (активы в финансовой системе). Ключевой элемент — регулярные сверки через API между CMDB и системами управления изменениями, чтобы отслеживать соответствие внесенных изменений утвержденным запросам.

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

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

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

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

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