Здравствуйте!
Встала задача описать бизнес-процессы компании. Раньше имел дело с DFD и IDFEx. "Рисовал" в BPWin, верхние уровени описывал на DFD, нижние подробно описывал  IDFE3.
Но недавно увидел BPMN и она показалась мне более удобочитаемой.
Можно ли заменить IDFEx на BPMN? Т.е. рисовать верхние уровни с помощью DFD (нравится), а какие-то операции на низком уровне описывать BPMN?
Можно ли делать декомпозицию для BPMN? Сейчас рисую в Visio и создаю отдельную владку, на которую делаю ссылку.

Приведу пример. Если можно, скажите, применим ли такой подход, не "осудят" ли меня иностранные коллеги и по возможности укажите на мои ошибки.
Заранее огромное спасибо!

Для простоты привожу только процесс создания заказа:
1. web-портал отправляет в erp-систему заказ (формат xml)
2. заказ сохраняется в БД erp-системы, на портал отправляется результат создания заказа.
3. заказ обрабатывается складом в результате получается физический заказ. в процессе формирования заказ проходит этапы:
- начало сборки: меняется статус в БД.
- сборка: в коробку кладут товары в соотвествии со списком заказа, меняется статус в БД.
- учет (подтверждение сборки): меняется статус в БД.
- контроль сборки: проверяется фактическое наличие товара в коробке и в списке заказа.
- - Если заказ полный - меняется статус
- - Если в заказе не хватает товара - на линии его дополняют и снова отправляют на контроль
- - Если заказ дополнить нечем - формируется лист недовложений и списывается сумма недовложений
4. заказ отправляется

На рисунках:
1 - Верхний уровень.
2 - Декомпозиция "ERP-системы"
3 - Декомпозиция "Обработка заказа на складе"

Выражаю свою точку зрения.

Как я понимаю, Вам необходимо именно в графическом виде изобразить бизнес-процессы? Если да, то почему бы и не описать их именно в таком ключе, указав в итоговом документе общий принцип? Мне такой подход нравится. В нём, как и в других подходах заложен принцип декомпозиции. Единственное в чем разница - это то, что на нижних уровнях Вы используете BPMN, которая, на мой взгляд, является более подробной, насыщенной и понятной, нежели IDEF3.

Но я могу быть не прав. Интересно выслушать мнение коллег.

Можно ли заменить IDFEx на BPMN?
Ответ: Да.

Т.е. рисовать верхние уровни с помощью DFD (нравится), а какие-то операции на низком уровне описывать BPMN?
Ответ: Да. Если это разные диаграммы. Одна диаграмма верхнеуровневый процесс (DFD), и набор диаграмм низкоуровненых процессов (BPMN).

Но имеет ли смысл вводить такое разбиение? И корректно ли оно?
Мое мнение - нет.

Аналитик работает не чтоб ему нравилось рисовать диаграммы DFD, а чтоб процесс стал более понятен заинтересованным лицам, а им, если это профессиональные аналитики со знанием стандарта из семейства IDEF* и BPMN, будут непонятны различия этих диаграмм.
Практики использующие BPMN в качестве своего основного инструмента говорят, что нотация в среднем осваивается года за два.

Итого: аналитик должен использовать единообразный инструмент для описания БП.

Спасибо за ответы.

Для себя делаю выбор в пользу BPMN, т.к. швейцарские коллеги считаюи IDEFx архаизмом =(
На выходных почитал блогов и книжек, оказывается верхний уровень удобно описывать и в BPMN.

Скажите, а нормальная ли практика, если я рисую в BPMN субпроцесс (свернутый), а на отдельной диаграмме делаю подробное описание этого субпроцесса?
Т.е. все процессы, для которых я намерен делать описание на более низком уровне, на диаграмме я изображаю как субпроцесс, если не собираюсь делать декомпозицию, то использую таск.
Саму декомпозицию субпроцкссов делаю на отдельной диаграмме.

Можно попросить вас покритиковать мою первую BPMN диаграмму? Пожалуйста:

т.к. швейцарские коллеги считаюи IDEFx архаизмом =(

Может ваши коллеги подскажут нам какую еще аналогичную по наглядности, пониманию и простоте, нотацию вместо IDEF0 использовать для отображения деятельности в виде ICOM модели?

Я лишь перпедал мнение коллег. Я использовал IDEF по сей день, однако сотрудничество вынуждает менять инструментарий...

el-niko,
Как Вы уже правильно поняли - в BPMN можно рисовать модели верхнего уровня, ИМХО так и нужно делать, две нотации смешивать я бы не стал.

IAFedorov,
Сорри, за глупый вопрос, а что такое ICOM модель?

Сорри, за глупый вопрос, а что такое ICOM модель?

I - input
C - control
O - output
M - mechanism

По сути, это стрелки, которые входят в IDEF0-блок.

bas, спасибо, а есть где-то описание методологии "декомпозиции" BPMN-диаграмм? Т.е. как правильно делать описание процессов переходя от верхнего уровня к более низким? В разных статьях это делается по разному и в разных инструментах это предлагается делать тоже неодинаково.
Например в Intalio предлагается рисовать подпроцесс непосредственно на той же диаграмме, что и процесс верхнего уровня, это не удобно.
Возможно есть способ описать субпроцес на отдельной диаграмме и связать потоки сообщений на верхнем уровне?

Может посоветуете информативный блог или книгу (жалетельно на русском) по bpmn?

Идем в соответствующий раздел форума и, вот это да, находим там:
http://www.uml2.ru/forum/index.php?topic=326.0

Особенно рекомендую присмотреться к комментариям АБ.

I - input
C - control
O - output
M - mechanism

По сути, это стрелки, которые входят в IDEF0-блок.

Про стрелки в IDEF0 знаю, только никогда не знал, что это так называется одним сокращением )

По сути:
* IO - есть в BPMN
* C - в какой-то мере, это кто исполняет БП (есть BPMN), но более шире
* М - не так часто встречал, что в реальных примерах это использовалось.

Я думаю не зря ушли от CM в более новых нотациях.

Про стрелки в IDEF0 знаю, только никогда не знал, что это так называется одним сокращением )

По сути:
* IO - есть в BPMN
* C - в какой-то мере, это кто исполняет БП (есть BPMN), но более шире
* М - не так часто встречал, что в реальных примерах это использовалось.

Я думаю не зря ушли от CM в более новых нотациях.

Александр, не совсем с тобой соглашусь.

C - это правила, документация, в соответствии с которыми должен выполняться процесс, а вот M - это как раз тот, кто исполняет БП.

Кстати, по поводу ICOM... Я в литературе читал (автор Черемных или Маклаков), что правильно говорить не ICOM-модель, а ICOM-коды. Ведь именно эти коды идентифицируют стрелки, входящие (исходящие) из IDEF-блока.

C - это правила, документация, в соответствии с которыми должен выполняться процесс, а вот M - это как раз тот, кто исполняет БП.

Кстати, по поводу ICOM... Я в литературе читал (автор Черемных или Маклаков), что правильно говорить не ICOM-модель, а ICOM-коды. Ведь именно эти коды идентифицируют стрелки, входящие (исходящие) из IDEF-блока.

По последней фразе, совершенно верно. ICOM-коды

С- управление - вход, который иницирует начало процесса, управляет ходом процесса, ограничивает ход процесса, регламентирует ход процесса. Нет управления - процесс не может начаться, потому важность этого входа в IDEF0 - абсолютная.

M-механизм, инструмент, средство - это то с помощью чего требуется исполнять процесс: персонал, оборудование, и т.п.

ни С ни М - само по себе не преобразуется в результат О, но участвует в его создании.

Т.е. рисовать верхние уровни с помощью DFD (нравится), а какие-то операции на низком уровне описывать BPMN?

Регулярно так делаю и другим рекомендую. Вопрос только в том, что считать верхним уровнем. Для вашего примера достаточно BPMN.

по возможности укажите на мои ошибки.

Ну раз просите

На DFD-диаграмме логично было бы трактовать Navision как внешнюю сущность, а Заказ как источник данных. У вас сделано наоборот.

На BPMN-диаграмме ошибок много. Самая вопиющая - сообщения внутри одного пула. Промежуточное событие Довложение без исходящих потоков управления. Опять заказ в роли внешней сущности.

нормальная ли практика, если я рисую в BPMN субпроцесс (свернутый), а на отдельной диаграмме делаю подробное описание этого субпроцесса?

Не просто нормальная - это рекомендуемая практика.

как правильно делать описание процессов переходя от верхнего уровня к более низким? В разных статьях это делается по разному и в разных инструментах это предлагается делать тоже неодинаково.

Как правильно моделировать в BPMN не объяснить в двух словах. У меня на объяснения уходит два полных дня.

Например в Intalio предлагается рисовать подпроцесс непосредственно на той же диаграмме, что и процесс верхнего уровня, это не удобно.

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

Может посоветуете информативный блог или книгу (жалетельно на русском) по bpmn?

Да простят мне саморекламу, http://mainthing.ru/ru/tag/bpmn/