Вопрос о возврате к предыдущему элементу в рамках бизнес-процесса
Добрый день!
Пользуемся Вашим продуктом (Sales) второй год, разрабатываем собственные схемы бизнес-процессов под нужды предприятия. Назрела проблема с отработкой бизнес-процессов пользователями, а именно в их желании вернуться на предыдущий этап (активность) в связи с тем, что завершили ее "случайно", либо ситуация требует корректировки бизнес-процесса "задним числом".
Можете поделиться какими-нибудь наработанными решениями по данному вопросу?
Нами было проработано два варианта решения задачи.
1. С помощью стадий, как в процессе «Управление лидом».
Выявленные минусы:
- отсутствие наглядности схемы бизнес-процесса, если процесс нелинейный
- при большом количестве стадий процесс становится трудоемким в разработке (стандартный процесс содержит 15-17 стадий-активностей)
2. Реализация возвратов на предыдущий этап с помощью соответствующего результата в Активности.
Выявленные минусы:
- утяжеление схемы бизнес-процесса из-за дополнительных связей
- необходимость дополнительных условий в случае, если процесс имеет несколько веток, в итоге соединяющихся в один результирующий элемент
- отсутствие возможности вернуться на любую стадию процесса
В идеале хотелось бы по сигналу запускать бизнес-процесс, который бы менял активный элемент в конкретном экземпляре уже запущенного бизнес-процесса. Однако возможно ли реализовать такой подход, чтобы при этом приложение работало стабильно?
P.S. прошу прощения, если подобный вопрос уже был. Если так, прошу указать на него ответ. Заранее спасибо.
Нравится
Катерина, здравствуйте!
Не совсем понятно, что подразумевается под “ В идеале хотелось бы по сигналу запускать бизнес-процесс, который бы менял активный элемент в конкретном экземпляре уже запущенного бизнес-процесса.” - какой ожидаемый результат с точки зрения пользователя и с точки зрения поведения приложения.
Рекомендую углубится в первый предложенный вариант – “ 1. С помощью стадий, как в процессе «Управление лидом»”.
“стандартный процесс содержит 15-17 стадий-активностей” – разделить на несколько логических блоков. Каждый блок привязать к определенной стадии. Каждый блок в результате будет состоять условно из 3-4 активностей.
Далее реализовать один из подходов:
Вариант 1. С помощью модели: Один родительский процесс и множество подпроцессов. (пример – базовый процесс управления лидом).
Вариант 2. С помощью модели: Стартовый сигнал по изменению стадии – в конце БП изменять стадию на следующую.
Вариант 3. С помощью DCM/Кейс менеджмента (вариант доступен начиная с версии 7.9)
Такая модель, которая привязана к стадиям, позволяет:
1. Легко переключаться между стадиями. В результате не придётся проходить все этапы от создания записи до перевода в конечное состояние. Можно повторно продолжить с интересующего места, достаточно выбрать предыдущую стадию в дашборде или изменить вручную.
2. Легче отслеживать на каком этапе произошел сбой при выполнении.