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

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

ОК, раз мы с Вами понимаем, что процессы - это не простые цепочки последовательно выполняющихся шагов - будем считать, что "понятия сверили".
По поводу уровней декомпозиции... дело в том, что я не вижу нужды в описывании всех процессов с N-ми уровнями детализации, поскольку мне не близки идеи реинжиниринга (в данном случае под реинжинирингом я понимаю описание всех процессов и революционный скачок к новой жизни). Иногда (чаще всего) процесс запускается в жизнь с детально прописанными одним-двумя шагами и "заглушками" в виде обобщенных шагов. Дальше детализация может быть неравномерной.
Это не означает, что не надо вообще иметь некоего укрупненного представления о процессах. Кака раз надо. Т.е. общую картину представлять себе надо, а вот детализировать все процессы по какого-то определенного уровня... зачем? с какой целью? Это, пожалуй, и есть главный вопрос: цель? Сообразно целям и действуйте.

По поводу книг - все самое интересное и то, что можем рекомендовать для чтения выкладываем на bpms.ru. Ничего не скрываем:)

Книги по BPM в природе есть, по BPMS как-то сразу и не припомню. Да и почему обязательно книги? По BPMS есть хорошие обзоры, например могу порекомендовать от BPTrends (на английском естественно). Там неплохи и вводная часть, и анализ конкретных систем.

Что найти наврядли удастся - это вразумительное описание конкретного проекта с использованием BPMS. Только маркетинговые тексты. Впрочем это проблема IT вообще, а не конкретно BPMS. Да и что касается книг - кто может порекомендовать книгу по ERP?

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

Так, давайте по-порядку ... а то я перестал понимать "шо вы имеете ввиду" :-) ...
1. С какой радости возник реинжениринг (в терминах Хаммера и Чампи) Для того чтобы понять источники ордеров в организации нужно делать реинжениринг???
2. Я утверждаю, что браться за BPMS и тем более SOA не имеет смысла, если вы не понимаете как устроена ваша оргазация, т.е. не имея модели ее Enterprise Architecture (другой вопрос, с какой степенью детализации она присутсвует и каков ее ЖЦ). Понимая EA, можно говорить и о BPMS ... и на основании EA принимать решение, будет ли использоваться BPMS, SOA и прочия buzzwords .... Именно отсюда и вытекает, что собственно BPMS и прочия есть 5 и 8 шаги. При этом абсолютно очевидно, что если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него. Если подходить имеено так, то не думаю что слудует "... приготовьтесь к тому, что в этот момент Вы просто начнете все с начала".
3. Из сего делаю вывод, что вы либо не поняли что имелось ввиду, и пошли по неверной цепочке рассуждений на тему реинжениринга, либо хотите таки сказать, что нужно "сажать, сажать, не дожидаясь весны" ...?

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

Тут больше вопрос к вам -- что вы имели ввиду (прямо как в старом одесском анекдоте :-)) ... цитата "из вас":

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

Suite, как вы верно заметели, действительно относиться к инструментарию ... и употребляется в настоящем времени (например с подачи того же Gartner) как обозначение класса систем. Тут возникает та же ситуация, что и с SQL Server -- это и класс продукта и ... да, одноименный продукт от MS. Аналогично и тут ... (Oracle) BPM Suite .. использован тот же маркетинговый прием ... Посему, дабы избежать путаницы (учитвая сложность интерпретации Suite вне контекста) имеет смысл говорить "System".
Теперь о смысле фразы ... получается, что вы предлагаете для процессоного управления сразу же использовать определенные тулы ... Это примерно то же, что сказать -- "если вы хотите чтобы у вас в компании с требованиями было все ОК -- используйте requirements definition and management tools". Хотя аудитории UML2.RU отлично известно, что для того чтобы эффективно использовать те самые RDM Tools нужно поставить процессы, классифицировать требования и только потом можно будет использовать tools ... иначе это будет неэффективно.  Другой вопрос -- что занимаясь постановкой процесса you should keep in mind tools will be used.

Так, давайте по-порядку ... а то я перестал понимать "шо вы имеете ввиду" :-) ...
1. С какой радости возник реинжениринг (в терминах Хаммера и Чампи) Для того чтобы понять источники ордеров в организации нужно делать реинжениринг???

похоже, говорим о разных вещах. Если под шагами 1-4  имеются в виду уровни декомпозиции процессов, то это достаточно глубокий уровень детализации, практически попытка описать все процессы "as is" и "to be". Я считаю этот подход "реинжиниринговым" (не факт, что за этим последует реинжиниринг как таковой, но начало то самое). В этом случае до уровня 5-8 маловероятно добраться. Но если все же удастся, то поверьте моему опыту - автоматизировать вы будете совсем не то, что "надекомпозировали".

2. Я утверждаю, что браться за BPMS и тем более SOA не имеет смысла, если вы не понимаете как устроена ваша оргазация, т.е. не имея модели ее Enterprise Architecture (другой вопрос, с какой степенью детализации она присутсвует и каков ее ЖЦ). Понимая EA, можно говорить и о BPMS ... и на основании EA принимать решение, будет ли использоваться BPMS, SOA и прочия buzzwords ....

Здесь согласна. С уточнением, что BPMS и SOA уже для многих далеко не buzzwords. По крайней мере, последние год-полтора это явно показали.

Именно отсюда и вытекает, что собственно BPMS и прочия есть 5 и 8 шаги.

Это если "S" - Suite. Если же речь идет о построении системы бизнес-процессов предприятия, то на 5 шаге вспоминать об этом уже поздновато

При этом абсолютно очевидно, что если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него. Если подходить имеено так, то не думаю что слудует "... приготовьтесь к тому, что в этот момент Вы просто начнете все с начала".

Сами себе противоречите. Сначала говорите, что выбор BPMS - 5 шаг, а потом говорите, что надо изначально под него затачиваться. Или я Вас не правильно поняла? Что есть "выбор вендора"?

Тут больше вопрос к вам -- что вы имели ввиду (прямо как в старом одесском анекдоте :-)) ... цитата "из вас":

"если Вы всерьез заинтересованы в процессном управлении и в автоматизации процессного управления, то Вам следует познакомиться не только (и не столько!!!) с BPMN, а обратиться к теме BPMS (Business Process Management Suite) и SOA (сервисно-ориентированной архитектуре)."
Suite, как вы верно заметели, действительно относиться к инструментарию ... и употребляется в настоящем времени (например с подачи того же Gartner) как обозначение класса систем. Тут возникает та же ситуация, что и с SQL Server -- это и класс продукта и ... да, одноименный продукт от MS. Аналогично и тут ... (Oracle) BPM Suite .. использован тот же маркетинговый прием ... Посему, дабы избежать путаницы (учитвая сложность интерпретации Suite вне контекста) имеет смысл говорить "System".

имела в виду то, что написала. Хотя можно добавить, что начинать надо с BPM без всяких "S" - с концепции.
А говорить имеет смысл то, что имеете в виду - если инструментарий, то Suit, если посторенную на предприятии модель - System. Дабы, как Вы правильно заметили, "избежать путаницы".

2WJ:
Возможно мы действительно о разном ... но ...
1. Не понимаю, почему as-is\to-be обязательно возникают при детализации процессов? Почему речь идет об уровнях ... что, шаги бывают исключительно вглубь? Речь шла буквально о том, что браться за BPMS и SOA не имеет смысла без понимания той же EA ... посему первыми шагами должно быть построение той самой EA (с необходимой и достаточной детализацийе, для решения поставленных задач конкретной организации) в части BA и прочих архитектур. Это и есть первые шаги ...
2. По поводу buzzwords ... скажите мне пожалуйста примеры организаций в России, где серьезно рабают на базе SOA и BPMS, чтобы можно было говорить что это действительно системный подход? Какой уровень зрелости бизнеса и ИТ должен быть в такой организации??? Пока что на том же Oracle Tech Days не было ни одного серьезного примера ... только куски, где использованы некоторые подходы SOA и прочия.
3. На тему противоречия.  Цитата:

BYUR: >> При этом абсолютно очевидно, что если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него. Если подходить имеено так, то не думаю что слудует "... приготовьтесь к тому, что в этот момент Вы просто начнете все с начала".

WJ >> Сами себе противоречите. Сначала говорите, что выбор BPMS - 5 шаг, а потом говорите, что надо изначально под него затачиваться. Или я Вас не правильно поняла? Что есть "выбор вендора"?

Я же вроде вполне ясно написал ... "если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него". Что означает буквально следующее ... имея EA можно принимать решение об использовании или неиспользовании BPM System. После чего и "затачивать" _конкретные_ процессы под нее.

WJ, Юрий, может вам лучше новую тему открыть? Если конечно вы сами понимаете о чем спорите В любом случае явно ведь не о книгах по BPMN. Сможете сформулировать предмет дискуссии - глядишь, и другие подключатся. А там и вообще - что-нибудь в результате родится.

PS. Юрий, правильно говорить BEPL, а писать все же - BPEL.
PPS. Oracle - это особый случай. Они сами пока не знают что у них есть в области BPM (во всяком случае если говорить о Московском офисе). Впрочем, IBM - случай еще более особый

Да, да, я что-то тоже перестал понимать о чем спор
Хотел отделить тему, но не нашел откуда
Да и вообще тема не про книги

ОК, прекращаем дискуссию.

PS. Юрий, правильно говорить BEPL, а писать все же - BPEL.

Чистой воды опечатка ... сорри.

Специально для Юры - развернутый комментарий сразу нескольких авторитетов на тему BPEL и BPMN: http://bpms.ru/library/reviews/08/index.html#c915. Впрочем, остальным тоже может быть интересно.