не уверена что все это книги, но зато на русском

http://nvoynov.googlepages.com/bpmn-practice.pdf
http://www.directum-journal.ru/files/2488240.pdf
http://idefinfo.ru/content/category/5/102/55/
http://process.siteedit.ru/page67
http://web-edu.iriit/~eugine/file.php/1/bpmn-practice.pdf
http://www.intuit.ru/department/se/vismodtp/9/2.html

ничего не подойдет?

Изучил материалы. Но целостной картине о порядке моделирования не сложилось. Собственно на главный вопрос "С чего начать при построении модели на BPMN?" ответ не нашел:)

Если в двух словах, то надо идти от общего к частному. Т.е. на верхнем уровне крупные БП, а далее каждый детализируется с помощью Диагарма на которм уже расположены сами Activity.

Если в двух словах, то надо идти от общего к частному. Т.е. на верхнем уровне крупные БП, а далее каждый детализируется с помощью Диагарма на которм уже расположены сами Activity.

Ну а что является общей диаграммой? Или ее лучше наверное назвать конекстной диаграммой. В курсе "Проектирование ИС" http://www.intuit.ru/department/se/devis/13/3.html Грекул предлагает делать use case диаграмму в качестве контекстной и от нее уже описывать бизнес-процессы. Но мне сдается, что такой подход не удобен, т.к. не видны бизнес-процессы низкого уровня. Например у нас есть БП: продажа и БП: пополнение склада контрагента, в оба БП входит БП: перемещение товаров контрагенту.

С чего Вы начинаете описывать бизнес-процессы. Какую документацию оформляете?

p.s. Описание бизнес процессов нацелено на автоматизацию

Мы приняли у себя 4 уровня декомпозиции:
1. Уровень Группы БП, может иметь несколько уровней иерархии и по сути ничем не связанные между собой. Например Группа БП Продажи, Поставки и т.д. Оформляется в виде артефакта БП или пакета (у нас Спаркс ЕА) не связанные м\у собой
2. Уровень БП, один уровень, это крупно последовательность БП, которая детализаирует последний уровень Группы БП. Например Поставка крупно делается так Заключить Договорные Отношения -> Заказать Товар -> Принять Товара и т.д. Оформляется в виде артефактов БП, соединенных  управляющими потоками
3. Уровень Действий, это детализация каждого БП в виде последовательности действий. Например Принять Товара делится на Привезти товар -> Оформить приемку  и т.д. Оформляется в виде артефактов Действия, Дорожки, Объекты данных, управл потоки и потоки сообщений
4. Уровень Операций, это детализация каждого Действия в виде более детальной последовательности Действий. И по сути является отрожением операций в Системе. Оформляется также как п.3.

П.4. не обязателен у нас, мы предпочитаем Детализировать Действия из п.3 уже в виде текста.

Мы приняли у себя 4 уровня декомпозиции:
1. Уровень Группы БП, может иметь несколько уровней иерархии и по сути ничем не связанные между собой. Например Группа БП Продажи, Поставки и т.д. Оформляется в виде артефакта БП или пакета (у нас Спаркс ЕА) не связанные м\у собой
2. Уровень БП, один уровень, это крупно последовательность БП, которая детализаирует последний уровень Группы БП. Например Поставка крупно делается так Заключить Договорные Отношения -> Заказать Товар -> Принять Товара и т.д. Оформляется в виде артефактов БП, соединенных  управляющими потоками
3. Уровень Действий, это детализация каждого БП в виде последовательности действий. Например Принять Товара делится на Привезти товар -> Оформить приемку  и т.д. Оформляется в виде артефактов Действия, Дорожки, Объекты данных, управл потоки и потоки сообщений
4. Уровень Операций, это детализация каждого Действия в виде более детальной последовательности Действий. И по сути является отрожением операций в Системе. Оформляется также как п.3.

П.4. не обязателен у нас, мы предпочитаем Детализировать Действия из п.3 уже в виде текста.

Спасибо. Так намного понятнее.

А уровни декомпозии - это некоторое соглашение. Никаких регламентирующих документов на этот счет нет? Т.е. правила "описания" являются некоторым соглашением?
И еще вопрос, который может не по теме, но тоже меня волнует: с помощью чего Вы делаете описание БО? Как связываете с БП? В Activity UML и BPMN есть возможность указать артефакт - это не достаточно для понимания БО? По каким признакам группируете БО? Например можно ли так разделить модель БО: Артефакты, учавствующие в процессе продаж, артефакты, учавствующие в процессе закупок и т.д.?

А уровни декомпозии - это некоторое соглашение. Никаких регламентирующих документов на этот счет нет?

Это наше внутренее соглашение. Ведь БПМН - это нотация, что хочешь, то и изображай.
Уровни декомпозиции вроде прописаны в SADT и ARIS.

И еще вопрос, который может не по теме, но тоже меня волнует: с помощью чего Вы делаете описание БО? Как связываете с БП? В Activity UML и BPMN есть возможность указать артефакт - это не достаточно для понимания БО?

Мы делаем структурную Д БО с помощью Д Классов (ДК). ИМХО этого достаточно. Причем Спаркс ЕА позволяет привязать к БП (вход\выход) эти самые классы (вместо Объектов Данных). Тем самым получаем в каких БП участвую нужные нам БО и получаем статическую структуру взаимосвязей БО.

По каким признакам группируете БО? Например можно ли так разделить модель БО: Артефакты, учавствующие в процессе продаж, артефакты, учавствующие в процессе закупок и т.д.?

Конечно можно и даже нужно. Т.е. можно группировать БО по Группам БП или даже мельче.

1. Уровень Группы БП, может иметь несколько уровней иерархии и по сути ничем не связанные между собой. Например Группа БП Продажи, Поставки и т.д. Оформляется в виде артефакта БП или пакета (у нас Спаркс ЕА) не связанные м\у собой

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

2. Уровень БП, один уровень, это крупно последовательность БП, которая детализаирует последний уровень Группы БП. Например Поставка крупно делается так Заключить Договорные Отношения -> Заказать Товар -> Принять Товара и т.д. Оформляется в виде артефактов БП, соединенных  управляющими потоками

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

3. Уровень Действий, это детализация каждого БП в виде последовательности действий. Например Принять Товара делится на Привезти товар -> Оформить приемку  и т.д. Оформляется в виде артефактов Действия, Дорожки, Объекты данных, управл потоки и потоки сообщений
4. Уровень Операций, это детализация каждого Действия в виде более детальной последовательности Действий. И по сути является отрожением операций в Системе. Оформляется также как п.3.

П.4. не обязателен у нас, мы предпочитаем Детализировать Действия из п.3 уже в виде текста.

Я знаю, что такое исполняемый код, но не имею понятия, что такое исполняемый текст:)))
Шутка, конечно, но из этой фразы я поняла, что нарисованные вами процессы - это только инструкция, регламент, но не исполняемая схема. Если вы имеете представление о BPM-системах, то поймете, что я имею в виду под словом "исполняемая". Если нет - поясню.

Топикстартеру:
если Вы всерьез заинтересованы в процессном управлении и в автоматизации процессного управления, то Вам следует познакомиться не только (и не столько!!!) с BPMN, а обратиться к теме BPMS (Business Process Management Suite) и SOA (сервисно-ориентированной архитектуре).

Процесс Покупки и процесс Продажи не связаны между собой??

А где Вы увидели Покупку и Продажу? У меня была Поставка и Продажа, и на Д связывать их не имеет смысла, это две отдельные группы, которые могут быть связна м\у собой внутри дальнейшей детализацией.

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

Если мы говорим об одной полной цепочке, то почему нет? Представьте тогда свое видение каким образом нужно декомпозировать!

Я знаю, что такое исполняемый код, но не имею понятия, что такое исполняемый текст:)))
Шутка, конечно, но из этой фразы я поняла, что нарисованные вами процессы - это только инструкция, регламент, но не исполняемая схема. Если вы имеете представление о BPM-системах, то поймете, что я имею в виду под словом "исполняемая". Если нет - поясню.

Да, пока мы БПМН используем только для описания.

Топикстартеру:
если Вы всерьез заинтересованы в процессном управлении и в автоматизации процессного управления, то Вам следует познакомиться не только (и не столько!!!) с BPMN, а обратиться к теме BPMS (Business Process Management Suite) и SOA (сервисно-ориентированной архитектуре).

Думаю, что обращение к BPMS и тем более к SOA при заинтересованности в процесном управлении -- это 5 и 8 шаги соответственно. Для начала нужно построить классификацию БП организации, на основании некой референсной модели. Например для телекомов есть очень неплохая классификация eTOM. При "обработке напильником" можно применить для любой организации, оказывающей услуги.

Кстати в термине BPMS "S" отнюдь не Suite, а System ....

если Вы всерьез заинтересованы в процессном управлении и в автоматизации процессного управления, то Вам следует познакомиться не только (и не столько!!!) с BPMN, а обратиться к теме BPMS (Business Process Management Suite) и SOA (сервисно-ориентированной архитектуре).

Посоветуйте ресурсы/книги, где можно изучить данные вопросы?

Согласен с Юрой.

Думаю, что обращение к BPMS и тем более к SOA при заинтересованности в процесном управлении -- это 5 и 8 шаги соответственно. Для начала нужно построить классификацию БП организации, на основании некой референсной модели. Например для телекомов есть очень неплохая классификация eTOM. При "обработке напильником" можно применить для любой организации, оказывающей услуги.

Если Вас интересует реинжиниринг бизнес-процессов - то, возможно, это 5, 8... а скорее 10000... шаги (это уже не имеет значения, поскольку Вы вряд ли до них доберетесь ) Мой личный опыт (не утверждаю, что нет опровержений): я не видела НИ ОДНОГО примера, когда бы в организации существовал BPM, образовавшийся в результате реинжиниринга.

Кстати в термине BPMS "S" отнюдь не Suite, а System ....

Смотря о чем Вы говорите. Если об инструментарии - то именно Suite, если о системе, построенной на основании использования этого инструментария (грубо говоря - то, чего получилось на конкретном предприятии) - это однозначно Systems.
) устареваете

Если мы говорим об одной полной цепочке, то почему нет? Представьте тогда свое видение каким образом нужно декомпозировать!

Почитайте еще раз внимательно тот пост. Если речь идет о заключении договора, то контроль его исполнения - это отдельный процесс. Если в рамках этого договора могут быть несколько заказов товара - это несколько экземпляров ДРУГОГО процесса. При этом, заказы могут быть не полностью удовлетворены, существуют возвраты, претензии... Прямых путей "Встал-пошел-направо-сел" в бизнесе не бывает.

Кстати, наши заказчики нередко предоставляют нам схемы своих процессов, выполненные в Visio, ARIS - кто в чем может. Обратите внимание: ЕЩЕ НИ ОДНА ИЗ НАРИСОВАННЫХ ИМИ СХЕМ, ВОСПРОИЗВЕДЕННАЯ В BPMS НЕ РАБОТАЛА В ПРИНЦИПЕ. Ни одна и ни разу. И выполнены они были не самыми последними аналитиками.
Поэтому, если Вы, воспользовавшись рекомендацией Юрия, оставите это на 5-8 шаги, то приготовьтесь к тому, что в этот момент Вы просто начнете все с начала.

Изучил материалы. Но целостной картине о порядке моделирования не сложилось. Собственно на главный вопрос "С чего начать при построении модели на BPMN?" ответ не нашел:)

Полагаю, начать надо с целеполагания. Смоделировать процесс на BPMN - это ведь не самоцель?

Описание бизнес процессов нацелено на автоматизацию

Это в первом приближении сошло бы за цель, но тут есть две засады:

1) Автоматизировать бизнес-процессы можно ОЧЕНЬ по-разному. Навскидку: а) можно сделать заказную разработку, "зашив" процессную логику в программный код; б) если у вас есть достаточно развитая ERP-образная система, то можно воспользоваться функциональностью a-la workflow, которая в таких системах обычно имеется; в) можно автоматизировать бизнес-процесс при помощи BPMS.

Нотация BPMN вообще-то рассчитана на тех, кто идет по третьему пути. Но тут появляется засада 2) Сегодняшние BMPS поддерживают BPMN кое-как, плюс к этому множественность версий: есть BPMN 1.0, 1.1, 2.0 (в проекте).

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

Что касается Enterprise Architecture, на которую свалилась эта дискуссия, то эта тема отдельная от BPMN. Хотя да, в принципе начинать надо с этого. Но на уровне корпоративной архитектуры есть процессы, бизнес-объекты, другие артефакты, и на этом уровне абстракции не интересует какая там используется нотация для процессов. Кстати на эту тему мы недавно опубликовали толковую статью, рекомендую: bpms.ru/library/articles/how-to-simplify-bp-changes.

Почитайте еще раз внимательно тот пост. Если речь идет о заключении договора, то контроль его исполнения - это отдельный процесс. Если в рамках этого договора могут быть несколько заказов товара - это несколько экземпляров ДРУГОГО процесса. При этом, заказы могут быть не полностью удовлетворены, существуют возвраты, претензии... Прямых путей "Встал-пошел-направо-сел" в бизнесе не бывает.

А кто говорил про простые линейные процессы? Они ветвятся очень сильно. Тут скорее вопрос в идеологии декомпозиции.
Мы на 2ом уровне представляем простой верхоуровней процесс зачастую линеней с небольшими ветвлениями + бывают БП которые никак не связаны с другими и следовательно могут выполняться в любом месте. Далее (на 3ем уровне) уже декомпозируем каждый БП более сложно с возможным реиспользованием уже существующих БП.
Вы как предлагаете декомпозировать? Все БП 2ого уровня должны быть не связаны м\у собой?

Кстати, Вы так и не порекомендовали книг по БПМС ...