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

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

После этапа, когда работа считается завершенной после подтверждения тестировщиком, следующим этапом в эволюции Definition of Done является Agile-подход, при котором работа считается завершенной после того, как владелец продукта принял результат разработки. В соответствии с подходами, такими как SAFe, владелец продукта является единственным членом команды, который может принимать истории как выполненные, что включает проверку соответствия критериям Definition of Done. Для больших организаций этот процесс усложняется дополнительными уровнями приемки: на уровне команды, системы, решения и релиза.

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

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

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

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

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

В России знания в области профессионального управления аутсорсингом ИТ-услуг пока мало востребованы. Это может быть связано с несколькими причинами: отсутствием информации о существующих источниках знаний, таких как OPBOK, SIAM или стандарты ISO 37500; особенностями локального рынка, где требования к формализации управления поставщиками могут быть менее строгими; или недостаточным пониманием ценности сертификаций и профессиональных стандартов в этой области. Также возможной причиной может быть отсутствие давления со стороны бизнеса на формализацию процессов управления аутсорсингом, что приводит к низкому спросу на соответствующие компетенции среди ИТ-специалистов.

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