👀 Разбор кейса работы с BIAN

Процесс: "Оформление онлайн-заявки на кредитную карту".

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

BIAN говорит нам действовать иначе.

1️⃣ Мы открываем эталонную модель BIAN и видим, что наш процесс можно разложить на несколько стандартных бизнес-способностей:    ▫️ Customer Onboarding: Первичная регистрация и верификация клиента.    ▫️ Product Matching: Подбор подходящего продукта (карты) под параметры клиента.    ▫️ Credit Risk Assessment: Оценка кредитного риска.    ▫️ Card Issuance: Выпуск карты.    ▫️ Account Management: Управление счетом карты. 2️⃣ Каждая из этих способностей — это независимый сервис со своими операциями (InitiateOnboarding, CheckProductEligibility, AssessCreditRisk). 3️⃣ Наша задача как аналитиков — не придумывать эти сервисы с нуля, а сопоставить требования нашего проекта с уже существующими в BIAN способностями и описать сценарии их взаимодействия.

🟢 Что мы получаем в итоге?

▫️Скорость: Мы не изобретаем велосипед. У нас уже есть готовая таксономия и модель данных. ▫️Четкость: Все участники проекта (бизнес, архитекторы, разработчики) говорят на одном языке. ▫️Гибкость: Если нам нужно изменить процесс (например, подключить нового поставщика скоринга), мы меняем только сервис Credit Risk Assessment, а не весь процесс целиком.

♥️ Как BIAN помогает в работе аналитика?

1️⃣ Как источник требований и словарь терминов.    ▫️Сценарий: Вы начинаете новый проект по автоматизации взыскания долгов. Открываете модель BIAN, находите способность "Collections".    ▫️Польза: Вы мгновенно получаете готовый список связанных бизнес-терминов (Delinquent Account, Collection Plan), возможных операций (Create Collection Case) и смежных сервисов (Customer Agreement, Account Management). Это ваша отправная точка для интервью с бизнес-экспертами. 2️⃣ Как инструмент для анализа AS-IS и проектирования TO-BE.    ▫️Сценарий: Вам нужно описать текущий ландшафт систем (AS-IS) и спроектировать целевой (TO-BE).    ▫️Польза: Вы накладываете существующие системы на карту BIAN. Становится наглядно видно, где функционал дублируется (три системы выполняют одну способность), а где есть пробелы. При проектировании TO-BE вы просто "назначаете" сервисы на новые или модернизированные системы. 3️⃣ Как основа для проектирования API.    ▫️Сценарий: Разработчики просят у вас спецификации для API нового микросервиса.    ▫️Польза: BIAN предоставляет готовые шаблоны для API-контрактов для многих сервисов. Вы можете взять за основу стандартные операции и объекты данных, значительно ускорив проектирование и повысив согласованность API по всему банку. 4️⃣ Как мост между бизнес-архитектурой и ИТ-архитектурой.    ▫️Сценарий: Вам нужно объяснить бизнес-заказчику, почему вы предлагаете разбить систему на три отдельных модуля.    ▫️Польза: Вы показываете ему карту BIAN: "Вот, смотрите, это не я придумал. Это отраслевой стандарт. Модуль 1 отвечает за Customer Agreement, модуль 2 — за Payment Execution, модуль 3 — за Fraud Detection. Так надежнее и гибче".

🫠 Неужели все так прекрасно?

BIAN — это не серебряная пуля. Начиная его использовать, важно понимать:

🔅Это эталон, а не догма. BIAN нужно адаптировать под специфику вашего проекта/банка. Не все способности могут быть вам нужны, а какие-то, возможно, придется добавить. 🔅 Высокий порог входа. Чтобы эффективно использовать BIAN, команда (особенно аналитики и архитекторы) должна его изучить и понять. Требуются инвестиции в обучение. 🔅Фокус на "Что", а не "Как". BIAN не говорит, как именно реализовывать сервис — на какой технологии, с помощью какой СУБД. Это задача вашей технической команды.