vrr/doc
2
0
Fork 0
mirror of https://github.com/bpmbpm/doc.git synced 2026-04-30 20:40:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
doc/METAMODEL/PROCESS/capability.md
Dmitry 5ffa10c4f2
Update capability.md
2025-10-29 20:07:33 +03:00

6.5 KiB
Raw Blame History

1 Capability MetaModel

... в работе

2 about the Capability

2.1 Eugene_Demochko

Комент к Карта бизнес-способностей. Просвечиваем корпоративные боли и лечим их архитектурно: эволюция бизнес-аналитика

Вижу две проблемы

1 Простые вещи делаем сложными и запутанными

1.1 Процесс как «черный ящик»
Capability – возможность, способность и т.п. Это тот же самый процесс, но «абстрактный», т.е. абстракция процесса. «Черный квадрат архитектора» или процесс – как «черный ящик». Когда мы говорим «процесс», то подразумеваем, что знаем как он устроен внутри (как реализован, его подпроцессы и т.п.).
Когда мы не знаем как он устроен или хотим скрыть его реализацию, то говорим «абстрактный процесс», например, абстрактный \ условный процесс «Передача файла» - где эта передача не конкретизируется и может быть реализована 20-тью способами и нам не так важно какими.
Часть приводят вектор: детальный процесс -> верхнеуровневый процесс -> Capability (возможность, способность), но выделить отдельной сущностью абстракцию процесса (абстрактный \ условный процесс \ операция) мы можем на любом уровне декомпозиции (дерева процессов), т.е. не обязательно на «верхушке» дерева процессов.

Не так давно Capability и способность vs возможность, обсуждались на ТГ ABPMP и М. Смирнова, ссылки см. https://github.com/bpmbpm/doc/tree/main/EA/GOST/version2#2-business-capabilities
У В. Копченкова на эту тему (Способность vs Возможность & Способность vs Процесс) доклад pdf, но на мой взгляд – это скорее запутывает и отдаляет нас от «прозрачной математики в EA \ BPM».

1.2 Продукт
Если нам не важна реализация процесса и мы говорим про «условный процесс», то что тогда важно? Результат процесса – Продукт. При абстрагировании «процесса» мы фактически говорим про «условный его продукт». Если нам нужно «как-то перевозить по земле 7 человек», но подразумеваем некий семиместный автомобиль с неважно каким двигателем. Таким образом, Capability становится «два в одном флаконе» - условный процесс + условный продукт без детализации конкретной реализации.

2 Сложные вещи не пытаемся строго формализовать (формальная семантика, математизация),

Поэтому построить точную МетаМодель EA \ BPM пока не получается
2.1 МетаМодель процесса
На рис. Метамодель компонентов оценки и их связей в нотации ArchiMate (пример)
ris
вместо Бизнес-способность (Capability) должна быть надпись Продукт.
Процесс «реализует» (имеет на выходе) продукт (выход процесса \ операции \ функции).

2.2 Общая проблема – отсутствие четкого формализма в описаниях EA \ BPM, типа «теория процессов» / «теория архитектуры» или «теория организации» такого уровня как «теория множеств» или «теория графов». ArchiMate \ TOGAF – имеют низкую выразительность и точность (низкое качество проработки).
Вопросу онтологии процесса (его метамодели, его математическому описанию) не уделяется должного внимания.
Конечно его описание будет включать математическое описание его составных частей, прежде всего workflow \ docflow (свои метаМодели \ онтологии). Пока для EA \ BPM нет даже математического \ онтологического каркаса. Для начала попробую шееровский EPC – концепт представить через Теорию множеств.

Мысли (механика «процесса», онтология, метаМодель, математическая запись и т.п.) собираю тут:

3 Doc