Comments 15
Хорошая тема. Мне на самом деле почему-то почти не попадались публикации, где бы рассматривались вопросы миграции вот в таком вот плане. Т.е. мигрировать вроде бы и можно — а практически получается, что ряд изменений процесса приводят к невозможности миграции запущенных экземпляров.
Действительно, тема как вы подметили практически не освещена в русскоязычном сегменте. Поэтому был удивлен прочитав вашу статье по этой тематике, что и послужило одним из импульсом для продолжения данной темы. Буду рад услышать ваше мнение о прототипе в следующей части статьи.
Как то странно выглядит логика удаления таска 2.
Мне кажется, в версии 2 (промежуточной) надо от таска 2 переходить не к завершению БП, а к таску 3. Иначе нарушается логика всего бизнес процесса.
Мне кажется, в версии 2 (промежуточной) надо от таска 2 переходить не к завершению БП, а к таску 3. Иначе нарушается логика всего бизнес процесса.
По моим наблюдениям матрицы более полно и просто описывают бизнес-процессы, хотя менее наглядно. Как-нибудь напишу свои соображения как формализировать БП с помощью матриц.
интересно, может подскажите ссылки на источники?
К сожалению все в голове: математика, конечные автоматы, графы, булевая логика, статистика, вероятности.
Почти любой бизнес-объект можно рассмотреть как объект с дискретными параметрами. Можно написать матрицу перехода из одного состояния в другое. Можно написать матрицы сочетаний для различных параметров. По матрицам хорошо видны валидные и невалидные состояния.
Например, возьмем простой случай — договора. Можно написать матрицу сочетания типа клиента (ЮЛ, ФЛ) и тарифного плана (к примеру есть план Стандарт и VIP).
Теперь допустим имеются такие слова: «для всех договоров ЮЛ» делаем действие1. Для всех «договоров Стандарт» делаем действие2.
На матрице сразу видно противоречие, что «для договоров ЮЛ с тарифом Стандарт» будет непонятно какое выполнять действие — 1 или 2. И сразу будет видна вероятность попасть на противоречие.
Почти любой бизнес-объект можно рассмотреть как объект с дискретными параметрами. Можно написать матрицу перехода из одного состояния в другое. Можно написать матрицы сочетаний для различных параметров. По матрицам хорошо видны валидные и невалидные состояния.
Например, возьмем простой случай — договора. Можно написать матрицу сочетания типа клиента (ЮЛ, ФЛ) и тарифного плана (к примеру есть план Стандарт и VIP).
Теперь допустим имеются такие слова: «для всех договоров ЮЛ» делаем действие1. Для всех «договоров Стандарт» делаем действие2.
На матрице сразу видно противоречие, что «для договоров ЮЛ с тарифом Стандарт» будет непонятно какое выполнять действие — 1 или 2. И сразу будет видна вероятность попасть на противоречие.
Для объекта — понятно, как можно составить матрицу.
Но как быть с бизнес процессом в целом? БП может разветвляться и ветви выполняются без синхронизации. Например, синхронизация в самом конце. Ведь для такого процесса понадобится ОЧЕНЬ большая матрица… И представить процесс как набор матриц отдельных шагов или объектов наверно не получится. По крайней мере я не представляю, как.
Но как быть с бизнес процессом в целом? БП может разветвляться и ветви выполняются без синхронизации. Например, синхронизация в самом конце. Ведь для такого процесса понадобится ОЧЕНЬ большая матрица… И представить процесс как набор матриц отдельных шагов или объектов наверно не получится. По крайней мере я не представляю, как.
Ведь для такого процесса понадобится ОЧЕНЬ большая матрица
Согласен, если количество значений параметров N, то для анализа сочетаний нужна матрица N*N. Но зато будет видна вся картина. Алгоритм элементарный, только данных много.
Даже простой БП может содержать больше 100 значений параметров. Проанализировать матрицу 100*100 человеку уже крайне тяжело. А многие реальные процессы могут содержать тысячи значений параметров.
Так что матрица заменить BPMN не может. Ведь с диаграммами в первую очередь работают люди, а они не могут воспринимать гигантские матрицы.
Разве что жить в них могут. :)))
Так что матрица заменить BPMN не может. Ведь с диаграммами в первую очередь работают люди, а они не могут воспринимать гигантские матрицы.
Разве что жить в них могут. :)))
100*100 человеку уже крайне тяжело
Вручную тяжело, а вот если автоматизировать, то быстро.
Даже матрица 10 000 * 10 000 будет содержать 100 000 000 клеток (100 млн) — для персонального компьютера это не предел. Даже в памяти легко поместится.
Так диаграммы и нужны в первую очередь для того, чтобы на них смотреть «вручную».
Описание бизнес процесса надо сначала придумать (создать), и только потом верифицировать, запускать на выполнение и т.п. И придумывают описание БП «вручную». Я допускаю, что есть люди, которые могут создать описание БП в виде матрицы 1000*1000. Но таких явно ОЧЕНЬ мало. А все остальные используют BPMN.
Описание бизнес процесса надо сначала придумать (создать), и только потом верифицировать, запускать на выполнение и т.п. И придумывают описание БП «вручную». Я допускаю, что есть люди, которые могут создать описание БП в виде матрицы 1000*1000. Но таких явно ОЧЕНЬ мало. А все остальные используют BPMN.
Логично был бы в этом примере принцип дизъюнкции, т.к. «договора ЮЛ с тарифом Стандарт» входят в оба множества, но все зависит от конкретного контекста.
Матричный подход напомнил мне сразу Decision Management — стандарта DMN 1.1, который активно используется внутри BPM процессов как Business Rule Task.
Матричный подход напомнил мне сразу Decision Management — стандарта DMN 1.1, который активно используется внутри BPM процессов как Business Rule Task.
Sign up to leave a comment.
Автоматизация бизнес-процессов или что такое «Сложность». Часть 1