Согласно второму принципу DASA, важность ориентации на конечный результат (Create with the End in Mind) заключается в отказе от водопадного подхода и процессно-ориентированных моделей, где сотрудники выполняют только конкретные функции без понимания общей картины. Вместо этого компании должны действовать как продуктовые организации, явно сфокусированные на создании продуктов для реальных заказчиков. Это требует, чтобы все сотрудники понимали полный контекст создания продукта и представляли его конечными пользователям. Такой подход позволяет более эффективно выстраивать процессы, минимизировать разрыв между отделами и обеспечивать создание ценности для клиентов с самого начала процесса разработки.

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

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

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

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

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

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

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

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

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