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

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

В процессе непрерывного улучшения услуг (CSI - Continual Service Improvement) BRM играет важную инновационную роль. BRM определяет возможности по оптимизации ценности, которую сервис-провайдер несет заказчикам. BRM может выявлять возможности как в рамках текущей деятельности (благодаря постоянной осведомленности о задачах заказчика), так и в рамках периодических service reviews. BRM отвечает за документирование выявленных возможностей или потребностей и их передачу для дальнейшей проработки. BRM также отслеживает прогресс реализации улучшений и при необходимости выступает координатором деятельности, выполняемой в рамках других процессов, особенно в случаях риска потери фокуса на цели улучшения.

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

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

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

Детализация моделей изменений не может быть максимальной по следующим причинам: - Трудозатраты: чрезмерная детализация, стремление к учету «каждого чих», приведет к значительным временным и ресурсным затратам на разработку и поддержку моделей, при этом потенциальная польза от такого подхода будет несопоставима с затратами. - Системные ошибки: чем детальнее и сложнее модели, тем выше вероятность наличия системных ошибок, что может привести к непредвиденным последствиям при реализации изменений. - Отсутствие гибкости: максимальная детализация снижает способность процесса адаптироваться к уникальным ситуациям, когда стандартные процедуры не учитывают специфику конкретной задачи, вынуждая координаторов нарушать установленные правила. - Уровень неопределенности изменений: в отличие от процесса управления инцидентами, где важна скорость и чёткие алгоритмы, процесс управления изменениями характеризуется высокой степенью неопределенности. Поэтому необходим аналитический подход, оценка влияния, определение стоимости и других параметров, что делает недопустимым полностью предопределённый регламент для всех случаев. Поэтому требуется баланс между достаточной детализацией для стандартных изменений и гибкостью процесса для нестандартных ситуаций.

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

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

Заинтересованные стороны играют ключевую роль в домене EDM COBIT 5. Процесс EDM05 напрямую связан с их потребностями, так как обеспечивает прозрачность и информирование заинтересованных сторон. Кроме того, все процессы домена EDM ориентированы на удовлетворение ожиданий и требований заинтересованных лиц. Например, процессы EDM02, EDM03 и EDM04 направлены на оптимизацию ценности, рисков и ресурсов именно с точки зрения интересов заинтересованных сторон. Таким образом, заинтересованные стороны выступают как основные получатели результатов деятельности системы руководства ИТ.