bpmnforum.ru

1. shakir
   Участник

   Рейтинг:8

    

   Коллеги, подскажите, пожалуйста.
   Процесс по проведению закупки. Два действующих лица: Заказчик и Поставщик. После публикации извещения есть промежуток времени, пока идет прием заявок, в котором может произойти несколько действий, а может не произойти.
   Пока идет прием заявок Заказчик может внести (или ничего не делать) изменения в извещение и в этот же промежуток времени ему может прийти (или не прийти) запрос на разъяснение. Также на запрос Заказчик может как ответить, так и не ответить на данный запрос. И в этот же промежуток времени Заказчик может вообще отменить (или не отменить) проведение процедуры закупки. Такое комбо)

   На данный момент следующий вариант. Насколько грамотно использование событийного непрерывающего подпроцесса в спонтанном подпроцессе?

   

   Файлы

   1. Спонтанный.png (63.1 KB, 2 downloads) 4 года old

   Опубликовано 4 года назад #

2. Анатолий Белайчук
   Хранитель

   Рейтинг:498

    

   Вы процесс моделируете для людей (регламент) или для процессного движка (исполняемый процесс)?

   Общение с поставщиком ведется традиционными способами (телефон, email) или через онлайновую площадку и личный кабинет?

   От ответа на эти вопросы зависит какими элементами стоит пользоваться, а каким нет.

   Но таймер в обоих случаях у вас используется не по делу.

   Опубликовано 4 года назад #

3. shakir
   Участник

   Рейтинг:8

    

   Вы процесс моделируете для людей (регламент) или для процессного движка (исполняемый процесс)?

   
   Процесс для людей

   Общение с поставщиком ведется традиционными способами (телефон, email) или через онлайновую площадку и личный кабинет?

   
   Закупка проводится на электронной торговой площадке

   Подкорректировала этот кусок, сейчас вроде больше похоже на правду. Хотя... чем больше изучаешь BPMN, тем больше ощущение, что ничего не понимаешь)

   

   Файлы

   1. схема.png (97.7 KB, 0 downloads) 4 года old

   Опубликовано 4 года назад #

4. Анатолий Белайчук
   Хранитель

   Рейтинг:498

    

   В вашу схему вкралась ошибка: в то время, когда вносятся изменения в извещение/продлевается срок приемки заявок, запросы на разъяснение не обрабатываются и таймер тоже. Это стандартная ловушка развилки по событиям. Решение - параллельная развилка и терминатор.

   Непонятно зачем два таймера со сроком приема предложений.

   Запрос на разъяснение лучше трактовать как отдельный процесс (связанный с основным по данным) или как эскалацию, триггером которой является непрерывающий прикрепленный обработчик события-условия или сообщения.

   Опубликовано 4 года назад #

5. shakir
   Участник

   Рейтинг:8

    

   Спасибо большое за комментарии.
   По поводу развилки по событиям тоже потом дошло, что события не смогут идти параллельно.

   Немного подкорректировала. Единственно, мне кажется, что не совсем поняла насчет последнего комментария по запросу на разъяснение.

   

   Файлы

   1. Screenshot_2.png (92.1 KB, 0 downloads) 4 года old

   Опубликовано 4 года назад #

6. Анатолий Белайчук
   Хранитель

   Рейтинг:498

    

   С запросом на разъяснение вы правильно разобрались - прикрепленный обработчик и подпроцесс-обработчик это практически одно и то же.

   А вот с параллельной развилкой у вас беда: процесс на ней сходу зависнет. Подумайте еще, точно ли возврат должен быть именно к шлюзу?

   Опубликовано 4 года назад #

7. shakir
   Участник

   Рейтинг:8

    

   Подумайте еще, точно ли возврат должен быть именно к шлюзу?

   
   А возврат может быть к стартовому событию? Или добавить какое-то действие между стартовым событием и шлюзом?

   Опубликовано 4 года назад #

8. Анатолий Белайчук
   Хранитель

   Рейтинг:498

    

   Нет, в стартовое событие поток управления приходить не может.

   Вы понимаете почему процесс у вас зависнет на параллельной развилке?

   Опубликовано 4 года назад #

9. shakir
   Участник

   Рейтинг:8

    

   Верхнее событие (внесение изменений) может и не произойти и токен, получается, будет стоять на развилке, пока не закончится срок приема заявок.
   Но все равно смущает реализация.

   А такой вариант? Токен будет стоять между стартовым событием и таймером, в это время как раз могут происходить непрерывающие события: запрос на разъяснение и/или внесение изменений

   

   Файлы

   1. Screenshot_3.png (77.4 KB, 2 downloads) 4 года old

   Опубликовано 4 года назад #

10. Анатолий Белайчук
    Хранитель

    Рейтинг:498

     

    В целом все корректно, но пара моментов смущают:
    1) Где же собственно получение заявки? Бизнес-исключения обработаны, а магистральный путь - нет.
    2) Почему одни события обрабатываются прикрепленным событием, а другие - подпроцессом-обработчиком? Стилистический разнобой.

    Ну и это конечно не для людей схема, а для роботов - для среднестатистического человека слишком мудрено.

    Опубликовано 4 года назад #

11. shakir
    Участник

    Рейтинг:8

     

    Огромное спасибо) пришло понимание, как такие сложные куски можно моделировать.

    Обработка и просмотр заявок будут дальше по процессу. До момента вскрытия конвертов Заказчику заявки недоступны. Только их количество. Стоит этот момент тоже отобразить?

    Опубликовано 4 года назад #

12. Анатолий Белайчук
    Хранитель

    Рейтинг:498

     

    Ну как бы для порядка - конверт пришел, с ним же надо что-то сделать? В сейф спрятать, я не знаю...

    Опубликовано 4 года назад #

13. shakir
    Участник

    Рейтинг:8

     

    Поняла, добавлю. Спасибо)

    Опубликовано 4 года назад #

RSS лента этой темы

Ответ

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