Вчера возобновил серию разборов/review по первому шагу системного мышления. Этот шаг подразумевает три поворота мысли:
– поиск системы как “вещи в физическом мире” (интересует groundingHolon, а не метонимия на разные привязанные к нему объекты – поведения, описания-эпистемы, характеристики-свойства и т.д.). И вот тут застревают обычно все программисты, ибо они работают традиционно с описаниями и моделями, а вот объект моделирования сам по себе обсуждают редко. Программистов приходит много, поэтому на этом шаге часто застреваем: однозначную референцию получить довольно трудно.
– ход от “вещи в физическом мире” к системе, то есть разговор о границе, эмерджентности, функциональности по отношению к окружению (и вот тут функциональность описывается как viewpoint клиента, да ещё и value ни разу не “ценность”, а “польза” – и этот тест на “пользу” и отрицательные экстерналии “кому вред” обычно трудно проходится).
– ход на целевую систему как предмет договорённости в организации: предмет развития. То, чем торгуем, поэтому хотели бы увеличить поток продукта. И тут все трудности, описанные Голдраттом: надо свой интерес заместить общим, “глобальный максимум”. Мысль тут трудно работает, ибо сразу понятно: обосновать связь своего маленького проекта с максимизацией выпуска обычно более чем трудно. Но надо! Тут основное – “договорить всех”, проверяем всё лифтовым текстом и разговором про “целевую, нашу и вашу систему”.
Было несколько интересных примеров, я на них пробовал новые ходы объяснений.
Так, попался традиционный случай “доступа в интернет”, но поскольку говорили с программистом, который знал про семиуровневый стек OSI (Сетевая модель OSI — Википедия ), я попытался выйти на обсуждение “доступа” на физическом уровне (там “доступ” к физической структуре – кабелю, аппаратуре связи и битики в их физическом представлении). Дальше идея была в оттрассировании этого “доступа” затем на всей вертикали, ибо там где-то посередине будет транспорт и вот там уже это будет называться “интернет-доступ”, ниже ведь нет “интернета” как следования протоколу. Не обязательно строго OSI, можно “физика → связь → интернет протокол → транспорт по сети → приложение”, очень грубо. Всё одно, проявляется проблема чисто программистского образования, когда не учат работе аппаратуры: чем ниже по уровням, ближе к физике, тем труднее рассуждение.
Мы даже не дошли до идеи удержание сеанса, ибо торгуем-то не “доступом” (это ларёк симок торгует “доступами”), а в телекоме торгуют сеансами доступа – и надо бы различать “удержание сеанса” на уровне “удержания сеанса” физического доступа, сеанса “доступа в интернет” и “сеанса работы с приложением” (скажем “игрового сеанса”)! В современных 5G спецификациях «сессия» существует уже на уровне связности — PDU Session. Опять многослойная путаница в лексике, “session” (сеанс) — не только про приложения.
Что тренируем? Внимание к словам: одно слово означает похожее по смыслу, но разное на разных уровнях – и надо сначала договориться, о каких уровнях протокола говорим. Словесная метка “доступ” не гарантирует, что ей помечен в разных фразах один и тот же объект. Удержать связное рассуждение про “доступ” на многих уровнях невозможно, если не понимать, как эти уровни связаны друг с другом (“не понимать, как работает”), а теория говорит, что без grounding договориться будет нельзя, описания разных уровней, отвязанных от “битов на физическом уровне” легко разъедутся – и нет другого способа их связать, кроме как сказать, что это по-разному описанные физически представленные битики где-то там, в самом низу. Это общий ход в мышлении, очень трудно понимается.
Ещё интересно было поразбираться с ПИФами, поскольку “ценные бумаги” и вообще фондовый рынок обычно никто не обсуждает по существу, с выходом в физический мир (что такое “фонды”? Это ж “фондовый рынок”? Да, этимология опять ведёт к grounding, к латинскому fundus – основание, почва, земельное владение, которое потихоньку превращалось во французское fonds publics как бумаги госзаймов, под которыми было золотишко, но потом, дальше это из гос.облигаций перепрыгнуло на вообще любые ценные бумаги, под которыми уже были активы предприятий – имущество, деньги и всё остальное, часто называемые уже “капитал”. Про “имущество” под всеми этими “фондами” (ценными бумагами) смотрите фильм “Деньги других людей”, его просмотр в наших резидентурах в обязательной программе). Grounding для ПИФов – это реальные активы (имущество, в том числе деньги, на которые у кого-то есть юридически обеспеченные права, пусть и через цепочки учётных организаций вроде реестров, депозитариев и даже бухгалтерий, которые учитывают всякие права требования на что-то другое). Дальше уже можно подниматься “от земли”: доли в этих правах требования или участия, управляющая компания как исполнитель каких-то работ.
В ПИФах – не “продажи продукта”, это вроде “сервис управления” (за процент!) акциями как “талончиками прав на предприятие” (а предприятие – вполне вещь!) но процент всегда получает управляющий, он в плюсе всегда, а покупатель что покупает – он же может купить убыток, формально он не “покупатель” (хотя может быть “покупателем работ по управлению”), он инвестор, который участвует в прибылях и убытках, несёт на себе риски и выигрыша, и проигрыша!
Ладно, если это только управление-сервис, то что там с SLA-SLO, в чём обещание, когда обещать прибыль инвестору невозможно? Мышление идёт тут заученными фразами, а на этих фразах далеко не уедешь, объяснений в них нет, только цитирование законов (при этом я как раз писал этот самый закон о рынке ценных бумаг и поэтому вынужден был подробно разбираться). Обсуждать “выход в физический мир” в этих случаях трудно ввиду незнания предметной области фондового . Знание системного мышления помогает указать на то, что надо взять из знаний о предметной области, но оно же не заменяет знаний предметной области!
Ещё один проект был про банкротство (не первый раз!), и мы опять откатились к “банкрот” – то есть изменения мира сводились к изменению отношений одного лица, но “отношение” ведь там многоместное! Там трудно, ибо это же обязательственное право, а не вещное – и гражданский кодекс с обязательствами очень плохо работает (мы когда-то с Виктором Агроскиным и Цереном Цереновым пытались затеять общественную дискуссию о необходимости переработки ГК, ибо информационное право сплошь и рядом обязательственное и там сразу интересные проблемы с grounding. Но они решаемые!). Тут ходы были на молекулярные модели в химии, “из шариков и палочек”. Процедура банкроства похожа на химическую реакцию: атомы-лица те же, а вот молекулы после реакции уже другие, меняются “химические связи”. Моделировать надо граф обязательств, многоместные отношения!
Процедура банкротства меняет commitment-связи сразу у нескольких участников, а не только «свойство должника». Commitment — то, что имеет режим принудительного исполнения и санкций за невыполнение, а promise — более широкий класс утверждений с последующими ожиданиями исполнения (и ещё там речевые акты, которые надо отличать: не любое содержание обещания реально обещано, и не любое обещанное деонтично). И вот тут оказывается, что нельзя обсуждать одного банкрота, а надо обсуждать и кредиторов как минимум. У них были одни отношения до банкротства, а стали после банкротства другие – и нельзя считать, что результатом является только банкрот, но не ограбленные кредиторы. Опять же, банкротством часто оформляется рейдерский захват, и концентрироваться на одном банкроте как “был должник, стал банкрот, потом и это почистим” – нельзя.
Тут ещё у меня в кустах рояль: в FPF я как раз наладил работу с обещаниями: разведение обещаний и долженствования (promise и commitment), актов выдачи обещания (speech act), условий приёмки выполнения обещания и т.д. – это делалось главным образом для описания разных вариантов сервисов с разведением всяческих в SRE чётко разводимых сущностей – SLI (измеряем), SLO (целевой диапазон оптимизации) → SLA (если юридически оформляем обещание и вводим последствия за неисполнение), например, см. Google SRE - Defining slo: service level objective meaning. Это всё очень привычно для интернет-доступа (там же программисты), но вполне можно развернуть и в сторону управления ПИФами, и в сторону проведения банкротств.
Я уже месяц назад исправлял онтологию и лексику сервиса в FPF. Тогда всё закончилось переименованием в ServiceClause и вроде бы проблем стало меньше. Но в R1 у многих оказалась работа с сервисом и FPF говорил на эту тему что-то невнятное. Поэтому я сделал очередные правки в FPF, приведя к большей (хотя и не до конца) совместимости с пониманием сервиса в руководстве по системному моделированию (R6, там оказалось примерно 100К знаков разъяснений по поводу сервиса). ServiceClause стал “содержанием обещания”, PromiseContent, всем сразу полегчало (там было больше сотни упоминаний в тексте). В A.6.8 (паттерн повышения семантической точности путём ситуационной распаковки термина “сервис” в набор точных понятий, искоренение метонимии) дополнил онтику вокруг “сервиса”, а “нераспакованный” service убрал окончательно (ибо это оставалось ещё как “возможный синоним для PromiseContent”, что всех и путало). Вот типовой кусочек из неизбежных диалогов с неестественным интеллектом в ходе такой работы, обсуждаем “результат выполнения обещания”: “Имя Outcome тут было выбрано, чтобы учитывать разные варианты обещаного. Например, иногда обещается “проработать 5 минут” (и тогда этот outcome – работа по оговорённому методу, что происходит в ходе самого оказания услуги, а не потом, тип тут - work по методу), иногда обещается “результат” как то, что появляется потом, и метод неважен (выкопанная яма, а лопатой или экскаватором уже неважно), иногда и одно, и другое (уложенная причёска, но работа не более 20 минут, метод стрижки-укладки, а не парик, а результат уложенные волосы “для званого вечера”). Ровно поэтому слово такое общее. Онтологически, конечно, работа-по-обещанию, результат-работы-по-обещанию и outcome-обещания разные объекты, не должны путаться в лексике. Слова вроде result тут плохи, ибо это чаще результат-работы-по-обещанию, не включает работу-по-обещанию”. В руководстве по системному моделированию примеры различий в обещаниях – “5 минут проработать” vs “яма выкопана” vs “причёска за 20 минут”.
Это всё уже учтено, с сервисом теперь в FPF всё ОК. Брать свеженький поправленный FPF, как всегда, тут: GitHub - ailev/FPF: First Principle Framework.
А следующий разбор/review по первому шагу системного мышления у меня будет 12 марта 2026.
