Модель концептов первой главы системного развития

Новая грамотность
1

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


Человек может предположить: "Ну, возможно, практика состоит из умений что-то делать и каких-то теоретических знаний. Практика – это апробация теории, а в результате апробации практика или теория должны измениться и прийти в соответствие друг другу". И все вроде бы правильно, пока мы не попытаемся прокоммуницировать с людьми и выяснить что они на самом деле имели ввиду под своими словами.


Может выясниться любопытная вещь. Кто-то под практикой понимает набор специализированных техник (может быть терминологическим синонимом); кто-то только открывает для себя сущность "практики" и еще не сформировал никакого понимания для себя; у кого-то понимание этой сущности может совпасть с нашим. Однако такие модели крайне полезны в быту и работе. Прежде чем проектировать ИТ-систему, прорабатывать новый проект или изучать дисциплину, бывает небесполезно построить "метамодель" предметной области.
Далее приведено мое видение метамодели сущностей из первой главы учебника по системному саморазвитию.

1.-metamodel
1.-metamodel1024×695 40.9 KB
Рисунок 1. Модель "сущность-связь"

Здесь видно, как практика связана с дисциплиной и технологией. Рабочий продукт появляется в результате действий практик и это является одним из результатов рабочего проекта. Рабочий проект имеет связи с объектами "прикладных знаний", "ролевого мастерства" и "трансдисциплины"

Описание модели и выводы

Каждая связь подписывается типом и имеет "силу отношения". Связь с перпендикулярной по отношению к ней самой, чертой обозначает 1 экземпляр, а с "лапкой" на конце – множественное отношение.

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


Инженеры и аналитики могут (и, как мне кажется, должны) создавать модели рабочих предметных областей.
Интересно, что такая модель создается нашим мозгом вне зависимости от нашего желания. Изучая мир, мы создаем, связываем и наполняем концептами сами себя. Сначала в детстве перенимаем от социальной среды и значимых взрослых. А позже – так как нам это кажется удобным для своих целей и нужд. Наши концепты не всегда будут оптимальными. Наша задача – прикладывать дополнительные усилия по ее пересмотру, актуализации, или замене "устаревших сущностей".

Отсюда же, в том числе, рождаются конфликты с родственниками, на работе, с друзьями и т.д. Каждый из участников конфликта обладает своим набором концептов "правильного мира". И эти картины мира, входя в противоречие друг с другом, приводят к столкновениям.

2

Дмитрий, спасибо за схему, помогает лучше уложить в голову материал первой главы!

Я в работе тоже часто составляю подобные схемы, поэтому хотел бы поделиться практикой, которую использую я. Называется Concept mapping. Почитать можно здесь: Concept Mapping and Concept Modeling — Sensemaking at the Business Level (Features)
В качестве технологии использую Miro.
Основные отличия от той практики, которую использовали вы:

  1. на модели не указывается “количественность” отношений. Это хорошо, потому что упрощает моделирование (а моделирование, это отсечение неважного, “количественность” здесь не важна, как я считаю)
    принципы моделирования, на которые опираюсь:
  • https://www.hosiaisluoma.fi/blog/modelling-practices-principles/
  • Цитата: Моделирование в системном мышлении — это главное средство борьбы со сложностью. Большая сложность — это когда чересчур много деталей в описании, и даже непонятно, что в этих описаниях важно, а что неважно. Моделирование — это и есть описание только самого важного, и опускание при описании неважного. Документирование моделей позволяет удержать важное во внимании. А неважное во внимании не удерживается, остаётся только в разговорах. Источник: курс Системное мышление 2020, раздел "Мультимодель и междисциплинарность".
2. имеются стрелки, показывающие направление отношения.

И один комментарий по сути схемы:
В моем понимании, рабочий продукт не является частью системы. Рабочий продукт, это результат деятельности по созданию системы. Например, вот это статья, это рабочий продукт, созданный в проекте “Построение мастерства системного саморазвития”. Целевая система проекта - Ваше мастерство саморазвития. Но данная статья не является частью вашего мастерства.

3

Артем, спасибо за комментарий!

  1. я действительно опирался на т.н. "логическую модель данных", как будто предполагая автоматизировать управления этими сущностями в системе. Именно поэтому тут нет стрелок, а есть мощности связей. Это и правда усложняет восприятие. MIRO отличный инструмент, я рисовал эту картинку в drawio.
  2. Согласен, спасибо. По ходу чтения буду проводить ревизию того, что нарисовал! :)