конечно не по феншую, это не имеет отношения потому что к процессу

А если будет юзер-таска, назначеннная на сотрудника, с названием "Получить документы Клиента". И для нее есть бизнес-правило: ждать не более двух дней. То я не могу повесить на нее таймер на два дня, а должен отчетик придумать и заставить его регулярно смотреть?

кого заставить?

Вот, кого-то, ответственного за KPI. Чтобы он пришел и пнул. Так получается?

про время все соображения тут https://bpmn2.ru/vremya-%D0%B2-bpmn/

Все исходит из того, что мы не можем клиентом управлять так же, как и сотрудником. А если начинаем делать так, клиентов (да и меня) это начинает дико бесить. Когда тебе говорят, вот теперь так сделайте, а на вопрос почему отвечают, что вы на первой странице присоединились к некому внутреннему регламенту, вот теперь исполняйте. Я к такому бизнесу в 21 веке не вернусь. Буду бить таких рублем.

Поэтому и надо сразу в архитектуре своих процессов это закладывать, показывая клиента как «свернутый пул», например. И закладывая в процесс лишь точки взаимодейсвия с клиентом, «касания», а не UserTask.

Я смотрел все твои видео, но пересмотрю.

Да не надо клиентом управлять. Надо давать ему возможность. Удобную. И это никак не связано с тем, каким способом мы это сделаем, юзер-таской или еще чем-то. Клиент об этом никогда не узнает.

Согласен, но через user task, больше шансов перейти эту черту и начать им управлять. Мне кажется именно из-за этого такая рекомендация от наших западных коллег.

Клиент в виде свернутого пула - это не участник процесса, это внешняя система, в которой работает клиент и которая сама раздает клиенту какие-то задания. А с нашим процессом она взаимодействует интеграционно. И это уже другая задача, в другом контексте, отличном от обсуждаемого.

ойвсё

Пожалуй

А если отвлечься о теории? 😊
Совсем никто не сталкивался с чем-то подобным?

Создаем таску по таймеру на контакт-центр - "позвонить клиенту".
Дальше по результату звонка - клиент или предоставляет паспорт или услуга не оказывается.

ага, а если не ответил?

Регламент на это должен быть с разными вариантами эскалации (повторный звонок, что то еще, остановить оказание услуги)

Спор как обычно крутится вокруг объема функционала, который непосредственно представлен на схеме процесса и который находится за кадром (в коде воркеров например)
Если у вас не много процессов, они достаточно простые и где-то разово возникла необходимость "интерактивного" взаимодействия с клиентом, то технически это можно сделать в виде UserTask c "обвязкой" таймерами и "лишними" переходами

А если у вас сложные процессы с многократными эпизодами взаимодействия с клиентом, то общий подход правильно вынести, чтобы не засорять схемы и не плодить сущности

Я согласен с позицией, что не надо "программировать" на BPMN - важный плюс - читаемость, понятность для не-айтишников полностью убивается

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

Это какой-то документ публичный? Интересно почитать

негласная договорённость, которая сквозит у всех в книжках, например method and style