Бизнес-аналитик в процессе проектирования ИТ-решений

В идеальных условиях именно роль «бизнес‑аналитик» в производственном ИТ‑процессе должна быть «входной точкой» для бизнес‑заказчика, формализующей, как правило, неструктурированные требования в структурированные. Через эту же роль должна производиться обратная связь ИТ‑команды бизнес‑заказчику.

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

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

Инструменты формализации бизнес-требований

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

Качественное описание бизнес-процессов автоматизации - основа проектирования и дальнейшего контроля качества ИТ-решений.

Стандартом (или лидером среди прочих нотаций, таких как EPC, CFF, IDEF0 и пр.) описания бизнес‑процессов можно назвать BPMN (Business Process Model and Notation). Данный язык действительно является мощным инструментом для изложения бизнес‑логики. А вот структуру бизнес‑объектов (или бизнес‑данных) в нём описать невозможно, только указать сами бизнес‑объекты в процессе. А эти объекты прямо созависимы с описываемыми бизнес‑процессами и глоссарием терминов. Такую возможность даёт Archimate, при этом в данном языке присутствуют и остальные ключевые для проектирования объекты описания: в таблице приводится сравнительный анализ элементов различных нотаций и языков моделирования.

Сравнение состава объектов нотаций моделирования бизнес-процессов
Сравнение состава объектов нотаций моделирования бизнес-процессов

Несмотря на то, что Archimate является более концептуальным и высокоуровневым, архитектурным языком моделирования, при его использовании можно так же достаточно детально описывать бизнес‑процессы. При этом, возможность описания в нём структуры данных (бизнес‑объектов) как части бизнес‑процесса позволяет отобразить, какие составные элементы бизнес‑объекта могут быть самостоятельным триггером и/или выходом шагов бизнес‑процесса. Такую логику нельзя отобразить в BPMN (как и в других приведённых выше нотациях). Это крайне полезное преимущество при проработке бизнес‑требований и дальнейшего взаимодействия с бизнес‑заказчиком.

Пример отображения влияния составных элементов бизнес-объектов на высокоуровневый бизнес-процесс в нотации Archimate
Пример отображения влияния составных элементов бизнес-объектов на высокоуровневый бизнес-процесс в нотации Archimate

Главным же преимуществом BPMN по сравнению с Archimate является огромное количество условий (логических операторов) и событий, что удобно для низкоуровневого описания и изложения очень подробной бизнес-логики.

События BPMN
События BPMN

Таким образом, использование бизнес‑аналитиком двух языков моделирования, BPMN и Archimate, для формализации бизнес‑требований на высоком и низком уровне — вопрос не только удобства, но и улучшения качества, связанности и дальнейшего каскадированиия бизнес‑требований. Такая агрегация инструментов — большой шаг в развитии роли и личных компетенций тех, кто в этой роли работает.

Бизнес-требования как часть архитектуры

Почему было упомянуто дальнейшего каскадирование требований: в статье https://habr.com/ru/articles/953794/ приводилось развёрнутое описание связи бизнес-требований и архитектуры. Отмечу здесь, что работа бизнес-аналитика затрагивает два архитектурных домена - бизнес-архитектуру и данные, т.к. ключевые объекты его проектирования - это бизнес-процессы и бизнес-объекты (концептуальные модели данных). Артефакты, разрабатываемые бизнес-аналитиком в любом случае всегда содержат (или должны содержать) компоненты этих двух доменов. Проблема в том, что как правило, пообъектная связь бизнес-требований с остальными доменами никем не выявляется.

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

При внедрения Archimate в работу бизнес‑аналитика наравне с BPMN и стандартизации подхода проектирования бизнес‑требований на базе двух языков моделирования, можно сэкономить большое количество времени на «приземление» спроектированных бизнес‑процессов на ИТ‑ландшафт (обычно именно на этом этапе уходит самый большой временной ресурс участников проектирования). В идеальном варианте на схемах бизнес‑процессов в Archimate, полученных от бизнес‑аналитика, остальными ролями проектирования (например, архитекторами), должны добавляться объекты доменов приложений и инфраструктуры — информационные системы, интеграции, платформы и так далее в привязке к конкретным шагам бизнес‑процессов.

Комментарии (8)


  1. ASenchenko
    07.10.2025 14:49

    Просто мысли на полях Вашей заметки. Не критика.

    Применение расширенного BPMN (приведённых Вами модификаторов событий и не упомянутых в статье модификаторов функций) требует очень хорошей подготовки как аналитика, так и его аудитории. В реальности очень мало кто может корректно (по Брюсу) использовать в схеме, а уж тем более прочитать, "эскалацию" и "сигнал".
    Значительно чаще на практике встречается простая блочная, начерченная в BPMN-редакторе.

    EPC не является в явном виде "конкурентом" или заменой BPMN. Опять же, на практике часто встречал BPMN на уровне абстрактного Концепта, а ниже уже в деталях по функциям - EPC. Это хорошо читается.

    Вы не упомянули C4. Это реально хороший инструмент.Особенно для enterprise architect (посмотрел Ваш профиль, внёс правку :))) )

    IDEF таки мёртв. Чего его поминать то ? :))))


    1. Eugene_Demochko Автор
      07.10.2025 14:49

      Спасибо за мысли!

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

      C4 не упомянул, но он действительно был бы уместен больше в предыдущей статье, а здесь я и TOGAF не обозначил (хотя архимейт его производная)

      EPC не конкурент, но опять же, по моему опыту, гораздо менее распространённая и функциональная нотация и у неё в меньшей степени репутация некоего "стандарта", а вот на IDEF0 есть даже ГОСТ, он до сих пор применяется в некоторых организациях)


      1. ASenchenko
        07.10.2025 14:49

        ГОСТ это конечно аргумент.

        Однако, я сам смотрю на это (и ребятам своим рекомендую) с чисто практической точки зрения

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

        2. Доступность. Сейчас уже не так и просто найти инструменты для работы с IDEF. В том же конфлюенсе я их не видел. Даже во встроенном в конфлюенс draw.io этой нотации по-моему нет.

        А вот по поводу недооцененности EPC соглашусь. Причем непонятно почему. По сути это графическое представление usecase, который сейчас весьма популярен для написания FT. В Aris express даже был встроенный инструмент для конвертации текста в схему и обратно


        1. itGuevara
          07.10.2025 14:49

          В Aris express даже был встроенный инструмент для конвертации текста в схему и обратно

          ARIS SmartDesign? Он про таблицы.


          1. ASenchenko
            07.10.2025 14:49

            Я на память уже не скажу, но глянув Вашу статью - да. Оно похоже


  1. itGuevara
    07.10.2025 14:49

    Сравнение состава объектов нотаций моделирования бизнес-процессов

    Идея правильная (достаточно трех BPMN\EPC\ArchiMate\VAD), но
    а) дополнить, например, BPMN: Data Objects \ Data Stores, промежуточное событие и др.

    б) показать не только объекты (причем если больше пяти, то пятерку значками, а далее цифру "всего", а для ArchiMate лучше сразу брать Next), но и типы связей и к каким объектам они применимы.  


  1. FrankNStein
    07.10.2025 14:49

    Как низккевалифицированный в теории 1Сник могу сказать, что простейший BPMN, где на схеме кроме функций отражаем объекты метаданных системы, рулит.

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


  1. OlgaVivanova
    07.10.2025 14:49

    В каком инструменте моделирования можно эти две нотации совместить?

    Только Business Studio последней версии?