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

Жизненный цикл управления значительными инцидентами отличается от обычных инцидентов несколькими ключевыми аспектами: 1) Требуется назначение специального ответственного лица для управления именно этим инцидентом; 2) Обязательно уведомление топ-менеджмента; 3) Необходимость масштабной координации между множеством подразделений и команд (ИТ, административное, ИБ, связь); 4) Активация специальных аварийных процедур; 5) Параллельное проведение расследования причин инцидента, которое организуется отдельно от процесса реагирования; 6) Обязательный анализ после восстановления услуг с целью определения возможностей для улучшения. В отличие от обычных инцидентов, значительные требуют мобилизации дополнительных ресурсов и особых методов управления.

Приоритетные виды лицензий следует выбирать исходя из текущих проблем организации. Например, это могут быть продукты Microsoft с подпиской, часто устанавливаемые вручную, или «прикладной софт» (например, Photoshop), который сотрудники копируют без контроля. Серверное ПО редко становится первоочередной задачей. Ключевой критерий – наличие уже существующего процесса учёта (даже в Excel), так как внедрение системы для управления тем, что никто не готов отслеживать, обречено на провал.

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

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

Причины дисбаланса между стимулированием и наказанием включают структурные особенности систем оплаты труда, где премии часто интегрированы в базовый оклад и их легко урезать, но сложно увеличить. Корпоративные политики часто недостаточно гибкие для включения процессных метрик в систему поощрений. Годовой цикл премирования отдаляет поощрение от текущих достижений и делает его недостаточно мотивирующим. Культурные установки, наследующие лозунгам вроде «не умеешь – научим, не хочешь – заставим», усугубляют ситуацию. Это наблюдается не только в российских компаниях, но и в международной практике, где литература по управлению ИТ уделяет больше внимания контролю, чем разработке систем стимулирования.

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

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

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

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