Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - WJ

Страницы: 1
1
Жаль, что поздно увидела ветку. Но может пригодится кому:
Цитировать
Как иначе вы нарисуете обмен сообщениями из процесса с внешними контрагентами, например клиентами?
нарисую внешний пул пустым, и message Flow к нему. И могу сделать его любым по размеру, т.к. он пустой (т.е. можно нарисовать и узкий, и длинный - какой понравится).

2
Asd,
составление отчетности - это бизнес-функция. Не путайте.
Есть еще такое понятие, как "поток работ", которое часто путают с бизнес-процессом. Поток работ - это некая определенная последовательность действий, при которой начало следующего действия предполагает обязательное завершение предыдущего. То есть действия выполняются по порядку (кстати, иногда это параллельные действия, но тоже упорядоченные). Линейность.
В жизни не все можно описать в виде потока работ. Определенные действия могут порождать некоторое количество других действий или сами порождаются какими-то событиями. Это обычно называют ad-hoc процессы. Мне не хочется даже пытаться давать еще одно n+1 -е определение бизнес-процессов, но если Вы действительно хотите разобраться, что является бизнес-процессом, а что нет, то найдите следующие признаки:
1. кроссфункциональность (по этому признаку бизнес-процессы бухгалтерии сразу отпадают)
2. взаимодействие n к m (то есть n процессов могут порождать m событий или процессов и наоборот)
3. повторяемость (часто процессы путают с проектами)
Я не скажу, что этого всегда хватает, чтобы правильно выявить процессы - это довольно сложная работа. Но, по крайней мере, это ключевые отличия.
По поводу "ценного результата на выходе" - с этим определением (с его однозначностью) можно поспорить. Существуют  процессы, добавляющие ценность, и процессы, добавляющие стоимость (как правило, это внутренние процессы). К примеру, процесс увольнения сотрудника (начиная с подачи заявления, включая подписание бегунка, размещение заявки на замещение вакансии, истребования задолженностей, получения выходного пособия и проч.) - это внутренний процесс, ценности для конечного заказчика он не представляет, затраты увеличивает. Но при этом он действительно необходим.
Вообще-то в подобном споре полностью победить не удастся никому. Куда ни ткни, даже в самый, казалось бы, явный "процесс" - обязательно придется разбираться, с какими бизнес-процессами он взаимодействует, какими бизнес-функциями оперирует, какой документооборот порождает и т.д. Есть такой термин - Process Discovery - выявление бизнес-процессов. Не все так просто :-)

3
2 anastazya,
практичнее делать подобные вещи отдельными процессами, которые могут быть инициированы из разных процессов. Использование отдельных процессов позволяет:
1. запускать процесс (в нашем случае Анализ) автономно (не из другого процесса);
2. Инициировать из одного процесса несколько экземпляров процесса Анализ (к примеру, если нужно анализировать несколько разных сегментов по одной заявке);
3. Подпроцесс, включенный в процесс, является частью схемы этого процесса. Поэтому изменения в подпроцессе повлекут за собой изменение схемы основного процесса. И в этом случае дальнейшее поведение уже запущенных экземпляров процесса процеса будет зависить от исполняющей программы - в некоторых случаях все запущенные версии процесса исполняются по старой схеме, а все новые - по новой. Но иногда и все запущенные будут исполняться по новой схеме. А отдельно стоящий процесс стартует в последней версии, даже если инициирующий процесс был запущен раньше, чем изменялся вспомогательный.

4
Экспортировать схему в BPMS и попытаться исполнить. Надежнее ничего не придумаете.

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

6
Так, давайте по-порядку ... а то я перестал понимать "шо вы имеете ввиду" :-) ...
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. Дабы, как Вы правильно заметили, "избежать путаницы".

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

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

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

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

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

9
Думаю, что обращение к BPMS и тем более к SOA при заинтересованности в процесном управлении -- это 5 и 8 шаги соответственно. Для начала нужно построить классификацию БП организации, на основании некой референсной модели. Например для телекомов есть очень неплохая классификация eTOM. При "обработке напильником" можно применить для любой организации, оказывающей услуги.
Если Вас интересует реинжиниринг бизнес-процессов - то, возможно, это 5, 8... а скорее 10000... шаги (это уже не имеет значения, поскольку Вы вряд ли до них доберетесь :) ) Мой личный опыт (не утверждаю, что нет опровержений): я не видела НИ ОДНОГО примера, когда бы в организации существовал BPM, образовавшийся в результате реинжиниринга.
Кстати в термине BPMS "S" отнюдь не Suite, а System ....
Смотря о чем Вы говорите. Если об инструментарии - то именно Suite, если о системе, построенной на основании использования этого инструментария (грубо говоря - то, чего получилось на конкретном предприятии) - это однозначно Systems.
:))) устареваете

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

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

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

11
К тому, что сказал АБ, хочу добавить: речь идет о том, что BPM-системы умеют из нарисованной схемы и обозначенных на ней атрибутов процесса генерить автоматические экранные формы, которые позволяют исполнять процесс, заполнять его требуемыми данными - все как в жизни, только без удобств. Автоматические формы действительно не пригодны для промышленной эксплуатации, однако помимо тестирования процесса они могут пригодиться и как временная "заглушка" для измененных или добавляемых шагов уже работающего процесса. Поясню:
аналитик отладил процесс, программист для каждого ручного шага процесса нарисовал экранную форму - все работает. Вы изменяете процесс - добавляете еще один промежуточный шаг. Форму программист еще не нарисовал, а процесс останавливать нельзя - оже уже в промышленной эксплуатации. Как временное решение запускаем процесс в эксплуатацию с одной автоматической формой (остальные остались как были). Да, какие-то данные придется внести руками вместо привычного выбора из базы и без каких-то удобств. Ну и что? Что это в сравнении с остановкой процесса или работой по старой схеме из-за боязни, что программа этого не может?

Страницы: 1