Текущая практика управления бизнес-требованиями и корпоративной архитектурой

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

В этой записи я объясню связь этих двух областей управления (знаний).

Что такое бизнес-требования на автоматизацию?

Они фокусируются на:

• решении бизнес-проблем: например, устранить «узкие места», снизить количество ошибок, ускорить выполнение процессов и т.д.;

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

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

Бизнес-требования - это основной выход процесса управления бизнес-архитектурой организации в контексте автоматизации.

Что такое корпоративная архитектура (Enterprise Architecture)?

Корпоративная архитектура (КА) — это целостное представление о структуре и функционировании организации, как системы.

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

КА часто описывают через домены (например, модель TOGAF):

• бизнес-архитектура: стратегия, бизнес-процессы, организационная структура, роли, бизнес-объекты, бизнес-способности;

• архитектура данных/информации: ключевые данные, их потоки, модели хранения и управления;

• архитектура приложений: набор прикладных систем, их функции и взаимодействие между собой;

• технологическая архитектура: «Железо», ПО, сети, инфраструктура (облака, серверы и т.д.).

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

Как связываются между собой процессы проектирования бизнес-требований и управления корпоративной архитектурой

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

Проще говоря: бизнес-требования — это «хотелки», а корпоративная архитектура — «правила игры» и «фундамент», которые определяют, КАК эти «хотелки» можно реализовать.

Вот как это работает на практике

Бизнес-требования формируют вектор развития КА:

• новые драйверы для изменений: бизнес‑требование «Внедрить AI‑чатбот для поддержки клиентов» становится драйвером для развития архитектуры приложений (нужно выбрать платформу для чат‑бота) и архитектуры данных (нужен доступ к базе знаний и истории заказов);

• определение приоритетов: КА помогает оценить, какие из бизнес-требований являются наиболее стратегически важными и соответствуют долгосрочным целям компании.

КА накладывает ограничения и дает возможности для реализации требований:

• соблюдение стандартов: бизнес-требование должно быть реализовано в рамках утвержденных технологических стандартов (например, использование облачной платформы AWS, а не Google Cloud, если это стандарт компании);

• интеграция, ане создание «островков»: КА требует, чтобы новая функциональность не была «вещью в себе». Она должна быть интегрирована с существующими ERP, CRM и другими системами, используя утвержденные API и шины данных;

• безопасность и комплаенс: архитектура диктует требования к безопасности данных, которые автоматизация должна соблюдать (например, правила хранения ПДн);

• использование существующих активов: КА может показать, что для реализации бизнес-требования можно использовать или доработать уже имеющуюся систему, а не покупать новую, что сэкономит деньги.

Агрегация требований

На рисунке изображён общий процесс агрегации требований.

Для того, чтобы правильно и максимально качественно реализовать бизнес-требования, их нужно «прогнать» через процесс управления требованиями сквозь архитектурные домены (речь о производственном конвейере, в основе которого заложены архитектурные паттерны).

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

Результат

Бизнес-требования не просто превращаются в задачу для разработчиков "сделайте систему". Оно трансформируется в архитектурно значимое требование, которое:

• вписывается в существующий ландшафт систем;

• соответствует стандартам компании;

• учитывает будущее развитие (масштабируемость);

• избегает создания изолированного решения, которое в будущем станет проблемой.

Преимущества приведённого подхода

При организации ИТ-производства с учётом данного подхода удаётся в лучшей степени управлять процессами:

• стратегической согласованности: проекты автоматизации работают на общие цели компании, а не решают сиюминутные проблемы одного подразделения/заказчика;

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

• эффективности инвестиций: решения более продуманы, что снижает общую стоимость владения (меньше доработок, проще поддержка, легче интеграция);

• гибкости и адаптивности: создается не набор разрозненных ИТ-решений, а целостная, гибкая ИТ-среда, способная быстро реагировать на новые бизнес-вызовы.

В конечном счёте это сказывается на удовлетворённости заказчиков реализованными ИТ-решениями и в целом на повышении качества ИТ-продукта.

Вывод

Бизнес-требования и корпоративная архитектура — две стороны одной медали. Бизнес-требования без учета КА ведут к хаосу, «зоопарку» систем и техническому долгу. Корпоративная архитектура без ориентации на бизнес‑требования превращается в бюрократическую надстройку, которая тормозит развитие.

Успешная автоматизация— это всегда диалог между бизнес‑заказчиками (которые формулируют «ЗАЧЕМ») и архитекторами (которые знают «КАК» это правильно сделать в контексте всей компании).