Моделирование «возможности» и «способности»

К вопросу о моделировании понятия «возможности», а так же ряда других понятий, в инженерных моделерах вроде ArchiMate.

Как мы в конце концов определяем, что некая цель достигнута? Фиксируя некое феноменальное состояние, до этого отмаркированное, как «целевое», «должное», отличаемое от «насущного» до выполнения действия и неотличаемое от него в случае успеха. Сколь-нибудь сложные изменения, и тем более — стратегические изменения, включают в себя множественные такие состояния. По факту нужно отслеживать широкую феноменологичную картину мира. Разные подразделения и специалисты обычно отвечают за изменение отдельных частей этой картины, а архитекторы сводят её в компактные модели, снижая разнообразие состояний до уровня, когда оно может быть потреблено отдельным человеком в короткое время с небольшим усилием: чеклисты, диаграммы, таблицы и прочая.

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

«Возможность» в таком разрезе — это картина мира (или её десигнатор), которая понимается стейкхолдерами как достижимая с помощью имеющейся практики в данном бизнес контексте, и соответствующим образом маркированная в модели. Т.е. констатируются явно или неявно
(1) картина наличного состояния системы, часто неявно;
(2) картина целевого состояния, маркированная как «возможность» — явно;
(3) общий для первых двух контекст — ресурсные ограничения и целеполагание, позволяющие маркировать (2) — неявно;
(4) ресурсообеспеченная практика, переводящая систему из (1) в (2) в рамках (3) — неявно.

И лучше говорить не о 3D-картинах, а о 4D-сценариях. «Маркировки» нужны для управления картиной мира модельера-архитектора в процессе стратегирования, чтобы осуществлять навигацию в пространстве различных картин мира/сценариев, один из которых должна рано или поздно быть направлена на исполнение операторам, а качественная коммуникация остальных (невозможные, рискованные, желательные и пр.) должна привести к правильной параметризации первого.

«Невозможность» — это констатация отсутствия (4). «Способность» (capability), для которой я пока вообще не видел внятного определения, можно определить как возможность, привязанная к оператору (или классу). Т.е. «способность к Б = констатация наличия у оператора некоторой ресурсообеспеченной практики А для реализации сценария Б». Можно в таком же духе [рекурсивно] расписать и необходимость/need, и ограничение/constraint прочие концепты, приводя всё к относительно небольшому переносимому базису, собранному из исполняемых сущностей.

Правда, это далеко и от Essense, и от ArchiMate.
 
UPD 2018-03: Дискуссии в FB:
Концепты «возможности» и «способности» нам нужны для успешного планирования. Просто размещение боксиками на картинке малополезно, любые концепты можно как-то связать отношениями, и что дальше? Для планирования мы используем сценирование, и некоторые обобщённые сценарии наделяем модальностями, специальными атрибутами, позволяющими приоритезировать варианты реализации. Без этих маркировок успешное планирование невозможно. Когда мы разводим сценарии, действия/практики и модальные предикаты, алгоритм получить сильно проще.
Поэтому, «способность к Б» — это когда некоторый наличный у Н сценарий отмаркирован как имеющий шансы на успешное завершение, что обусловлено фактом, что например у Н есть ресурсы А или совокупность ресурсов и внешних факторов А.
Возможность — это можно определить, как положительная маркировка, обусловленная только состоянием системного окружения. Но, это вопросы дефиниций. Практический смысл конструирования аттенциональной структуры конструкций — иметь такие паттерны, которые позволяют удешевить планирование и деятельность. Просто больше онтологических схем тут может и не помочь.
 
Alexander Turkhanov «7.1 Definition of the Capability in P2M The capability in P2M refers to program and project managers’ a systemic set of practical
capability founded on P2M’s body of knowledge, practice experience and personal qualities of attitude and ethics, which are necessary for practice. Capability building is the process of integrating these three capability elements. The capability is embodied in individuals.»
 
Здесь способность связывается с конфигурацией актора, у которого должны быть «experience and personal qualities». Но здесь упоминается, но отбрасывается аспект «necessary for practice», то бишь нормирование первого относительно контекста деятельности.
Качества агента — это компетенция, а наличие сценария, когда компетенция решает целевую проблему — это способность. «А может пилить» — это не способность, это навык. «А может перепилить рельсу зубочисткой в условиях полярной ночи» — это способность, компетенция в системном окружении. Онтика «наличие рельсы в ночи» — констатация возможности для А реализовать способность.
«Возможность» я бы отнёс к конфигурации окружения, «компетенцию» — к конфигурации агента, а «способность» — к их пересечению.

Читайте также:

Добавить комментарий