Режим отображения и редактирования процессов

[Мария Полевая]

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

[Dmitry Goncharenko]

Это пожелание встречается достаточно часто. К сожалению, BPMN не очень хорошо ложится на автоматические сценарии ПланФикса (ну или они не очень хорошо на нее ложатся), так как BPMN хорошо отображает линейное и однопоточное выполнение процесса, а автоматические сценарии ПланФикса работают в многопоточном режиме и больше напоминают механизм распространения сигнала по нейронной сети, когда от одного нервного центра сигнал одновременно может разбежаться по нескольким веткам, на конце каждой из которых вызвать новое событие, которое запустит новые сценарии - и так далее, каскадом.

Соответственно, корректно отобразить эту работу в стандартной нотации у нас не получается. Если же жестко привязаться к прохождению по статусам процесса и отобразить только их, то часть реально производимых системой действий не войдет в эту схему, что сведет ее пользу к минимуму.

[Александр Лещинский]

Тогда вопрос можно расширить до "А можно поддержку UML"? С нелинейностью и вариативностью в нем, как стандарте, все достаточно неплохо.
И как формат импорта/экспорта (не только редактирования и визуализации) отлично пойдет

[Dmitry Goncharenko]

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

[Робот Обработчик]

Недавно разработчики реализовали визуальную схему с возможностью настроек последовательности задач https://planfix.com/ru/blog/vsyo-nachin ... fiksovski/ Очень хотелось бы получить подобную настройку и для процессов.

Простой полу костыльный вариант:
Не перерабатывать существующую логику сценариев. Сделать только в процессах альтернативный интерфейс создания сценариев и их настройку на подобии реализованного планировщика связей.
Я создаю прямоугольнички сценариев. Соединяю из связями. У связи настраиваются стандартные Триггеры срабатывания сценария. Так же у связи настраиваются условия. Где настраиваются сами действия, в прямоугольнике или в связи, надо подумать.

Гениальная простота:
У сценария скорее всего есть id. Если нет, то, думаю, это не сложно создать. В задаче создать поле, в которое будет прописываться этот id сценария. Так мы будем знать на каком этапе задача в процессе. И этот id будет одним из обязательных условий сценария.

При создании или перетягивании связи в фоне будет создаваться действие сценария, которое будет прописывать id сценария, в который ведет эта связь.
Сценарий отработал. Задаче прописался новый id сценария. Только у связей ведущих от этого сценария в условиях срабатывания автоматически прописан id. Соответственно следующие этапы этого процесса отработают только на задачах, находящихся на правильном текущем этапе.

Надеюсь понятно обрисовал идею.

[Илья Федоров]

Пока не очень понятно что такое "связь сценариев".
Сейчас они никак между собой не связаны, значит предлагается их создать?
Что это такое эта связь? В чем её назначение?

Сейчас сценарии это независимые друг от друга "сущности". Выполнение одного непосредственно не связано с выполнением другого, только косвенно, например один сценарий меняет значение поля, а другой реагирует на это изменение.
При этом нет никакой гарантии что второй отработает, поскольку иногда случаются сбои в выполнении сценариев.

Если бы можно было "заставлять пользователей" выполнять жесткую последовательность действий, тогда был бы смысл и в таких связках. Но сейчас это не так и не скоро наверно такое появится.
А сейчас пользователь просто работает в контексте шаблона задачи и последовательность его действий не может быть жестко регламентирована.
"Хочу" сначала заполню поле 1, потом поле 2. А завтра буду делать наоборот заполню поле 2, а потом 1. И сценарии должны учитывать такую "непоследовательность".

[Дмитрий Макаров]

Сейчас я настраиваю сценарий крупными мазками. В условиях 1-2 пункта. После эксплуатации начинают вылезать проблемы, он срабатывает на слишком большом количестве задач. Начинаю добавлять условий, отсекая не нужное. Но при отработке этого сценария начинают отрабатывать давно настроенные старые сценарии. Приходится лезть в них и вносить правки в их условиях, иногда руша процесс на который они были запилены.
Я не профессионал. Я пользователь системы. Мне нужны удобные инструменты настройки. Рисовать свои процессы на бумажках или искать для этого сторонние предложения, я считаю не приемлемым. Я хочу последовательный процесс. Хочется его визуализировать. Это поможет в нахождении узких мест и повысит удобство моей работы.

Внутри ПФ всё останется по старому. Предлагается только изменить интерфейс.
Четырехугольник это этап в котором находится задача.
Связь четырехугольников это сценарий.
Задача в состоянии 1-й этап. На схеме процесса от этого этапа идут стрелки к четырехугольникам Этап2.1 / 2.2 / 2.5 / 3.0 / 7.11 Эти стрелки это и есть сценарии. В них настраиваются триггеры срабатывания, условия, действия, короче весь интерфейс сценария.

[Илья Федоров]

Так просто эта тема не взлетит. Ведь помимо смены статусов задачи есть много других событий.
Статус может не меняться, но событие нужно отлавливать, и это в схему уложить будет очень не просто.
Проблема тут методическая
- "процесс" несмотря на название не является процессов в понимании методологии (это не просто набор статусов, а это цели процесса, его ограничения, ресурсы, окружение процесса, результаты процесса, входы и выходы и т.п.);
- "сценарий" не является объектом управления, это просто строка/функция которая есть и которая выполняет своё действие, ничего не зная про другие сценарии.

[Дмитрий Макаров]

Так просто эта тема не взлетит. Ведь помимо смены статусов задачи есть много других событий.
Статус может не меняться, но событие нужно отлавливать, и это в схему уложить будет очень не просто.
Проблема тут методическая
- "процесс" несмотря на название не является процессов в понимании методологии (это не просто набор статусов, а это цели процесса, его ограничения, ресурсы, окружение процесса, результаты процесса, входы и выходы и т.п.);
- "сценарий" не является объектом управления, это просто строка/функция которая есть и которая выполняет своё действие, ничего не зная про другие сценарии.

Не нашел в описании своей идеи упоминание смены статусов задачи. Я явно указал, что функционал сценариев останется прежним. Меняется только интерфейс настройки.

Сценарий так и будет ничего не знать про другие сценарии.

Процесс, настраиваемый в графическом редакторе будет прописывать в условия сработки сценария id отправного этапа. И добавлять в действия пропись в задачу id этапа назначения. (это переосмысление вчерашней хотелки)

[Дмитрий Макаров]

Вот такая штука

Стандартные настройки сценария. Но при создании или перетягивании этой тонкой линии, которая является сценарием, автоматически добавлять 2 вещи. см рис

1. В условие срабатывания сценария добавлять значение поле задачи = id этапа начала сценария. В данном случае "1111"

2. В действия сценария менять значение поля задачи на id этапа завершения сценария. В данном случае "2222"

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

[Илья Федоров]

Не понятно что вы имеете ввиду тогда под "этапами " задачи". Это какое-то её состояние, набор условий в которых находится сама задача и её окружение (например в сценариях могут быть условия связанные с "состоянием" надзадачи?

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

1. Как быть со сценариями которые не приводят к смене "этапа" (в терминах планфикс статуса процесса задачи), а просто что то меняют?
Буде стрелочка на тот же квадратик?
Если таких сценариев 10, будет 10 стрелочек?
У каждой сущности есть свое назначение и своя логика.

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

В специализированных методологиях/языках моделирования есть разные виды диаграмм, и я как специалист со знаниями (не очень грубокими, каюсь) в этих "нотациях" понимаю что нет одной такой диаграммы в которой можно увязать вообще все.
У каждой диаграммы/нотации/схемы (на примере UML) своё назначение и своя цель. Одни отображают последовательность смены состояний во времени, другие изменение данных объекта, третие взаимосвязи высшего уровня.

Разработка такого рода инструментов это очень сложный методический и технический вопрос. Учитывая идеологию ПланФикс вряд ли стоит ждать развития инструментом управления сценариями в этом направлении.

[Илья Федоров]

Вот такая штука https://prnt.sc/mssuY19QXTFa

Картинка у меня не открывается. В форуме можно присоединить файл и встроить вывод картинки прямо в тему

[Дмитрий Макаров]

1. Как быть со сценариями которые не приводят к смене "этапа" (в терминах планфикс статуса процесса задачи), а просто что то меняют?

Такие сценарии будут настраиваться по старому. Не предлагается полностью перейти на такой вариант настройки.

[Алексей Сахоненко]

Как я понимаю, речь идёт о создании сценариев двух типов:
1. "простые", когда они могут быть описаны с помощью UML и "нарисованы" в ПФ аналогично тому, как сейчас можно нарисовать связи между задачами в новом типе планировщика.
2. "сложные", открывающиеся по нажатию какой-нибудь хитрой кнопочки. В этом случае могло бы бы предупреждение БОЛЬШИМИ БУКВАМИ НА БЕЛОМ ЭКРАНЕ типа "вы вступаете на скользкую тропу и нажатием этой кнопки понимаете все последствия, что вам предстоят" и далее - был бы тот способ создания сценариев, что используется сейчас.

Мне кажется, что в 90% случаев хватило бы режима (1). Во всяком случае я смотрю на свои сценарии и понимаю, что в моём случае - это точно так. А может даже и 95% ))