Моделирование «возможности» и «способности»
К вопросу о моделировании понятия «возможности», а так же ряда других понятий, в инженерных моделерах вроде ArchiMate.
Как мы в конце концов определяем, что некая цель достигнута? Фиксируя некое феноменальное состояние, до этого отмаркированное, как «целевое», «должное», отличаемое от «насущного» до выполнения действия и неотличаемое от него в случае успеха. Сколь-нибудь сложные изменения, и тем более — стратегические изменения, включают в себя множественные такие состояния. По факту нужно отслеживать широкую феноменологичную картину мира. Разные подразделения и специалисты обычно отвечают за изменение отдельных частей этой картины, а архитекторы сводят её в компактные модели, снижая разнообразие состояний до уровня, когда оно может быть потреблено отдельным человеком в короткое время с небольшим усилием: чеклисты, диаграммы, таблицы и прочая.
Стратегическое моделирование выполняется человеком, и потому мы вынуждены использовать компактные представления, нотацию типа той, что в ArchiMate. В ней мы даём короткие метки большим картинам мира, чтобы запихать их в нормально воспринимаемую модель. Но мы должны всегда иметь ввиду, что за этим стоят большие количества состояний, каждое из которых для изменения или достижения требует отдельного действия от соответствующего оператора.
«Возможность» в таком разрезе — это картина мира (или её десигнатор), которая понимается стейкхолдерами как достижимая с помощью имеющейся практики в данном бизнес контексте, и соответствующим образом маркированная в модели. Т.е. констатируются явно или неявно
Как мы в конце концов определяем, что некая цель достигнута? Фиксируя некое феноменальное состояние, до этого отмаркированное, как «целевое», «должное», отличаемое от «насущного» до выполнения действия и неотличаемое от него в случае успеха. Сколь-нибудь сложные изменения, и тем более — стратегические изменения, включают в себя множественные такие состояния. По факту нужно отслеживать широкую феноменологичную картину мира. Разные подразделения и специалисты обычно отвечают за изменение отдельных частей этой картины, а архитекторы сводят её в компактные модели, снижая разнообразие состояний до уровня, когда оно может быть потреблено отдельным человеком в короткое время с небольшим усилием: чеклисты, диаграммы, таблицы и прочая.
Стратегическое моделирование выполняется человеком, и потому мы вынуждены использовать компактные представления, нотацию типа той, что в ArchiMate. В ней мы даём короткие метки большим картинам мира, чтобы запихать их в нормально воспринимаемую модель. Но мы должны всегда иметь ввиду, что за этим стоят большие количества состояний, каждое из которых для изменения или достижения требует отдельного действия от соответствующего оператора.
«Возможность» в таком разрезе — это картина мира (или её десигнатор), которая понимается стейкхолдерами как достижимая с помощью имеющейся практики в данном бизнес контексте, и соответствующим образом маркированная в модели. Т.е. констатируются явно или неявно
(1) картина наличного состояния системы, часто неявно;
(2) картина целевого состояния, маркированная как «возможность» — явно;
(3) общий для первых двух контекст — ресурсные ограничения и целеполагание, позволяющие маркировать (2) — неявно;
(4) ресурсообеспеченная практика, переводящая систему из (1) в (2) в рамках (3) — неявно.
И лучше говорить не о 3D-картинах, а о 4D-сценариях. «Маркировки» нужны для управления картиной мира модельера-архитектора в процессе стратегирования, чтобы осуществлять навигацию в пространстве различных картин мира/сценариев, один из которых должна рано или поздно быть направлена на исполнение операторам, а качественная коммуникация остальных (невозможные, рискованные, желательные и пр.) должна привести к правильной параметризации первого.
«Невозможность» — это констатация отсутствия (4). «Способность» (capability), для которой я пока вообще не видел внятного определения, можно определить как возможность, привязанная к оператору (или классу). Т.е. «способность к Б = констатация наличия у оператора некоторой ресурсообеспеченной практики А для реализации сценария Б». Можно в таком же духе [рекурсивно] расписать и необходимость/need, и ограничение/constraint прочие концепты, приводя всё к относительно небольшому переносимому базису, собранному из исполняемых сущностей.
Правда, это далеко и от Essense, и от ArchiMate.
UPD 2018-03:
Концепты «возможности» и «способности» нам нужны для успешного планирования. Просто размещение боксиками на картинке малополезно, любые концепты можно как-то связать отношениями, и что дальше? Для планирования мы используем сценирование, и некоторые обобщённые сценарии наделяем модальностями, специальными атрибутами, позволяющими приоритезировать варианты реализации. Без этих маркировок успешное планирование невозможно. Когда мы разводим сценарии, действия/практики и модальные предикаты, алгоритм получить сильно проще.
Поэтому, «способность к Б» — это когда некоторый наличный у Н сценарий отмаркирован как имеющий шансы на успешное завершение, что обусловлено фактом, что например у Н есть ресурсы А или совокупность ресурсов и внешних факторов А.
Возможность — это можно определить, как положительная маркировка, обусловленная только состоянием системного окружения. Но, это вопросы дефиниций. Практический смысл конструирования аттенциональной структуры конструкций — иметь такие паттерны, которые позволяют удешевить планирование и деятельность. Просто больше онтологических схем тут может и не помочь.
Поэтому, «способность к Б» — это когда некоторый наличный у Н сценарий отмаркирован как имеющий шансы на успешное завершение, что обусловлено фактом, что например у Н есть ресурсы А или совокупность ресурсов и внешних факторов А.
Возможность — это можно определить, как положительная маркировка, обусловленная только состоянием системного окружения. Но, это вопросы дефиниций. Практический смысл конструирования аттенциональной структуры конструкций — иметь такие паттерны, которые позволяют удешевить планирование и деятельность. Просто больше онтологических схем тут может и не помочь.
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», то бишь нормирование первого относительно контекста деятельности.
Качества агента — это компетенция, а наличие сценария, когда компетенция решает целевую проблему — это способность. «А может пилить» — это не способность, это навык. «А может перепилить рельсу зубочисткой в условиях полярной ночи» — это способность, компетенция в системном окружении. Онтика «наличие рельсы в ночи» — констатация возможности для А реализовать способность.
Качества агента — это компетенция, а наличие сценария, когда компетенция решает целевую проблему — это способность. «А может пилить» — это не способность, это навык. «А может перепилить рельсу зубочисткой в условиях полярной ночи» — это способность, компетенция в системном окружении. Онтика «наличие рельсы в ночи» — констатация возможности для А реализовать способность.
«Возможность» я бы отнёс к конфигурации окружения, «компетенцию» — к конфигурации агента, а «способность» — к их пересечению.
UPD 2018-07-24:
https://web.facebook.com/ivan.padabed/posts/2009736545725217?comment_id=2010096275689244&reply_comment_id=2011392478892957
https://web.facebook.com/ivan.padabed/posts/2009736545725217?comment_id=2010096275689244&reply_comment_id=2011392478892957
Если несколько расширить контекст использования понятий и сами концептуализации, то кмк, можно business function/практику и capability/оргспособность представить как специализации «практики» по параметру деонтической модальности.
Для некой организационной окрестности capability — это интерфейс практики, законтрактованной в модальности «возможно», что в разнообразной бизнес-среде позволяет создавать адаптивные производственные цепочки/value chains.
Business function в этом паттерне — обеспечивающая практика в среде предприятия, где разнообразие целенаправленно уменьшается для повышения устойчивости и управляемости, и контракты тут более жёсткие. Интерфейс маркируется в модальности «обязательно». Нарушение функционального контракта — исключительная ситуация.
В больших корпорациях с богатым внутренним миром, уже и внутренний ландшафт становится вариативен. Берём тот же паттерн, меняем масштаб окрестности и получаем уже caps более мелкого масштаба, где границей контрактования оргспособности является уже не бизнес-граница корпорации, а его неким образом выделяемой части.
Для некой организационной окрестности capability — это интерфейс практики, законтрактованной в модальности «возможно», что в разнообразной бизнес-среде позволяет создавать адаптивные производственные цепочки/value chains.
Business function в этом паттерне — обеспечивающая практика в среде предприятия, где разнообразие целенаправленно уменьшается для повышения устойчивости и управляемости, и контракты тут более жёсткие. Интерфейс маркируется в модальности «обязательно». Нарушение функционального контракта — исключительная ситуация.
В больших корпорациях с богатым внутренним миром, уже и внутренний ландшафт становится вариативен. Берём тот же паттерн, меняем масштаб окрестности и получаем уже caps более мелкого масштаба, где границей контрактования оргспособности является уже не бизнес-граница корпорации, а его неким образом выделяемой части.
