Бизнес-аналитик в процессе проектирования ИТ-решений
В идеальных условиях именно роль «бизнес‑аналитик» в производственном ИТ‑процессе должна быть «входной точкой» для бизнес‑заказчика, формализующей, как правило, неструктурированные требования в структурированные. Через эту же роль должна производиться обратная связь ИТ‑команды бизнес‑заказчику.
На практике такой подход встречается редко и функциональность роли "бизнес-аналитик" часто либо полностью, либо частично вменена другим производственным ролям - системным аналитикам, различного вида архитекторам, руководителям проектов, ИТ бизнес-партнёрам и т.д.
В каждой организации сложились свои разновидности ИТ-процессов и обязанности участников, но необходимость взаимодействия с бизнес-заказчиком и формализации его потребностей на автоматизацию в понятный ИТ-команде стандартизированный язык является общей.
Инструменты формализации бизнес-требований
Бизнес-требования должны быть унифицированным инструментом, а значит - выражаться в типовом шаблоне. Шаблон может содержать различную бизнес-информацию, но ключевой с точки зрения проектирования ИТ-решения является информация с описанием бизнес-процессов как объекта автоматизации в привязке к глоссарию терминов.
Качественное описание бизнес-процессов автоматизации - основа проектирования и дальнейшего контроля качества ИТ-решений.
Стандартом (или лидером среди прочих нотаций, таких как EPC, CFF, IDEF0 и пр.) описания бизнес‑процессов можно назвать BPMN (Business Process Model and Notation). Данный язык действительно является мощным инструментом для изложения бизнес‑логики. А вот структуру бизнес‑объектов (или бизнес‑данных) в нём описать невозможно, только указать сами бизнес‑объекты в процессе. А эти объекты прямо созависимы с описываемыми бизнес‑процессами и глоссарием терминов. Такую возможность даёт Archimate, при этом в данном языке присутствуют и остальные ключевые для проектирования объекты описания: в таблице приводится сравнительный анализ элементов различных нотаций и языков моделирования.
Несмотря на то, что Archimate является более концептуальным и высокоуровневым, архитектурным языком моделирования, при его использовании можно так же достаточно детально описывать бизнес‑процессы. При этом, возможность описания в нём структуры данных (бизнес‑объектов) как части бизнес‑процесса позволяет отобразить, какие составные элементы бизнес‑объекта могут быть самостоятельным триггером и/или выходом шагов бизнес‑процесса. Такую логику нельзя отобразить в BPMN (как и в других приведённых выше нотациях). Это крайне полезное преимущество при проработке бизнес‑требований и дальнейшего взаимодействия с бизнес‑заказчиком.
Главным же преимуществом BPMN по сравнению с Archimate является огромное количество условий (логических операторов) и событий, что удобно для низкоуровневого описания и изложения очень подробной бизнес-логики.
Таким образом, использование бизнес‑аналитиком двух языков моделирования, BPMN и Archimate, для формализации бизнес‑требований на высоком и низком уровне — вопрос не только удобства, но и улучшения качества, связанности и дальнейшего каскадированиия бизнес‑требований. Такая агрегация инструментов — большой шаг в развитии роли и личных компетенций тех, кто в этой роли работает.
Бизнес-требования как часть архитектуры
Почему было упомянуто дальнейшего каскадирование требований: в статье https://habr.com/ru/articles/953794/ приводилось развёрнутое описание связи бизнес-требований и архитектуры. Отмечу здесь, что работа бизнес-аналитика затрагивает два архитектурных домена - бизнес-архитектуру и данные, т.к. ключевые объекты его проектирования - это бизнес-процессы и бизнес-объекты (концептуальные модели данных). Артефакты, разрабатываемые бизнес-аналитиком в любом случае всегда содержат (или должны содержать) компоненты этих двух доменов. Проблема в том, что как правило, пообъектная связь бизнес-требований с остальными доменами никем не выявляется.
Использование же Archimate в работе бизнес-анлалитика может стать первым шагом для чёткого и стандартизированного связывания бизнес-требований с техническими, мостиком между бизнесом и ИТ через проектирование архитектуры, в которой бизнес-аналитик выступает первым номером. Это инструмент, позволяющий сделать апгрейд роли "бизнес-аналитик" до участника архитектурного проектирования ИТ-решений, а также задающий контекст для роста в роль "бизнес-архитектор".
При внедрения Archimate в работу бизнес‑аналитика наравне с BPMN и стандартизации подхода проектирования бизнес‑требований на базе двух языков моделирования, можно сэкономить большое количество времени на «приземление» спроектированных бизнес‑процессов на ИТ‑ландшафт (обычно именно на этом этапе уходит самый большой временной ресурс участников проектирования). В идеальном варианте на схемах бизнес‑процессов в Archimate, полученных от бизнес‑аналитика, остальными ролями проектирования (например, архитекторами), должны добавляться объекты доменов приложений и инфраструктуры — информационные системы, интеграции, платформы и так далее в привязке к конкретным шагам бизнес‑процессов.
Комментарии (22)
itGuevara
07.10.2025 14:49Сравнение состава объектов нотаций моделирования бизнес-процессов
Идея правильная (достаточно трех BPMN\EPC\ArchiMate\VAD), но
а) дополнить, например, BPMN: Data Objects \ Data Stores, промежуточное событие и др.б) показать не только объекты (причем если больше пяти, то пятерку значками, а далее цифру "всего", а для ArchiMate лучше сразу брать Next), но и типы связей и к каким объектам они применимы.
Eugene_Demochko Автор
07.10.2025 14:49спасибо, наверное нужно будет написать отдельную статью про архимейт и уже с ним сравнивать прочие нотации. Связи между объектами (за исключением динамических, имеющихся в других нотациях) это его большой плюс
FrankNStein
07.10.2025 14:49Как низккевалифицированный в теории 1Сник могу сказать, что простейший BPMN, где на схеме кроме функций отражаем объекты метаданных системы, рулит.
Хорошо читается как заказчиком, так и аналитиками и программистами, определяет матрицу доступа до функциональных ролей и объектов, не требует запредельной квалификации аналитиков. Достаточно дешево, достаточно сердито.
Eugene_Demochko Автор
07.10.2025 14:49спасибо за комментарий! согласен, BPMN во многих местах отлично применяется, в статье я описывал метод перехода от сложившейся практики бизнес-аналитика дальше в архитектурную сферу, чтобы читаемые схемы были первым вариантом архитектурного артефакта
ASenchenko
07.10.2025 14:49Вот она истина то :)))
Главное чтобы читатель понял. А то бывалоча набегут коучи с экспертами и давай рассуждать какой гейт не так повёрнут...
Я кстати без доли сарказма сейчас.
Видел минимум 3 реализации “внутренних нотаций“ на базе BPMN
OlgaVivanova
07.10.2025 14:49В каком инструменте моделирования можно эти две нотации совместить?
Только Business Studio последней версии?
Eugene_Demochko Автор
07.10.2025 14:49Если из отечественных, то точно в BS (там реализован пообъектный учёт элементов разных схем), но ещё в Sila Union указана поддержка, не пробовал.
OlgaVivanova
07.10.2025 14:49Спасибо.
Вы пробовали в BS обе нотации для целей одного процесса?
и C4 системы описать, которые в процессе задействованы?
Удобно?
Я только о возможностях знаю, но пока рисую в draw.io: копипаст всего всюду, выгрузка только картинками и пдф, и ни один бесплатный ИИ по этим схемам даже внятное текстовое описание не составит, с которым его же табличное описание сходится
olku
07.10.2025 14:49Использую и обучаю коллег Structurizr с sequence diagrams в plantuml для динамики.
ASenchenko
07.10.2025 14:49Смотря что понимать под "совместить"
Так то в draw.io обе модели есть. Юзабилити самого draw.io обсуждать не будем :)))) Зато он встроен в конфлюенс и имеет бесплатную локальную версию
Eugene_Demochko Автор
07.10.2025 14:49Кажется, что речь про возможность переиспользования объектов - например, шаг процесса со схемы BPMN как аналогичный объект вставить на диаграмму в архимейте. В таблице со сравнением как раз и про это тоже. BS такое точно позволяет. По крайней мере, я так понял вопрос)
OlgaVivanova
07.10.2025 14:49draw.io - прекрасная рисовалка с удобным десктопом, но в ней даже автонумерации процессов нет, это просто айтишная версия ПауэрПойнта.
Было бы здорово настоящий инструмент моделирования использовать, чтобы данные в базе хранились и выгружались в таблицы и регламенты не креативным копипастом с рассеянной перепутаницей печатных символов)Eugene_Demochko Автор
07.10.2025 14:49Тогда из отечественных систем точно могу бизнес-студио рекомендовать, а в целом есть ещё до 5 аналогичных, но нужно смотреть функционал что позволяет.
ASenchenko
07.10.2025 14:49В этом плане нам сейчас особо не до жиру на некоторое время (косится на свой персональный ключик Enterpise architect)
Тогда Бизнес студио как Евгений пишет. Других идей нет
Eugene_Demochko Автор
07.10.2025 14:49есть анонсы помимо БС, а вдруг там будет не хуже, чем ЕА?)
ASenchenko
07.10.2025 14:49Увидим.
Хотя я бы уже сел писать статью “как жить БА если у тебя под рукой один кофлюенс" :)))
ASenchenko
Просто мысли на полях Вашей заметки. Не критика.
Применение расширенного BPMN (приведённых Вами модификаторов событий и не упомянутых в статье модификаторов функций) требует очень хорошей подготовки как аналитика, так и его аудитории. В реальности очень мало кто может корректно (по Брюсу) использовать в схеме, а уж тем более прочитать, "эскалацию" и "сигнал".
Значительно чаще на практике встречается простая блочная, начерченная в BPMN-редакторе.
EPC не является в явном виде "конкурентом" или заменой BPMN. Опять же, на практике часто встречал BPMN на уровне абстрактного Концепта, а ниже уже в деталях по функциям - EPC. Это хорошо читается.
Вы не упомянули C4. Это реально хороший инструмент.Особенно для enterprise architect (посмотрел Ваш профиль, внёс правку :))) )
IDEF таки мёртв. Чего его поминать то ? :))))
Eugene_Demochko Автор
Спасибо за мысли!
Насчёт расширенного BPMN - согласен, на моей практике и упрощённый вариант BPMN бывает сложен. Я тут скорее хотел показать, как в идеальных условиях применения мэтчились бы на практике эти языки.
C4 не упомянул, но он действительно был бы уместен больше в предыдущей статье, а здесь я и TOGAF не обозначил (хотя архимейт его производная)
EPC не конкурент, но опять же, по моему опыту, гораздо менее распространённая и функциональная нотация и у неё в меньшей степени репутация некоего "стандарта", а вот на IDEF0 есть даже ГОСТ, он до сих пор применяется в некоторых организациях)
ASenchenko
ГОСТ это конечно аргумент.
Однако, я сам смотрю на это (и ребятам своим рекомендую) с чисто практической точки зрения
Читаемость. Мы чертим схемы не для того, чтобы на стенку повесить и медитировать, а для того чтобы их читали. IDEF давно утратил массовость и людей, помнящих и понимающих какая стрелка свеху, а какая снизу, уже не так и много.
Доступность. Сейчас уже не так и просто найти инструменты для работы с IDEF. В том же конфлюенсе я их не видел. Даже во встроенном в конфлюенс draw.io этой нотации по-моему нет.
А вот по поводу недооцененности EPC соглашусь. Причем непонятно почему. По сути это графическое представление usecase, который сейчас весьма популярен для написания FT. В Aris express даже был встроенный инструмент для конвертации текста в схему и обратно
itGuevara
ARIS SmartDesign? Он про таблицы.
ASenchenko
Я на память уже не скажу, но глянув Вашу статью - да. Оно похоже