Архитектура ИИИ, Реестра, Конвейера и программных библиотек на примере «30 марок × 30 экспертов»
Научная серия: 1. Как сбалансировать требования экспертов · 2. От альянсных контрактов к координационной системе · 3. От переговоров к обучающейся отраслевой сети · 4. От балансировки требований к балансировке программ.
Аннотация
В первых трёх статьях серии были последовательно рассмотрены балансировка требований внутри общей системы, механизмы длительной координации самостоятельных организаций и превращение отдельных переговоров в проверяемый цифровой след отраслевой сети. Настоящая работа исследует следующий уровень сложности: как одновременно развивать несколько партнёрских программ, сохраняя их предметную специфику, совместимость и возможность машинного сопровождения.
Материалом исследования стали пилотные программы Альянса «30 марок × 30 фабрик», «30 марок × 30 экспертов» и «30 марок × 30 магазинов». Методически работа относится к исследованию через проектирование: архитектурная гипотеза формулируется в виде системы паспортов, информационных объектов, CJM, BPMN, программных библиотек и контрольных процедур, после чего проверяется на реальных задачах и отрицательных путях.
Предлагается различать два уровня инженерии требований. На первом согласуются требования участников внутри одной программы. На втором балансируются требования самих программ к общей инфраструктуре: идентичности человека, данным CRM, ежедневному Срезу, автоматизации, интерфейсам ИИ-агентов и переносу знаний. Результатом является архитектура, в которой ИИИ задаёт общий язык и правила совместимости; Реестр сохраняет единую идентичность; Конвейер обрабатывает подтверждённые изменения; каждая программа имеет собственную библиотеку, CJM, BPMN, роли, стадии и доказательства результата. На примере экспертной программы показано, как эта архитектура связывает вход и согласие с правилами, квалификацию задачи, реакцию эксперта, взаимный выбор, консультацию, следующий шаг, подтверждённый результат и отдельно согласованный CASE, не смешивая состояние человека, задачи и программы.
Работа не утверждает доказанный экономический эффект. Она формулирует проверяемую конструкцию и метрики для следующих пилотов: время до следующего предметного шага, долю подтверждённых переходов, число конфликтов данных, сохранность отрицательных путей и стоимость запуска новой программы.
Ключевые слова: инженерия требований, балансировка требований, архитектура программ, межорганизационная координация, CJM, BPMN, цифровой след, программная библиотека, ИИ-агенты, индустрия моды.
Схемы в статье предназначены для понимания архитектуры людьми. Это не машиночитаемая спецификация и не попытка заменить исследовательское объяснение кодом.
1. Четвёртый этап исследования
В первой статье балансировка требований была описана как инженерная процедура: заинтересованные стороны формулируют потребности, ограничения, права принятия решений и критерии приёмки, после чего система получает новую проверяемую базовую линию. Важным результатом было различение согласования и усреднения. Противоречие нельзя устранить красивой общей формулировкой; нужно определить, какое требование меняется, кто вправе принять изменение и каким испытанием оно проверяется.
Во второй статье вопрос был расширен до межорганизационной координации. Исследования David Mosey показали, почему согласованное решение недостаточно один раз зафиксировать: самостоятельным участникам нужны общие процедуры, раннее включение ролей, работа с рисками и накопление знаний между проектами. Перенос этих механизмов в индустрию моды был обозначен как исследовательская гипотеза, а не как уже доказанный эффект.
В третьей статье единицей анализа стал ограниченный рабочий эпизод: запрос, ответ, уточнение требований, решение сторон, проверяемый результат и возможное изменение общего знания. Было показано, как событие превращается в операционное состояние, затем — в подтверждённый кейс и только после проверки — в переносимое правило.
Четвёртая статья рассматривает следующий этап. После запуска нескольких программ возникает риск создать для каждой из них отдельную CRM, отдельную картину человека, отдельную автоматизацию и несовместимый язык состояний. Противоположная крайность — объединить разные программы в универсальный процесс и потерять их предметную логику. Поэтому объектом балансировки становятся уже не только требования участников, но и требования программ к общей инфраструктуре.
В этой работе мы называем это балансировкой второго порядка:
балансировка первого порядка
= требования участников внутри одной программы
балансировка второго порядка
= требования разных программ к общему языку,
данным, автоматизации и интерфейсам
Первый уровень отвечает на вопрос, как марке и эксперту согласовать задачу, результат и следующий шаг. Второй — как экспертная, производственная и розничная программы используют одну идентичность человека и один доказательный контур, но не смешивают свои роли, стадии и правила результата.
2. Исследовательский вопрос и метод
Основной исследовательский вопрос формулируется так: какая архитектура позволяет одновременно сопровождать множество партнёрских программ, не копируя общую инфраструктуру и не унифицируя предметные процессы до потери смысла?
Из него следуют четыре частных вопроса:
- Какие элементы должны быть общими для всех программ?
- Какие элементы обязаны оставаться внутри конкретной программы?
- Как переносить подтверждённое изменение между Реестром, Конвейером и программной проекцией без перезаписи истории?
- Как проверить, что новая программа действительно совместима с общей инфраструктурой, а не только похожа на предыдущую по оформлению?
Исследование строится как design science: создаваемая архитектура рассматривается как проверяемый артефакт. Её источниками служат действующие паспорта, наблюдаемые переходы в программах, CRM-проекции, рабочие встречи, комментарии, подтверждённые CASE и разрывы процесса. Проектное решение проверяется не только успешными связками, но и задержками, отказами, отсутствием ответа, конфликтами источников и ошибками автоматизации.
Единицей анализа является не человек вообще и не программа вообще, а переход между двумя подтверждёнными состояниями вокруг конкретного объекта: заказа, экспертной задачи, консультации, поставки или иного ограниченного результата.
3. Архитектурная гипотеза
Предлагаемая архитектура разделяет общий язык, инфраструктуру сопровождения и предметные программы.
ИИИ
└── общий язык, совместимость и общие паспорта
Инфраструктура Альянса
├── Реестр сообщества / CRM
└── Конвейер сопровождения
Программы Альянса
├── 30×30 фабрики
│ └── собственная библиотека
├── 30×30 эксперты
│ └── собственная библиотека
├── 30×30 магазины
│ └── собственная библиотека
└── другие программы
Эта схема вводит четыре принципиальные границы.
ИИИ не является ещё одной программой. Он задаёт общий язык, минимальные правила совместимости, форматы манифестов и общие паспорта. Подключение библиотеки к ИИИ не делает её содержание частью открытого Свода и не передаёт агенту дополнительные права.
Реестр не является программой. В нём человек сохраняет одну идентичность, даже если участвует в нескольких программах и выполняет разные роли. Реестр отвечает на вопрос «кто это и в каких контурах он участвует», но не заменяет предметную историю заказа, задачи или консультации.
Конвейер не является программой. Это горизонтальная инфраструктура сопровождения: сбор разрешённых сигналов, дедупликация, формирование Среза дня, запись подтверждённой дельты, readback, квитанция и анализ разрывов. Конвейер не решает, что означает консультация для рейтинга эксперта или образец для производственной пары. Это определяет библиотека соответствующей программы.
Библиотека программы не является CRM или архивом переписок. Она хранит версионируемые правила предметного процесса: роли, объекты, стадии, CJM, BPMN, документы, критерии результата, ограничения автоматизации и интерфейс совместимости с ИИИ.
Разделение позволяет одной инфраструктуре обслуживать много программ, не создавая единого «сверхпроцесса», в котором заказ, экспертная задача и поставка ошибочно становятся вариантами одного статуса.
4. Единая оболочка программ и предметная вариативность
Для масштабирования до десятков программ недостаточно дать им похожие названия и одинаковые таблицы. Нужна единая структурная оболочка, внутри которой предметные части могут различаться.
Программа Альянса
├── паспорт и граница
├── роли и объекты работы
├── вход и информированное согласие с правилами
├── CJM участника
├── BPMN процесса
├── стадии и критерии переходов
├── рабочая среда: сайт, комментарии, чат, встречи
├── CRM-проекция
├── связь с Конвейером
├── документы и шаблоны
├── доказательства результата и метрики
├── собственная библиотека
└── версия, история и gates
Единая оболочка не означает одинаковую полноту. Для зрелой программы элементы могут быть приняты и проверены; для пилотной — находиться в статусе candidate, pilot или gap; отдельный элемент может быть not_applicable. Такое различение важнее формальной комплектности: отсутствующий BPMN должен быть показан как пробел, а не восстановлен агентом по аналогии с другой программой.
Инвариантными для всех программ являются единая идентичность человека, происхождение события, режим доступа, правило неперезаписи истории, подтверждение перехода, контроль внешних действий и возможность readback. Вариативными остаются предметные роли, объекты, стадии, документы, критерии квалификации, способы приёмки и метрики результата.
общий инвариант
+ конфигурация конкретной программы
+ фактические участники и объекты
= исполнимая партнёрская цепочка
Программа при этом не равна одной цепочке. «30 марок × 30 экспертов» задаёт правила образования множества связок; каждая конкретная работа марки и эксперта остаётся отдельным эпизодом с собственными участниками, границами и результатом.
5. Инженерия требований в программе «30 марок × 30 экспертов»
Экспертная программа является самостоятельным предметным контуром, а не копией производственной программы с заменой слова «фабрика» на слово «эксперт». Её основной объект — задача марки и доказуемое изменение после экспертного вмешательства.
Требования сторон различаются:
- марке нужно понять, какой эксперт релевантен задаче, что потребуется на входе, какой результат можно получить и как его принять;
- эксперту нужна ограниченная постановка задачи, доступ к необходимым данным, понятные полномочия и способ зафиксировать результат, не раскрывая закрытый метод;
- сервису нужно показать функцию, условия применения и измеримый выход, не выдавая демонстрацию за внедрение;
- куратору нужно видеть взаимный интерес, следующий шаг, срок и подтверждение обеих сторон;
- Реестру нужна одна идентичность человека и отдельная связь
человек × программа × роль; - Конвейеру нужны события с источником, ключом дедупликации, режимом доступа и доказательством перехода;
- ИИ-агенту нужен ограниченный контракт действия: что он читает, что предлагает, что не вправе записывать или отправлять без approval.
Эти требования сводятся не в единый текст, а в связанную систему представлений.
реальный запрос и источники
↓
требования и ограничения сторон
↓
объекты и роли программы
↓
CJM: что видит и делает человек
↓
BPMN: кто, когда и на каком основании действует
↓
CRM: какое состояние подтверждено
↓
контракты автоматизации и контрольные проходы
↓
результат, отрицательный путь или новый разрыв
↓
версионирование библиотеки программы
После предметной проверки экспертного контура движение задачи описывается восемью рабочими стадиями. Их обозначения E0–E7 остаются временными до сверки с формальной BPMN и не являются утверждёнными индексами:
E0 вход в программу и принятие правил участия и обработки данных
↓
E1 регистрация и квалификация задачи без избыточных закрытых данных
↓
E2 предварительная реакция эксперта: релевантность, запрос данных,
мотивированный отказ или рекомендация другой компетенции
↓
E3 взаимный выбор и согласование формата, границ данных, результата,
ролей и коммерческих условий
↓
E4 консультация и предварительный итог, подтверждённый или исправленный маркой
↓
E5 следующий шаг: завершение, пауза или длительный проект
↓
E6 подтверждённый результат: стороны зафиксировали, что изменилось
↓
E7 CASE, опционально и только по отдельному согласию на публикацию
Каждая стрелка является отдельным требованием к доказательству. Публикация задачи не означает её квалификацию. Квалификация не означает ответ эксперта. Ответ не означает взаимный выбор. Факт созвона не означает подтверждённый результат. Длительная работа, подтверждённый результат и CASE являются последовательными, а не альтернативными состояниями. Подтверждённый результат может оставаться закрытым и при этом быть валидным результатом программы.
Согласие с правилами программы является первым наблюдаемым CJM-состоянием, а не подразумевается из добавления человека в чат. Оно возникает до квалификации задачи и содержательного взаимодействия. Марка и эксперт подтверждают правила участия и обработки данных, границы доступа и порядок следующего шага.
После консультации эксперт публикует предварительный итог: предмет разговора, позиции сторон, решение или расхождение, следующий шаг, владельца, срок и открытые вопросы. Марка подтверждает запись или исправляет её. Только после этого общий безопасный статус может быть перенесён в CRM и карточку. Такая двухсторонняя верификация одновременно является частью CJM и процессным шлюзом BPMN. До согласования правил, инфраструктуры и пользы для сторон она остаётся наблюдаемым фактом и не меняет рейтинг автоматически.
Минимальный координационный срез ограничен участниками и ролями, общим типом задачи, стадией, результатом этапа, следующим шагом и потребностью в других компетенциях. Рабочие чаты, документы, финансовые данные, содержание консультаций, диагностика, рекомендации и методология остаются в закрытом контуре эксперта и клиента. Их передача или использование для обучения моделей требуют отдельного основания и согласия.
До подключения текущих клиентских проектов модель проверяется на обезличенных сценариях и завершённых примерах. Отдельно проверяются отказ эксперта или марки, недостаток данных, отсутствие взаимного выбора, пауза, неподтверждённый результат и подтверждённый, но закрытый результат. После этого согласуются состав данных будущего пилота, место хранения, круг доступа, удаление, выход из программы, измеримая польза и метрики Альянса.
6. Почему одной CRM недостаточно
У одного человека может быть несколько экспертных задач, несколько ролей и участие в разных программах. Поэтому архитектура различает как минимум три уровня состояния:
человек
└── единая идентичность в Реестре
человек × программа
└── роль, участие, операционный фокус и ближайший шаг
человек × задача × контрагент
└── предметная стадия и доказательства конкретной работы
Попытка хранить все три уровня в одном поле создаёт ложные выводы. Завершённая консультация по одной задаче не делает все задачи человека завершёнными. Участие марки одновременно в производственной и экспертной программах не позволяет переносить производственный статус в экспертную вкладку. Изменение текущего фокуса не должно стирать историю предыдущих задач.
Поэтому Конвейер сначала собирает доказательный слой по объектам работы, затем формирует программную проекцию человека и только после проверки применяет минимальную дельту к CRM. Запись отделена от анализа источников; после записи выполняется readback; отдельная квитанция показывает, что изменилось, какие разрывы остались и какие действия требуют человека.
источники
↓
нормализованные события
↓
срез по задачам
↓
программная проекция человека
↓
проверенная дельта CRM
↓
readback
↓
квитанция и анализ разрывов
Такой конвейер может работать для разных программ, потому что не присваивает событиям предметный смысл самовольно. Правила перехода от события к стадии находятся в библиотеке программы и версионируются отдельно.
7. Библиотеки программ как механизм совместимости
Общая библиотека ИИИ и библиотеки программ образуют не иерархию подчинения, а систему совместимых контуров.
ИИИ
└── общий язык, схемы совместимости и общие паспорта
Библиотека «30×30 фабрики»
└── роли, параметры, CJM, BPMN и методы производственной программы
Библиотека «30×30 эксперты»
└── роли, задачи, CJM, BPMN и методы экспертной программы
Библиотека «30×30 магазины»
└── роли, квалификация, CJM, BPMN и методы розничной программы
Совместимость проверяется через явные манифесты, версии, контрольные суммы, границы доступа и список отсутствующих элементов. Общий паспорт может использоваться несколькими программами с одним идентификатором стандарта; предметный паспорт остаётся внутри своей библиотеки. Изменение экспертной стадии не меняет автоматически производственный CJM, а удачный локальный шаблон не становится общим правилом ИИИ без межпрограммной проверки.
Это решение сохраняет соавторство и одновременно разделяет архитектурные зоны ответственности. Речь идёт не о ретроспективном подсчёте коммитов или текстовых фрагментов, а о том, какой слой системы каждый соавтор развивает, проверяет и соединяет с остальными. Юлия Кондарева отвечает за CJM, запуск и воспроизводимость структуры программ; Денис Симонов — за BPMN, процессную модель, библиотеки и взаимодействие с агентами; Алина Цуцу и Алина Косоветис — за предметную модель экспертной программы и её проверку на реальных задачах; Лана Харьговская — за операционный контур сопровождения, CRM, рабочий ритм и проверку переходов на реальной работе; Анна Булгакова — за редакционную и техническую проверку интерфейсов, понятность текстов и реализуемость решений на платформе; Алексей Баженов — за соединение программ в общую инфраструктуру и партнёрские цепочки. Эти зоны встречаются в согласованных интерфейсах, версиях и критериях проверки, не растворяясь в обезличенном «общем документе».
8. Что меняется в архитектуре Альянса
Статья не вводит новую нумерацию и не превращает программы в новые сущности A. Она уточняет отношения между уже используемыми объектами.
В Онтологии Альянса полезно явно различить четыре понятия:
- программа — ограниченная среда совместной работы с участниками, правилами, ритмом и критериями результата;
- библиотека программы — версионируемое описание её ролей, маршрутов, процессов, документов и границ автоматизации;
- программная проекция участника — роль, состояние и ближайший шаг конкретного человека внутри одной программы;
- Конвейер сопровождения — общая инфраструктура, которая собирает подтверждённые изменения по разным программам, но не подменяет их предметные правила.
Связи между ними можно описать так:
человек участвует в программе в определённой роли
программа описывается собственной библиотекой
программа использует Реестр и Конвейер как общую инфраструктуру
конкретная совместная работа образует TRxTR
несколько сопоставимых TRxTR могут дать основание для A1.x
Для архитектуры кооперационных сборок <code>A</code> это важное уточнение. Программа не равна кооперационной сборке A1.x, а отдельная партнёрская цепочка не получает такой индекс автоматически. Программа создаёт среду, в которой возникают и проверяются реальные пересечения траекторий. Только несколько сопоставимых случаев, матрица требований, повторяемый состав ролей и подтверждённый способ сборки позволяют рассматривать кандидат A1.x.
программа
↓ создаёт условия для повторяющихся случаев
TRxTR + TRxTR + TRxTR
↓ сопоставление требований, ролей и результатов
кандидат повторяемой сборки A1.x
↓ экспертная и архитектурная проверка
принятая модульная сборка
Поэтому в статье об A следует добавить явную границу: программа, её библиотека, комната, событие и единичная цепочка являются источниками опыта, но не самой сборкой A1.x. Это изменение не отменяет действующую модель A; оно делает понятнее путь от эксперимента к воспроизводимой кооперации.
Из статьи следуют и практические изменения паспортов: общая структурная оболочка программ; отдельный паспорт библиотеки каждой программы; наблюдаемое согласие с правилами; единая связь программ с Реестром и Конвейером; интеграционная проверка нескольких библиотек в «Симуляции моды». Эти изменения сначала применяются в рабочих паспортах и пилотах. Дельты Онтологии и страницы A проходят отдельную архитектурную сверку перед публикацией.
9. «Симуляция моды» как интеграционный тест
Отдельная программа «Симуляция моды» позволяет проверить не только один маршрут, но и совместимость нескольких библиотек. В игровом цикле марка выбирает эксперта, затем вместе с ним — производство, после чего команда готовит предложение ритейлеру и реагирует на одно риск-событие.
марка
↓ выбирает
эксперта
↓ вместе выбирают
производство
↓ команда готовит предложение
ритейлеру
↓
готовая цепочка получает риск
↓
пересобирает договорённости и защищает решение
Симуляция не является Конвейером и не подменяет реальные сделки. Она выступает цифровым crash test архитектуры: одинаково ли участники понимают роли, достаточно ли данных в профилях, работают ли документы передачи, различаются ли решения человека и агента, сохраняется ли происхождение результата. Неудача команды в игре может быть полезным результатом, если она показывает конкретный разрыв между библиотеками программ.
10. Проверяемые гипотезы и метрики
Архитектура должна оцениваться не по числу созданных паспортов. Для пилота предлагаются пять групп показателей.
Качество переходов: время от задачи до первого предметного ответа; доля переходов с источником и подтверждением; доля консультаций, по которым обе стороны зафиксировали итог.
Сохранность состояния: число перезаписанных или потерянных исторических состояний; число конфликтов между CRM, карточкой и источником; доля отрицательных путей, сохранённых с причиной.
Совместимость программ: число общих паспортов, используемых без копирования; число предметных параметров, ошибочно перенесённых между программами; доля библиотек, прошедших проверку манифеста и прав.
Устойчивость автоматизации: повторный прогон без дублей; доля записей с успешным readback; число внешних действий, остановленных корректным gate; число разрывов, обнаруженных до сообщения участнику.
Масштабирование: время и объём ручной работы на запуск новой программы; доля структурной оболочки, переиспользованной без изменения смысла; время до первой подтверждённой партнёрской цепочки.
Экономические выводы требуют отдельного дизайна исследования и исходной линии. Более быстрый ответ или более полная CRM ещё не доказывают снижение транзакционных издержек, рост выручки или устойчивость сети. На текущем этапе проверяется механизм координации и качество доказательств.
11. Ограничения
Исследование основано на развивающихся пилотах, поэтому часть CJM, BPMN, метрик и библиотек имеет статус кандидата. Наблюдаемое улучшение интерфейса не равно подтверждённому улучшению результата участника. Реальные задачи создают сильную эмпирическую основу, но не образуют случайную или контрольную выборку.
Состояния программы зависят от качества источников и своевременности человеческого подтверждения. ИИ может извлечь кандидат факта, обнаружить противоречие и подготовить дельту, но не вправе заменять согласие стороны правдоподобным выводом. Закрытый метод эксперта, коммерческие данные, рабочие документы и личные переписки не становятся частью программной библиотеки. Текущие клиентские проекты не входят в пилот автоматически.
Наконец, одинаковая структурная оболочка программ остаётся гипотезой до проверки на программах, существенно отличающихся от 30×30: Сопровождении, Лаборатории, образовательных и финансовых контурах.
Заключение
Переход от одной успешной программы к портфелю из десятков программ требует нового этапа балансировки. Недостаточно согласовать требования марки и фабрики, марки и эксперта или марки и магазина. Нужно согласовать требования самих программ к общей идентичности, данным, автоматизации, агентам и правилам переноса опыта.
Предлагаемая архитектура удерживает это разделение: ИИИ задаёт общий язык и совместимость; Реестр хранит единую идентичность; Конвейер собирает и проверяет изменения; программы интерпретируют их в собственных предметных моделях; библиотеки программ сохраняют CJM, BPMN, документы и критерии результата. Благодаря этому общая инфраструктура может масштабироваться, не превращая разнообразие рынка в один универсальный статус.
Программа «30 марок × 30 экспертов» делает эту гипотезу проверяемой. Её инженерный результат — не список экспертов и не число встреч, а воспроизводимый переход от согласия и квалифицированной задачи к подтверждённому результату, в котором видны требования, решения, доказательства, отрицательные пути и границы автоматизации. Следующий этап исследования — сначала проверить модель на обезличенных сценариях и завершённых примерах, затем согласовать условия одного будущего пилота и только после этого сравнивать независимые циклы по заранее зафиксированным метрикам.
Зоны ответственности соавторов в архитектуре
Соавторство в этой работе не измеряется количеством коммитов, страниц или отдельных формулировок. Архитектура разделена на связанные зоны, в которых начинается и развивается работа каждого соавтора:
- Юлия Кондарева — CJM, запуск программ и воспроизводимость их структурной оболочки;
- Денис Симонов — BPMN, процессная модель, устройство программных библиотек и взаимодействие с ИИ-агентами;
- Алина Цуцу и Алина Косоветис — предметная модель экспертной программы и проверка архитектуры на реальных задачах марок и экспертов;
- Лана Харьговская — операционный контур сопровождения, CRM, рабочий ритм программы и проверка переходов и разрывов на реальной работе;
- Анна Булгакова — редакционная и техническая проверка интерфейсов, понятность текстов для участника и реализуемость решений на платформе;
- Алексей Баженов — балансировка программ, их соединение с общей инфраструктурой и проектирование партнёрских цепочек.
Разделение зон не изолирует работу соавторов. CJM должен быть согласован с BPMN, предметная модель — с реальными задачами, библиотеки — с общей инфраструктурой, а партнёрская цепочка — с проверяемым опытом участников. Поэтому результат возникает в точках соединения зон и уточняется по мере пилотов.
Зоны ответственности описывают текущую архитектурную рамку. Соавторы могут уточнять их по результатам пилотов; такие изменения фиксируются как новые версии, а не как переписывание происхождения решений.
Связанные научные работы
- Как сбалансировать требования экспертов и не остановить развитие общей системы.
- От альянсных контрактов к координационной системе: зачем мы изучаем David Mosey.
- От переговоров к обучающейся отраслевой сети: требования, роли и проверяемый цифровой след.
- Malone, T. W., Crowston, K. The Interdisciplinary Study of Coordination. DOI: 10.1145/174666.174668.
- Hevner, A. R. et al. Design Science in Information Systems Research. DOI: 10.2307/25148625.
- Peffers, K. et al. A Design Science Research Methodology for Information Systems Research. Journal publication.
- Oliveira, N., Lumineau, F. How Coordination Trajectories Influence the Performance of Interorganizational Project Networks. DOI: 10.1287/orsc.2017.1151.
Следующий этап совместной проверки
Публикация фиксирует рабочую исследовательскую версию, а не завершение архитектуры. Следующий цикл совместной проверки включает:
- проверку зон ответственности на реальной работе;
- отделение принятых CJM/BPMN от кандидатных версий;
- проверку термина «балансировка второго порядка» на других программах;
- уточнение научных ссылок и библиографического оформления;
- дальнейшее различение работающих, пилотных и планируемых механизмов;
- версионирование изменений после новых программных циклов;
- утверждение минимального координационного среза, режима данных и условий отдельного согласия будущего пилота.
