С чего начать при построении модели на BPMN?(Прочитано 29743 раз)
Мы на 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.
« Последнее редактирование: 10 Ноября 2008, 17:56:43 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Так, давайте по-порядку ... а то я перестал понимать "шо вы имеете ввиду" :-) ...
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. После чего и "затачивать" _конкретные_ процессы под нее.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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

PS. Юрий, правильно говорить BEPL, а писать все же - BPEL.
PPS. Oracle - это особый случай. Они сами пока не знают что у них есть в области BPM (во всяком случае если говорить о Московском офисе). Впрочем, IBM - случай еще более особый :)
« Последнее редактирование: 11 Ноября 2008, 18:00:29 от АБ »



Да, да, я что-то тоже перестал понимать о чем спор :)
Хотел отделить тему, но не нашел откуда :)
Да и вообще тема не про книги :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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



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

Чистой воды опечатка ... сорри.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19