Я бы делал что-нибудь в таком духе
1. сущность "Шаг"
2. Сущность "Исполнитель"
3. Сущность "Задание" - связь многие-ко-многим между Шагами и Исполнителями + еще какое-то количество дополнительных атрибутов, в частности, призанка "готово". То есть на каждом шаге N Исполнителям назначаются Задания. По-видимому, на Шаге N у исполнителя M может быть несколько заданий - для отображения частичного исполнения.
4. Отношение "многие-ко-многим" между Шагами - (предыдущий шаг, последующий шаг, тип "and/or"). То есть шаг 1 может перейти либо в шаг 2, либо в шаг 3, а по окончании шага 2 начинаются одновременно шаги 4, 5 и 6.
5.(?) Условия для начала шага - находятся в отношении N:1 к Шагам. (вот тут надо анализировать, возможно, можно обойтись без условий, одними только заданиями. Потому что иначе возникают вопросы типа "все задания предыдущего шага исполнены, условия для текущего не выполнены. Кто виноват?". Нужны ли условия - это, по уму, вопрос к Вашим бизнес-аналитикам).

proposed amendment
объект - воздействие - исполнитель

Имхо так можно описывать лишь произошедшие обработки, а не правила обработок.
Как, скажем, планируется описать необходимость параллельных воздействий?
Циклическую обработку?
ССылку в Шаге на рабочий обьект сделать можно, это верно (хотя и зависит от того, ак описаны в системе эти самые рабочие обьекты). Хотя... Вот, скажем, граф процесса "Пускание мыльных пузырей" - какой обьект тут будет рабочим (родительским)?

Дмитрий16
А можно чуть подробнее - какой смысл вкладывается в понятие Шаг

Шаг - это некая последовательность действий, в результате который описываемый процесс
переходит в принципиально другое состояние - где-то так.

Подумал еще - да, условия все-таки необходимы, причем отношение 1:N у них будет не с Шагами,
а с Переходами между Шагами- то есть к каждому Переходу может быть привязано n условий.

Я пока не вижу смысла в выделении отдельной сущности "состояние" - для чего она Вам необходима?
Далее - имхо условия могут быть шире, чем "ссылка на предыдущее состояние с процентом выполнения", и зависеть от совершенно внешних от процесса вещей.
Вот, скажем, уже упоминавшийся процесс "Выдувание мыльных пузырей" :)
в моей схеме он будет состоять из 2-х шагов
А. "Подготовка" (с кучей заданий "приготовление раствора", "добывание трубочки", etc). Если выяснится, что задания зависят друг от друга - нужно будет его разбить на подшаги.
Б. "Выдувание пузыря" (по-видимому, с одним заданием "выдувание пузыря", хотя это зависит от требуемой детализации)
и 2-х переходов
1. из А в Б, безусловный (или с псевдоусловем "выполнение всех заданий предыдущего шага" )
2. Из Б в Б, с условием "нам еще не надоело?" :)

Как это будет выглядеть в Вашей схеме?

В Вашей схеме нет цикличности, каковая присутствует в процессе - это имхо нехорошо.
И "всех пузырей" - это как? Мы изначально не знаем, сколько пузырей нам нужно, мы должны их делать, пока не случится специальное событие "нам надоело". Я про это и говорил - не все условия можно выразить через предыдущие шаги.
Это не такой уж высосанный из пальца пример, условия "от забора до обеда" в реальной практике встречаются нередко. Навскидку - работа городского транспорта.

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

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