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

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

Принцип разделения полномочий (Segregation of Duties, SoD) в контексте ролевого управления доступом (RBAC) представляет собой механизм, который не позволяет назначать одному пользователю наборы прав, которые в совокупности могли бы привести к потенциальным конфликтам интересов или мошенническим действиям. Например, сотрудник, который может создавать поставщиков и одновременно утверждать платежи этим поставщикам, представляет собой риск. RBAC позволяет предопределить такие конфликтные сочетания ролей и заблокировать их одновременное назначение одному пользователю. Это значительно снижает риск предоставления избыточных полномочий и повышает безопасность информационных систем.

Для связи ИТ-метрик с бизнес-целями следует заменить показатели, фокусирующиеся только на выходах, на метрики, влияющие на результаты. Вместо 'времени ответа на запрос' измерять 'рост NPS клиентов', вместо 'количества релизов' - 'ускорение вывода продукта на рынок'. Хороший пример - компания Ford, которая заменила KPI 'количество строк кода' на 'снижение времени сборки авто', повысив эффективность ИТ на 200%. Необходимо всегда проверять, как технические метрики влияют на конечные бизнес-результаты и перестроить систему отчетности и поощрений вокруг этих результатов.

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

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

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

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

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

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