DRAKON.SU

Есть нотация ЕРС (Event-Driven Process Chain), которая давно и хорошо формализует бизнес-процессы.
Хотелось бы понять, что можно заимствовать из Дракона чтобы улучшить нотацию для формализации бизнес-процессов. Справа показаны блоки - заменители Дракона.
Из того, что нашел в
Иконы и макроиконы языка ДРАКОН. 2020 год https://forum.drakon.su/viewtopic.php?f=224&t=6765

Пока из таких заимствований вижу только выделение в «левый ствол» основного сценария процесса (в ЕРС альтернативные ветки рисуются симметрично). Однако и это сомнительно, например, когда оба варианта являются равнозначными (нельзя определить, когда одна ветка основная (без ошибок, т.е. «да»), а вторая «обработка ошибок» («нет»).
Как будет выглядеть на Драконе представленный алгоритм (прилагаю)? На схему добавил пояснения про WorkFlow, DocFlow, Блок атрибутов (это вариант ЕРС с выделенными зонами WorkFlow и DocFlow, т.е. документы \ материалы всегда рисуются справа от функции).
Дополнительно прикладываю пояснение к окружению функции ЕРС.
Если на Драконе не получится также хорошо визуализировать логику бизнес-процессов как в ЕРС, то почему бы ИТ-инструментам Дракона параллельно не поддержать такую простую нотацию как ЕРС?
Полагаю, что если столько задействовать энергии (сколько тут посвящено Дракону) в VAD и EPC (структурные схемы, типа орг-диаграмм, - не в счет, - они простые), то давно был бы уже отечественный ARIS.

Событийная цепочка процессов

Материал из Википедии — свободной энциклопедии

Пример EPC-диаграммы (на немецком).


Событийная цепочка процессов (EPC-диаграмма, англ. event-driven process chain) — тип блок-схемы, используемой для бизнес-моделирования. EPC может быть использована для настройки системы планирования ресурсов предприятия (ERP),[1] и для улучшений бизнес-процессов.

Описание

Организации используют EPC-диаграммы для планирования потоков работ бизнес-процессов. Существует ряд инструментов для создания EPC-диаграмм, некоторые из этих средств поддерживают инструментонезависимый формат обмена данными EPC — язык разметки EPML.

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

EPC-метод был разработан Августом-Вильгельмом Шеером в рамках работ над созданием ARIS в начале 1990-х годов[2]. Используется многими организациями для моделирования, анализа и реорганизации бизнес-процессов.

Элементы событийных цепочек процессов
Elements of an Event-driven Process Chain.svg

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

Примеры событий: «договор подписан», «требование зафиксировано», «материал на складе». В EPC график событий представлен в виде шестиугольника. EPC-диаграммы должны как начаться с события, так и заканчиваются событием.

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

Организационная единица — должность в организации (например, «старший мастер») или подразделение организации (например, «отдел закупок»), элемент, которому может быть поручено выполнение функции.

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

Примерами являются «материал», «заказ», изображается в виде прямоугольника.

Логический соединитель — элемент управления в диаграмме, определяющий ветвление потока работ в зависимости от завершения выполнения функции или возникновения событий.
Если функция F1 завершилось, то произойдет либо событие E1, либо событие E2
Если произошло либо событие E1, либо событие E2, тогда начинается функция F1

Логические взаимосвязи — элементы управления, отвечающие за сочленение потоков — конъюнкция, дизъюнкция или строгая дизъюнкция.

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

Поток информации — соединение функции и входящих и исходящих данных, с которых функция считывает изменения или сама их вносит.

Назначение организационный единицы — связь между организационной единицей и функцией, за которую она ответственна.

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

Примечания

Bart-Jan Hommes (2004). The Evaluation of Business Process Modeling Techniques. TU Delft. p.137.
а.-З. Scheer (2002). «ARIS. Vom Geschäftsprozess zum Anwendungssystem». Springer. стр.20.

https://bit.ly/3IFuOD1

Событийная цепочка процесса

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

В модели ЕРС отражается последовательность, т.е. цепочка событий и функциональных шагов (операций, функций), которые в совокупности решают определенную задачу.

Опционально в моделях могут быть описаны исполнители, документы, ИТ-системы, которые необходимы для реализации каждого шага цепочки, а также добавлены ограничения по времени, стоимости, качеству и т.д., налагаемые на отдельные функции из цепочки.

Модель ЕРС является наиболее информативной и удобной при описании детальных бизнес-процессов компании.

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

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

Объекты, наиболее используемые в диаграммах ЕРС, и их названия приведены в табл. 4.1, связи между объектами представлены в табл. 4.2.

Далее см. здесь

"Пример EPC-диаграммы (на немецком).", т.е. EPK Teil1 - пример наиболее уродливого ЕРС. Примеров таких конечно много.
Это связано с большой "вольностью" классической ЕРС (eEPC), поэтому и говорю о ее модернизации. Если что, рисую процессы в ЕРС с 2000.

Привел пример "структурированной" по WorkFlow \ DocFlow EPC, назовем ее ЕРС-D. Пример "структурирования" функции и расположения элементов ее детализации (см. ранее приложенный файл): Process-as-Event-driven-Process-Chain-EPC.png
Предлагаю отталкиваться от приведенного примера алгоритма: Как будет выглядеть схема в Драконе?
На моей схеме алгоритма указаны: алгоритм процесса, пояснения по зонам Work\DocFlow, пояснения - аналогичные иконы Дракона. Интересует схема "алгоритма процесса" в Драконе. Пояснения даны лишь как дополнения, а не как элементы процесса.

Получается, что воспроизвести мою схему простенького процесса (без потери информации) на Драконе - не простая задача.
Если что: как это делается для ЕРС. Человек не знающий нотации, ставит бесплатный ARIS Express отсюда (регистрацию требуют, редиски):
https://www.ariscommunity.com/aris-express
Далее выбираем ЕРС и кнопка Smart Disigner, выползает табличка. Заполняем табличку и созерцаем автоматом построенную схему процесса в ЕРС.
Видео тут: https://www.ariscommunity.com/videos/ho ... gn-process
К сожалению, ARIS Smart Disigner не строит ЕРС, структурированные по Work\DocFlow.

ARIS Smart Disigner поддерживает много нотаций, но он закрытый и много чего еще умеет.
Примерно такое же было бы полезно и для Дракона. Однако, куда лучше сделать универсальный открытый Smart Disigner (Open Source), в который мы бы смогли добавлять любые нотации, включая Драконовкую (ну и конечно структурированную ЕРС).

Дмитрий, вы правы. Потому что мы не знакомы с EPC.
Дмитрий, у вас большой опыт работы с EPC. Вы этим занимаетесь с 1990 года, ваш опыт — 22 года интенсивной работы.

1. Вот бесплатный редактор ДРАКОНа https://drakonhub.com/ru/

2. Вот мой имейл vdp2007@bk.ru
Пришлите мне письмо и я вам пришлю пояснения

Если бы я знал, что именно рисовать (какие квадратики), то я бы нарисовал без всякого специального редактора, например, сразу в drawio или в visio (или рукой на салфетке и приложил бы фотку). Но проблема не "в чем рисовать", а "что рисовать".
Что рисовать, просьба подсказать тут: и другим будет интересно. Я показал автозамену в Драконе некоторым объектам ЕРС и показал это прямо в схеме примера (слева). Схема предложенного процесса (пункт выдачи) очень простая.

Может не нужно пытаться воспроизвести схему процесса в Драконе (если это так сложно для такой простой задачке) и признать, что ЕРС для бизнес-процессов явно лучше и сконцентрироваться на ее совершенствовании? Т.е. сразу перейти к вопросу как улучшить ЕРС, в том числе, что-то позаимствовав из Дракона.
Только сразу хочу сказать, что много разных типов квадратиков (иконок, типов объектов) - это плохо, т.е. не хотелось бы наращивать номенклатуру типов объектов. Тут важно понимать, что есть типы, а есть подтипы, например, слева от функции может стоять только два - три принципиально разных тапа объекта, например, материальный продукт (образующий поток материалов) и документ (DocFlow), а сами они уже могут иметь много подтипов, например, бумажный или электронный документ (отражаются хоть и разными картинками-иконками, но по сути однотипны и различие картинок можно свести к минимуму), но это не расширение номенклатуры.

Здесь возникает первое расхождение в идеологии.

В чем суть?

Дракон-схему можно нарисовать в drawio или в visio (или рукой на салфетке), но есть недостаток — при ручном рисовании возможны ошибки. В частности, возможны ошибки при ручном рисовании соединительных линий между элементами.

Чтобы исключить ошибки (или уменьшить их вероятность) в Драконе не рекомендуется (запрещено) пользоваться универсальными инструментами (drawio, visio, yEd и пр.) и рисовать вручную.

При создании дракон-алгоритмов необходимо пользоваться только специализированными инструментами, которые называются ДРАКОН-конструктор. Наиболее простой для освоения ДРАКОН-конструктор — DrakonHub https://drakonhub.com/ru/

ДРАКОН-конструктор автоматически проводит все соединительные линии между графическими фигурами.
При этом скорость рисования дракон-схемы значительно повышается.

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

Конкретизируйте, пожалуйста, вопрос, потому что по ходу диалога вы обсуждаете на мой взгляд разные вещи.
Вы хотите узнать:
А) как усовершенствовать ЕРС-схемы с помощью принципов построения дракон-схем?
Б) могут ли дракон-схемы заменить ЕРС-схемы?
В) можно ли ЕРС-схему без потерь информации перечертить в дракон-схему?

Касаемо вопроса А я бы задал встречный вопрос: а действительно ли ЕРС-схемы неэргономичны? Так или иначе, это уже сформированная и утверждённая концепция, имеющая и плюсы, и минусы, как и любые другие. Может Вы хотели бы создать гибрид этих двух подходов (ЕРС-Дракон)?

На вопрос Б ответ "да". Вот я нашёл пример дракон-схем для описания бизнес-процессов https://infostart.ru/1c/articles/504530/. В смысле достижения цели (а цель этого черчения - описать бизнес-процесс) подойдёт любое средство описания бизнес-процессов: и ДРАКОН, и BPMN, и IDEF0. Просто далее мы умалчиваем, на что в каждом инструменте делается упор.
Вышли погулять математик, художник и поэт. Забрались на холм, а с вершины холма прекрасно видно поле, на котором пасутся коровы.
Математик увидел координатную сеть, с коровами-точками, расставленными по ней.
Художник увидел интересное сочетание цветов - светло-зелёный цвет травы луга и мёртво-обесцвеченные пятна в виде коров.
Поэт, взглянув на это, почувствовал безмятежность и быстро ассоциировал с этим такие строки "Как корова на лугу / Щиплет медленно траву".
Каждый из них может описать поле, но по-своему, специфично.

Ответ на вопрос В более развёрнутый и, быть может, его всё-таки не надо давать. Но у меня есть несколько идей, как ЕРС-схему ассоциировать с дракон-схемой. Всё равно бы для этого я прислал отдельное сообщение в тему.

P.S. Мне было приятно, что в первом сообщении Вы, автор темы, использовали до боли знакомый комментарий на зелёном фоне. Очень приятно

Б) могут ли дракон-схемы заменить ЕРС-схемы?
В) можно ли ЕРС-схему без потерь информации перечертить в дракон-схему?

Это одинаковые условия: если В) невозможно, то невозможно и Б).
Мы говорим про однозначное исполнение алгоритма процесса. На одинаковом уровне детализации две схемы ЕРС и Дракона должны давать единые результаты. Из схемы должно быть понятно, кто сделал каждую операцию процесса, какие входы и выходы у каждой операции (функции), какие инструменты применялись. Естественно вся логика ветвления (выполнения действий через И\ИЛИ\ЛИБО).
При этом должна быть возможность однозначно формализовать Любой процесс (бизнес-процесс). "Однозначно" подразумевает то, что все читатели применив правила нотации однозначно прочтут схему: и художник и математик.

> Касаемо вопроса А я бы задал встречный вопрос: а действительно ли ЕРС-схемы неэргономичны?
ЕРС хороша, но и она требует модернизации, как и все остальное.
Уже выделение в отдельные зоны WorkFlow\DocFlow - на мой взгляд, значимое совершенствование.

Поясните, в чем проблема повторить приведенный мной простейший пример ЕРС на Драконе? Каких элементов нет в Драконе?

Дмитрий, сегодня постараюсь выложить вашу схему на ДРАКОНе (первое приближение).

Да, Вы правы. Возможно, я в Б вкладывал больший смысл.
Здесь тоже с моей стороны неудачный пример. Давайте пример с иностранными языками. Три полиглота - знают английский, немецкий и французский. Каждый говорит на том языке, который ему ближе, роднее, но и другие языки он понять может. Опять же повторюсь, что с помощью любой нотации можно описывать бизнес-процессы, но у каждой своя специфика. И я даже больше говорю о процессе преобразования идеи в схему, чем о донесении схемы другим людям.



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


1) В дракон-схемах нет блока для явного указания исполнителя (org. unit). Первый вариант решения - комментарий, второй - использование иконы "Полка", если, конечно, алгоритм небольшой, если вы не устанете, и если это будет выглядеть лаконично. Кстати, на комментарии не обязательно смотреть как на что-то неполноценное...их частоту и важность устанавливает чертёжник. Если чертёжник - мастер своего дела и хорошо знает предметную область, то и комментарии у него будут здравыми.
2) Для входных данных в дракон-схемах есть икона "формальные параметры". Но в дракон-схемах нет блока для явного указания выходных данных. На мой взгляд, их можно:
- писать в иконе "Конец"
- оставлять в комментарии либо в самом начале алгоритма, либо в самом конце
3) То есть понятие "Функция" в ЕРС-схемах соответствует в целом понятию "алгоритм" и, соответственно, отдельной дракон-схеме, вызываемой в конструируемом процессе иконой "вставка". ... Всё-таки вставка. Было бы это элементарное действие, был бы простой блок "действие" (прямоугольник обычный). Но тут есть сопутствующие данные, которые подсказывают, что это целая процедура. У простого действия всё-таки понятно сразу, кто исполнитель, что подаётся на вход и что на выход (например, включить микроволновку).
4) Понятие "Событие" в ЕРС-схемах я бы интерпретировал в трёх смыслах. С одной стороны, событие - это наступающее явление, новый смысловой блок процесса. Поэтому "событие" можно отразить в виде "ветки" силуэта. С другой стороны, событие - ярый (и кажется единственный) участник логических операций, что делает его связанным с "развилкой". А с ещё одной стороны, событие - это назначение какого-то статуса ("началась дневная смена"), поэтому опять же никто не отменял комментарии.
Итого, если процесс участвует в операциях xor, or, and, то он будет в развилке. Иначе если "событий" в схеме, не участвующих в логических операциях, больше одного - они будут ветками. А если такое событие всего одно - пусть остаётся комментарием.
5) Владимир Паронджанов сделал ссылку на хороший источник с информацией по ЕРС-схемам, но кстати не добавил самое главное - это те самые таблицы 4.1 и 4.2, на которых цитирование заканчивается. В них кратко показано самое важное. Как я прочёл в ЕРС-схемах возможны три логические операции - или, и, исключающее или. Я нашёл на форуме попытку сделать исключающее или viewtopic.php?f=162&t=6122&hilit=%D0%98%D1%81%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D1%8E%D1%89%D0%B5%D0%B5+%D0%B8%D0%BB%D0%B8 . Обсуждение этой формы было спорным и действительно, для Вас наверное эта форма сильно громоздка. Вы можете использовать просто условие "Event #2 xor Event #3" или "либо Событие 2, либо Событие 3", но вот автор бы с Вами не согласился и сказал бы, что это непонятно. Я добавил в схему видение Владимира Паронджанова, хотя думаю, что для учёных людей можно применять и короткие условия (исключительный случай, так сказать).

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

Alex_st_Tomsk, те схемы, которые мы рисуем, должны иметь четкое и однозначное представление. Все, что нарисовано должно ложиться в Linked Data (LD), т.е. триплеты.
Применительно к ЕРС, показал тут:
https://habr.com/ru/post/708026/comment ... t_25053928
Т.е. мы не можем, и роль и еще что-то отразить как "универсальный комментарий", т.к. роль - это определённый тип объекта и при анализе схемы, мы должны иметь возможность "автоматом" (без смыслового анализа текста комментария) сказать, например, Водитель участвует в таких - то процессах. Т.е. в триплетах сделать сортировку по объекта типа "Роль" со значением "Водитель". "Картинки цветные" - это всего лишь графическое обозначение логических триплетов (RDF), т.е. под "капотом" картинок ЕРС лежит приведенная выше LD-логика.
В итоге: несмотря на нотацию, по одному и тому же процессу (с одинаковым уровнем детализации), мы должны получить одинаковые триплеты: семантические отношения объектов, приведенных на схеме, включая события, функции и др.
Такой подход хорошо виден при автопостроении схемы процесса из скрипта: dot (graphviz) drawio (import csv, dot, mermaid) и др.

По заданию Дмитрия выкладываю бизнес-процесс (алгоритм)
«Подготовка товара и отправка клиенту»
на языке ДРАКОН.


Примечания

1. Показана последовательность действий.
2. Показаны акторы: водитель и оператор.
3. Удалена за ненадобностью операция XOR. В Драконе операции конъюнкция, дизъюнкция и инверсия (отрицание) строго выполняются, но соответствующие знаки логических операций становятся ненужными.

Последнюю (самую нижнюю) фигуру шестигранник я не понял, Поэтому она не нарисована.
Остальное не показано. Это первое приближение.

В ЕРС-D также нет подобных кружков, но стрелки между объектами включают подпись XOR\OR\AND.


Она ничем не отличается от предыдущей. Только нужно нарисовать одну стрелку и будет классический Event EPC, полагаю, что не противоречащий Дракону.
Смысл Event Дракона в том, что он имеет два фильтра, а классический Event EPC - один фильтр, т.е. у него только нога "ДА". Это нормально, точнее более логично чем классический (условия в блок-схеме) выбор решения. На этой концепции можно считать и построена ЕРС, т.е. название этой нотации - "цепь процессов, управляемая событиями".
Другими словами в ЕРС - как и любом фильтре с одним выходом, все "ДА" проходят фильтр, а все нет - не проходят, т.е. фактически возвращаются в начало фильтра.
Т.е. Фильтр ЕРС всегда замыкает ветку нет на начало фильтра, что просто не показывается, но подразумевается (фильтр не прошел, значит иди в начало фильтра). Непонятно, зачем показывать эту ветку "нет", в Условиях (читай фильтрах) Дракона, когда "все что нет" - это возврат в начало условия. При этом в Драконе Условие не потребует вопросительного знака, а лишь утвердительное: "Товар в наличии" ( "Товар в наличии" = "ДА").
"Товар не поступил" - почему нельзя в Драконе показать ровно также, как "Товар в наличии" и параллельно, при этом сделав ветку "ДА" на конец схемы (ветку "нет", замкнув также в начало шестиугольника)?

Каждый процесс генерит не только продукты (продукты процесса), но и результирующие события. Этим событием (Клиент оповещен) мы формализуем "событийный результат процесса".
Т.е. можно считать, что с событиями и WorkFlow заменимость EPC - Дракон выявлена (с "исполнителем" - пока не совсем "гладко", но хоть "как то").
Осталось понять, что делать с Инструментами и DocFlow.

Логические связки OR\AND в ДРАКОНе не нужны. Они изображаются визуальными средствами.
Логика в ДРАКОНе описана здесь, стр. 124–184.

Как удалить логические связки?
Ответ показан на рисунке

По замечаниям Дмитрия в дракон-схему внесены два исправления:

1. Внесена вторая икона Комментарий "Товар в наличии" (вообще-то она не нужна, получается масло масляное; но она не вредит; пусть будет).

2. В самом низу добавлен шестиугольник (икона Вопрос) в виде цикла Стрелка с надписью "Клиент оповещен о готовности пункта выдать товар?".

В ДРАКОНе термин "подразумевается" в связи с иконой Вопрос не допустим.
Оба выхода иконы Вопрос (Да и Нет) должны быть указаны явно.

Такая ситуация в ДРАКОНе не допустима (разрушительна).
Должны быть показаны обе "ноги". Одна "нога" разрушает логику ДРАКОНа, так как вводит неоднозначность или путаницу.

EPC не отличается от любой обычной блочной нотации. Даже дорожки заимствует из BPMN. Зачем скрещивать ее с ДРАКОНом когда я на ДРАКОНе все напишу на всех логических уровнях и для всех стейкхолдеров проекта. Практическое применение этих моделей очень сомнительно. Логику не проверяет, не компактно, куча пересечений. Сложный бизнес - процесс в такой нотации превращается в нечитаемый клубок. Но если вам нравится EPC - пожалуйста.

Сложный - потом. Предложенный в начале поста очень простой процесс - нарисуйте в Драконе.

ЕРС заимствует что-то у BPMN? Вы представляете какая у них разница в дате рождения? Как старожил BPM (ЕРС) может что-то позаимствовать у еще не рожденного тогда BPMN (2004 v1.0)?