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

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

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

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

Первый принцип DevOps по DASA — Деятельность должна быть ориентирована на заказчика (Customer-Centric Action). Этот принцип включает постоянные инвестиции в продукты и услуги, которые обеспечивают максимальную удовлетворённость заказчика. Также он подразумевает необходимость коротких циклов обратной связи с заказчиками и конечными пользователями. Кроме того, принцип включает деятельность в духе Lean-стартапов с постоянными инновациями, что помогает быстро адаптироваться к меняющимся потребностям клиентов и тестировать новые идеи в реальных условиях.

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

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

ITIL 4 предлагает решать проблему разобщенности через принцип 'Используйте целостный подход' (Think and work holistically) и через рассмотрение четырех аспектов управления ИТ-услугами. Этот принцип подразумевает необходимость понимания того, как все части организации работают вместе интегрированным образом. Вместо того чтобы фокусироваться на отдельных элементах (процессах без учета инструментов и компетенций, или наоборот), ITIL 4 предлагает рассматривать четыре взаимосвязанных аспекта: организации и люди, информация и технологии, партнеры и поставщики, потоки создания ценности и процессы. Для устранения разобщенности также необходимо формировать организационные структуры, ориентированные на сотрудничество, развивать культуру доверия и прозрачности, обеспечивать достаточные компетенции сотрудников и правильно определять взаимодействие с партнерами. Важно рассматривать процессы не изолированно, а как часть потоков создания ценности, что обеспечивает целостное преобразование входов в результаты, воспринимаемые клиентом.

Utility (Полезность) и Warranty (Гарантия) являются двумя основными характеристиками услуги. Utility отвечает на вопрос fit for purpose - пригодность к цели, помогает ли услуга пользователю достичь желаемого результата. Например, свет в темной комнате полезен для чтения книги. Warranty отвечает на вопрос fit for use - пригодность к использованию, представляет собой четыре компонента: доступность, мощность, безопасность и непрерывность. Услуга может иметь высокую полезность (помогает достичь цели), но низкую гарантию (например, свет мигает, что затрудняет чтение). Полезность определяет соответствие услуги цели, а гарантия - условия, в которых услуга может быть использована.

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