Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => IDEF ARIS BPMN и пр. => Тема начата: Сергей Наумов от 07 Ноября 2008, 13:21:25
-
не уверена что все это книги, но зато на русском
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 (http://bpms.ru/library/articles/how-to-simplify-bp-changes).
-
Почитайте еще раз внимательно тот пост. Если речь идет о заключении договора, то контроль его исполнения - это отдельный процесс. Если в рамках этого договора могут быть несколько заказов товара - это несколько экземпляров ДРУГОГО процесса. При этом, заказы могут быть не полностью удовлетворены, существуют возвраты, претензии... Прямых путей "Встал-пошел-направо-сел" в бизнесе не бывает.
А кто говорил про простые линейные процессы? Они ветвятся очень сильно. Тут скорее вопрос в идеологии декомпозиции.
Мы на 2ом уровне представляем простой верхоуровней процесс зачастую линеней с небольшими ветвлениями + бывают БП которые никак не связаны с другими и следовательно могут выполняться в любом месте. Далее (на 3ем уровне) уже декомпозируем каждый БП более сложно с возможным реиспользованием уже существующих БП.
Вы как предлагаете декомпозировать? Все БП 2ого уровня должны быть не связаны м\у собой?
Кстати, Вы так и не порекомендовали книг по БПМС ...
-
Мы на 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 (http://bpms.ru/library/reviews/08/index.html#c915). Впрочем, остальным тоже может быть интересно.