Сравнение 2х бесплатных LLM c платной LLM на одном и том же запросе и одной версии FPF

iurii-kalin · 18.Июль.2026 12:37:16

продолжение безумных экспериментов по сравнению бесплатных и доступных (пока) LLM.

дизайн эксперимента следующий:
использован fpf редакции 2026-07-18 (скачано с оф репозитория) upd: не совсем так. обнаружил что в opus fpf был не самый свежий. дополнил ответ, пересчитанный на свежем fpf.
использован одинаковый текст запроса: “*отдел ит сопровождает и развивает информационные системы. *
предложи вариант вычисления границ систем. нам надо определить периметр зоны ответственности ит отдела, чтобы понимать где ит отдел отвечает, а где уже не наша зона ответственности. системы сопровождаемые отделом управляют производственными процессами компании, поддерживают сквозные процессы и обмениваются данными с другими информационными системами.
приведи пример для системы ерп которая управляет закупкой, производством, складами, оплатами, расчетом себестоимости, построением отчетности, бух и налоговый учет
ерп как система представлена 1 контекстом. но области бизнеса/деятельности которые она поддерживает представлены собственными контекстами и все эти отдельные контексты отображаются в 1 контекст ерп через мосты.
какие могут быть ходы для решения задачи вычисления границ систем? предложи порядок действий и шаблон описания границы
рассуждай с опорой на fpf.”

Использованные LLM:

anthropic/claude-opus-4.8 (платный)
GLM-5-Turbo (бесплатная, с регистрацией)
Qwen3.7-Max (бесплатная, с регистрацией)

В LLM создан новый чистый чат и загружен fpf

на выходе получены следующие результаты:

anthropic/claude-opus-4.8, fpf не от 2026-07-18

anthropic/claude-opus-4.8:

Вычисление границ информационных систем и периметра зоны ответственности ИТ-отдела

Рассуждение с опорой на FPF (контекстно-ориентированный подход: контексты, границы, мосты/bridges).

1. Постановка проблемы

ИТ-отдел сопровождает и развивает системы, которые:

управляют производственными процессами компании,

поддерживают сквозные (end-to-end) процессы,

обмениваются данными с другими ИС.

Нужно определить периметр зоны ответственности — где заканчивается «наше» и начинается «не наше».

Ключевая сложность: граница системы ≠ граница зоны ответственности ≠ граница бизнес-области. Эти три вещи путают, и именно поэтому «границы расплываются». FPF даёт язык, чтобы их развести.

2. Базовые понятия FPF, на которые опираемся

Понятие Что это Пример из ЕРП

Контекст (Context) Замкнутая смысловая область со своей моделью, языком и правилами. Внутри контекста термины однозначны. «Закупки», «Производство», «Склад», «Себестоимость» — каждый свой контекст. Плюс отдельный контекст «ЕРП-система».

Граница контекста (Boundary) Линия, на которой меняется модель/язык/владелец. За границей те же слова значат другое. «Заказ» в закупках ≠ «заказ» в производстве.

Мост (Bridge) Явное сопоставление (маппинг) между двумя контекстами: как объект/понятие одного отображается в другой. Мост — это контракт. Контекст «Склад» → контекст «ЕРП»: остаток номенклатуры отображается в проводку/регистр.

Зона ответственности Набор контекстов + мостов, которые обязуется поддерживать конкретный владелец (ИТ-отдел). ИТ отвечает за контекст «ЕРП» и все мосты, входящие в него.

Главная идея: система (ЕРП) — это один контекст-агрегатор, в который через мосты проецируются множество бизнес-контекстов (закупки, производство, склад, оплаты, себестоимость, отчётность, учёт). Граница системы проходит по мостам, а не по бизнес-процессам.

3. Три уровня границ (разделяем явно)

Граница бизнес-области (домена) — определяется бизнесом, не ИТ. Пример: «за процесс закупки отвечает отдел снабжения».

Граница системы (технического контекста) — где начинается и заканчивается ЕРП как артефакт: код, данные, конфигурация, интеграции.

Граница зоны ответственности ИТ — контексты и мосты, которые ИТ сопровождает и развивает.

Периметр ИТ = (множество контекстов, которыми владеет ИТ) ∪ (множество мостов, за которые ИТ отвечает).

Правило разграничения на мосту:

На каждом мосту у стрелки есть источник и приёмник. Ответственность за мост несёт тот, кто владеет преобразованием/контрактом, а не тот, кто владеет данными на концах.

4. Пример: система ЕРП

4.1 Контексты, проецируемые в ЕРП

ЕРП = 1 контекст-агрегатор. Бизнес-области = самостоятельные контексты, отображаемые в ЕРП через мосты:
   [Закупки]        [Производство]      [Склад]
       \                  |                /
        \                 |               /
         v                v              v
   ================ КОНТЕКСТ «ЕРП» ==================
         ^                ^              ^
        /                 |              \
       /                  |               \
  [Оплаты]      [Себестоимость]     [Бух/Налог. учёт] --> [Отчётность]
Каждая стрелка — мост с контрактом (что, в каком формате, с какой семантикой отображается).

4.2 Примеры мостов внутри/вокруг ЕРП

Мост Источник Приёмник Что отображается Владелец моста

M1 Закупки ЕРП Заказ поставщику → документ поступления ИТ

M2 Производство ЕРП Производственный заказ → списание/выпуск ИТ

M3 Склад ЕРП Движение остатков → регистр складского учёта ИТ

M4 Оплаты ЕРП Платёж → взаиморасчёты ИТ

M5 Себестоимость ЕРП Затраты → расчёт себестоимости ИТ

M6 ЕРП Отчётность (BI) Регистры → витрина/отчёт спорно — граница периметра

M7 Банк-клиент (внешняя ИС) ЕРП Выписка → платёж ИТ отвечает за приём, банк — за выгрузку

M8 ЕРП ГИС/ФНС (внешняя ИС) Декларация → отправка ИТ до точки передачи, дальше — не наша зона

4.3 Где проходит периметр

Внутри периметра ИТ: контекст «ЕРП» + мосты M1–M5 (внутренние проекции бизнес-областей в ЕРП).

На границе периметра (совместная ответственность): M6, M7, M8 — здесь нужен явный контракт, кто отвечает за какую половину моста.

Вне периметра ИТ: внутренняя логика внешних систем (банк, ФНС, BI-платформа стороннего вендора), а также сами бизнес-процессы в бизнес-контекстах (это домен бизнеса, а не ИТ).

5. Порядок действий (алгоритм вычисления границ)

Шаг 0. Зафиксировать язык. Договориться о терминах: контекст, граница, мост, владелец, контракт. Без единого языка граница не считается.

Шаг 1. Выделить контексты. Перечислить все бизнес-области/деятельности (закупки, производство, склад, оплаты, себестоимость, учёт, отчётность) как отдельные контексты. Отдельно — систему-агрегатор (ЕРП).

Шаг 2. Нарисовать проекции в систему. Для каждого бизнес-контекста показать, как он отображается в ЕРП. Каждая проекция = мост.

Шаг 3. Инвентаризировать мосты. Составить реестр всех мостов: внутренних (контекст→ЕРП) и внешних (ЕРП↔другая ИС). Для каждого — источник, приёмник, семантика.

Шаг 4. Пройти по каждому мосту и назначить владельца. Для каждого моста ответить: кто владеет преобразованием/контрактом? Это и определяет, попадает ли мост в периметр ИТ.

Шаг 5. Классифицировать мосты: «внутри периметра» / «на границе (совместные)» / «вне периметра».

Шаг 6. Провести линию периметра. Периметр = граница множества контекстов и мостов, помеченных как «внутри». Спорные мосты требуют явного контракта (SLA/договор о разграничении).

Шаг 7. Проверить закрытость. Убедиться, что не осталось «висящих» стрелок — данных, которые входят/выходят без назначенного владельца моста. Каждая точка пересечения границы должна иметь контракт.

Шаг 8. Формализовать и согласовать. Оформить по шаблону (раздел 6), согласовать с владельцами смежных контекстов (бизнес, внешние вендоры).

Шаг 9. Пересматривать при изменениях. Любой новый интеграционный поток = новый мост = проверка периметра.

6. Шаблон описания границы системы
ГРАНИЦА СИСТЕМЫ: <название системы / контекста-агрегатора>
Версия: <x.y>   Дата: <дата>   Владелец периметра: <ИТ-отдел / подразделение>

1. КОНТЕКСТ-АГРЕГАТОР
   - Наименование:
   - Назначение (какие бизнес-области поддерживает):
   - Технический состав (код, БД, конфигурации, инфраструктура):

2. ВХОДЯЩИЕ БИЗНЕС-КОНТЕКСТЫ (проецируемые в систему)
   Для каждого:
   - Контекст:
   - Владелец контекста (бизнес-подразделение):
   - Что проецируется в систему:

3. РЕЕСТР МОСТОВ
   | ID | Источник | Приёмник | Что отображается | Направление | Владелец моста | Класс |
   |----|----------|----------|------------------|-------------|----------------|-------|
   | M1 |          |          |                  | вход/выход  | ИТ / смежник   | внутри / граница / вне |

4. ПЕРИМЕТР ЗОНЫ ОТВЕТСТВЕННОСТИ ИТ
   - Внутри периметра (контексты и мосты): ...
   - На границе (совместная ответственность + ссылка на контракт/SLA): ...
   - Вне периметра (явно НЕ наша зона): ...

5. КОНТРАКТЫ НА ГРАНИЧНЫХ МОСТАХ
   Для каждого граничного моста:
   - Мост:
   - Наша половина (за что отвечает ИТ):
   - Чужая половина (за что отвечает смежник):
   - Точка передачи ответственности (где именно):
   - Формат/протокол/семантика контракта:
   - SLA / договор:

6. ПРОВЕРКА ЗАКРЫТОСТИ
   - Есть ли потоки без назначенного владельца моста? (да/нет)
   - Список открытых вопросов:

7. СОГЛАСОВАНИЯ
   - Владельцы смежных контекстов, подписи, даты.
7. Итоговые правила-эвристики

Граница проходит по мостам, а не по процессам. Бизнес-процесс может тянуться через несколько контекстов — ИТ отвечает не за процесс, а за проекции и мосты.

Нет моста без владельца. Любая стрелка через границу должна иметь ответственного за контракт.

Спорный мост = совместная ответственность + явный контракт. «По умолчанию» — это источник конфликтов.

Внутренняя логика чужого контекста — не наша зона. Мы отвечаем до точки передачи и за корректность нашей половины моста.

Один контекст — один язык. Если внутри «системы» появляются два несовместимых языка — это признак, что там на самом деле два контекста и между ними нужен мост.

anthropic/claude-opus-4.8, fpf от 2026-07-18, ответ переписан для инженера менеджера не знакомого с fpf

anthropic/claude-opus-4.8:

Границы систем и зона ответственности ИТ-отдела

Логика взята из FPF, но изложена обычным инженерно-управленческим языком. Термины FPF даю в скобках — только чтобы при желании сверяться со спецификацией.

1. Развести три разных объекта

«Границы плывут», потому что смешивают то, что в FPF считается разными вещами:

Что это Простыми словами Хозяин

Система как целое (holon) Сам продукт: код, база, настройки, интеграции ЕРП ИТ

Описание/схема (description) Диаграмма, регламент, карта интеграций ИТ как автор, но это НЕ сама система

Ответственность (commitment) Обязательство «поддерживаем и развиваем» Согласуется с бизнесом

Главное правило: коробка на диаграмме — это не граница системы. Граница задаётся правилом принадлежности (что внутри, что — среда), а не рисунком.

2. Как проводить границу (приём «система в контексте»)

Шаг А. Правило принадлежности (A.1 HolonDelimitationRelation): явный критерий, что часть системы, а что — среда.

Шаг Б. Отделить внутренние части от пересекающих связей (B.1.2 SystemAggregationRelation): модули ЕРП vs. обмены данными через границу.

Вывод: зона ответственности ИТ проходит по связям (интеграциям), а не по бизнес-процессам. Процесс — бизнесу, система и её стыки — ИТ.

3. Пример ЕРП

ЕРП = одна система, обслуживает много областей: закупки, производство, склад, оплаты, себестоимость, отчётность, бух- и налоговый учёт.

У каждой области свой смысл слов (BoundedContext): «заказ» в закупках ≠ «заказ» в производстве. При попадании в ЕРП данные переводятся на общий язык ЕРП — это ваши «мосты» (в FPF — translation relation между контекстами).
   Закупки      Производство      Склад
      \              |              /
       \             |             /   (перевод в язык ЕРП)
        v            v            v
      ============  ЕРП  ============
        ^            ^            ^
       /             |            \
   Оплаты      Себестоимость     Бух/Налог. учёт --> Отчётность
4. Правило разграничения на связях

Тип связи Пример Ответственность

Внутренняя (область → ЕРП) Закупки → поступление ИТ полностью

Пограничная (ЕРП ↔ чужая система) Банк-клиент → платёж делим: до точки передачи — мы, дальше — не мы; нужен договор

Внешняя внутренняя логика банка/ФНС/BI не наша зона

Периметр ИТ = все внутренние связи + наши половины пограничных.
Хозяин связи — тот, кто поддерживает преобразование данных на ней.

5. Порядок действий

Договориться о словах (система, среда, связь).

Назвать систему и сформулировать правило принадлежности.

Выписать области и их особые термины.

Составить реестр всех связей через границу.

Каждой связи назначить хозяина и тип.

Провести линию периметра (внутреннее + наши половины пограничного).

Пограничные связи закрыть договорами/SLA.

Проверить, что не осталось связей без хозяина.

Согласовать с бизнесом и вендорами; пересматривать при новых интеграциях.

6. Шаблон реестра связей

Пустой шаблон — колонки для описания любой связи через границу системы:

№ Откуда (источник) Куда (приёмник) Какие данные / что переезжает Направление Тип связи Хозяин связи Точка передачи ответственности Формат / протокол SLA / договор В периметре ИТ?

вход / выход / двусторонняя внутренняя / пограничная / внешняя ИТ / смежник / совместно да / частично / нет

7. Пример заполненного реестра для ЕРП

№ Откуда Куда Какие данные Направление Тип связи Хозяин связи Точка передачи Формат/протокол SLA/договор В периметре ИТ?

С1 Область «Закупки» ЕРП Заказ поставщику → документ поступления вход внутренняя ИТ — (внутри системы) внутр. механизм ЕРП внутр. регламент ИТ да

С2 Область «Производство» ЕРП Производственный заказ → выпуск/списание вход внутренняя ИТ — внутр. механизм ЕРП внутр. регламент ИТ да

С3 Область «Склад» ЕРП Движения номенклатуры → регистр складского учёта вход внутренняя ИТ — внутр. механизм ЕРП внутр. регламент ИТ да

С4 ЕРП Область «Себестоимость» Затраты и распределения → расчёт себестоимости двусторонняя внутренняя ИТ — внутр. механизм ЕРП внутр. регламент ИТ да

С5 ЕРП Область «Отчётность (BI)» Регистры → витрины/отчёты выход внутренняя ИТ — внутр. выгрузка внутр. регламент ИТ да

С6 Банк-клиент (внешняя ИС) ЕРП Банковская выписка → платёж, разнесение вход пограничная совместно Файл выписки в согласованном формате в обменном каталоге ISO 20022 / 1С-формат обмена Договор с банком + SLA ИТ на приём частично (наша половина — приём и разбор)

С7 ЕРП ФНС / гос. системы Декларация, отчётность → отправка выход пограничная совместно Момент передачи в оператора ЭДО ФНС-форматы XML, ЭП Договор с оператором ЭДО частично (до передачи оператору — мы)

С8 ЕРП Внешний BI-вендор (SaaS) Финансовые регистры → аналитическая платформа выход пограничная совместно Наша выгрузка в API/хранилище вендора REST API / выгрузка в S3 Договор с BI-вендором + SLA частично (наша выгрузка — наша, их платформа — нет)

С9 Внешняя MES-система ЕРП Факт выработки цеха → производственный учёт вход пограничная совместно Обменный сервис/шина на нашей стороне REST / брокер сообщений SLA между ИТ и владельцем MES частично (приём и трансформация — наши)

С10 Платформа банка (внутр. логика) — Обработка платежа внутри банка — внешняя банк — — — нет

Как читать периметр по реестру:

строки С1–С5 (тип «внутренняя») — целиком в зоне ИТ;

строки С6–С9 (тип «пограничная») — в зоне ИТ только наша половина до точки передачи; обязательно закрыты договором/SLA;

строка С10 (тип «внешняя») — вне периметра ИТ.

8. Пять правил на каждый день

Граница — по связям, не по процессам. Процесс — бизнесу, интеграции — ИТ.

Схема ≠ граница. Граница — это правило принадлежности, а не рисунок.

Нет связи без хозяина. Любой обмен через границу — с ответственным.

Спорная связь = делим + договор. «По умолчанию» = будущий конфликт.

Разный смысл одного слова = разные области, между ними обязателен явный перевод.

GLM-5-Turbo

GLM-5-Turbo:

Опираясь на спецификацию First Principles Framework (FPF), задача вычисления границ зоны ответственности ИТ-отдела сводится к построению явных граничных утверждений (boundary claims) вместо использования размытых реляционных слов (таких как «сопровождает», «поддерживает», «управляет»).

Ваше наблюдение, что ERP — это один контекст, а бизнес-области — другие контексты, связанные мостами, абсолютно точно попадает в ядро FPF (паттерны A.1.1 U.BoundedContext и A.6.9 Cross-Context Sameness Disambiguation).

Ниже представлены концептуальные ходы, порядок действий и шаблон описания границы.

Возможные ходы для решения задачи (опираясь на паттерны FPF)

Ход 1: Семантическое восстановление отношения «сопровождает» (RPR, паттерн A.6.P)
Слово «сопровождает» является триггером для Relational Precision Restoration. Оно скрывает за собой разные kinds of relations. ИТ-отдел не «сопровождает процесс закупки» (это делает бизнес). ИТ-отдел обеспечивает функционирование (U.Mechanism, паттерн A.6.1) информационного контура, который отображает (через мост/bridge) контекст закупок в контекст ERP. Граница проходит там, где заканчивается U.Mechanism ИТ и начинается бизнес-U.Method.

Ход 2: Декомпозиция через Boundary Norm Square (паттерн A.6.B)
Любая граница системы раскладывается на 4 квадранта утверждений:

L (Laws): Законы системы (например, формула расчета себестоимости).

A (Admissibility): Допустимость (кто имеет роли для ввода данных, проверка прав доступа).

D (Deontics/Commitments): Обязательства ИТ (SLA на доступность, время восстановления).

E (Work-Effects): Выполняемая работа и ее факты (инсталляция патчей, бэкапы).
Ход: ИТ отвечает за D и E в полном объеме, за A — частично (реализация механизма проверок, но не назначение ролей), а за L — не отвечает (бизнес-логика принадлежит бизнес-контекстам).

Ход 3: Фиксация ClaimScope (G) через USM (паттерн A.2.6)
Граница — это всегда множество (set-valued scope). Зона ответственности ИТ — это ClaimScope (G), который задается явно перечисленным множеством сущностей, механизмов и контекстов. То, что не попало во множество G — вне зоны ответственности.

Ход 4: Разделение EntityOfConcern и Description (паттерн A.7 Strict Distinction)
ERP как программный комплекс (U.System) — это одна сущность. Отчет о себестоимости в ERP (U.Episteme) — это описание. Граница ИТ-ответственности проходит по инфраструктуре порождения и хранения описаний (механизмы, базы данных, интеграции), а не по смысловому содержанию описаний (правильность формул — ответственность финансового контекста).

Порядок действий для ИТ-отдела

Шаг 1. Инвентаризация Bounded Contexts и мостов (A.1.1, A.6.9)

Нарисуйте карту контекстов. Центр — ERP Context. Вокруг — Procurement Context, Production Context, Warehouse Context, Accounting Context.

Для каждого моста (Bridge) зафиксируйте: направление маппинга, какие именно слоты (поля/данные) трансформируются, где происходят потери (Loss Notes). Это сразу покажет, где заканчивается ERP и начинается чужая система.

Шаг 2. Выделение владельцев контекстов (A.2 Role Taxonomy, A.2.1)

Для каждого бизнес-контекста зафиксируйте Holder#Role:Context. Например, Финдиректор#ВладелецЛогики:AccountingContext.

ИТ-отдел получает роль Provider#InfrastructureCarrier:ERPContext.

Шаг 3. Сборка механизмов ИТ (A.6.1 U.Mechanism)

Перечислите, какие именно U.Mechanism ИТ предоставляет для ERP: механизм хранения данных, механизм транспорта (интеграции через мосты), механизм аутентификации (Admissibility), механизм вычислительного исполнения.

Шаг 4. Заполнение Boundary Norm Square для каждого интерфейса/моста (A.6.B, A.6.C)

Возьмите каждый интерфейс взаимодействия ERP с бизнесом или другими системами.

Распределите утверждения по квадратам L/A/D/E. Это создает “контракт” (Unpacking Contract, A.6.C), где четко видно, что ИТ обещает (Promise Content, A.2.3), а что остается на стороне бизнеса.

Шаг 5. Фиксация заблокированных перечитываний (A.15.4, A.6.P)

Explicitly опишите, что ИТ не делает. Например: “ИТ не гарантирует бизнес-корректность введенных в систему данных” или “ИТ не отвечает за сбои в физической логистике, отраженные в интерфейсе склада”. Это защищает от appearance-based reliance (когда бизнес видит красивый дашборд и думает, что ИТ отвечает за правильность цифр на нем).

Шаблон описания границы ИТ-системы (на примере ERP)

Шаблон структурирован так, чтобы удовлетворять требованиям A.6 (Signature Stack & Boundary Discipline) и A.2.6 (USM).
# BOUNDARY STATEMENT: Зона ответственности ИТ-отдела за контекст ERP

## 1. Идентификация и Scope (USM, A.2.6)
- **System/Holon:** ERP-система (как программно-аппаратный комплекс)
- **Bounded Context:** `ERP Context`
- **ClaimScope (G) [IN]:** 
  - Инфраструктура серверов и СУБД ERP.
  - Код и конфигурация `ERP Context`.
  - Механизмы транспортировки данных через мосты (API, шины).
  - Механизмы исполнения транзакций (ACID-гарантии внутри ERP).
- **ClaimScope (G) [OUT]:** 
  - Содержательное наполнение справочников (номенклатура, контрагенты).
  - Бизнес-правила расчета себестоимости и налогов.
  - Физические процессы на складах и производстве.

## 2. Контекстная карта и Мосты (A.1.1, A.6.9)
- **Bridge 1:** `ERP Context` ↔ `Accounting Context` (Бухучет)
  - *Direction:* bidirectional
  - *ИТ отвечает за:* Транспортную целостность пакета проводок.
  - *ИТ НЕ отвечает за:* Корректность формулы генерации проводки (принадлежит Accounting Context).
- **Bridge 2:** `ERP Context` ↔ `Warehouse Management System (WMS)`
  - *ИТ отвечает за:* Доступность endpoint-а приема данных от WMS.
  - *ИТ НЕ отвечает за:* Своевременность сканирования штрихкодов на складе.

## 3. Boundary Norm Square (A.6.B) для U.Mechanism ERP
- **[L] Laws (Законы):** Ит-отдел НЕ является автором бизнес-законов. ИТ реализует технические законы (например, "запись в БД либо фиксируется целиком, либо откатывается").
- **[A] Admissibility (Допустимость):** ИТ реализует механизм проверки ролей (RBAC). ИТ НЕ назначает роли сотрудникам (это делает бизнес через Admin бизнес-системы). ИТ отвечает за то, что механизм невозможности подмены роли работает.
- **[D] Deontics / Commitments (Обязательства - SLA):** 
  - Доступность UI ERP: 99.5% в рабочие часы.
  - Время восстановления БД (RTO): 4 часа.
  - Время ответа API интеграции: < 500ms при 95-м перцентиле.
- **[E] Work-Effects (Работа и эффекты):** 
  - Deploy релизов.
  - Мониторинг логов.
  - Восстановление из бэкапов.

## 4. Promise Content (Содержание обещания, A.2.3)
- **AccessSpec:** Бизнес-пользователи с валидными учетными данными получают доступ к функциям ERP в рамках назначенных им бизнес-ролей.
- **AcceptanceSpec:** Система считается работоспособной, если выполняются метрики из квадранта [D] и отсутствуют критические ошибки (Severity 1) в логах транзакций.

## 5. Заблокированные перечитывания (Overread Blocking, A.15.4)
Следующие интерпретации являются НЕДОПУСТИМЫМИ при определении границы ответственности ИТ:
1. *Ошибка приравнивания интерфейса к агенту:* Наличие в ERP экрана "Расчет себестоимости" не означает, что ИТ-отдел отвечает за правильность рассчитанной себестоимости.
2. *Ошибка переноса авторитета:* Отображение в ERP дашборда "Задержки оплаты" не делает ИТ ответственным за взыскание дебиторской задолженности.
3. *Ошибка поддержки (Support-as-basedness, A.6.6):* Факт того, что ИТ "сопровождает" блок оплаты, не означает, что ИТ является базой (base) для финансового процесса. Базой является финансовый контекст, ИТ — лишь носитель (carrier).

## 6. Условияreopen (A.16.2)
Граница [G] должна быть пересмотрена (reopen), если:
- Бизнес-контекст делегирует ИТ-отделу роль владельца бизнес-правила (изменение Holder#Role).
- Архитектура меняется так, что мосты исчезают (например, расчет себестоимости полностью уходит во внешний микросервис вне зоны ИТ-отдела).
Резюме для вашей задачи

Используя FPF, вы перестаете спорить с бизнесом на уровне «кто за что отвечает» в абстрактных терминах. Вы переводите спор в плоскость механизмов (A.6.1), обязательств (A.2.8) и контекстов (A.1.1). Как только бизнес говорит: “Но это же в ERP, значит это ваши ошибки”, вы открываете шаблон и показываете раздел 2 (Мосты) и раздел 5 (Заблокированные перечитывания), демонстрируя, что нахождение данных в контексте ERP не делает ИТ владельцем логики (L) и допустимости (A) этих данных.

Qwen3.7-Max

Qwen3.7-Max:

Для решения вашей задачи мы опираемся на дисциплину FPF, которая строго разделяет систему (механизм), смысл (контекст) и ответственность (роли). Главная проблема ИТ-отделов — смешение ошибки механизма (баг, падение сервера, не ушел транспорт) и ошибки семантики/процесса (кладовщик ввел не то количество, бухгалтер провел документ задним числом).

1. Выбор карт практического применения (Semantic Practical-Use Cards)

Для вашей задачи лучше всего подходят и дополняют друг друга три карты:

SYSTEM-IN-CONTEXT: Позволяет разделить ERP (как ИТ-контекст) и бизнес-домены (как внешние контексты) и настроить между ними явные переходы.

ARCHITECTURE: Помогает описать границы через «Сигнатуры» (интерфейсы, API, форматы документов) и «Механизмы» (код, серверы, БД).

PROBLEM-SHAPING: Помогает отделить зону, где ИТ должно чинить систему, от зоны, где бизнес должен чинить свои процессы и данные.

Выбранная директивная связка: SYSTEM-IN-CONTEXT + ARCHITECTURE.

2. Текущий Объект Внимания (EntityOfConcern) и Практический Вопрос

Объект внимания: Периметр ответственности ИТ-отдела на стыке ERP и бизнес-подразделений (а также внешних систем).

Практический вопрос: Где заканчивается обязательство ИТ «обеспечить работу системы» и начинается обязательство бизнеса «предоставить корректные данные и принять решение»?

3. Порядок действий (Ходы для вычисления границ)

В FPF граница — это не просто линия на схеме, а набор контрактов (Сигнатур) и правил переноса смысла (Мостов).

Шаг 1. Инвентаризация Контекстов (E.10.D1 Lexical Discipline for Context)

Признайте, что ERP — это один ИТ-контекст со своим словарем (например, «Транзакция», «Проводка», «ID номенклатуры»).
Бизнес-домены (Склад, Закупки, Бухгалтерия) — это другие контексты со своим словарем (например, «Фактическая отгрузка», «Договор с поставщиком», «Налоговая база»).

Действие: Составьте реестр бизнес-контекстов, которые обслуживает ERP. Признайте, что слово «Себестоимость» в контексте Управленческого учета и в контексте Налогового учета (даже если они живут в одной ERP) — это разные сущности, требующие разных правил.

Шаг 2. Фиксация Сигнатур на границах (U.Signature)

Сигнатура — это публичный контракт: какие данные входят, какие выходят и какие «законы» (инварианты) при этом соблюдаются.

Действие: Для каждого стыка (например, «Склад → ERP» или «ERP → Банк-Клиент») опишите Сигнатуру.

Пример для ERP: Сигнатура «Приемка на склад» гласит: Если на вход подан валидный JSON/документ с ID товара и количеством, то система гарантирует атомарное увеличение остатка в БД.

Шаг 3. Разделение Механизма и Доменных Правил (U.Mechanism vs Domain Laws)

Это главный ход для снятия с ИТ чужой ответственности.

Механизм (Зона ИТ): Код, базы данных, сети, интеграционные шины. ИТ отвечает за то, что механизм выполнил Сигнатуру (данные не потерялись, транзакция не зависла, доступность 99.9%).

Доменные правила (Зона Бизнеса): Смысл данных. ИТ не отвечает за то, что кладовщик отсканировал не тот штрихкод, или что бухгалтер выбрал неверную статью затрат, если система технически позволила это сделать согласно Сигнатуре.

Шаг 4. Настройка Мостов между контекстами (F.9 Alignment & Bridge)

Поскольку бизнес-контексты отображаются в контекст ERP через мосты, нужно зафиксировать, кто отвечает за потери при переводе.

Действие: Если бизнес-контекст «Закупки» передает данные в ERP-контекст «Склад», Мост описывает правила маппинга. Если маппинг сломался из-за изменения API — это инцидент ИТ. Если бизнес изменил логику расчета себестоимости, но не уведомил ИТ для обновления Моста — это инцидент Бизнеса.

Шаг 5. Назначение Ролей (A.15 Role-Method-Work Alignment)

Закрепите роли для каждой границы.

Владелец Механизма (ИТ): Отвечает за Uptime, Bug-fixing, Backup, Transport.

Владелец Смысла / Процесса (Бизнес): Отвечает за Data Quality, Business Logic, User Training.

4. Шаблон описания границы (Boundary Card)

Используйте этот шаблон для каждого критического стыка (например, «Интеграция ERP и WMS (складской системы)» или «Ввод первичной документации в ERP»).

Поле шаблона Описание и пример заполнения (для стыка Склад → ERP)

1. Имя границы Bridge: Warehouse_Ops -> ERP_Inventory

2. Сторона А (Источник) Контекст: Складские операции.
Владелец: Директор по логистике.

3. Сторона Б (Приемник) Контекст: ERP (Модуль Склада и Бухгалтерии).
Владелец: ИТ-директор (за механизм), Фин. директор (за данные).

4. Сигнатура (Контракт) Формат передачи: API REST / XML-файл.
Инвариант: Quantity >= 0, ItemID существует в справочнике ERP.

5. Зона ответственности ИТ (Механизм) 1. Доступность API/очередей (SLA 99.9%).
2. Гарантия доставки (атомарность транзакции).
3. Валидация формата (отклонение битого JSON).
4. Логирование факта передачи (аудит).

6. Зона ответственности Бизнеса (Смысл) 1. Физическое соответствие товара сканируемому коду.
2. Своевременность сканирования (бизнес-процесс).
3. Корректность справочников (бизнес должен вовремя заводить новые ItemID).

7. Триггер эскалации (Litmus Test) Это баг ИТ, если: API вернул 500, транзакция зависла, данные дублировались из-за сбоя шины, справочник не обновился по расписанию.
Это проблема Бизнеса, если: API вернул 200 OK, но на складе нехватка, себестоимость рассчиталась “криво” из-за неверно введенной ставки налога, документ проведен задним числом.

8. Штрафы и потери (Loss Notes) Если бизнес меняет физический процесс (например, вводит маркировку “Честный знак”), но не закладывает время на доработку Моста (Сигнатуры) в ERP, ИТ не несет ответственности за простой на кассе.

5. Как это работает на примере ERP (Резюме для руководства)

Чтобы защитить ИТ-отдел от необоснованных претензий, внедрите следующее правило (инвариант FPF):

«ИТ-отдел гарантирует, что ERP корректно исполнит заложенные в нее законы (Сигнатуры) на основе предоставленных данных. ИТ-отдел не гарантирует, что предоставленные бизнесом данные отражают физическую реальность, и не принимает бизнес-решения за пользователя».

Пример с расчетом себестоимости:

Бизнес-контекст: Производство. Мастер цеха вводит факт списания материалов.

Мост: Передача факта списания в модуль расчета себестоимости.

ИТ-контекст (ERP): Алгоритм расчета себестоимости (ФИФО/Средняя).

Граница: Если ИТ-алгоритм математически неверно сложил суммы — виноват ИТ. Если мастер цеха забыл списать бракованные детали, и из-за этого себестоимость готовой продукции занижена — виноват Бизнес (Производство), так как Мост сработал штатно, но на вход Механизма поступили семантически неверные данные.

Этот подход переводит разговоры из плоскости «У вас система плохо работает» в плоскость «Давайте проверим логи на границе: Сигнатура соблюдена? Данные ушли? Значит, проблема в процессе на стороне источника».

Цель поста - дать объективную картину работы разных LLM в одинаковых условиях: один и тот же запрос, одна и та же версия fpf (если вообще такие категории тут уместны).

aleksandr-lapygin · 19.Июль.2026 20:59:57

Какой вывод для себя сделали по итогам сравнения?

iurii-kalin · 19.Июль.2026 22:19:18

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

Понятие	Что это	Пример из ЕРП
Контекст (Context)	Замкнутая смысловая область со своей моделью, языком и правилами. Внутри контекста термины однозначны.	«Закупки», «Производство», «Склад», «Себестоимость» — каждый свой контекст. Плюс отдельный контекст «ЕРП-система».
Граница контекста (Boundary)	Линия, на которой меняется модель/язык/владелец. За границей те же слова значат другое.	«Заказ» в закупках ≠ «заказ» в производстве.
Мост (Bridge)	Явное сопоставление (маппинг) между двумя контекстами: как объект/понятие одного отображается в другой. Мост — это контракт.	Контекст «Склад» → контекст «ЕРП»: остаток номенклатуры отображается в проводку/регистр.
Зона ответственности	Набор контекстов + мостов, которые обязуется поддерживать конкретный владелец (ИТ-отдел).	ИТ отвечает за контекст «ЕРП» и все мосты, входящие в него.

Мост	Источник	Приёмник	Что отображается	Владелец моста
M1	Закупки	ЕРП	Заказ поставщику → документ поступления	ИТ
M2	Производство	ЕРП	Производственный заказ → списание/выпуск	ИТ
M3	Склад	ЕРП	Движение остатков → регистр складского учёта	ИТ
M4	Оплаты	ЕРП	Платёж → взаиморасчёты	ИТ
M5	Себестоимость	ЕРП	Затраты → расчёт себестоимости	ИТ
M6	ЕРП	Отчётность (BI)	Регистры → витрина/отчёт	спорно — граница периметра
M7	Банк-клиент (внешняя ИС)	ЕРП	Выписка → платёж	ИТ отвечает за приём, банк — за выгрузку
M8	ЕРП	ГИС/ФНС (внешняя ИС)	Декларация → отправка	ИТ до точки передачи, дальше — не наша зона

Что это	Простыми словами	Хозяин
Система как целое (holon)	Сам продукт: код, база, настройки, интеграции ЕРП	ИТ
Описание/схема (description)	Диаграмма, регламент, карта интеграций	ИТ как автор, но это НЕ сама система
Ответственность (commitment)	Обязательство «поддерживаем и развиваем»	Согласуется с бизнесом

Тип связи	Пример	Ответственность
Внутренняя (область → ЕРП)	Закупки → поступление	ИТ полностью
Пограничная (ЕРП ↔ чужая система)	Банк-клиент → платёж	делим: до точки передачи — мы, дальше — не мы; нужен договор
Внешняя	внутренняя логика банка/ФНС/BI	не наша зона

№	Откуда	Куда	Какие данные	Направление	Тип связи	Хозяин связи	Точка передачи	Формат/протокол	SLA/договор	В периметре ИТ?
С1	Область «Закупки»	ЕРП	Заказ поставщику → документ поступления	вход	внутренняя	ИТ	— (внутри системы)	внутр. механизм ЕРП	внутр. регламент ИТ	да
С2	Область «Производство»	ЕРП	Производственный заказ → выпуск/списание	вход	внутренняя	ИТ	—	внутр. механизм ЕРП	внутр. регламент ИТ	да
С3	Область «Склад»	ЕРП	Движения номенклатуры → регистр складского учёта	вход	внутренняя	ИТ	—	внутр. механизм ЕРП	внутр. регламент ИТ	да
С4	ЕРП	Область «Себестоимость»	Затраты и распределения → расчёт себестоимости	двусторонняя	внутренняя	ИТ	—	внутр. механизм ЕРП	внутр. регламент ИТ	да
С5	ЕРП	Область «Отчётность (BI)»	Регистры → витрины/отчёты	выход	внутренняя	ИТ	—	внутр. выгрузка	внутр. регламент ИТ	да
С6	Банк-клиент (внешняя ИС)	ЕРП	Банковская выписка → платёж, разнесение	вход	пограничная	совместно	Файл выписки в согласованном формате в обменном каталоге	ISO 20022 / 1С-формат обмена	Договор с банком + SLA ИТ на приём	частично (наша половина — приём и разбор)
С7	ЕРП	ФНС / гос. системы	Декларация, отчётность → отправка	выход	пограничная	совместно	Момент передачи в оператора ЭДО	ФНС-форматы XML, ЭП	Договор с оператором ЭДО	частично (до передачи оператору — мы)
С8	ЕРП	Внешний BI-вендор (SaaS)	Финансовые регистры → аналитическая платформа	выход	пограничная	совместно	Наша выгрузка в API/хранилище вендора	REST API / выгрузка в S3	Договор с BI-вендором + SLA	частично (наша выгрузка — наша, их платформа — нет)
С9	Внешняя MES-система	ЕРП	Факт выработки цеха → производственный учёт	вход	пограничная	совместно	Обменный сервис/шина на нашей стороне	REST / брокер сообщений	SLA между ИТ и владельцем MES	частично (приём и трансформация — наши)
С10	Платформа банка (внутр. логика)	—	Обработка платежа внутри банка	—	внешняя	банк	—	—	—	нет

Поле шаблона	Описание и пример заполнения (для стыка Склад → ERP)
1. Имя границы	`Bridge: Warehouse_Ops -> ERP_Inventory`
2. Сторона А (Источник)	Контекст: Складские операции. Владелец: Директор по логистике.
3. Сторона Б (Приемник)	Контекст: ERP (Модуль Склада и Бухгалтерии). Владелец: ИТ-директор (за механизм), Фин. директор (за данные).
4. Сигнатура (Контракт)	Формат передачи: API REST / XML-файл. Инвариант: `Quantity >= 0`, `ItemID` существует в справочнике ERP.
5. Зона ответственности ИТ (Механизм)	1. Доступность API/очередей (SLA 99.9%). 2. Гарантия доставки (атомарность транзакции). 3. Валидация формата (отклонение битого JSON). 4. Логирование факта передачи (аудит).
6. Зона ответственности Бизнеса (Смысл)	1. Физическое соответствие товара сканируемому коду. 2. Своевременность сканирования (бизнес-процесс). 3. Корректность справочников (бизнес должен вовремя заводить новые `ItemID`).
7. Триггер эскалации (Litmus Test)	Это баг ИТ, если: API вернул 500, транзакция зависла, данные дублировались из-за сбоя шины, справочник не обновился по расписанию. Это проблема Бизнеса, если: API вернул 200 OK, но на складе нехватка, себестоимость рассчиталась “криво” из-за неверно введенной ставки налога, документ проведен задним числом.
8. Штрафы и потери (Loss Notes)	Если бизнес меняет физический процесс (например, вводит маркировку “Честный знак”), но не закладывает время на доработку Моста (Сигнатуры) в ERP, ИТ не несет ответственности за простой на кассе.