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

В структуре оказания услуг можно выделить три основные составляющие: 1) предоставляемые заказчику ресурсы (например, размещение в гостинице, предоставление доступа в интернет, обеспечение средств автоматизации бизнеса); 2) выполняемая сотрудниками поставщика услуг деятельность (такая как доставка грузов, уборка помещений, консалтинг, обучение как передача знаний); 3) сочетание деятельности и ресурсов (например, обучение как передача умений работы с ресурсами, такси и другие транспортные услуги, реализация бизнес-процессов заказчика). Для традиционных ИТ-услуг преобладает первая группа, где полезность создается главным образом за счет предоставляемых ресурсов, а не за счет деятельности ИТ-службы.

Управление рисками и постоянное совершенствование услуг (CSI) тесно связаны. Согласно Чарльзу Бетцу, обе сущности (риск и зона улучшения) требуют отслеживания и часто включают эквивалентные активности по исследованию. На практике деятельность в рамках непрерывного совершенствования часто приводит к идентификации новых рисков, а идентифицированные риски, в свою очередь, запускают новые циклы улучшений в рамках CSI. Это создает взаимоусиливающую связь, где управление рисками становится неотъемлемой частью процесса постоянного совершенствования услуг, обеспечивая более обоснованные управленческие решения и более предсказуемые результаты.

Для построения дерева отказов для функции «Обработка обращений» следует выполнить следующие шаги: определить топ-событие (отказ функции обработки обращений); выявить прямые причины этого отказа на первом уровне (например: недоступность базы данных, ошибки в логике обработки, проблемы с сетью между компонентами); для каждой из этих причин определить более низкоуровневые события, пока не достигнуты базовые события, которые уже не требуют дальнейшей декомпозиции (сбои оборудования, программные ошибки, действия персонала). При этом следует использовать правильные логические операторы между событиями («И», «ИЛИ» и др.). Например, если для отказа обработки обращений необходимо одновременное отсутствие сетевой связности между сервером и БД, а также сбой в прикладном слое – используется оператор «И». Если же достаточно одного из этих условий – оператор «ИЛИ». Базовые события размещаются на листьях дерева и могут быть оценены количественно для последующего расчета вероятности топ-события.

На основе анализа дерева отказов можно точно определить, какая конфигурационная единица (КЕ) влияет на какую функциональность услуги. Поскольку дерево наглядно показывает, какие КЕ и в какой комбинации приводят к отказу конкретной функции, становится возможным оценить критичность времени восстановления каждой КЕ. Например, если отказ определенной КЕ ведет к полной недоступности критически важной функции через оператор «ИЛИ», это означает, что для этой КЕ требуется минимальное RTO. Если же КЕ влияет на функцию только в комбинации с другими отказами через оператор «И», то RTO для такой КЕ может быть более мягким. Таким образом, FTA позволяет связать архитектурную модель с показателями непрерывности, а не устанавливать RTO/RPO на основе общих рекомендаций или произвольных решений.

Управление уровнем услуг (Service Level Management, SLM) играет ключевую роль при согласовании срочных изменений, обеспечивая коммуникацию между ИТ-организацией и бизнес-заказчиком. SLM отвечает за обсуждение и согласование целевых показателей доступности на период внедрения изменений, а также за обновление сервисных соглашений при необходимости временной корректировки целевых показателей. SLM обеспечивает прозрачность и осознанность бизнеса относительно последствий срочных изменений, фиксирует согласованные условия и помогает поддерживать доверительные отношения между ИТ и бизнесом в условиях необходимости оперативного реагирования на меняющиеся требования.

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

Для оценки необходимость введения OLA в конкретной организации необходимо провести детальный анализ целесообразности. Нужно проверить, действительно ли введение OLA добавит ценность в управление внутренними процессами или просто создаст дополнительный административный груз. Следует оценить возможные последствия: изменится ли организационная структура, насколько сложным будет контроль выполнения обязательств, и действительно ли внутренние подразделения готовы работать в режиме, близком к отношениям с внешними поставщиками. Также важно проверить, будет ли введение OLA упрощать взаимодействие или вносить путаницу, и есть ли уже существующие SLA и UC, которые покрывают необходимые аспекты без дублирования вводом OLA. В большинстве случаев оказывается, что OLA не требуется, и достаточно SLA и UC.

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

В IT4IT Reference Architecture определены четыре основных потока создания ценности (Value Streams): 1) Strategy to Portfolio (S2P) - охватывает процессы от определения бизнес-стратегии до формирования портфеля ИТ-услуг, включая управление портфелем, финансами и инвестициями; 2) Requirement to Deployment (R2D) - описывает процессы от определения требований к услуге до ее развертывания в эксплуатацию, включая разработку и тестирование; 3) Request to Fulfill (R2F) - охватывает предоставление услуг конечным пользователям, включая управление запросами, инцидентами и изменениями; 4) Detect to Correct (D2C) - отвечает за управление эксплуатацией, включая мониторинг, обнаружение проблем и их устранение. Каждый Value Stream представляет собой последовательность функциональных компонентов, которые вместе создают ценность для организации, начиная от бизнес-потребностей и заканчивая предоставлением работоспособных ИТ-услуг.