Всем привет. Помогите разобраться. В организации есть несколько БП:
1. Рассмотрение ходатайств (инициируется подачей ходатайства субъектом рынка) - цель: дать согласие или несогласие на сделку - экономическую концентрацию, гос. помощь или создание гос. предприятия;
2. Плановый анализ рынков (инициируется годовым планом проверок) - цель: выявление монополистов и доминатов, а так же соглашений (согласованных действий) субъектов рынка;
3. Проведение расследований (инициируется жалобой, заявлением) - цель: выявление монополистов и доминатов, а так же соглашений (согласованных действий) субъектов рынка.

Каждый из этих БП подразумевает стадию или подпроцесс - проведения анализа рынков. Как это должно отобразится на диаграмме? Для каждого БП дублировать? Или отдельно расписать БП Анализ рынков, а потом ссылаться на описанный БП? Уже совсем запуталась. Заранее спасибо.

А почему Вам не нравится второй вариант?? Описываете БП "проведения анализа рынков" и если он везде одинаков, то ссылаетесь на него из остальных БП.

А вы какие диаграммы используете для описания и в какой нотации?

Не то чтобы не нравится, хочется понять как правильно

Алексей, я использую диаграмму Activity - UML.

2 anastazya,
практичнее делать подобные вещи отдельными процессами, которые могут быть инициированы из разных процессов. Использование отдельных процессов позволяет:
1. запускать процесс (в нашем случае Анализ) автономно (не из другого процесса);
2. Инициировать из одного процесса несколько экземпляров процесса Анализ (к примеру, если нужно анализировать несколько разных сегментов по одной заявке);
3. Подпроцесс, включенный в процесс, является частью схемы этого процесса. Поэтому изменения в подпроцессе повлекут за собой изменение схемы основного процесса. И в этом случае дальнейшее поведение уже запущенных экземпляров процесса процеса будет зависить от исполняющей программы - в некоторых случаях все запущенные версии процесса исполняются по старой схеме, а все новые - по новой. Но иногда и все запущенные будут исполняться по новой схеме. А отдельно стоящий процесс стартует в последней версии, даже если инициирующий процесс был запущен раньше, чем изменялся вспомогательный.

Алексей, я использую диаграмму Activity - UML.

UML позволяет описывать подпроцессы на основной диаграмме деятельности, для этого предлагается использовать элемент "Structured Activity Node" (UML Superstructure Specification, v2.1.2, subsection 12).
В зависимости о задачи, возможно использование нескольких типов элементов:
- Structured Activity Node - описывает обычный, исполняемый вид деятельности, операции которого не используются в других видах деятельности;
- Loop Node - циклический вид деятельности, состоящий из нескольких секций: настройки, проверки условий и тела (настройка осуществляется каждый раз при входе в цикл);
- Sequential Node - последовательный вид деятельности, в котором все действия выполняются по порядку;
- Conditional Node - вид деятельности выполнение которого варьируется в зависимости от входных условий (состоит из двух секций: проверки условий и тела);
что позволяет довольно гибко подходить к описанию подпроцесса и встраивать его в различные бизнес-процессы.

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

UML позволяет описывать подпроцессы на основной диаграмме деятельности, для этого предлагается использовать элемент "Structured Activity Node" (UML Superstructure Specification, v2.1.2, subsection 12).
В зависимости о задачи, возможно использование нескольких типов элементов:
- Structured Activity Node - описывает обычный, исполняемый вид деятельности, операции которого не используются в других видах деятельности;
- Loop Node - циклический вид деятельности, состоящий из нескольких секций: настройки, проверки условий и тела (настройка осуществляется каждый раз при входе в цикл);
- Sequential Node - последовательный вид деятельности, в котором все действия выполняются по порядку;
- Conditional Node - вид деятельности выполнение которого варьируется в зависимости от входных условий (состоит из двух секций: проверки условий и тела);
что позволяет довольно гибко подходить к описанию подпроцесса и встраивать его в различные бизнес-процессы.

Мое мнение - огород с Structured Activity Node и его специализациями городить не стоит. Кстати в стандарте нет описания нотации для этих узлов. Они - не болee чем  другая форма уже существующих узлов.

Так что, anastazya, просто рисуй блок схему, а то что общее обзывай везде одинаково и для этих элементов используй дополнительный символ (трезубец, направленный вниз, т.е. типа "иерархия") в правом нижнем углу, который показывает, что где-то есть диаграмма, которая раскрывает сущность данной деятельности.

Всем спасибо. Меня заинтересовало сообщение Алексея по поводу входных параметров... Скажем если БП Анализ рынка, находясь в разных процессах использует разные криетрии для анализа??? Денис, что ты думаешь по этому поводу?

Всем спасибо. Меня заинтересовало сообщение Алексея по поводу входных параметров... Скажем если БП Анализ рынка, находясь в разных процессах использует разные криетрии для анализа??? Денис, что ты думаешь по этому поводу?

Каждый входной параметр определяется своим типом. Главное, чтобы совпадали типы.

В моем случае они совпадают. А если различия всеже есть?  Или скажем отличается состав параметров, т.е 1, 2, 3 одинаковы для двух БП, но 2-ой БП содержит еще ряд параметров 4,5,6? Что тогда?

Деятельности - это не классификаторы и для них нельзя применять обобщение (которое в общем тут напрашивается).

Я думаю все сильно определяется контекстом.
В твоем случае, я бы нарисовал все варианты деятельности "Анализировать рынок" по отдельности, а затем нашел бы у них общие части.
И не обязательно, чтобы общие части возникли на главной диаграмме. Пусть они возникнут на вспомогательных, связанных с каждым конкретным анализом.

ОК. Понятно. У меня такая мысль возникла... Что если в диаграмме "Анализ рынка" с помощью условий и ветвлений указать разные варианты. БП будет одним, но его выполнение будет зависеть от различного рода условий...А?

ОК. Понятно. У меня такая мысль возникла... Что если в диаграмме "Анализ рынка" с помощью условий и ветвлений указать разные варианты. БП будет одним, но его выполнение будет зависеть от различного рода условий...А?

Это конечно можно сделать если
1) разные варианты анализа не большие по объему
2) кому-то интересно на одной диаграмме увидеть все варианты анализа сразу