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

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

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

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

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

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

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

Кроме термина 'владелец процесса' в литературе по процессному управлению используются такие альтернативные названия, как 'управляющий процесса' (process manager), 'распорядитель процесса' (process steward) и 'спонсор процесса' (process sponsor). Эти термины часто применяются в тех случаях, когда человек, назначенный на роль, не обладает всеми необходимыми полномочиями для полноценного управления процессом, и термин 'владелец' становится условным. Например, 'распорядитель' (steward) лучше отражает роль человека, который не владеет процессом в прямом смысле, но ответственен за его развитие и поддержание в рабочем состоянии. Выбор термина зависит от конкретной ситуации и уровня полномочий, которыми обладает назначенный человек.

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

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