Реализация процесса с разделением контролирующей и исполняющей составляющих, попытка переложить методику автоматного программирования на BPMN
Файлы
-
Мебель.bpm (38.2 KB, 39 downloads) 11 лет old
-
Опубликовано 11 лет назад #
-
Боюсь без дополнительных комментариев тут не обойтись. Как минимум добавить аннотаций на схему, а желательно и сопроводительный документ, поясняющий архитектуру. Можно текстом прямо здесь, в каментах.
Есть сомнения по поводу типов задач:
- Оповещение как send task - если имеется в виду оповещение по email, то это script task
- Формирование плана как business rule. Сомнительно. Либо user, либо service.
- Производство как manual. Почему не user?Опубликовано 11 лет назад # -
Прошу прощения за долгое молчание, не подписался на комменты.
По поводу типов задач:
- Оповещение - это сообщение в соответствующий процесс, подробно опишу в пояснении
- хм.. формирование плана - имеется в виду подготовка выборки по всем заказам, где начальник цеха ставит галочки - то, что будем делать сегодня, не уверен точно, что можно здесь использовать
- это поправил, добавил задачу выставления статуса "произведено". Ручную ввел только в качестве комментария - здесь что-то делается. Убрать её?п.с. Пишу пояснения, дорабатываю схему.
Опубликовано 11 лет назад # -
Итак, привожу описание приведенной схемы
В технологии производства предусмотрен один "управляющий" процесс "Обслуживание клиента", в котором заложена логика запуска "исполнительных" процессов и логика отработки сообщений, поступающих от них.
Суть деятельности такова:
* Клиент обращается в компанию. Запускается селекторный процесс "Работа с клиентом". В зависимости от цели прихода, запускается основной управляющий процесс "Обслуживание клиента", либо посылаются сообщения существующему "управляющему" процессу, либо запускаются вспомогательные исполнительные процессы, которые в зависимости от результатов своего исполнения посылают соответствующие сообщения управляющему процессу.* В управляющий процесс заложена следующая логика (очень упрощенная, исходная представлена Владиславом Гороховым):
Happy Path:Клиент обращается - готовим предложение - подписываем предварительный договор - запуск управляющего процесса (берем на контроль) - далее запускаются параллельно деятельность по контролю производства, деятельность по контролю закупки комплектующих, деятельность по контролю доставки, деятельность по контролю монтажа - когда все процессы завершены, переходим к деятельности по контролю качества и заканчиваем управляющий процесс.
Логика межпроцессного взаимодействия реализована на механизме сообщений и на механизме обращении к данным. Сообщения запускают исполняющие подпроцессы (либо подпроцессы запускаются по таймеру в соответствии с графиками поставок и производства).
Исполняющие процессы либо изменяют данные и/или посылают сообщения соответствующим экземплярам управляющего процесса.Сразу поясню по поводу параллельности запуска деятельностей по контролю производства, закупки комплектующих, доставки и монтажа. В соответствии с требованиями заказчика поставка и монтаж могут быть произведены до окончания стадии производства и закупки комплектующих, то есть имеет место итерационное выполнение этапов производства, закупки комплектующих, доставки и монтажа, без жесткого закрепления последовательности: кухня, произведенная частично (произведен какой-то один отдельный модуль), может быть поставлена и смонтирована, и так до тех пор, пока не будут произведены и смонтированы все части. Та же логика заложена и в деятельность закупки комплектующих.
"Работа с клиентом": Селекторный процесс
Клиент обращается в компанию, в зависимости от цели приходя запускаем тот или иной исполнительный процесс, среди них:
«Подготовка предложения»
«Заключение договора»
«Доработка заказа»
В случае отказа, посылается сообщение в соответствующий экземпляр управляющего процесса и управляющий процесс прерывается с ошибкой.Подготовка предложения может проводиться несколько раз, и каждый раз клиент может уходить «на подумать». При этом все предложения сохраняются в базу, и при повторном приходе есть возможность перейти сразу к фазе заключения предварительного договора.
п.с. больше рисунков не вошло - см. схему в BizAgi
Файлы
-
Контроль_закупки_тех.png (52.1 KB, 18 downloads) 11 лет old - Контроль_производст (31.7 KB, 14 downloads) 11 лет old
- Мебель_v.2.png (434.1 KB, 34 downloads) 11 лет old
- Мебель_v.2.bpm (49.9 KB, 14 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Читателям: коллеги, будете изучать схему - не забудьте заглянуть вовнутрь подпроцессов "Контроль производства", "Контроль доставки" и пр.
Авторам: замечания.
1. Подпроцесс "Контроль закупки техники".
- Прикрепленный обработчик эскалации наверное должен быть непрерывающим? Но вообще-то эскалация тут представляется излишней: "Связаться с поставщиком" - это задача, которую мы назначаем своему сотруднику, а потом спрашиваем его - "ну как?".
- Вперемешку развилки "пустые" и с буквой "Х" - это моветон.
- Параллельная развилка в верхней ветке - так и задумывалось?2. Подпроцессы контроля всего остального
- Где таймеры? Фокус этой схемы в том, что контролируются события не только состоявшиеся (товар произведен, товар отгружен и т.п.), но и несостоявшиеся! Этот момент оказался упущен.Опубликовано 11 лет назад # -
Доработал схему:
1. Насчет непрерывающей эскалации - согласен. Попытался исправить, не нашел где это можно сделать. Убрал эскалацию совсем, как и процесс Связаться с поставщиком. Упаковал все в один шаг.
везде поставил Х
насчет параллельной ветки - да, процессы производства, закупки, доставки и монтажа выполняются параллельно в том смысле, что до окончания процесса производства (все модули произведены) или закупки комплектующих (не все комплектующие закуплены) можно уже начать производить частичную поставку и монтаж.
2. Да, согласен, это упущение. Таймеры расставил - в качестве "ускорителя" процесса используется письмо директору (отправляется скриптом), либо другому контролирующему лицу
Файлы
- Мебель_v.3.bpm (50.6 KB, 46 downloads) 11 лет old
Опубликовано 11 лет назад # -
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.