Data Modeling для бизнес-аналитика — это перевод бизнес-процессов и требований в понятную схему данных (data model): сущности, связи, атрибуты и правила, чтобы ИТ не «додумывали» смысл. Связь с BPMN простая: BPMN показывает что делают люди и системы, а моделирование данных — с чем именно они это делают и что обязано сохраниться в ИС.

Если вы хоть раз видели, как одна и та же «Заявка» в разных командах внезапно превращается в «Обращение», «Тикет», «Инцидент» и «Сущность_123», то вы уже понимаете, зачем business analyst’у data modeling. BPMN-диаграммы (Business Process Model and Notation — нотация моделирования процессов) красивые, но коварные: они легко создают иллюзию точности. А потом выясняется, что у «Клиента» нет уникального идентификатора, «Договор» бывает без номера (да, в реальной жизни такое встречается), а «Статус» меняется так, что любой SQL начинает плакать.

По рынку это тоже видно. В российских вакансиях бизнес-аналитиков и системных аналитиков всё чаще мелькают требования: ERD/ER-диаграммы, нормализация, SQL, понимание DWH (Data Warehouse — хранилище данных), integration/data contracts. И это не «хотелки»: компании устали платить за ошибки в данных. Один неверно понятый атрибут в CRM или биллинге — и вы неделями разгребаете последствия в 1С, SAP-заменителях, самописных платформах, интеграциях с Госуслугами или СБП. Смешно? Нет, дорого.

Почему BPMN без data model часто превращается в фанфик

Тезис: BPMN отвечает на «как идёт работа», но не фиксирует «что такое сущности»

Обоснование. BPMN хорошо показывает поток: события, задачи, шлюзы, роли, сообщения между системами. Но BPMN почти не задаёт строгую семантику данных: что такое «Заявка», какие у неё обязательные поля, как она связана с «Клиентом», «Договором», «Платежом» и «Товаром».

Практический вывод. Если вы хотите, чтобы аналитика не развалилась на этапе разработки/интеграции, вам нужна data model рядом с BPMN: хотя бы концептуальная (conceptual model) и логическая (logical model).

Подводный камень. Частая ошибка — пытаться «запихнуть» смысл данных в подписи задач BPMN: «Проверить заявку (номер, дата, клиент, сумма…)». Это не модель. Это комментарий, который никто не поддерживает.

Как использовать BPMN, чтобы построить data model (и не сойти с ума)

Рабочая связка выглядит так:

1. Берём BPMN и выписываем ключевые «существительные» из задач/сообщений/событий: Клиент, Заявка, Договор, Счёт, Платёж, Товар, Доставка, Возврат.
2. Фиксируем жизненный цикл: статусы и переходы (это часто видно по шлюзам и событиям).
3. Определяем границы: что хранит наша система, что приходит из внешних (например, Сбер ID/ЕСИА, 1С, CRM, сервис доставки).
4. Строим ERD (Entity-Relationship Diagram): сущности (entities), атрибуты (attributes), связи (relationships), кардинальности (1:1, 1:N, M:N).
5. Проверяем на сценариях из BPMN: «на каждом шаге процесса какие сущности читаем/пишем/валидируем?»

Подводный камень. Не путайте «статус» и «событие». В BPMN вы рисуете событие «Оплата получена», а в data model фиксируете, что у платежа есть дата/сумма/метод/идентификатор транзакции, а у заказа меняется статус. Это разные вещи.

Основы data model: что должен уметь бизнес-аналитик

Тезис: бизнес-аналитику не обязательно быть архитектором БД, но базу нужно знать

Обоснование. На проектах в РФ бизнес-аналитику регулярно прилетает: «опиши данные», «согласуй справочники», «что считаем источником истины», «как маппим поля между CRM и 1С». Это уже не «хочу/не хочу», это часть job-to-be-done.

Практический вывод. Минимальный набор:

• понятия: сущность, атрибут, ключ (PK), внешний ключ (FK), связь, кардинальность;
• нормальные формы (хотя бы 1NF–3NF на уровне здравого смысла);
• разница между концептуальной, логической и физической моделью;
• умение читать ERD и задавать неудобные вопросы по данным;
• SQL на уровне SELECT/JOIN/GROUP BY (чтобы проверять гипотезы и качество данных).

Подводный камень. «Сделаю табличку в Excel, и нормально». Excel — не модель. Он не фиксирует связи и ограничения, а именно в них живут баги.

Концептуальная vs логическая vs физическая: что делать БА

Кейс из практики: как BPMN спасли, добавив model данных (и наоборот)

Кейс №1 (успешный): «Заявка» перестала быть мифологией

Процесс в BPMN был идеален: клиент оставляет заявку, система проверяет, оператор уточняет, дальше договор, оплата, исполнение. Но в требованиях «Заявка» была одна, а в жизни их оказалось три: черновик (заполнил не всё), подтверждённая (прошла валидацию), заявка-на-услугу (после договора). Пока не сделали логическую data model, разработка вела три разных объекта в коде, интеграция с 1С падала, а BI-отчёты считали конверсию «как получится».

Что сделали. Разделили сущности: Lead/Черновик, Application/Заявка, Order/Заказ. Прописали ключи, статусы, обязательные поля и связи с Клиентом и Договором. BPMN остался почти тем же, но стал проверяемым: на каждом шаге понятно, что создаётся/обновляется.

Кейс №2 (неудачный): BPMN «как использовать BPMN» без данных = дорогая импровизация

Команда нарисовала BPMN на 20+ задач и гордо ушла в разработку. Data modeling отложили «на потом». Итог: справочник статусов плодился в трёх системах (CRM, личный кабинет, 1С), у каждого свой набор значений. Через 2 месяца начали «сводить» статусы по маппингу, ещё через месяц поняли, что не хватает сущности «Причина отказа», потому что в BPMN она была текстом в задаче «Отклонить заявку».

Цена ошибки. Доработки интеграций, миграции данных, переделка отчётности. Самое неприятное — это не разовая боль, а долг. Технический, продуктовый и репутационный.

Что требуют вакансии и сколько времени нужно, чтобы «въехать»

Если без карго-культа: базовый навык моделирования данных можно поднять за 4–8 недель при 5–7 часах в неделю, если вы параллельно тренируетесь на реальных кейсах (интернет-магазин, заявки на услугу, биллинг, доставка). Для уверенного уровня, где вы не просто рисуете ERD, а умеете обсуждать ограничения и источники данных, обычно нужно 3–6 месяцев практики на проекте.

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

Коммерческие факторы: где вас могут развести на «обучение моделированию данных»

Рынок обучения в РФ по data modeling обычно распадается на три формата: короткие интенсивы, большие программы «аналитик под ключ» и корпоративные внутренние курсы. По деньгам разброс заметный: от 10–30 тыс. ₽ за короткий модуль до 120–250 тыс. ₽ за расширенные программы по аналитике. Но цена не равна пользе.

• Что обычно входит: основы ERD, нормализация, SQL, немного про DWH, практика на кейсах.
• За что часто доплачивают: проверка домашних, доступ к наставнику, разбор вашего проекта, подготовка портфолио, «карьерный трек».
• Где риск: если курс учит рисовать «красивые квадратики», но не учит задавать вопросы: ключи, уникальность, источники истины, правила валидации, версионность справочников.

Экспертный вердикт и инструмент: чек‑лист «Share of Model» для БА

Если коротко: BPMN без data model — как инструкция по сборке шкафа без списка деталей. Формально всё верно, а шурупы лишние. Ниже — инструмент, который повышает вашу «долю модели» в проекте (Share of Model): меньше домыслов, меньше переделок, больше predictability.

5 вопросов, которые нужно задать себе перед тем, как рисовать (или покупать курс)

1. Я различаю процесс и данные? BPMN — про поток работ. Data modeling — про смысл сущностей и правила хранения.
2. Я умею из BPMN извлекать сущности? Существительные, документы, справочники, объекты учёта.
3. Я фиксирую ключи и кардинальности? «У клиента много договоров» — это не философия, это 1:N.
4. Я делаю словарь данных? Определение, формат, обязательность, источник, правила.
5. Я проверяю модель сценариями? Беру 5–7 реальных кейсов и прогоняю: что создаётся, что меняется, что запрещено.

Стратегии для разных профилей

• Если вы «перебежчик» в IT (без опыта): берите связку BPMN + основы ERD + SQL. Цель — уметь объяснить 1 процесс и 1 модель данных на собесе без магии.
• Если вы Junior BA/SA (1–3 года): прокачивайте логическую модель, интеграции (маппинг полей), правила качества данных. Это быстрее всего конвертируется в деньги и доверие команды.
• Если вы ближе к PO/PM: держите концептуальную модель и словарь терминов. Это снижает стоимость коммуникации — самый дорогой вид «бага».

Частые вопросы