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

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

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

Для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений необходимы следующие основные типы регламентирующих документов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы (АС) или выполнения доработок, обычно называемый «Положение о разработке прикладного ПО». Он содержит описание состава работ, ответственных лиц, входных и выходных документов для каждой стадии. Важная особенность – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. 2) Документ, определяющий порядок приёмки новых АС в эксплуатацию, который может быть частью первого документа и обычно называется «Положение о внедрении информационных систем». Он включает определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и других аспектов. Может дополняться политиками релизов. 3) Документ, определяющий архитектурные и технологические стандарты, распространяющиеся на разработку новых решений. Включает определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания, требований к интерфейсам, резервированию, мониторингу, журналированию и другим техническим аспектам. Эти документы образуют совокупный регламент управления изменениями и релизами в части разработки и внедрения прикладного программного обеспечения.

Основная цель домена руководства (EDM) в структуре COBIT 5 заключается в обеспечении того, чтобы система управления ИТ эффективно поддерживала достижение целей организации, учитывая интересы заинтересованных сторон. Для этого домен EDM обеспечивает оценку текущего состояния системы управления ИТ, определение направления её развития и мониторинг результатов. Конкретно это выражается в управлении ценностью, рисками и ресурсами в области ИТ, а также в поддержании системы руководства и обеспечении её прозрачности для заинтересованных лиц.

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

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

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

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

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