FPF ((raw text) -> Связь "ЕРП" - "План" - "Поток"

Блоги Юрий Калин (блоги)
1

Связь “ЕРП” - “План” - “Поток”
На основе спецификации FPF (паттерны A.15, E.18, A.2.2, A.4, A.7), связь между ERP, Планом и Потоком строится через разделение временных режимов, онтологических типов и механизмов учета вариаций.

1. Онтологический статус объектов (A.7, A.15, E.18)

Объект Статус в FPF Паттерн Суть
ERP U.System (инструментальный) A.1 Программно-аппаратный холон, выступающий держателем эпистем и регистратором работ. Не является трансформером материала.
План U.WorkPlan (Эпистема) A.15.2 Описание намерений (baseline) в Design-Time. Не является исполнением.
Поток U.Flow (Валюация) E.18 Измеримая характеристика последовательности событий U.Work в Run-Time.
Работа U.Work (Событие) A.15.1 Датированный факт исполнения, связывающий План и Поток.

2. Механизм связи: Временная дуальность (A.4)

Связь возможна только через мост между Design-Time (T^D) и Run-Time (T^R):

  1. План (U.WorkPlan) существует в T^D. Это декларация ресурсов, окон и зависимостей (A.15.2:4.2).
  2. Поток (U.Flow) реализуется в T^R. Он состоит из фактических событий U.Work (A.15.1).
  3. ERP функционирует в обоих режимах:
    • В T^D: хранит и версионирует U.WorkPlan и U.MethodDescription.
    • В T^R: регистрирует U.Work (логи, транзакции, факты затрат).

3. Точка сопряжения: U.Work и Вариация (A.15.2:4.5)

Прямой связи «План → Поток» нет. Связь опосредована через U.Work и механизм аудита:

  • Базовая линия (Baseline): Элемент плана (PlanItem) цитируется в событии U.Work как plannedAs.
  • Вариация (Variance): Поток считается «управляемым», если система фиксирует отклонения между U.WorkPlan (намерение) и U.Work (факт потока).
    • Δt: Отклонение по времени (окно Γ_time).
    • Δc: Отклонение по ресурсам (Γ_work vs бюджет плана).
  • Правило: План не переписывается под факт (no backfill). Вариация фиксируется в U.Work.Audit (A.15.3:8.1).

4. Ограничение потока: Возможность (A.2.2)

Текст обсуждения верно указывает: «Скорость потока не будет выше текущих возможностей». FPF формализует это через U.Capability:

  • Физическое ограничение: Поток ограничен U.Capability производственной системы (держатель U.System), а не возможностями ERP.
  • **WorkScope:Capability требует явного указания U.WorkScope (условия применимости) и WorkMeasures (меры производительности) (A.2.2:4.2).
  • Роль ERP: ERP может проверять план на соответствие U.Capability (алгоритмы APS/MRP), но не может расширить физический WorkScope. Если план требует потока выше WorkMeasures, он недопустим (нарушение guard).

5. Ресурсный след (B.1.6)

Связь плана и потока через ресурсы моделируется агрегацией Γ_work:

  • В Плане: Бюджеты и резервирования ресурсов (epistemic budgets).
  • В Потоке: Фактические затраты (Γ_work — Work as Spent Resource).
  • Связь: Сопоставление бюджета плана и факта Γ_work позволяет оценить эффективность потока (costing, energy consumption).

6. Контекстуальность (A.1.1, F.9)

  • ERP как Контекст: ERP задает U.BoundedContext для управленческой эпистемы (словарь, стандарты данных).
  • Производство как Контекст: Физический поток существует в контексте цеха/логистики.
  • Мост (Bridge): Связь между «планом в ERP» и «потоком в цеху» требует явного U.Bridge (F.9). Данные о потоке (телеметрия, сканы) транспортируются в ERP через этот мост с учетом уровня конгруэнтности (CL). Ошибки возникают, когда контексты смешиваются без моста (например, когда статус в ERP считается фактом физического наличия без верификации).

Резюме

В терминологии FPF:

  1. ERP — это U.System, управляющий эпистемами (U.WorkPlan) и регистрирующий события (U.Work).
  2. План — это U.WorkPlan (намерение в T^D), служащий базовой линией.
  3. Поток — это U.Flow (валюация над U.Work в T^R), ограниченный U.Capability физической системы.
  4. Связь осуществляется через сравнение U.Work (факт) с U.WorkPlan (план) через механизм Variance и агрегацию ресурсов Γ_work.

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