Перед этим в качестве расширения этой метамодели (и можно подумать, получится ли это в соответствии с правилами расширения метамодели, прописанными в ISO 24744, или придется этот стандарт сходу нарушать) будет добавлена даже не метамодель BPMN 2 для инженерной группы описания (классические "бизнес-процессы"), а группу описаний обоснования выбора элементов метода для приведения в действие, предложенную Голдраттом в картах действий и результатов (http://praxos.ru/index.php/Карта_действий_и_результатов). Ибо внедрение каждого элемента нужно как-то мотивировать -- и поэтому в описание включать дополнительные элементы, относящиеся не ко времени исполнения метода, а ко времени убалтывания исполнителей и менеджеров на предмет необходимости выбора этого метода для приведения в действие. Речь идет о method (architecture) case, аналогичном requirement case, architecture case и вообще assurance case (http://ailev.livejournal.com/578461.html)
Это, кстати, ответ на вопрос годичной давности программы исследований PraxOS 2.2 (http://ailev.livejournal.com/640851.html) пункт "з) карты действий и результатов как формат записи процессов" -- с соответствующей переформулировкой вопроса: записывать нужно не "процессы", а разноуровневые модели метода (в том числе и его архитектуру), а карты действий и результатов добавляют необходимость совмещения записи архитектуры разбиения метода (method breakdown structure) и соответствующее обоснование этого разбиения.
Крайне важно отметить, что данный постинг демонстрирует основной заход PraxOS: представление/объяснение чрезвычайно широкого круга методов при помощи относительно компактного множества концепций. Так, традиционные для системной инженерии концепции архитектуры (в данном случае в ее простейшем варианте -- функционального разбиения) и обоснования (assurance case), примененные к такой системе, как "метод" позволяют понять и обсудить в том числе "карту действий и результатов" Голдратта. Заодно подтверждается, что (как это неоднократно замечалось многими академическими исследователями), что ничего у Голдратта идейно нового нет -- а гениальность его только в том, что он это "не новое" систематически и в ассортименте применяет в производственной практике.
Тем самым мы вернулись к необходимости инструмента (софта PraxOS), в котором можно работать с ситуационной инженерией методов в том стиле, в котором работает Голдратт (включая артефакт "карта действий и результатов", как отражающий группу описаний архитектуры метода и обоснования ее выбора). Очевидно, что это тот же самый софт универсального моделера (http://ailev.livejournal.com/757999.html), в котором можно обсуждать любые архитектуры/модели и их обоснования.
Теперь главным вопросом является получение такого моделера. Ибо дальше без моделера в стиле постингов в блоге уже мало что можно сделать.