Люди + агенты как единая управляемая структура · глубокий разбор#

📖 Как читать этот документ#

Это источник-правды для систематизации компании под AI: не верхушка, а уровень внедрения. Документ устроен как набор контуров C1–C5 + надстройки A (Агенты), слоя D (Данные) и сквозных правил и контроля (Governance) — каждый раскрывает один слой управляемости от карты бизнеса до дашборда собственника. Каждый раздел написан по единому шаблону: Что это · Сущности (именованные объекты) · Механика · Кто делает · Зачем/что ломается без · По этапам зрелости · Как внедряется (SMB без ERP) · Антипаттерны · Связи. Читать сверху вниз (хребет строится снизу) либо точечно — по нужному контуру через Связи.

👔 Короткая версия для собственника (5 мин) →

🏷️ Название и позиция#

Ядро (что это технически): «AI-система управляемости» / System of Control — слой, который делает компанию управляемой через единый цифровой след людей и агентов.
Витрина (как звучит собственнику): «Командный центр собственника» (Owner Cockpit) — поверхность, на которой собственник приоритизирует, мониторит, симулирует.
Позиция в одном предложении: это system-first, а не AI-first — сначала выстраивается управляемость (процессы, роли, регламенты, данные, контроль), и только поверх неё садится AI как усилитель; именно этот порядок — антидот к 95% (MIT) / 80% (RAND) провалов пилотов.

🧭 Схема контуров#

Кликни по картинке — откроется интерактивная схема. Горизонтальный вариант для слайда/печати: landscape.

Хребет читается снизу вверх: C1 Карта → C2 Процессы → C3 Люди → C4 Регламенты → C5 Контроль → Управляемость. +A Агенты — надстройка над слоем людей (помощник), а на верхних стадиях — и узел-сотрудник рядом с ними (цифровой сотрудник). Слева направо разнесены слой действий (люди работают как привыкли) и слой данных (агенты собирают след фоном) — они сходятся в D · SSOT. Обратная петля контроля: «горит» в C5 возвращается правкой в C2/C4. Governance прошивает все контуры. Ось зрелости — сбоку, целевой скачок 3→4.

System of Control: детальная карта архитектуры AI-ориентированной организации — Governance, контуры C1–C5, +A Агенты, слой действий и слой данных, онтология-ядро. — Детальная карта всей архитектуры одним кадром: Governance обрамляет контуры C1–C5 и надстройку **+A Агенты**; слева — слой действий (люди), справа — слой данных, в центре — онтология-ядро и SSOT-конвейер.

🪜 Лестница зрелости#

Путь от «зоопарка» ботов к системному бизнесу: лестница стадий 3→4, пять контуров и сравнение характеристик. — Путь от «зоопарка» ботов к системному бизнесу: целевой скачок стадия 3 → стадия 4 (единый SSOT, исполняемые AOP, дашборд собственника) — вся методика одной картинкой.

Почему 95% AI-пилотов проваливаются: автоматизируют хаос вместо системы.

Стадия	Что характеризует	Где AI	Целевой скачок
1 · Awareness	Всё руками; структура и правила в головах; AI отрицают/осознают. Карты, ролей, следа нет.	Нет / точечное любопытство
2 · Active	ChatGPT точечно, ad hoc; нет своих систем, реестров, владельцев; результат не оседает.	Внешний чат, ручной копипаст
3 · Operational «зоопарк»	Свои боты есть, но вразнобой: дубли, рассинхрон, у каждого свой «клиент» и своё хранилище; риск ключевого лица (bus-factor); silent failures незаметны.	Разрозненные узкие боты без реестра	━━ старт скачка ━━
4 · Systemic «контур»	Единая карта+онтология, реестры ролей/процессов/агентов, единый SSOT, governed-KPI, дашборд, федеративная конституция, drift-детекция.	Стандартизованные агенты в едином контуре	◀▶ ЦЕЛЕВОЙ СКАЧОК 3→4 (макс. ценность по MIT)
5 · Transformational	Управляемость как система; AI-native операционка; контуры самоподдерживаются, роли двигаются вверх по value stack; симуляция «что-если».	AI штатная прослойка действие↔данные

🗺️ C1 · Карта бизнеса (фундамент)#

C1 · Единая карта бизнеса и онтология — фундамент.

Что это#

C1 — это контур, который отвечает на единственный вопрос, без ответа на который любой AI-слой галлюцинирует: «что вообще представляет собой этот бизнес как объект, который мы собираемся оцифровывать?». Это L0 zoo-фреймворка — карта, которую все вышестоящие контуры (процессы, люди, агенты, данные, контроль) обязаны буквально повторить своей структурой. C1 фиксирует продукт, ценностные потоки, узлы (отделы/функции) и их владельцев, границы бизнеса и — главное — единую онтологию/идентичность (что в этой компании считается «клиентом», «сделкой», «объектом»). Без согласованной онтологии два бота, два сотрудника и три таблицы под словом «клиент» понимают три разные вещи, и SSOT (контур D) собирается из взаимно несводимых фактов.

Роль C1 — быть «РАГ для сознания» собственника и для всех агентов: статической, человекосозданной точкой опоры, относительно которой считываются все остальные слои. Это не «стратегия» и не «миссия» — это инженерный скелет-модель бизнеса на одну страницу, по которому видно, из каких частей он состоит, кто за каждую отвечает и где проходит его контур. По грунту Дмитрия это business map по Рыбакову (Продукт → проекты/процессы → люди → управление → инструменты) и «база знаний клиента как фундамент». По индустрии это пересечение Ontology/Identity-компонента Context Layer (Atlan) и языка Digital Twin of Organization (Gartner) — карты, на которой собственник «приоритизирует, мониторит, симулирует».

Сущности#

Конкретные артефакты, которые создаются и существуют в C1:

Business Map (одностраничная карта) — единственный обязательный артефакт контура. Формат: один файл 00-MAP.md (или одна страница Notion/один лист Miro). Структура жёстко по слоям Рыбакова: Продукт → Проекты/Процессы → Люди → Управление → Инструменты. Это скелет-модель бизнеса: схема, которую остальные контуры наполняют. Пример строки слоя «Люди»: Узел: Продажи · Владелец: Ирина (РОП) · Вход: лид · Выход: оплаченная сделка.
Карточка продукта (Product Definition) — что компания продаёт и за какой результат клиент платит. Поля: название · обещанный результат (jobs-to-be-done) · единица продажи · за что именно идёт оплата · что НЕ входит. Это якорь: ценностные потоки и определение «сделки» выводятся отсюда, а не наоборот.
Реестр ценностных потоков (Value Streams) — список сквозных потоков «от триггера до ценности у клиента». Формат строки: Поток · стартовый триггер · конечная ценность · какие узлы пересекает. Пример: Поток «Производство тиража» · триггер: подтверждённый макет · ценность: отгруженный тираж · узлы: продажи→препресс→печать→логистика. Это мост к C2 (процессы) — поток разворачивается в процессы.
Реестр узлов и владельцев (Nodes & Owners) — отделы/функции как «узлы федерации». Поля: узел · функция (зачем существует) · владелец (1 имя) · вход · выход · граничит с (узлы). Принцип федеративной конституции: каждый узел суверенен (свой 00-CONTEXT как локальная база), но подчинён общим стандартам карты. Один владелец на узел — обязателен (антидот риску ключевого лица).
Онтология / Глоссарий идентичности (Ontology · 04-glossary.md) — ядро контура и его самая недооценённая сущность. Это таблица единых определений ключевых сущностей бизнеса. Поля: Термин · Определение (что СЧИТАЕТСЯ этим) · Когда возникает · Когда закрывается/исчезает · Уникальный ключ (как опознаём дубль) · Чем НЕ является. Пример: Клиент = юрлицо, по которому есть ≥1 оплаченная сделка; ключ — ЕДРПОУ/ИНН; НЕ клиент — лид без оплаты. Без этого case_id в будущем event-логе (контур D) собирать не из чего.
Границы бизнеса (Boundaries) — явный список того, что внутри контура и что снаружи: что делаем сами · что отдано подрядчику · где кончается наша ответственность · смежные юрлица/каналы. Закрывает зону, где обычно течёт «теневая работа» вне всякого учёта.
Карта инструментов (Tooling Inventory) — где сейчас физически живут данные каждого узла: узел · инструмент (Excel/CRM/чат/голова) · кто ведёт · формат. Это вход для контура D: показывает, из каких источников агентам предстоит порождать след с нуля (для SMB без ERP — критично).

Механика (что происходит)#

Поток работы через контур, по шагам:

Сбор сырья. Собственник + аналитик проходят бизнес сверху вниз по слоям Рыбакова: что продаём → какими потоками это создаётся → какие узлы участвуют → кто владелец каждого → чем меряют → где данные. Источник — интервью, не догадки.
Определение продукта. Заполняется карточка продукта. От «за что платит клиент» отстраивается всё остальное (иначе ценностные потоки описывают активность, а не ценность).
Прорисовка ценностных потоков. Каждый поток фиксируется как линия «триггер → ценность» с перечнем узлов. Потоки — горизонтальны, узлы — вертикальны; их пересечение даёт матрицу ответственности.
Кристаллизация онтологии. Самый дорогой шаг: команда договаривается, что считается клиентом/сделкой/объектом, и фиксирует ключи идентичности. Здесь вылавливаются конфликты («у продаж клиент = контакт, у бухгалтерии = юрлицо»). Расхождение не замазывается — выносится в обсуждение и разрешается одним определением.
Назначение владельцев и границ. Каждому узлу — один владелец; явно отрезается внешнее (подрядчики, смежные юрлица).
Сборка карты. Всё сводится в один артефакт 00-MAP.md. Критерий готовности: новый человек (или новый агент) по карте за 15 минут понимает, из чего состоит бизнес и кто за что отвечает.
Замок на верхние контуры. Карта становится обязательным шаблоном: C2 повторяет потоки→процессы, C3 повторяет узлы→роли, D строит SSOT по онтологии C1. Любой вышестоящий контур, не сводимый к карте, — сигнал, что карта неполна, и его правят, обновляя C1.

Что во что превращается: интервью → карточка продукта → потоки → узлы+владельцы → онтология (ядро) → одностраничная карта → шаблон-инвариант для всех контуров.

Кто делает#

Определение продукта и границ бизнеса — СОБСТВЕННИК (это его картина мира; делегировать нельзя, можно только записать с его слов).
Кристаллизация онтологии/идентичности — СОБСТВЕННИК утверждает, ЧЕЛОВЕК-аналитик фасилитирует и сводит конфликты определений. Это решение уровня владельца, потому что от него зависит, как считается весь бизнес.
Прорисовка ценностных потоков и реестра узлов — ЧЕЛОВЕК-аналитик (внешний консультант или внутренний COO) на интервью с владельцами узлов.
Назначение владельца узла — СОБСТВЕННИК (только он может закрепить ответственность).
Сборка и оформление карты в 00-MAP.md, ведение глоссария, проверка консистентности терминов — AI-АГЕНТ (структурирует сырьё интервью в шаблон, ловит синонимы и дубли определений, предлагает уникальные ключи; человек создаёт истину, агент усиливает).
Поддержание карты в актуальном состоянии (диффы при изменении структуры) — AI-АГЕНТ предлагает, ЧЕЛОВЕК-владелец карты утверждает.

Принцип сквозной: истину создаёт человек (особенно собственник для онтологии), AI — усилитель и оформитель, расчёт и определения не выдумывает.

Зачем / что ломается без него#

C1 — фундамент, потому что это единственный контур, задающий систему координат. Без него:

Онтологический хаос. Под «клиентом» каждый узел понимает своё → SSOT (D) собирается из несводимых фактов → дашборд собственнику (C5) показывает суммы, которые ничего не значат («у нас 200 клиентов» — это контакты, оплаты или юрлица?).
Агенты галлюцинируют структуру. Бот без карты не знает, к какому узлу относится задача и что считать сделкой — порождает мусорный след, который потом нельзя свести.
Риск ключевого лица. Нет реестра узлов и владельцев → знание «как тут всё устроено» живёт в голове одного человека; уходит он — карта теряется.
Scope creep сверху. Без границ агенты и процессы расползаются на смежные юрлица и теневую работу, и никто не знает, где кончается бизнес.
AI-first вместо system-first. Без карты компания строит ботов на несуществующем фундаменте — отсюда 95% (MIT) / 80% (RAND) провалов пилотов. C1 — это и есть «сначала система, AI поверх».

По этапам зрелости#

1 Awareness. Карты нет вообще. Структура бизнеса — в голове собственника; «клиент» и «сделка» каждый понимает по-своему. На вопрос «из чего состоит бизнес» собственник отвечает разными словами в разные дни.
2 Active. Карты как артефакта нет, но собственник от руки/в ChatGPT набрасывает структуру ad hoc под конкретную задачу. Определения возникают разово и не сохраняются; узлы и владельцы нигде не закреплены.
3 Operational («зоопарк»). Появились куски карты, но разрозненно: оргсхема в одном файле, прайс — в другом, у каждого бота своё представление о «клиенте». Дубли определений, противоречия между источниками. Нет одного 00-MAP.md и единой онтологии — самый дорогой провал, потому что данные уже копятся, но несводимы.
4 Systemic («контур»). Есть единая одностраничная карта 00-MAP.md, единая онтология с ключами идентичности, реестр узлов с одним владельцем на каждый. Карта — обязательный инвариант: процессы, люди, SSOT и дашборд повторяют её. Узлы суверенны, но подчинены общим определениям (федеративная конституция).
5 Transformational. Карта живёт как живая модель бизнеса: агенты читают её как контекст в runtime, изменение структуры бизнеса автоматически отражается в карте (агент предлагает дифф), собственник по ней «приоритизирует, мониторит, симулирует». Онтология — исполняемый контракт для всех агентов, а не документ.

Как внедряется (для SMB без ERP)#

Интервью с собственником (60–90 мин). Пройти 5 слоёв Рыбакова вслух. Записать дословно — это сырьё.
Карточка продукта. Один экран: результат, единица продажи, за что платят, что не входит. Согласовать с собственником.
Реестр узлов. Выписать все отделы/функции, на каждый — один владелец, вход, выход, соседи. Незакрытые («владельца нет») пометить красным — это будущие проблемы C3.
Реестр ценностных потоков. 3–7 главных потоков «триггер → ценность → узлы». Больше 7 для SMB — признак переусложнения.
Сессия онтологии (отдельная, самая важная). Собрать владельцев узлов, на каждый ключевой термин (клиент, сделка, объект, лид) выработать ОДНО определение + уникальный ключ + «чем не является». Зафиксировать в 04-glossary.md. Конфликты разрешает собственник.
Границы. Один список: своё / подрядчик / смежные юрлица / где кончается ответственность.
Карта инструментов. На каждый узел — где сейчас данные (Excel/чат/голова). Это вход для контура D.
Сборка 00-MAP.md. Агент сводит всё в одну страницу по шаблону карты. Тест готовности: новичок за 15 мин понимает бизнес.
Замок-инвариант. Объявить карту обязательным шаблоном: ни один процесс/бот/таблица не заводится, если не привязан к узлу и не использует онтологию C1.

Артефакты на выходе: 00-MAP.md, карточка продукта, 04-glossary.md (онтология), реестры узлов/потоков/инструментов, список границ. Всё — текстовые файлы/одна страница, без ERP.

Антипаттерны / грабли#

«Нарисовали оргсхему — считаем, что есть карта». Оргсхема — это иерархия людей, а не карта потоков, узлов и онтологии. По Минцбергу: организация — сообщество, а не оргсхема; карта без ценностных потоков и определений мертва.
Пропустить онтологию («и так все знают, кто такой клиент»). Самая дорогая ошибка: расхождение всплывёт на контуре D, когда несводимый след уже накопится. Онтология — не бюрократия, это case_id будущего event-лога.
Несколько владельцев (или ноль) на узел. «Отвечают все» = не отвечает никто; риск ключевого лица и пинг-понг. Ровно один владелец, всегда.
Карта-простыня вместо одной страницы. Если карта не помещается на экран и её не читают за 15 минут — это не L0, это документация. Длинно = мёртво.
Описывать «как хотим», а не «как есть». Карта — слепок реальности (грунт для process mining: «регламент vs факт»). Идеализированная карта расходится с тем, что породят агенты, и обесценивает SSOT. Сначала «как есть», улучшение — позже.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3 · «зоопарк»). Структура — в голове владельца. «Клиент» у продаж = оставивший заявку, у цеха = тот, чью кухню пилят, у бухгалтерии = внёсший предоплату. Один человек — три записи в трёх таблицах, отчёты не сходятся.

Стало (4 · «контур»). Одна страница 00-MAP.md + единая онтология: узел = строка с одним владельцем, «клиент» определён один раз.

Пример записи (строка карты + строка онтологии):

КАРТА → Узел: Продажи · Владелец: Ирина (РОП) · Вход: лид · Выход: договор+предоплата
ОНТОЛОГИЯ → Клиент = физлицо с подписанным договором и предоплатой ≥30%;
            ключ = телефон+e-mail; «замер без договора» = ЛИД, не клиент;
            возникает при подписании, закрывается при подписании акта монтажа

Полный сквозной разбор перехода 3→4 на другой компании (автосервис) — Приложение B.

Связи#

→ C2 Процессы (выход). Ценностные потоки C1 разворачиваются в процессы; C2 обязан повторить потоки карты. Вход для C2 — реестр Value Streams.
→ C3 Люди (выход). Реестр узлов и владельцев C1 — это скелет ролей и ответственности C3. Узел = будущая роль/00-CONTEXT суверенного узла.
→ +A Агенты (выход). Карта — контекст («РАГ для сознания») для каждого агента: к какому узлу он привязан, что считать сделкой. Без C1 у агента нет границ scope (отсюда scope creep).
→ D Данные/SSOT (выход, критичный). Онтология C1 задаёт схему SSOT и ключи идентичности (case_id, уникальные ключи дублей). Карта инструментов C1 — список источников, из которых агенты порождают след. SSOT собирается строго по определениям C1.
→ C5 Контроль/Дашборд (выход). Узлы карты — это разрезы дашборда; продукт и потоки задают, какие метрики вообще имеют смысл. KPI считаются на сущностях, определённых в онтологии C1.
← Governance (вход/сквозное). Федеративная конституция опирается на C1: узлы суверенны (своя локальная база), но обязаны общим определениям и шаблону карты. Governance = runtime-enforcement инварианта «всё привязано к карте».
← Обратная связь от всех контуров. Если любой контур не сводится к карте — это сигнал неполноты C1; карта правится. C1 — единственный контур, который остальные обязаны буквально повторить.

⚙️ C2 · Процессы#

C2 · Потоки ценности, точки handoff и цифровой след.

Что это#

Контур C2 — это слой ДЕЙСТВИЙ организации, разложенный на повторяемые единицы работы: процессы. Если C1 (Карта бизнеса) отвечает на вопрос «из чего состоит компания и как создаётся ценность» статически, то C2 описывает динамику — как ценность реально течёт от триггера к результату руками людей и агентов. В хребте Дмитрия это первый слой («ПРОЦЕССЫ → дела»): пока он не разложен, всё, что выше (люди, регламенты, контроль, агенты, данные), повисает в воздухе — нельзя назначить роль на несуществующий шаг, нельзя написать регламент к неописанной работе, нельзя посадить агента собирать след там, где не определено, какое действие он сопровождает.

Роль контура двойная. Во-первых, это операционная карта: инвентаризация того, как работа происходит «как есть» (as-is) ДО любой автоматизации — без неё AI-first превращается в автоматизацию хаоса. Во-вторых, это скелет цифрового следа: каждый шаг процесса — это место, где агент потом фоном соберёт данные (см. слой D), а собственник на дашборде (C5) увидит, где работа стоит. В SMB без ERP это особенно важно: процессов формально нет нигде, кроме голов людей, и контур C2 — первое, что превращает «ремесло» в «систему» (Craft2Scale).

Сущности#

Конкретные объекты, которые создаются и живут в этом контуре:

Карточка процесса (Process Card) — атомарная единица контура. Формат — markdown-файл или строка в реестре с полями: id (P-001), название (глагол + объект: «Обработать входящую заявку»), триггер (что запускает: «лид написал в Instagram Direct»), шаги (нумерованный список 5–15 действий), результат/выход (что на выходе: «заявка квалифицирована, в CRM, назначен менеджер»), владелец процесса, участники-роли, частота (N раз/день), точки handoff, статус (as-is / to-be / автоматизирован). Пример: P-003 «Выставить счёт» — триггер «менеджер закрыл сделку» → 6 шагов → выход «счёт отправлен клиенту, занесён в учёт».
SIPOC-таблица — паспорт процесса на одной странице: Supplier (кто даёт вход) | Input (что на входе) | Process (5–7 макрошагов) | Output (что на выходе) | Customer (кто получает результат). Заполняется ПЕРЕД детализацией шагов — это рамка, не дающая процессу «расползтись». Пример для найма: Supplier=рекрутер → Input=отклик кандидата → Process=скрининг→интервью→оффер → Output=вышедший сотрудник → Customer=руководитель отдела.
Карта потока ценности (Value Stream) — последовательность процессов, через которые проходит ОДИН тип ценности от запроса клиента до денег/результата. Не отдельный процесс, а цепочка карточек: «Лид → Квалификация → КП → Договор → Производство → Отгрузка → Оплата». Формат — горизонтальная диаграмма со временем на каждом шаге и временем ожидания МЕЖДУ шагами (где копится потеря).
Реестр процессов (Process Registry) — единая таблица всех карточек: id, название, владелец, value stream, зрелость, автоматизация, критичность для выручки. Это оглавление контура; первый артефакт, который видит собственник.
Карта handoffs (точки передачи ответственности) — отдельный список мест, где работа переходит от одного исполнителя/роли/системы к другому. Каждый handoff — поле: от_кого → кому, что передаётся, канал, риск разрыва. Это самые хрупкие точки (классика: «кандидат приехал на смену — а работы для него нет»: handoff между рекрутингом и планированием не сработал). Именно здесь процессы ломаются чаще всего, не внутри шагов.
Различение процесс vs проект — рабочая классификация (не один файл, а правило сортировки реестра): процесс = повторяемый, один и тот же триггер→результат много раз (его автоматизируют, регламентируют, сажают агента); проект = уникальный, разовый, с началом и концом (его не регламентируют, им управляют как набором задач). Путаница ломает весь контур: попытка «зарегламентировать» проект даёт мёртвый PDF, попытка «вести проектом» процесс даёт ручное переизобретение каждый раз.
Event Log (журнал событий) — таблица фактического исполнения, минимум 4 поля: case_id (id конкретного прохода — заявка №451), activity (выполненный шаг), timestamp, actor (кто). В SMB без ERP его не существует — и ключевая идея контура: агенты ПОРОЖДАЮТ его с нуля, фоново фиксируя каждый шаг по мере работы людей. Именно Event Log позволяет потом сравнить «регламент vs факт» (process mining).

Механика (что происходит)#

Работа течёт через контур так:

Инвентаризация as-is. Берётся value stream (например, «от лида до оплаты»), и для каждого звена заводится карточка процесса в формате «как есть на самом деле» — со слов того, кто реально делает работу, а не как «должно быть». Сначала SIPOC (рамка), потом детализация шагов.
Выявление handoffs. По каждой карточке отмечаются точки передачи — где работа уходит из рук в руки. Они выписываются в отдельную карту: это будущие точки отказа и места, где данные теряются.
Разметка процесс/проект. Реестр сортируется: повторяемое идёт в кандидаты на регламент+агента (C4/+A), уникальное выводится в проектное управление.
Наложение слоя данных. Для каждого шага определяется, какой цифровой след он оставляет (или должен оставлять) → это спецификация для агента: «когда менеджер отвечает лиду — агент фиксирует событие в Event Log». Так СЛОЙ ДЕЙСТВИЙ (человек работает как привык) разносится со СЛОЕМ ДАННЫХ (агент собирает фоном).
Сравнение факт vs регламент. Когда Event Log накопился — фактический путь процесса (как реально идут case_id) сопоставляется с задуманным. Расхождение («регламент говорит 5 шагов, факт — 8, и два — петли переделок») — это вход для оптимизации.
Итерация. Узкое место/разорванный handoff/лишний цикл переделки → переписывается карточка (as-is → to-be) → меняется регламент (C4) → перенастраивается агент (+A). Контур живой, не одноразовый.

Превращения: разговор с сотрудником → карточка процесса; набор карточек → value stream; шаги карточки → спецификация следа → Event Log; Event Log + карточка → диагноз расхождения → новая версия процесса.

Кто делает#

Инвентаризация процессов «как есть» (интервью исполнителей, черновик карточек) — AI-АГЕНТ (process-interviewer) формулирует и структурирует, ЧЕЛОВЕК-исполнитель даёт фактуру («истину создаёт человек, AI — усилитель»).
Утверждение, что процесс описан верно — ЧЕЛОВЕК-исполнитель/владелец процесса (только он знает реальность).
Назначение владельца процесса — СОБСТВЕННИК (это управленческое решение, не делегируется агенту).
Разметка процесс vs проект, приоритизация по критичности для выручки — СОБСТВЕННИК при поддержке агента-аналитика.
Ведение реестра процессов, поддержание актуальности карточек — AI-АГЕНТ (фоново), ревизия — ЧЕЛОВЕК (владелец).
Порождение Event Log, фиксация шагов — AI-АГЕНТ (полностью фоново, человек работает как привык).
Диагноз «факт ≠ регламент», предложение to-be — AI-АГЕНТ готовит, ЧЕЛОВЕК/СОБСТВЕННИК решает (изменение процесса необратимо для людей → human-in-the-loop).

Зачем / что ломается без него#

Без C2 организация не имеет языка, чтобы вообще говорить о работе системно. Конкретные провалы при отсутствии контура:

Автоматизация хаоса. Сажают агента на процесс, которого никто не описал → агент «галлюцинирует к шагу 3», потому что шаги нигде не зафиксированы, и каждый исполнитель делает по-своему.
Риск ключевого лица. Процесс живёт только в голове одного человека; он уходит в отпуск/увольняется — работа встаёт (типичная боль стадии «зоопарк»).
Разрыв на handoff. Самый дорогой класс провалов: «кандидат приехал — работы нет», «сделка закрыта — счёт не выставлен», «заявка пришла — никто не взял». Внутри каждого участка всё работает, но на стыках теряется, и никто не владеет стыком.
Нет базы для остального хребта. Нельзя написать регламент (C4) к неописанному процессу, нельзя посчитать KPI (C5) для несуществующих шагов, нельзя собрать данные (D) там, где не определено действие. C2 — фундамент, на котором стоят C4/C5/D.
Невозможность отличить «надо чинить процесс» от «надо лучше делать проект» → регламентируют разовое, теряют время на переописание уникального.

По этапам зрелости#

1 Awareness. Процессов как сущности нет вообще. Работа = «как привыкли», передаётся изустно, существует только в головах. Никто не отличает процесс от проекта. Handoffs невидимы, разрывы списывают на «человеческий фактор».
2 Active. Появляются разрозненные описания (кто-то набросал инструкцию в заметках, спросил ChatGPT «опиши процесс продаж»). Ad hoc, несвязно, без реестра и владельцев. Карточек нет — есть случайные тексты.
3 Operational («зоопарк»). Некоторые процессы описаны и даже частично автоматизированы своими ботами, но разрозненно: дубли описаний, у одного процесса две версии, нет единого реестра, владельцы не назначены, Event Log если и есть — у каждого бота свой. Handoffs между «островами автоматизации» рвутся. Риск ключевого лица сохраняется на уровне «кто настроил бота».
4 Systemic («контур»). Единый реестр процессов, у каждого — карточка по стандарту, назначен владелец, размечены value streams и handoffs. Агенты фоново порождают общий Event Log → можно сравнивать факт vs регламент. Процесс vs проект разведены. Это целевое состояние перехода 3→4.
5 Transformational. Контур самоподдерживающийся: процессы непрерывно сверяются с фактом, агенты предлагают оптимизацию, новые процессы заводятся по шаблону с первого дня с уже встроенным следом. Управляемость процессов = система, а не разовая инвентаризация; AI-native операционка.

Как внедряется (для SMB без ERP)#

Выбрать ОДИН денежный value stream — обычно «от лида до оплаты». Не описывать всю компанию сразу (узкий scope выживает, scope creep убивает).
Разложить его на 5–9 макропроцессов и завести реестр (одна таблица: id, название, владелец-кандидат, критичность).
На каждый процесс — SIPOC на одну страницу, затем карточку as-is со слов исполнителя (агент-интервьюер структурирует, человек подтверждает).
Выписать handoffs в отдельную карту — сразу видны самые хрупкие стыки, их чинить первыми.
Назначить владельца каждого процесса (решение собственника) — без владельца стык ничей.
Развести процесс/проект в реестре.
Определить цифровой след каждого шага → спецификация для агента, который начнёт порождать Event Log с нуля (в SMB без ERP это единственный способ получить факты). Встраивать сбор в канал, где люди УЖЕ работают (Instagram Direct, Telegram, таблица), а не плодить новый интерфейс (friction audit, integration > innovation).
Через 2–4 недели накопленного лога — первая сверка факт vs регламент, найти петли переделок и мёртвые шаги, переписать в to-be.

Минимальные артефакты на старт: реестр процессов (1 таблица), 5–9 карточек, карта handoffs, спецификация следа. ERP не нужен — карточки и реестр живут в markdown/таблице, Event Log порождают агенты.

Антипаттерны / грабли#

Описывать «как должно быть» вместо «как есть». Карточка to-be до карточки as-is = красивая фантазия, которую невозможно автоматизировать, потому что реальная работа идёт иначе. Сначала фотографируем реальность.
Boil the ocean — описать ВСЕ процессы сразу. Команда тонет, ничего не доходит до автоматизации. Один value stream → довести до конца → следующий.
Путать процесс и проект. Регламентируют разовое (мёртвый PDF), «ведут проектом» повторяемое (ручное переизобретение). Разметка обязательна.
Игнорировать handoffs, описывать только «тело» процессов. Внутри участков всё чисто, а ломается на стыках («кандидат приехал — работы нет»). Стыки без владельца = гарантированный разрыв.
Процесс без владельца. «Все отвечают» = никто не отвечает; карточка устаревает, расхождение факт/регламент копится молча. Каждый процесс — ровно один владелец.
Silent failures в порождении следа. Агент тихо перестал писать Event Log на шаге 4 — и диагностика идёт по дырявым данным. Нужны health-checks: процесс без событий за N дней подсвечивается на дашборде.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). «Замерщик съездил — дальше как-нибудь передаст дизайнеру.» ТЗ лежит в личном WhatsApp замерщика по 2–3 дня; пока он в разъездах — клиент остывает. Шаги у каждого свои.

Стало (4). Карточка процесса с явным handoff и SLA; передача — через карточку проекта, а не личный мессенджер.

Пример записи (карточка процесса):

P-02 «Выезд на замер»
триггер: согласован слот замера
шаги: 1 подтвердить слот → 2 замер на объекте → 3 фото+эскиз
      → 4 ТЗ в State Store → 5 handoff дизайнеру
результат (DoD): ТЗ готово, дизайнер уведомлён ≤24 ч · владелец: Игорь
handoff: Замерщик → Дизайнер (что: ТЗ+фото; канал: карточка проекта;
         риск: «терялось в личном WhatsApp»)

Связи#

← C1 (Карта бизнеса). Вход: C1 даёт перечень функций/направлений и то, как создаётся ценность; C2 раскладывает это на конкретные value streams и процессы. Без C1 непонятно, какие процессы вообще должны быть; без C2 карта C1 остаётся статичной схемой.
→ C3 (Люди). Выход: роли-участники и владельцы из карточек процессов — это «места», на которые C3 назначает конкретных людей и компетенции. Процесс определяет роль, человек заполняет роль.
→ +A (Агенты). Выход: каждый повторяемый процесс с описанными шагами и спецификацией следа — это ТЗ для узкого агента (вход/выход берутся прямо из карточки). C2 определяет, ГДЕ агент работает и какой след собирает.
→ C4 (Регламенты → AOP). Выход: карточка процесса (триггер→шаги→результат) — это исходник для AOP: регламент на естественном языке, превращаемый в исполняемый workflow. Регламент пишется НА процесс; нет процесса — нет регламента.
→ D (Данные → SSOT). Выход: спецификация цифрового следа каждого шага → агенты порождают Event Log → факты текут в SSOT. C2 говорит, какие события вообще существуют и что считать состоянием.
→ C5 (Контроль + Дашборд). Выход: Event Log + карточки дают сравнение «регламент vs факт» (process mining) и метрики по value stream (время цикла, потери на ожидании, разрывы handoff) — это сырьё для actionable-дашборда собственнику.
↔ Governance (сквозное). Изменение процесса (as-is → to-be) затрагивает людей и необратимо → проходит через human-in-the-loop; разметка владельцев и критичности — это runtime-правила, а не разовый комитет.

👥 C3 · Люди#

Что это#

C3 — слой «КТО» в хребте Дмитрия (ПРОЦЕССЫ → ЛЮДИ → РЕГЛАМЕНТЫ → КОНТРОЛЬ → УПРАВЛЯЕМОСТЬ). Если C2 отвечает на вопрос «какие дела делаются», то C3 отвечает «кто их делает, кто за них отвечает и через какой интерфейс работает». Это привязка процессов и шагов к конкретным носителям ответственности — ролям и их исполнителям. Исполнителем роли может быть человек, человек + AI-помощник (агент поверх), а на верхних стадиях — цифровой сотрудник (агент занимает роль-слот сам, под человеком-руководителем). Роль и её исполнитель — разные сущности: роль может «держать» и человек, и агент.

Ключевая роль контура двойная. Первое — навести классическую управляемость в людях (роли, зоны ответственности, кто кому подчинён, нет дыр и нахлёстов). Второе и более важное для AI-ориентированной организации — это точка входа адопшна: именно здесь реализуется принцип «человек делает работу как привык, агент собирает цифровой след фоном» (System of Engagement по триаде Moore/Greylock — действие людей = Engagement, след = digital exhaust). C3 — это разъём между живыми людьми в их привычных каналах (WhatsApp/Telegram, голос, чек-листы) и машинным контуром (+A Агенты, D Данные). По BCG 10-20-70 это тот самый «70% людей и процессов», который решает успех, а не алгоритмы. Без проработанного C3 любая агентская надстройка повисает в воздухе: некому работать через интерфейс, некому доверять, некому собирать след.

Сущности#

Конкретные объекты, которые создаются и живут в этом контуре:

Реестр ролей (Role Registry). Таблица/база, строка = роль (не человек). Поля: role_id, название роли, миссия роли в одну фразу, основные процессы из C2 (ссылки на process_id), ключевые результаты (что роль обязана выдавать на выход), требуемые навыки, канал работы (где роль реально живёт — Telegram/телефон/1С/полевой обход), статус (есть человек / вакантна / совмещена). Пример строки: R-07 · Приёмщик · "Превратить входящий звонок клиента в заведённый заказ" · процессы P-02 (приём), P-03 (диагностика) · выход: карточка заказа · канал: телефон + Telegram.
Карта «роль → человек» (Role-Person Map). Отдельная сущность, потому что один человек носит несколько ролей, а одну роль могут делить двое. Поля: person_id, ФИО, какие role_id несёт, % загрузки по каждой, признак «риск ключевого лица» (роль держится на одном человеке без дублёра). Пример: «Надя несёт R-03 (опер-менеджер) на 70% и R-09 (адм) на 30%; R-03 — риск ключевого лица, дублёра нет».
RACI-матрица на процессы C2. Строки = шаги процессов из C2, столбцы = роли. В ячейках буквы R (исполняет), A (отвечает/owner, ровно один на шаг), C (консультируют), I (информируют). Это сущность-стык C2↔C3: процесс получает ответственных, роль получает свои шаги. Инвариант: на каждый значимый шаг ровно один A; шагов без A быть не должно (дыра), двух A — тоже (конфликт).
Карточка роли (Role Card). Развёрнутый «паспорт» одной роли в формате документа (можно держать в 00-CONTEXT-логике локального узла). Содержит: миссию, границы (что НЕ входит), span of control (сколько людей/единиц под ролью), вход (что получает и от кого), выход (что отдаёт и кому), KPI роли (стык с C5), список AI-агентов-помощников этой роли (стык с +A), red flag-зоны под её KPI (минцберговский чек-лист слепых зон — что метрика роли НЕ видит).
Friction Audit (карта трения каналов). Артефакт-инвентаризация: по каждой роли — в каких каналах человек реально работает сегодня, сколько интерфейсов ему уже навязали, где «двойной ввод» (написал в WhatsApp + продублировал в систему). Поля: роль, канал, частота, «боль/трение», вердикт (встроить агента сюда / не плодить новый интерфейс). Принцип integration > innovation: агента ставим в канал, где человек уже живёт.
Реестр span of control / оргсвязей. Кто кому подчинён, у кого сколько прямых подчинённых, где перегруз (один руководитель тащит 12 человек) или вырожденные звенья. Может быть простой иерархической таблицей role_id → manager_role_id + счётчик подчинённых.
Карта движения роли по value stack. Для каждой роли — текущая высота на стеке McKinsey (исполнение → надзор → постановка целей) и целевая после внедрения агентов. Пример: «R-07 Приёмщик: сейчас 90% исполнение (руками заводит заказы); цель — агент заводит черновик заказа, человек переходит в надзор (проверяет/правит) → высвобожденное время на работу с клиентом».

Механика (что происходит)#

Как работа и данные текут через контур:

Из C2 приходят процессы и их шаги. Берём карту процессов и для каждого значимого шага задаём вопрос «кто?». Так наполняется RACI и Реестр ролей: процесс порождает роли, роль притягивает к себе шаги.
Роли привязываются к людям через Role-Person Map. Здесь же всплывают патологии: дыры (шаг без A), нахлёсты (двое думают, что отвечают), риски ключевого лица (всё на одном человеке), перегруз span of control.
Проводится Friction Audit: для каждой роли фиксируем, в каком канале человек уже работает. Это вход для +A — где встроить агента.
Над ролью встаёт агент-помощник (стык с +A), но НЕ меняет способ работы человека. Человек продолжает: звонит, пишет в Telegram, ходит в цех, диктует голос. Это слой действий. Параллельно агент фоном превращает эти действия в структурированный слой данных — цифровой след (написал в чат «принял мотор Иванова на диагностику» → агент создаёт/обновляет запись о заказе в D/SSOT). Так разносятся слой действий ↔ слой данных, и закрывается MIT learning-gap: организация учится без того, чтобы человек менял привычки.
Роль начинает двигаться вверх по value stack. То, что было исполнением (руками вбить, посчитать, скопировать), забирает агент; человек переходит в надзор (проверить черновик агента) и дальше — в постановку целей. Карта движения роли фиксирует это «до/после».
След от ролей сходится в D/SSOT, метрики ролей — в C5/дашборд. KPI из Карточки роли становятся строками в дашборде собственника; видно, кто что выдал на выход, не дёргая людей отчётами.

Кто делает#

Реестр ролей и RACI (первичное заполнение): СОБСТВЕННИК + человек-аналитик/консультант. Это управленческое решение «кто за что отвечает» — его нельзя делегировать агенту, истину о структуре создаёт человек.
Поддержание Role-Person Map в актуальности: ЧЕЛОВЕК (HR/операционный менеджер); AI-агент подсвечивает рассинхрон (роль в реестре есть — человека нет).
Friction Audit: ЧЕЛОВЕК (аналитик) проводит интервью/наблюдение; собственник валидирует приоритеты.
Сбор цифрового следа за работой роли: AI-АГЕНТ (фоновый, в канале роли). Человек просто работает.
Решение «двигать роль вверх по value stack» / какие шаги отдать агенту: СОБСТВЕННИК (это про деньги и риск). Автономия агента по риску: необратимое / траты > $0 — human-in-the-loop, решает человек роли.
Проверка черновиков агента (надзорный слой): ЧЕЛОВЕК-носитель роли.
Исполнять роль как цифровой сотрудник (где роль отдана агенту целиком): AI-АГЕНТ-исполнитель, но с ЧЕЛОВЕКОМ-руководителем (owner роли-слота), который принимает работу и отвечает за результат.
Назначение KPI роли: СОБСТВЕННИК совместно с носителем роли (стык с C5).

Зачем / что ломается без него#

C3 нужен, потому что процессы (C2) без привязки к ответственным — это инструкция без исполнителей, а агенты (+A) без ролей — это автоматизация в вакууме, которой некому пользоваться и нечей след собирать.

Что конкретно ломается без C3:

Дыры и нахлёсты ответственности. Шаг процесса есть, A нет — «я думал, это делает Петя». Или два A — конфликт и перекладывание. Заказы/задачи проваливаются в щели между людьми.
Риск ключевого лица. Критичная роль на одном человеке без дублёра и без описания — ушёл в отпуск/уволился, и процесс встал. Знание ушло с ним (память гниёт без обслуживания).
Агенты не приживаются. Без Friction Audit агента ставят как ещё один интерфейс «вот вам новая система, вносите сюда» — человек саботирует двойной ввод, след не собирается, пилот умирает (часть тех самых 95% провалов MIT / 80% RAND — провал не модели, а адопшна).
Люди застревают в исполнении. Без карты value stack агентов вешают «сбоку», люди продолжают руками делать то, что мог бы агент; высвобождения и роста ценности нет.
Собственник управляет людьми вручную, дёргая отчётами. Нет привязки «роль → выход → KPI» — приходится спрашивать каждого «ну что там», вместо того чтобы смотреть в дашборд.

По этапам зрелости#

1 Awareness. Ролей как сущности нет; в голове собственника «кто чем занимается». Всё держится на памяти и устных договорённостях. Дыры/нахлёсты не видны, риски ключевого лица не отслеживаются. Цифрового следа за людьми ноль.
2 Active. Появляются обрывочные описания должностей (где-то в чате/Word), кто-то из сотрудников точечно гоняет ChatGPT под себя. Единого реестра ролей нет, RACI нет, привязки к процессам нет. Знание о том «кто за что», по-прежнему в головах.
3 Operational («зоопарк»). У отдельных людей появились свои боты/помощники, но разрозненно: у каждого свой, дубли, никто не знает, кто чьим пользуется. Роли частично описаны, но бессистемно. Острый риск ключевого лица: и роли, и боты держатся на конкретных людях. Цифровой след собирается кусками и не сходится.
4 Systemic («контур»). Есть единый Реестр ролей + RACI на процессы C2, Role-Person Map с пометкой рисков ключевого лица, Friction Audit проведён. Над ролями стоят стандартизованные агенты-помощники в каналах, где люди уже работают; след фоном сходится в SSOT; KPI ролей — на дашборде. Узлы суверенны, но подчинены общим стандартам (федеративная конституция). Это целевое состояние перехода 3→4.
5 Transformational. Роли непрерывно двигаются вверх по value stack, люди работают преимущественно в надзоре и постановке целей, агенты несут исполнение (~2.5 человека на 50–100 агентов как ориентир сетевой agentic-структуры). Организация управляется как система; силосы заменены сетями людей+агентов; адопшн — норма, а не проект.

Как внедряется (SMB без ERP, с нуля)#

Выгрузить процессы из C2 и для каждого значимого шага задать «кто это делает / кто отвечает». Если C2 ещё нет — сначала он (system-first, не AI-first).
Собрать Реестр ролей (роль ≠ человек). Самый простой носитель — таблица (Google Sheets / Notion-база), без ERP. Заполнить поля из сущности №1.
Построить RACI на шаги процессов. Прогнать инвариант: на каждый шаг ровно один A; устранить дыры и двойные A. Это даёт мгновенную управленческую картину «где провалы».
Наложить людей (Role-Person Map), пометить риски ключевого лица и перегруз span of control. По каждому риску ключевого лица — решение: дублёр, описание роли, или агент-страховка.
Провести Friction Audit: по каждой роли выписать реальные каналы работы. Выбрать 1–2 роли с самым болезненным «двойным вводом» как пилот для агента.
На пилотной роли поставить агента ПОВЕРХ канала (человек пишет в Telegram как привык → агент фоном пишет в SSOT). Никакого нового интерфейса для человека. Это стык с +A и D.
Завести Карточку роли для пилотной роли: вход/выход, KPI, агенты-помощники, чек-лист слепых зон под KPI.
Вывести KPI роли на дашборд (стык с C5) — собственник видит выход роли без ручных отчётов.
Зафиксировать карту value stack «до/после» и расширять на следующие роли по тому же циклу.

Антипаттлерны / грабли.

«Новая система — вносите сюда». Заставить людей бросить WhatsApp/Telegram и работать в новом интерфейсе. Нарушает integration > innovation; люди саботируют, двойной ввод, след не собирается. Правильно: агент поверх существующего канала.
Роль = человек. Описывать не роли, а конкретных Петь и Маш. Уволился человек — рухнула «роль». Роль должна быть отделена от носителя (поэтому Реестр ролей и Role-Person Map — разные сущности).
Размытое или двойное A. «Отвечают все» = не отвечает никто; два A = конфликт. RACI без жёсткого инварианта «один A на шаг» бесполезен.
Игнор риска ключевого лица. Описали роли красиво, но не пометили, что три критичных держатся на одном человеке без дублёра и без выгруженного знания. Память узла гниёт без обслуживания.
Приказ сверху вместо движения снизу. Спустить роли/агентов директивой, не вовлекая носителей. По Минцбергу перемены устойчивее снизу; организация — сообщество, не оргсхема. Слепое доверие метрике роли вытесняет неизмеримую ценность (дивизионализация ≠ децентрализация) — поэтому в Карточке роли обязателен чек-лист слепых зон под KPI.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). Дизайнер Лена и считает смету, и рисует, и пишет клиенту, и торопит цех. Уходит в отпуск — проекты встают (риск ключевого лица). Сколько КП зависло без ответа — никто не видит.

Стало (4). Роль ≠ исполнитель: роль R-дизайнер расщеплена по value-stack — рутина уходит агенту, за человеком остаётся решение.

Пример записи (Role Card, фрагмент):

Роль: R-дизайнер-конструктор · исполнитель: Лена
  Исполнение (рутина) → агент proposal-drafter: пересчёт сметы по прайсу,
                        сборка черновика КП, напоминания клиенту
  Надзор → Лена (человек): дизайн-решение, утверждение цены и изменений
  Цели → Владелец: маржа проекта, загрузка цеха
Риск ключевого лица: было «весь проект в голове Лены» →
                     стало «знание в шаблонах + State Store»

Связи#

← C2 Процессы (вход). C3 берёт шаги процессов и навешивает на них ответственных через RACI. Процессы C2 — это «что», роли C3 — «кто это что делает». Без C2 ролям не к чему крепиться.
→ +A Агенты (выход/вход). C3 говорит агентам, какую роль каждый из них усиливает и в каком канале живёт человек (из Friction Audit). Агент = помощник конкретной роли, карточка роли ссылается на своих агентов. Обратно +A двигает роль вверх по value stack.
→ C4 Регламенты→AOP. Роли C3 — субъекты регламентов: AOP описывает, КАК роль выполняет шаг. «Кто» (C3) + «как одинаково» (C4) = воспроизводимость.
→ D Данные→SSOT (выход). Действия людей в их каналах (слой действий) агенты превращают в цифровой след (слой данных), который сходится в SSOT. C3 — источник этого следа: нет ролей и людей, работающих через каналы — нет и следа.
→ C5 Контроль+Дашборд (выход). KPI из Карточек ролей становятся метриками на дашборде собственника; выход каждой роли виден без ручных отчётов.
↕ Governance (сквозное). Автономия агента над ролью ограничивается по риску (human-in-the-loop на необратимом/тратах), RACI определяет, кто принимает решения. Носитель роли — точка runtime-контроля, а не комитет.

🤖 +A · Агенты (поверх людей)#

+A · Прослойка сбора и усиления поверх людей.

Что это#

«+A» — это контур, который вставляется поверх контура C3 «Люди», не заменяя его. Люди продолжают делать работу так, как привыкли (звонят, пишут в мессенджер, заполняют накладную, проводят встречу), но между слоем их действий и слоем данных появляется прослойка узких AI-агентов, которые собирают цифровой след фоном. Это операционализация хребта Дмитрия в точке стыка ЛЮДИ→КОНТРОЛЬ: вместо того чтобы заставлять человека вести вторую, «отчётную» жизнь в системе, агент превращает его естественные действия (System of Engagement) в структурированный факт (digital exhaust → System of Record/Intelligence). Это и есть закрытие MIT learning-gap и механика операционализации «70% — люди и процессы» из BCG 10-20-70: ценность создаёт не модель, а то, что человек ничего не меняет в своей работе, а след всё равно появляется.

Ключевой принцип контура: «человек работает — агент собирает». В базовом режиме агент — не автономный сотрудник, а усилитель и сборщик следа (копайлот над человеком). Истину создаёт человек, AI её фиксирует, нормализует и сверяет. На необратимых действиях и тратах автономии у агента — ноль (human-in-the-loop gate). Контур умышленно строится снизу-вверх и узким: набор маленьких специализированных агентов с явными границами, а не один «универсальный ассистент» — потому что на практике узкие агенты выживают, а scope creep убивает («галлюцинирует к шагу 3»).

Два режима агента — спектр исполнителя роли. Агент в этом контуре работает в одном из двух режимов, и роль может двигаться по спектру человек → человек + AI-помощник → цифровой сотрудник:

AI-помощник (копайлот) — садится поверх человека: человек держит роль и делает работу, агент помогает, корректирует, готовит черновики и собирает след. Исполнитель роли — человек.
Цифровой сотрудник — занимает роль и выполняет работу сам, заменяя часть (или всю) функцию сотрудника. Это уже не инструмент при человеке, а узел оргструктуры наравне с людьми: у него есть роль-слот в C3 «Люди», человек-руководитель (owner) и — главное — коннекторы (кому подчиняется, с кем стыкуется — люди и другие агенты, в каком канале живёт, как эскалирует). По сути цифрового сотрудника онбордят как человека: даёшь ему регламент (AOP) = должностную инструкцию, вход/выход, точки передачи и уровень автономии.

Чем выше автономия и необратимость действий цифрового сотрудника — тем жёстче коннекторы, gates и owner-надзор (автономия-по-риску). Принцип «истину создаёт человек» сохраняется: цифровой сотрудник действует в границах регламента и guardrails, а на необратимом и тратах всё равно есть человек на gate.

Сущности#

Контур состоит из конкретных, создаваемых и «трогаемых» объектов:

Типы агентов (5 архетипов-ролей). Каждый агент в реестре обязан принадлежать одному типу — это его «класс», задающий guardrails и уровень автономии: - Collector (собиратель следа) — слушает канал, где человек уже работает (Telegram-чат, почта, расшифровка звонка), и порождает структурированный факт. Для SMB без ERP это базовый агент — он создаёт event log с нуля. Автономия: пишет в данные, но не в боевые системы. - Drafter — готовит черновик (ответ клиенту, протокол встречи, описание задачи). Никогда не отправляет сам — отдаёт человеку на gate. - Qualifier — классифицирует/скорит (лид горячий/холодный, обращение — жалоба/заказ, риск сделки). Выдаёт метку + причину, не принимает решение. - Router — маршрутизирует: кому назначить, в какую папку/проект положить, какой следующий шаг. (Прямой аналог логики операционного кодекса Дмитрия: «определи проект, не угадывай».) - Reconciler / сверщик — сравнивает регламент vs факт: что было обещано (commitment) vs что сделано; что говорит AOP vs что реально произошло в event log. Поставляет drift-сигналы наверх.
Карточка-стандарт агента (Agent Card). Единый паспорт на каждого агента, в формате одного файла (YAML/MD), с обязательными полями: name: collector-telegram-remservice type: collector mode: assistant | digital-employee # помощник над человеком | цифровой сотрудник в роли purpose: "собрать факты обращений из клиентского чата в SSOT" input: источник + триггер (канал X, новое сообщение) output: схема факта (case_id, activity, timestamp, actor, payload) data_source: откуда читает (Telegram API / расшифровка) data_sink: куда пишет (таблица events в SSOT) schedule: событийно / cron 'каждые 15 мин' / по запросу runbook: что делать при сбое (ссылка на raw, ретрай, эскалация) autonomy: write-data-only | draft-only | execute-with-gate guardrails: запреты (не пишет в боевую систему, не тратит, не отправляет наружу) gate: кто/что подтверждает действие (human-in-the-loop: да/нет, кто) owner: ФИО человека-владельца/руководителя role_slot: роль/позиция в оргструктуре (C3), если это цифровой сотрудник; иначе — connectors: кому подчиняется · с кем стыкуется (люди/агенты) · канал · эскалация status: draft | active | paused | retired health: last_run, success_rate, last_error Это L2-сущность из zoo-фреймворка (реестр+карточка с вход/выход), доведённая до исполняемой полноты.
Реестр агентов (Agent Registry). Один список/таблица всех карточек — единственное место, где видно, кто из агентов существует, что делает, чем владеет человек и жив ли он. Поля-проекция карточек: name · type · owner · status · health · последний прогон. Без реестра неизбежен «зоопарк» (стадия 3): дубли, риск ключевого лица, никто не знает, что крутится.
Инструменты (tools / MCP). То, чем агент дотягивается до мира: коннекторы к каналам и хранилищам (почта, мессенджер, календарь, диск, SSOT-store). Каждый tool привязан к карточке и ограничен guardrails (read-only там, где нельзя писать).
Guardrails. Жёсткие, машинно-проверяемые ограничения на агента: что нельзя трогать, куда нельзя писать, что нельзя отправлять наружу, потолок трат = $0 без подтверждения. Это runtime-enforcement, а не комитет — правило живёт в конфиге агента и срабатывает в момент действия (governance как runtime, не как regламент-PDF).
Human-in-the-loop gates. Точки обязательной остановки, где человек подтверждает действие, прежде чем оно станет необратимым. Сущность gate = {какое действие, кто подтверждает, что показывается на подтверждение, fallback при таймауте}.
Матрица «Автономия-по-риску». Таблица, привязывающая уровень автономии к обратимости и деньгам действия:

Действие	Обратимо?	Траты?	Автономия агента
Собрать факт в SSOT	да	нет	полная (collector сам)
Подготовить черновик	да	нет	полная до отправки, отправка — gate
Назначить задачу внутри	да	нет	авто + лог, откат возможен
Отправить наружу клиенту	нет	нет	gate (человек жмёт «ок»)
Любая трата / платёж / договор	нет	да>$0	ноль автономии, всегда человек

Health-check / журнал прогонов. Поле health в карточке + лог: last_run, success/fail, last_error. Существует, чтобы ловить silent failures — агент, тихо переставший собирать след, хуже ручного процесса, потому что в данные приходит молчаливая дыра.
Цифровой сотрудник и его коннекторы. Когда агент не помогает человеку, а занимает роль, он становится узлом оргструктуры и получает «обвязку», как при найме человека: - role_slot — позиция в C3: какой участок держит, его вход/выход в сквозном процессе; - руководитель / owner — кому подчиняется, кто принимает его работу и отвечает за него; - коннекторы — точки стыковки: от кого получает (люди/агенты), кому передаёт (handoffs), в каком канале «живёт» (Telegram/CRM/почта), как и кому эскалирует; - регламент (AOP) — его исполнимая «должностная инструкция», сверяемая на drift; - уровень автономии — по матрице риска; на необратимом и тратах всё равно человек на gate.

Цифровой сотрудник = композиция архетипов (collector + qualifier + drafter + router…), которой выдан слот, регламент и коннекторы — он держит участок работы целиком, а не помогает по кусочку. Без коннекторов цифровой сотрудник повисает так же, как несонбордженный человек.

Механика (что происходит)#

Поток работы и данных через контур:

Действие. Человек делает работу в своём канале — пишет клиенту в Telegram, проводит звонок, ставит задачу. Слой действий не меняется.
Захват. Collector-агент через свой tool/MCP видит событие (новое сообщение, законченная встреча, расшифровка) — триггер из карточки.
Нормализация. Агент превращает сырое событие в структурированный факт по схеме output: минимум case_id + activity + timestamp + actor, плюс payload. Сырьё параллельно кладётся в raw/ (чтобы можно было пересобрать). Цифры/расчёты — вне LLM (детерминизм): агент извлекает и раскладывает, но не выдумывает суммы и даты.
Запись в данные. Факт пишется в SSOT — структурированный store состояния (SQL/граф), который агенты обновляют, а не только read-only RAG. RAG-извлечение — поверх, для поиска, не как источник истины о состоянии и времени.
Квалификация / маршрутизация. Qualifier ставит метку (+причину), Router определяет адресата/следующий шаг. Drafter, если нужно, готовит черновик ответа/протокола.
Gate. Если следующее действие необратимо или тратит деньги — агент останавливается на human-in-the-loop gate: показывает человеку черновик/предложение, человек подтверждает. Только после «ок» действие исполняется.
Сверка. Reconciler периодически сравнивает event log (факт) с AOP/обязательствами (регламент) и поднимает drift-сигнал, если «обещали ≠ сделали».
Наверх. Структурированные факты и drift-сигналы текут в контур D (SSOT) → C5 (Контроль/Дашборд собственнику).

Итог превращения: сырое человеческое действие → структурированный факт → сверенный сигнал → строка дашборда, без того чтобы человек вёл вторую отчётную жизнь.

Кто делает#

Определить, какой след нужен (какие факты ловим) — Собственник (это его язык управляемости, его KPI; Минцберг-оговорка: рядом держим чек-лист слепых зон, чтобы метрика не срезала неизмеримую ценность).
Спроектировать узкого агента и схему факта — Человек-архитектор контура (внедренец), не агент.
Захват, нормализация, запись следа — AI-агент (collector).
Классификация / скоринг / маршрутизация — AI-агент (qualifier/router), но решение по спорному кейсу — человек на gate.
Черновики наружу — AI-агент готовит, человек-владелец отправляет.
Любая трата / необратимое / отправка клиенту — только человек (gate).
Держать роль целиком как цифровой сотрудник (выполнять участок вместо сотрудника) — AI-агент в режиме цифрового сотрудника, но всегда с человеком-руководителем (owner), который принимает его работу; найм/онбординг (slot, коннекторы, AOP, автономия) делают человек-архитектор + собственник.
Владение каждым агентом (его здоровье, runbook, остановка) — конкретный человек-owner в карточке (по McKinsey ~2.5 человека на 50–100 агентов — но владелец у каждого агента всегда один и поимённый).
Утвердить уровни автономии и guardrails — Собственник + архитектор (governance-runtime).
Реагировать на drift-сигнал сверщика — Человек (агент только сигналит).

Зачем / что ломается без него#

Без этого контура остаётся неустранимый разрыв между тем, что люди делают, и тем, что попадает в данные. В SMB без ERP этот разрыв = пропасть: event-логов нет, поэтому либо людей заставляют вручную дублировать работу в CRM/таблицы (саботаж, неполные данные, «отчётная жизнь»), либо данных просто нет и собственник управляет вслепую. Конкретные провалы при отсутствии «+A»:

Дашборд врёт или пуст — нечем его наполнять: люди работают, след не собирается, KPI считаются по памяти и интуиции (то, против чего и нужна AI-система управляемости).
Регламент нечем сверить с фактом — AOP остаётся декларацией, drift не виден, «делаем как договорились» проверить невозможно.
Адопшн проваливается — без механики «человек работает, агент собирает» внедрение AI = ещё одна система, которую люди обходят (это и есть 95% MIT / 80% RAND провалов пилотов: AI-first без выстроенной управляемости).
Знание о том, кто что делает, живёт в головах — риск ключевого лица, тот самый «зоопарк».

По этапам зрелости#

1 Awareness. Контура нет. След не собирается вообще; вся работа и все данные — в головах и переписках. Агентов нет, есть отрицание/осознание. Слой действий = слой данных = ничего структурированного.
2 Active. Точечный ChatGPT ad hoc: человек руками просит модель «сделай черновик/суммируй звонок» и копипастит результат. Это drafter без карточки и без записи в данные — след не оседает, нет реестра, нет owner, нет gate как стандарта. Одноразовая польза, нулевая накопляемость.
3 Operational / «зоопарк». Уже есть свои боты-агенты, но разрозненно: несколько collector'ов/drafter'ов у разных людей, дубли, разные форматы выхода, нет единого реестра, риск ключевого лица. Silent failures незаметны. Автономия не отрегулирована по риску — где-то агент уже что-то отправляет сам. Цель — вытащить контур отсюда в стадию 4.
4 Systemic / «контур». Есть реестр агентов, у каждого — карточка-стандарт с owner, schedule, runbook, guardrails и health. Все collector'ы пишут в единый SSOT по общим схемам. Автономия-по-риску формализована (ноль на тратах/необратимом), gates стандартны, reconciler сверяет регламент vs факт. Federated-конституция: узлы (проекты/отделы) суверенны, но соблюдают общие стандарты карточки и схемы факта. Появляются первые цифровые сотрудники на простых, обратимых участках (агент держит роль целиком под owner'ом, вписан в оргструктуру с коннекторами). Это целевое состояние «+A».
5 Transformational. Контур «+A» становится частью AI-native операционки: новый процесс рождается сразу с агентом-сборщиком следа и AOP; управляемость работает как система, агенты — штатная прослойка между действием и данными, роли людей сдвинуты вверх по value stack (исполнение → надзор → цели), как в Agentic Organization. Часть ролей штатно держат цифровые сотрудники: оргструктура = люди + агенты-узлы, а человек — руководитель и точка эскалации.

Как внедряется (SMB без ERP, с нуля)#

Выбрать ОДИН канал, где люди уже живут (friction audit: не плодить новые интерфейсы — встраиваться в существующий, напр. клиентский Telegram-чат или почта). Integration > innovation.
Определить 3–5 фактов, которые нужны собственнику для одного KPI (что считаем «обращением», «обязательством», «сделкой»). Методология до инструмента.
Завести первого узкого collector'а под этот канал: создать его карточку-стандарт (все обязательные поля), задать схему факта case_id+activity+timestamp+actor+payload, настроить tool/MCP к каналу.
Поднять минимальный SSOT-store состояния — простая SQL-таблица/таблица событий (не вектор-RAG как источник истины), куда collector пишет. RAG — позже и поверх.
Создать реестр агентов (одна таблица) и завести в него карточку; назначить owner и runbook.
Прописать автономию-по-риску и guardrails: collector — write-data-only, ноль трат, ничего наружу без gate. Поставить human-in-the-loop gate на первое же действие наружу.
Включить health-check: фиксировать last_run/last_error; завести правило «нет прогона N часов → сигнал owner'у» (анти-silent-failure).
Добавить второго узкого агента (drafter или qualifier) только когда первый стабилен — расширяться количеством узких агентов, а не раздуванием одного.
Подключить reconciler последним, когда уже есть и факт (event log), и регламент (AOP из контура C4), чтобы сверять «обещали vs сделали».
Всё снизу-вверх: сперва один работающий контур на одном канале, потом тиражирование по federated-стандарту.

Антипаттерны / грабли#

Scope creep — один «универсальный агент». Пытаются сделать одного агента, который и собирает, и пишет, и отправляет, и решает. К шагу 3 он галлюцинирует. Лечится дроблением на узкие агенты по 5 типам.
Silent failures без health-check. Агент тихо перестал собирать след — данные молча гниют, дашборд врёт, и это хуже ручного процесса, потому что иллюзия покрытия. Лечится health-полем + правилом эскалации owner'у.
Автономия на необратимом/тратах. Дали агенту отправлять клиенту/тратить/подписывать без gate — первый же дорогой инцидент. Правило железное: ноль автономии на необратимом и любых тратах >$0.
Агент без owner'а и runbook'а («зоопарк»). Бот крутится, никто не отвечает за него, при сбое некому чинить, при увольнении сотрудника знание теряется — риск ключевого лица. Лечится обязательным поименным owner в карточке и реестром.
SSOT как чистый read-only RAG. Векторный store «не знает истины и времени», агенты не могут обновлять состояние. Нужен структурированный store состояния (SQL/граф), который агенты пишут, а RAG — извлечением поверх. Плюс: ~60% работы — это data plumbing, недооценка приводит к срыву сроков.
(грабли адопшна) Заставить людей менять способ работы ради агента — вместо «человек работает как привык, агент собирает фоном». Любое требование вести «вторую отчётную жизнь» убивает контур.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). На входящие в Instagram — автоответ «Спасибо, скоро ответим» и тишина. Ночные и выходные заявки теряются до утра; КП клиент ждёт 2–3 дня.

Стало (4). Два узких агента поверх людей: intake-collector сводит заявки из всех каналов в один реестр; proposal-drafter — цифровой сотрудник, по ТЗ собирает черновик КП к утру, человек проверяет и отправляет.

Пример записи (Agent Card):

id: proposal-drafter
тип: цифровой сотрудник (занимает рутинную часть роли R-дизайнер)
вход: ТЗ из P-02 · выход: черновик КП+смета на проверку Лене
коннекторы: прайс-лист (read) · State Store (read/write) · почта (draft-only)
автономия: draft-only — отправка клиенту через gate человека
владелец: Лена · health-check: нет черновика >4 ч после ТЗ → алерт

Связи (вход/выход)#

↔ C3 «Люди». Двойная связь: в режиме помощника «+A» садится поверх C3 (агент усиливает человека, owner берётся из «Люди»); в режиме цифрового сотрудника агент сам становится узлом внутри C3 — занимает роль-слот рядом с людьми, с человеком-руководителем и коннекторами к коллегам. Вход: действия людей (System of Engagement) + назначенные роли-слоты.
← C2 «Процессы». Вход: какой шаг процесса порождает какой факт — определяет, что должен ловить collector и где ставить gate.
← C4 «Регламенты → AOP». Вход для reconciler: живой AOP (SOP на естественном языке → исполняемый workflow + drift-detection) — эталон, с которым сверяется факт. Выход обратно: drift-сигналы уточняют AOP.
→ D «Данные → SSOT». Главный выход: collector'ы — это L4-«клей» zoo-фреймворка (агент читает описание/контекст из L1 → пишет факты в L3-хаб данных). Контур «+A» — основной поставщик следа в SSOT.
→ C5 «Контроль + Дашборд». Выход: структурированные факты и drift-сигналы → governed-расчёт KPI (semantic/metrics layer, dbt — один governed-расчёт, цифры вне LLM) → actionable-дашборд собственнику (L5 / Digital Twin of Organization: приоритизировать, мониторить, симулировать).
↕ Governance (сквозное). guardrails + автономия-по-риску + gates — это runtime-enforcement governance внутри каждого агента, а не отдельный комитет; реестр агентов — объект governance-надзора.

📋 C4 · Регламенты → AOP (исполнимый контракт)#

C4 · Регламент как исполнимый контракт (AOP) + детектор дрейфа.

Что это#

Слой РЕГЛАМЕНТЫ из хребта Дмитрия (ПРОЦЕССЫ → ЛЮДИ → РЕГЛАМЕНТЫ → КОНТРОЛЬ → УПРАВЛЯЕМОСТЬ) — это «чтобы все делали одинаково». В классике он умирает как мёртвый PDF: документ написан, лежит в папке, его никто не открывает, факт расходится с бумагой. Контур C4 переводит регламент из мёртвого документа в живой исполнимый контракт двойного назначения: одна и та же сущность читается человеком как SOP (инструкция «как делать») и исполняется агентом как AOP — Agent Operating Procedure (регламент на естественном языке → исполняемый workflow агента, по линии AWS Strands / Decagon). Регламент перестаёт быть описанием намерения и становится исполняемым артефактом, против которого можно проверять реальность.

Роль контура — быть прослойкой стандарта между тем, как люди и агенты должны работать (C2 Процессы, C3 Люди, +A Агенты), и тем, как они фактически работают (D Данные/SSOT). C4 не хранит факты (это слой D) и не хранит описание устройства бизнеса (это L1 база знаний zoo / C1 карта). C4 хранит норму и держит её сверку с фактом. В терминах System of Intelligence: C4 — это операционные плейбуки контекст-слоя (Atlan: Operational Playbooks), исполняемые поверх System of Record. Это контур, который превращает «у нас есть процессы» в «процессы соблюдаются и это видно».

Сущности#

Конкретные объекты, которые в этом контуре создаются и трогаются:

SOP (Standard Operating Procedure) — человекочитаемый слой контракта. Markdown-файл с фронтматтером. Поля: id, version, owner, trigger (когда запускается), steps[] (нумерованный список действий человеческим языком), definition_of_done, inputs, outputs, escalation (когда эскалировать человеку). Это то, что читает сотрудник. Пример шага: «3. Проверить, что у лида заполнен телефон в формате +XX; если нет — запросить у источника, не двигать дальше».
AOP (Agent Operating Procedure) — исполнимый слой того же контракта. Тот же SOP, размеченный для агента: к каждому шагу привязан tool (какой инструмент/действие), precondition, postcondition, autonomy_level (auto / human-in-the-loop / blocked), risk_class. AOP — это не отдельный документ, а исполнимая проекция SOP: один источник, два потребителя. Шаг 3 выше в AOP превращается в: precondition: lead.phone matches /^\+\d+/, on_fail: action=request_from_source, autonomy=auto, block_advance: true.
Чек-лист обязательных пунктов (mandatory checklist) — контроль ПОЛНОТЫ, не детерминизма. Отдельный список пунктов, которые агент ОБЯЗАН затронуть при исполнении регламента. Это лечит конкретную болезнь LLM — «пропустил пункт на шаге 3» — но не делает разбор детерминированным: агент по-прежнему рассуждает свободно, чек-лист лишь верифицирует, что ни один обязательный пункт не выпал. Формат: checklist[] с полями item, required: true/false, covered: bool (заполняется после прогона). Это разные вещи: детерминизм цифр живёт в слое D (расчёт ВНЕ LLM); полнота пунктов живёт здесь.
Drift-detector (детектор отклонения факт ↔ регламент). Сущность-правило, сверяющая событийный след из слоя D (event log: минимум case_id + activity + timestamp + actor, по van der Aalst / Celonis Process Mining) с предписанной в AOP последовательностью. Выдаёт drift_events[]: пропущенный обязательный шаг, нарушенный порядок, превышенный SLA, действие без предписания. Это операционализация «регламент vs факт» process mining для SMB, где event log агенты порождают сами (зазор: нет ERP — след генерируется с нуля).
Версия регламента (versioned contract). Каждый SOP/AOP — под версионированием (semver: MAJOR.MINOR.PATCH), с changelog, effective_from, supersedes. Старая версия не стирается — архивируется. Это обязательное условие «живого контракта»: когда процесс меняется, меняется версия, а drift меряется против действующей версии, не против легенды.
Decision Memory (память решений по регламенту). Лог прецедентов: «в кейсе X отступили от шага 5, потому что Y, решение принял Z». Поля: case_id, deviation, rationale, approved_by, date. По Atlan Decision Memory — чтобы исключения не превращались в тихий размыв стандарта, а накапливались как явные прецеденты (и питали следующую версию).
Карточка владельца регламента (steward card). Привязка каждого SOP/AOP к человеку-владельцу (MIT CISR stewardship-фактор). Поля: owner, review_cadence (как часто пересматривать), last_reviewed. Без явного владельца регламент гниёт (память гниёт без обслуживания — Reddit-практика).

Механика (что происходит)#

Как работа и данные текут через контур:

Извлечение нормы. Берётся реальный процесс из C2 и роль из C3. Человеческое «как мы это делаем» записывается в SOP (steps + definition_of_done). На этом этапе ещё нет агента — есть человекочитаемый стандарт.
Разметка в AOP. К каждому шагу SOP добавляются исполнимые атрибуты (tool, pre/postcondition, autonomy_level, risk_class) и собирается mandatory checklist. SOP → AOP — это не переписывание, а обогащение того же файла под второго потребителя (агента).
Исполнение через интерфейс. Человек делает работу как привык (механика адопшна: «человек работает — агент собирает фоном»). Агент либо ведёт его по AOP (подсказывает шаг, проверяет precondition), либо исполняет шаги с autonomy=auto сам. Каждое касание оставляет событие в event log слоя D.
Проверка полноты. После прогона чек-лист обязательных пунктов сверяется: все required: true пункты covered? Непокрытые — флаг. Это ловит «LLM дошёл до шага 3 и поплыл» до того, как результат уйдёт дальше.
Детекция дрейфа. Drift-detector сверяет фактический след (D) с предписанной в действующей версии AOP последовательностью. Расхождения → drift_events[].
Разрешение дрейфа. Дрейф — это сигнал, и у него две причины: либо реальность нарушает норму (чинить исполнение, эскалация по C5), либо норма устарела (чинить регламент → новая версия). Решение фиксируется в Decision Memory; если систематическое — поднимается версия AOP. Контракт остаётся живым.
research writes / delivery reads. Регламенты, которые вырабатываются/исследуются (новые SOP, апдейты версий), пишутся отдельным «research»-контуром; контур исполнения/доставки (delivery) их только читает. Это предотвращает гниение памяти: тот, кто исполняет в бою, не правит норму на лету — иначе стандарт размывается без следа.

Кто делает#

Извлечение реального процесса в SOP — ЧЕЛОВЕК (носитель процесса / РОП / операционный менеджер) при ассисте AI-АГЕНТА (агент интервьюирует, структурирует черновик; «истину создаёт человек, AI — усилитель»).
Разметка SOP → AOP (tool/pre/postcondition/autonomy) — AI-АГЕНТ генерирует разметку, ЧЕЛОВЕК-владелец валидирует (особенно autonomy_level и risk_class).
Назначение autonomy_level и risk_class — СОБСТВЕННИК / владелец регламента. Это решение про риск (human-in-the-loop на необратимом и на тратах > $0), его нельзя делегировать агенту.
Исполнение по AOP — AI-АГЕНТ (для auto-шагов) + ЧЕЛОВЕК (для шагов своей зоны; агент собирает след фоном).
Проверка чек-листа полноты — AI-АГЕНТ (механически сверяет covered), эскалация непокрытого — ЧЕЛОВЕКУ.
Детекция дрейфа — AI-АГЕНТ (drift-detector работает на event log автоматически).
Решение «чинить факт или чинить норму» — ЧЕЛОВЕК-владелец регламента; систематический/дорогой дрейф эскалируется СОБСТВЕННИКУ.
Подъём версии регламента — ЧЕЛОВЕК-владелец (research-контур пишет), фиксация — обязательна.
Утверждение нового/изменённого регламента как нормы — СОБСТВЕННИК (федеративная конституция: общий стандарт утверждается на уровне, который его держит).

Зачем / что ломается без него#

Без C4 регламент остаётся PDF: написан один раз, расходится с реальностью, никто не знает, соблюдается ли он. Конкретные провалы при отсутствии контура:

Нет единого «одинаково». Каждый сотрудник и каждый агент делают по-своему — слой РЕГЛАМЕНТЫ хребта проваливается, дальше рушится КОНТРОЛЬ (нечего проверять) и УПРАВЛЯЕМОСТЬ (нечем управлять).
Агент галлюцинирует к шагу 3. Узкий агент без явного AOP и чек-листа полноты ползёт за пределы scope, выдумывает шаги, тихо пропускает обязательные пункты. Scope creep убивает агента (Reddit-практика) — AOP жёстко очерчивает границу и список обязательного.
Silent failures. Без drift-detector отклонение факта от нормы невидимо — а тихий сбой хуже ручной работы: его не замечают, пока не прорвёт. Drift-detector + health-checks делают сбой видимым.
Норма устаревает молча. Без версионирования и Decision Memory регламент либо костенеет (его обходят, но он формально «есть»), либо тихо размывается исключениями. Дрейф некуда деть — он либо игнорируется, либо ломает стандарт без следа.
Риск ключевого лица и зоопарк. Без owner-карточек и единого формата регламенты живут в головах и в разрозненных ботах; уход человека уносит норму.

По этапам зрелости#

1 Awareness. Регламентов как артефактов нет или они в головах/случайных файлах; «как делать» передаётся устно. AI не участвует. SOP не написаны, AOP/drift/версий нет — норма неуправляема и невидима.
2 Active. Кто-то ad hoc просит ChatGPT «напиши регламент» — получается одноразовый текст в чате/Google Docs. Нет единого формата, нет связи с исполнением, нет версий. Регламент = мёртвый PDF, рождённый из LLM.
3 Operational (зоопарк). Появились боты, у некоторых зашита логика «как делать», но регламенты разрознены, дублируются между ботами, расходятся между собой; нет единого SOP↔AOP, нет drift-детекции, версии — в лучшем случае в чьей-то голове. Риск ключевого лица: норма живёт в конкретном боте/человеке. Это точка, из которой тянем вверх (3→4 — макс. скачок ценности).
4 Systemic (контур). Единый формат SOP/AOP, каждый регламент версионируется и имеет owner-карточку; чек-листы полноты встроены; drift-detector работает на едином event log слоя D; дрейф разрешается явно (Decision Memory) и питает версии; research writes / delivery reads разведены. Регламент — живой контракт. Федеративно: узлы держат свои SOP суверенно, общие стандарты — на уровне конституции.
5 Transformational. Регламенты самообновляются по сигналам дрейфа (норма подстраивается под доказанно лучший факт через research-контур с человеческой санкцией), AOP — основа AI-native операционки; управляемость как система: новый процесс рождается сразу как версионируемый исполнимый контракт, а не как документ-вдогонку.

Как внедряется (SMB без ERP)#

Выбрать 1–2 болевых процесса из C2 (узкое место, где «делают по-разному» дороже всего). Не весь бизнес сразу — узкий scope выживает.
Завести формат файла. Один шаблон SOP-AOP.md с фронтматтером (поля из «Сущностей»: id, version, owner, trigger, steps, definition_of_done, autonomy_level, risk_class, checklist). Положить в репозиторий стандартов (для фермы Дмитрия — естественно лёг бы рядом с 00-CONTEXT узла: регламент = локальный контракт узла, формат — общий по конституции).
Записать SOP с носителем процесса (человек диктует, агент структурирует). Зафиксировать definition_of_done и mandatory checklist — что НЕЛЬЗЯ пропустить.
Разметить в AOP: к каждому шагу — tool, pre/postcondition; владелец проставляет autonomy_level (по умолчанию human-in-the-loop на всём необратимом и тратах > $0) и risk_class.
Встроить в канал, где люди уже живут (integration > innovation, friction audit: не плодить новый интерфейс). Агент ведёт/исполняет по AOP, собирает event log фоном — так с нуля порождается след (зазор SMB без event-логов).
Включить чек-лист полноты на выходе каждого прогона: блокировать передачу дальше, если непокрыт обязательный пункт.
Запустить drift-detector против event log: сверка факт ↔ действующая версия. Начать с простейшего — «обязательный шаг пропущен / порядок нарушен / SLA превышен».
Поставить версионирование и owner-карточку на каждый регламент; назначить review_cadence. Развести research (пишет норму) и delivery (читает).
Вывести drift-метрику в дашборд C5 — % соблюдения регламента как actionable-сигнал собственнику.

Антипаттерны / грабли#

Мёртвый PDF. Написали красивый регламент, положили в папку — он не привязан к исполнению, не версионируется, не сверяется с фактом. Регламент без AOP и drift-детекции мёртв по определению.
Чек-лист путают с детерминизмом. Думают, что mandatory checklist делает разбор детерминированным. Нет: он лечит ТОЛЬКО полноту («LLM пропустил пункт»), но агент всё ещё рассуждает. Детерминизм цифр — это слой D (расчёт ВНЕ LLM), не C4. Смешение оставляет дыру: цифры в регламенте по-прежнему могут выдумываться, если их не вынесли в D.
Scope creep в AOP. Один AOP пытаются сделать «на весь отдел» — агент галлюцинирует к шагу 3. Узкие AOP выживают; широкие убивают агента.
Тихий дрейф без разрешения. Drift-detector есть, но дрейф никто не разбирает — события копятся, их перестают читать (silent failure второго порядка). Каждый дрейф обязан получить решение: чинить факт или чинить норму, с записью в Decision Memory.
Delivery правит норму на лету. Исполнитель в бою меняет регламент под себя без версии и санкции — стандарт размывается без следа, память гниёт. Правило research writes / delivery reads нарушать нельзя.
Регламент без владельца. Нет steward-карточки и review_cadence — регламент устаревает молча, риск ключевого лица возвращается.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). PDF «Стандарт работы с клиентом» висит в общем чате — открыли один раз. По факту предоплату берут «по договорённости»: 0 / 20 / 50 % — кто как договорился. Проекты уходят в цех без денег.

Стало (4). Регламент — исполнимый контракт (AOP), проверяемый в runtime, а не PDF. Нарушение ловит drift-детектор.

Пример записи (правило AOP):

RULE pre-payment:
  статус проекта = «в производство» РАЗРЕШЁН ТОЛЬКО ЕСЛИ
  предоплата.процент ≥ 30
  иначе → блок перехода + уведомить владельца (drift-алерт)
  проверка: при каждой смене статуса проекта

Связи#

← C2 Процессы (вход): C4 берёт реальные процессы и роли как сырьё для SOP. Процесс без регламента — это «делаем», но не «делаем одинаково».
← C3 Люди / +A Агенты (вход): из C3 берётся «кто исполняет» (owner, исполнитель-человек), из +A — карточка-стандарт агента (вход/выход), к которой AOP привязывает tool/autonomy. AOP — это «клей» (zoo L4) в части предписания: что агент обязан сделать.
→ D Данные/SSOT (выход и вход одновременно): C4 предписывает действия, исполнение которых порождает event log в D (выход — норма задаёт, какие события должны быть); drift-detector читает факт из D (вход — сверка против структурированного store состояния, не против read-only RAG). Граница строгая: C4 хранит норму, D хранит факт; детерминизм расчётов живёт в D, не в C4.
→ C5 Контроль + Дашборд (выход): drift-метрика (% соблюдения, число дрейф-событий, непокрытые обязательные пункты) уходит в дашборд собственнику как actionable-сигнал. C4 даёт C5 предмет контроля — без нормы KPI «соблюдаемости» не существует.
↕ Governance (сквозное): autonomy_level и risk_class в AOP — это runtime-enforcement governance (не комитеты, а правило, исполняемое в момент действия: human-in-the-loop срабатывает на необратимом). Версионирование + Decision Memory + федеративное утверждение нормы (узел суверенен, общий стандарт — на уровне конституции) — это governance, встроенный прямо в контракт.
↔ C1 Карта / L1 База знаний (разграничение): C4 НЕ описывает, как устроен бизнес (это C1/L1 — описание ≠ норма ≠ данные). C4 хранит предписание «как должно делаться», L1 — «как оно вообще работает», D — «как сделалось фактически». Три разных слоя, которые нельзя сливать.

🗄️ D · Данные → единый источник правды (SSOT, слой данных)#

D · Единый источник правды: Event Log, Data Contract, State Store.

Что это#

Контур D — это слой данных организации: единое, машиночитаемое место, где живут факты о состоянии бизнеса (а не описание того, как бизнес устроен — описание лежит в L1 базе знаний контура C4/Регламентов, и это принципиально другой слой). Если хребет Дмитрия идёт ПРОЦЕССЫ → ЛЮДИ → РЕГЛАМЕНТЫ → КОНТРОЛЬ → УПРАВЛЯЕМОСТЬ, то контур D — это разнесение СЛОЯ ДЕЙСТВИЙ (что люди делают, живёт в их привычных каналах) и СЛОЯ ДАННЫХ (цифровой след этих действий, который агенты собирают фоном), и сборка этого следа в один источник правды, питающий дашборд собственника (C5). В терминах разведки мира это System of Intelligence (Moore/Greylock) — слой, который надстраивается над System of Record и превращает «digital exhaust» от работы людей в управляемый актив.

Ключевая инженерная установка контура: SSOT — это НЕ чистый векторный RAG. RAG read-only, «не знает истины и времени», он годен для извлечения из неизменных документов, но не для хранения состояния. Истина о том, на какой стадии сделка №412 сегодня и кто за неё отвечает, должна жить в структурированном store состояния (SQL или граф), который агенты обновляют транзакционно, а RAG ставится поверх для семантического поиска. Перепутать эти две вещи — корневой архитектурный провал контура (см. антипаттерны).

Сущности#

Конкретные артефакты, которые в этом контуре можно создать и потрогать:

EVENT LOG (журнал событий) — append-only лента фактов «что произошло». Минимальная схема ван дер Аалста / Celonis: case_id | activity | timestamp | actor (+ опц. payload, channel, source_agent). Пример строки: deal-412 | "выставлен инвойс" | 2026-06-15T14:03Z | agent.invoicer | {amount: 4200, currency: EUR}. Это основа process mining «регламент vs факт»: по логу видно, как процесс течёт НА САМОМ ДЕЛЕ, а не как написано в AOP. Append-only — события не редактируются, только дописываются.
STATE STORE (хранилище состояния) — структурированный store ТЕКУЩЕГО состояния предметных сущностей (SQL-таблицы или граф). Не лента, а снимок «как есть сейчас»: deal-412: stage=invoiced, owner=Андрей, amount=4200, updated_at=.... Агенты его обновляют (read-modify-write), это и есть System of Record для SMB, который раньше держал ERP. Каждое обновление параллельно роняет строку в EVENT LOG.
CONTEXT LAYER (контекстный/семантический слой) — 5 компонентов Atlan: Semantic/Metrics Layer (один governed-расчёт каждого KPI, как dbt: «выручка» определена ОДИН раз и считается ВНЕ LLM); Ontology/Identity (что такое «клиент», «сделка», единый ID — что Андрей и А. Шанский это один actor); Operational Playbooks (ссылка на AOP, как трактовать данные); Lineage (откуда взялась цифра — от какого события/агента); Decision Memory (журнал принятых решений и их обоснований, чтобы агенты и люди не переоткрывали закрытые вопросы).
Предметные сущности (domain entities) — типизированные карточки объектов бизнеса со стабильными полями: Сделка (id, стадия, сумма, владелец, клиент_id), Клиент (id, контакты, сегмент, LTV), Объект, Задача (id, исполнитель, дедлайн, статус), Инвойс (id, сделка_id, сумма, оплачен), Кандидат. Именно они наполняют STATE STORE; их набор = карта C1, переведённая в данные.
DATA CONTRACTS (контракты данных) — формальная схема-договор на каждый поток: какие поля обязательны, типы, допустимые значения, владелец потока, что считать «свежим». Пример: контракт на Инвойс требует amount > 0, currency ∈ {EUR, UAH}, сделка_id существует в STATE STORE. Агент, пишущий невалидную запись, отбивается контрактом — это runtime-governance, а не комитет.
AI-Ready Data (профиль готовности) — не отдельный файл, а 4 проверяемых свойства всего слоя: unified (один источник, без дублей), governed (контракты + lineage), contextually meaningful (через CONTEXT LAYER), continuously refreshed (свежесть по SLA). Чек-лист, по которому слой признаётся «AI-ready».
RAG-индекс (поверх) — векторный/гибридный индекс над неизменными документами (договоры, регламенты, переписка) для извлечения. Стоит поверх STATE STORE, не вместо него.

Механика (что происходит)#

Человек делает работу как привык — в своём канале (мессенджер, почта, звонок, таблица). Это СЛОЙ ДЕЙСТВИЙ. Он ничего не «вносит в систему» специально.
Агент-наблюдатель (из контура A), встроенный в этот канал, собирает след фоном: распознаёт, что произошло событие → формирует запись по схеме EVENT LOG и валидирует её против DATA CONTRACT.
Валидная запись дописывается в EVENT LOG (append-only) и одновременно обновляет STATE STORE (агент делает read-modify-write предметной сущности: сделка-412 переходит invoiced). Lineage фиксирует, какое событие/агент породили изменение.
CONTEXT LAYER связывает запись с онтологией (резолвит, что «Андрей» = actor andrey.shansky) и с метриками (это событие влияет на KPI «выручка месяца», расчёт которого определён один раз).
KPI считаются детерминированно ВНЕ LLM по Semantic Layer поверх STATE STORE; LLM цифры не выдумывает, а только их достаёт и формулирует.
Готовые, governed-данные текут в C5 (дашборд собственника) и обратно в агентов (как контекст для следующих решений). RAG-индекс параллельно даёт семантический доступ к сырым документам.

Итог превращения: разрозненные человеческие действия → валидированные события → актуальное состояние → governed-метрики → управляемость.

Кто делает#

Проектирование схем (EVENT LOG, предметные сущности, DATA CONTRACTS, онтология) — ЧЕЛОВЕК (архитектор данных / интегратор; «методология до инструмента»). Это акт создания истины — его делает человек.
Сбор следа из каналов, формирование событий, валидация по контракту, write в EVENT LOG/STATE STORE — AI-АГЕНТ (узкий, по одному каналу/сущности; scope creep его убивает).
Резолв идентичности, поддержка lineage, расчёт метрик — AI-АГЕНТ детерминированными правилами + Semantic Layer; LLM не считает.
Разрешение противоречий и пробелов данных (два агента записали разное про сделку-412) — ЧЕЛОВЕК (human-in-the-loop); расхождение фиксируется, не перезаписывается тихо.
Утверждение определения KPI и онтологии, владение SSOT, доступ к дашборду — СОБСТВЕННИК (или назначенный data-steward; фактор stewardship по MIT CISR). Истину утверждает человек — «AI лишь усилитель».
Необратимые операции / траты >$0, инициированные данными — ЧЕЛОВЕК в петле (автономия по риску).

Зачем / что ломается без него#

Без слоя данных AI-организация невозможна: агенты действуют, но след их и людей работы исчезает (digital exhaust улетает в трубу), и собственник управляет вслепую. Конкретные провалы при отсутствии контура: (1) KPI считаются по-разному в разных чатах и таблицах — «выручка» у РОПа одна, у бухгалтера другая, спор о цифрах вместо управления; (2) silent failures — агент тихо сломался на шаге 3, никто не заметил, потому что нет состояния и health-check поверх него (а тихий сбой хуже ручной работы); (3) риск ключевого лица — данные живут в голове и личных таблицах сотрудника, ушёл человек — ушла история; (4) LLM-галлюцинации цифр, когда нет детерминированного расчёта вне модели; (5) невозможен process mining «регламент vs факт» — не видно, что AOP нарушается, потому что нет EVENT LOG. По BCG данные — это 20% (тех-слой), но без них не работают и 70% людей-и-процессов, и 10% алгоритмов.

По этапам зрелости#

1 Awareness. Данных-как-слоя нет. Факты живут в головах, бумажных журналах, разрозненных Excel. «Источник правды» = память владельца. EVENT LOG отсутствует как понятие.
2 Active. Точечный ChatGPT помогает считать/форматировать ad hoc, но результат никуда не пишется системно. По-прежнему нет STATE STORE, нет схем; данные одноразовые, после сессии теряются.
3 Operational («зоопарк»). Появились свои боты, КАЖДЫЙ со своим хранилищем: у бота продаж своя табличка, у бота поддержки своя. Дубли, рассинхрон, у каждого «свой» клиент-412. EVENT LOG если и есть, то у каждого бота свой формат. Это и есть боль, ради которой строят контур: данные есть, но не единые.
4 Systemic («контур»). Единый STATE STORE + общий EVENT LOG с одной схемой; DATA CONTRACTS на потоках; CONTEXT LAYER с governed-метриками (один расчёт KPI); lineage; дашборд собственника питается отсюда. Федеративная конституция: узлы (под-проекты/отделы) суверенны в своих данных, но общие стандарты схем и контрактов обязательны. Целевое состояние перехода 3→4.
5 Transformational. SSOT = живой Digital Twin of Organization: на нём можно не только мониторить, но и симулировать («что будет с выручкой, если…»), приоритизировать на языке совета директоров. Data-слой самообслуживается, decision memory полная, AI-native операционка.

Как внедряется (SMB без ERP)#

Ключевая особенность SMB: готового event-лога и ERP нет — агенты порождают след с нуля. Шаги:

Карта сущностей из C1. Выписать 5–8 предметных сущностей, реально живущих в бизнесе (Сделка, Клиент, Задача, Инвойс…) и их ключевые поля. Артефакт: таблица сущностей.
Спроектировать EVENT LOG-схему. Зафиксировать минимум case_id + activity + timestamp + actor. Артефакт: список допустимых activity по каждому процессу из C2.
Поднять STATE STORE. Для SMB — обычная SQL-БД (Postgres/SQLite) или Airtable/Notion-база как старт; таблицы = предметные сущности. Артефакт: схема БД.
Написать DATA CONTRACTS на каждый поток (обязательные поля, типы, владелец, свежесть). Артефакт: YAML/markdown-контракты.
Встроить агентов-сборщиков в существующие каналы (friction audit: НЕ плодить новый интерфейс — встроиться туда, где люди уже живут). Каждый агент узкий: один канал → одна сущность. Он порождает событие и обновляет state.
Поднять Semantic Layer — определить каждый KPI ОДИН раз, расчёт вне LLM. Артефакт: словарь метрик.
Поставить RAG поверх для документов и health-checks + дашборд поверх STATE STORE (silent failures недопустимы).
Назначить data-steward и владельца SSOT (stewardship). Включить human-in-the-loop на противоречиях и необратимом.

Принцип сборки — снизу вверх, методология до инструмента, «истину создаёт человек».

Антипаттерны / грабли#

SSOT = чистый векторный RAG. Состояние засунули в read-only векторную базу — система «не знает истины и времени», агенты не могут обновлять, всё рассыпается. Нужен структурированный store состояния + RAG только поверх.
LLM считает KPI. Цифры генерит модель, а не детерминированный Semantic Layer → галлюцинации в отчётах собственнику. Расчёт всегда ВНЕ LLM.
Scope creep агента-сборщика. Один агент пытается собирать след из всех каналов и про все сущности — «галлюцинирует к шагу 3». Узкие агенты выживают, широкие умирают.
Зоопарк хранилищ (застрять на стадии 3). У каждого бота своя база, нет общих схем/контрактов — дубли и рассинхрон. Лечится DATA CONTRACTS + единым STATE STORE, а не ещё одним ботом.
Память гниёт без обслуживания / тихая перезапись противоречий. EVENT LOG и decision memory никто не чистит и не разруливает; агент молча затирает чужую запись. Принцип «research writes, delivery reads», расхождения — в явный contradictions-журнал, не тихо.
Новый интерфейс вместо встраивания. Заставили людей вносить данные в отдельную систему → люди не вносят → след пустой. Integration > innovation: собирать там, где работа уже идёт.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). «Сколько заказов в работе?» — владелец звонит троим: менеджер считает по заявкам, цех по распилам, бухгалтер по оплатам. Три цифры, ни одна не сходится.

Стало (4). Единый Event Log (case_id+activity+timestamp+actor) + State Store; «заказов в работе» = один governed-запрос к одному источнику.

Пример записи (строки Event Log → State Store):

SD-2026-0617-007 | замер_проведён       | 2026-06-17 11:40 | Игорь
SD-2026-0617-007 | КП_отправлено        | 2026-06-18 09:12 | proposal-drafter
SD-2026-0617-007 | предоплата_получена  | 2026-06-19 14:03 | Ольга
→ State Store: проект SD-2026-0617-007 · статус «в производство» · предоплата 40 %

Связи#

← C1 (Карта бизнеса): карта даёт перечень предметных сущностей и процессов — вход для схем STATE STORE и activity EVENT LOG.
← C2 (Процессы): определяет допустимые активности и переходы состояний (что считать событием).
↔ C4 (Регламенты → AOP): РАЗВЕДЕНЫ намеренно — C4/L1 хранит описание «как должно быть» (знания), D хранит факты «как есть» (данные). Стык — process mining: сравнение EVENT LOG (D) с AOP (C4) даёт drift-detection «регламент vs факт».
↔ +A (Агенты): агенты — писатели в слой данных (порождают след, обновляют state) и читатели (берут state как контекст). D — их общая память и рабочее поле.
→ C5 (Контроль + Дашборд): governed-метрики Semantic Layer и состояние STATE STORE — прямой вход дашборда собственника; health-checks поверх состояния ловят silent failures.
↔ Governance (сквозное): DATA CONTRACTS + lineage + ownership SSOT — это runtime-enforcement governance (не комитеты), реализованный именно в слое данных.
Оговорка Минцберга: STATE STORE/KPI режут невидимую ценность — рядом с метриками держать чек-лист слепых зон, помнить, что организация ещё и сообщество, а не только то, что попало в EVENT LOG.

📊 C5 · Контроль + Дашборд собственнику#

C5 · Командный центр собственника: очередь действий.

Что это#

C5 — это контур, который превращает цифровой след всех нижних контуров (процессы C2, регламенты-AOP C4, SSOT-данные D) в одну управленческую поверхность собственника: набор governed-определений «что считать правдой» + actionable-вид «что делать сегодня». В хребте Дмитрия это слой КОНТРОЛЬ (KPI / проверка / отчётность), но в AI-версии он не отчётный, а исполнительный: не «вот цифры за месяц», а «вот три вещи, которые горят, и решение по ним за тобой». На витрину это выходит как «Командный центр собственника» (Owner Cockpit — язык собственника/совета: приоритизировать, мониторить, симулировать), технически — как System of Intelligence (Moore/Greylock) поверх System of Record: слой, который читает digital exhaust людей и агентов и сводит его в состояние, по которому принимают решения.

Ключевое отличие от классической BI-отчётности: C5 живёт на детерминизме (расчёт KPI ВНЕ LLM — LLM не выдумывает цифры, только формулирует, что они значат) и на обратной петле — каждое «горит» в дашборде должно иметь адрес возврата в C2 (сломанный процесс) или C4 (нарушенный регламент-AOP), иначе это просто красивый светофор, на который никто не жмёт.

Сущности#

Конкретные объекты, которые создаются и существуют в этом контуре:

metrics.yml (Semantic / Metrics layer, governed). Один файл-источник определений KPI — паттерн dbt-метрик. Поля на метрику: name, description, formula (SQL-выражение над SSOT), grain (по дню/неделе/клиенту), filters, owner (человек), source_tables, refresh. Пример: revenue = SUM(orders.amount) WHERE orders.status='paid' AND orders.is_test=false. Смысл: ОДИН governed-расчёт revenue/orders, а не 5 версий в пяти отчётах. «Сколько у нас заказов» имеет ровно один ответ.
Карточка KPI (KPI card / definition). Документ на каждую метрику: что меряем, формула простым языком, целевое значение (target/threshold), кто owner, чек-лист слепых зон (Минцберг — см. ниже), частота обновления, источник данных. Существует как .md в реестре метрик рядом с metrics.yml.
Плитки дашборда (tiles). Визуальные единицы поверхности. Каждая плитка = одна метрика из metrics.yml + состояние (норма / внимание / тревога), дельта к периоду, спарклайн, ссылка-drill в SSOT. Плитка НИКОГДА не считает сама — только рендерит governed-число.
Вид «ЧТО ДЕЛАТЬ СЕГОДНЯ» (action queue). Главный экран. Не графики, а очередь записей четырёх типов: 🔥 горит (порог пробит), ⏳ решение не принято (висит человек-in-the-loop по необратимому/тратам), 💰 должны деньги (просрочка дебиторки/незакрытый счёт), 🔧 сломанный процесс (variance из process mining). Запись = {тип, объект, с какого момента, к кому привязано, кнопка-действие}.
Health-checks (контракты живости). Набор проверок против silent failures — не «упал ли агент», а «течёт ли след». Каждый check = {что проверяем, ожидание, период, severity}. Примеры: «event log пополнялся за последние 24ч», «у >95% заказов проставлен статус», «агент-сборщик C4 писал в SSOT сегодня», «нет дубль-определения revenue». Health-check ловит немой отказ — когда система «работает», но данные молча перестали приходить.
Alerts (правила тревог). {metric/health-check, условие, канал, адресат, severity, что делать}. Срабатывают на пробой порога ИЛИ провал health-check. Падают в канал, где человек уже живёт (Telegram/почта), а не в отдельную панель, куда надо заходить.
Event Log (журнал событий) + variance-отчёт (Process Mining). Минимальная схема лога: case_id · activity · timestamp · actor (van der Aalst/Celonis). Variance-отчёт = сравнение «регламент/AOP (C4) vs факт (лог)»: где реальный путь кейса отклонился от заданного, как часто, сколько это стоит. Существует как таблица отклонений с привязкой к конкретному AOP.
Decision Memory (журнал решений собственника). Лог {дата, что горело, какое решение принял собственник, почему, исход}. Накапливает контекст: почему в марте отключили этот процесс. Это компонент Context Layer (Atlan) и страховка от повтора ошибок.

Механика (что происходит)#

Поток данных и работы через контур, по шагам:

Сбор следа (фон). Люди делают работу как привыкли (слой действий, C2/C3); агенты C4 фоном пишут цифровой след в Event Log и обновляют состояние в SSOT (слой данных, D). C5 ничего не собирает руками — он подписан на SSOT.
Детерминированный расчёт. Движок метрик берёт metrics.yml и считает KPI прямо над SSOT (SQL/граф), ВНЕ LLM. Результат — числа с одним governed-определением. LLM сюда не пускают считать — только объяснять.
Оценка состояния. Каждое число сверяется с target/threshold карточки KPI → плитка получает цвет. Параллельно прогоняются health-checks: течёт ли след вообще.
Process mining. По Event Log строится фактический граф процесса и сравнивается с AOP из C4 → variance. Большой variance = «сломанный процесс».
Сборка очереди действий. Из пробитых порогов, проваленных health-checks, висящих human-in-the-loop решений, просрочек по деньгам и variance собирается вид «ЧТО ДЕЛАТЬ СЕГОДНЯ». LLM здесь работает усилителем: формулирует каждую запись человеческим языком («дебиторка по клиенту X висит 14 дней, обычный цикл — 5») — но цифры берёт готовые, не выдумывает.
Доставка и решение. Срочное уходит alert'ом в живой канал. Собственник открывает очередь, по необратимым/денежным пунктам принимает решение → запись в Decision Memory.
Обратная петля. Решение/диагноз возвращается вниз: «сломанный процесс» → тикет на правку C2 или AOP C4; «немой отказ агента» → правка карточки агента C4; новое «что меряем» → новая запись в metrics.yml. Контур замыкается.

Кто делает#

Определить, что вообще считать управляемостью (какие KPI, что значит «горит»): СОБСТВЕННИК (его язык целей) + ЧЕЛОВtek-архитектор формализует. Истину создаёт человек.
Написать и держать metrics.yml / карточки KPI / чек-листы слепых зон: ЧЕЛОВЕК (data/ops-инженер, owner метрики). Governed-слой нельзя отдавать LLM на самосочинение.
Считать числа (детерминированный движок): КОД (SQL/движок метрик), не AI-агент и не человек руками.
Собирать след в Event Log / обновлять состояние SSOT: AI-АГЕНТЫ C4 (фоном, пока люди работают).
Прогонять health-checks и process-mining, формировать черновик очереди «что делать сегодня», писать человекочитаемые формулировки: AI-АГЕНТ (детерминированный расчёт + LLM-объяснение поверх).
Принимать решения по 🔥/💰/необратимому (human-in-the-loop): СОБСТВЕННИК. Автономия по риску — необратимое и траты > $0 не отдаются агенту.
Замыкать петлю (превратить диагноз в правку C2/C4): ЧЕЛОВЕК-владелец процесса; агент может предложить, но правку регламента подтверждает человек.

Зачем / что ломается без него#

Без C5 нижние контуры работают «вслепую»: агенты собирают след, SSOT наполняется — но собственник этого не видит и продолжает управлять по ощущениям и устным докладам. Конкретные провалы при отсутствии:

Silent failures дороже ручного труда. Агент молча перестал писать в SSOT, статусы не проставляются — а дашборда нет, значит никто не замечает неделями. По практике (Reddit) немой отказ хуже честного ручного процесса: ты думаешь, что система работает, а она врёт. Health-checks — единственный механизм, который это ловит.
Пять версий правды. Без metrics.yml каждый отчёт считает revenue по-своему; на совещании три цифры выручки, спор о цифрах вместо решений. Governed metrics layer убирает спор.
Отчётность вместо управления. Без вида «что делать сегодня» дашборд превращается в красивые графики, на которые смотрят раз в месяц. Боль: данные есть, действий нет — провал ценности, тот самый разрыв «зоопарк → контур».
Невидимая дебиторка и зависшие решения. «Должны деньги» и «решение не принято» без очереди просто теряются — деньги висят, необратимые шаги делаются агентом без санкции.
Регламент мёртв. Без process mining AOP из C4 остаётся декларацией: написано одно, делается другое, и никто не меряет зазор.

По этапам зрелости#

1 Awareness: контроля как контура нет. KPI — в голове собственника, «отчётность» = устные доклады и таблица в Excel, которую кто-то ведёт руками. Цифры расходятся, проверка реактивная (узнали, когда уже сломалось).
2 Active: точечный ChatGPT помогает свести отчёт ad hoc («сделай мне сводку из этой выгрузки»), но определения KPI не зафиксированы, дашборда нет, всё пересобирается заново каждый раз. След не собирается системно.
3 Operational («зоопарк»): появились свои боты и дашборды, но их несколько и они считают по-разному — у отдела продаж своя выручка, у финансов своя. Дубли определений, риск ключевого лица (метрику знает один человек), нет health-checks → silent failures проходят незамеченными. Это «отчётность есть, управляемости нет».
4 Systemic («контур»): один metrics.yml (governed), единый actionable-дашборд поверх SSOT, вид «что делать сегодня», работающие health-checks и alerts, process mining против AOP, обратная петля на C2/C4. KPI имеют owner'ов и чек-листы слепых зон. Это целевая стадия (скачок 3→4 — максимум ценности по MIT).
5 Transformational: контроль становится системой — симуляция («что будет, если отключить процесс X»), Decision Memory как актив, метрики самообслуживаются и пересобираются под новые вопросы; собственник управляет состоянием, а не собирает его. AI-native операционка.

Как внедряется (SMB без ERP)#

Порядок шагов и артефакты с нуля:

Спроси собственника 5–7 вопросов «по чему ты реально управляешь». Зафиксируй язык целей (язык командного центра). Выход: черновой список из 5–8 KPI — не больше. System-first: меряем то, чем управляем, не всё подряд.
Заведи реестр метрик: metrics.yml + карточка на каждый KPI. Один governed-расчёт на метрику. Это самый дорогой и самый важный артефакт — делается руками человека.
Реши, откуда брётся след. В SMB без ERP лога нет — агенты C4 ПОРОЖДАЮТ его с нуля: задай минимальную схему Event Log case_id · activity · timestamp · actor и навесь на агентов запись событий фоном, пока люди работают как привыкли.
Поставь детерминированный расчёт над SSOT (даже если SSOT — это SQLite/Google Sheets + структурированный store состояния; RAG только поверх для извлечения, НЕ как источник цифр).
Собери минимальный дашборд: сначала вид «ЧТО ДЕЛАТЬ СЕГОДНЯ», потом плитки. Начни с очереди действий, графики — потом. Actionable раньше красивого.
Включи health-checks с первого дня — хотя бы три: «след пополнялся», «статусы проставлены», «нет дубль-определения». Silent failure ловится только так.
Настрой alerts в канал, где люди уже живут (Telegram/почта). Friction audit: не плодить новую панель, встроить в существующий канал.
Добавь process mining, когда есть хотя бы один AOP в C4 — variance-отчёт «план vs факт».
Заведи Decision Memory — простой лог решений собственника. Дёшево, окупается контекстом.
Под каждый KPI — чек-лист слепых зон (Минцберг). Например, к «среднему чеку» — приписка: «не отражает лояльность и сарафан; рост чека за счёт ухода мелких клиентов — красный флаг, не победа».

Антипатт164ны / грабли.

Дашборд как отчётность, а не как действие. Делают красивые графики, открывают раз в месяц — управляемости ноль. Лечится приоритетом вида «что делать сегодня».
KPI считаются внутри LLM. Просят агента «посчитай выручку» — он галлюцинирует к третьему шагу. Цифры — детерминированно, вне LLM; LLM только объясняет.
Нет health-checks → silent failures. Самая дорогая грабля: система «работает», но след молча иссяк, и решения принимаются по протухшим данным. Хуже честного ручного процесса.
Пять версий KPI без semantic layer. Каждый отчёт со своей формулой revenue → споры о цифрах вместо решений.
Метрики вытесняют невидимую ценность (Минцберг). Метрический контроль начинает душить неизмеримое — отношения, доверие, качество. «Твёрдые данные режут невидимую ценность»: без чек-листа слепых зон под каждым KPI дашборд оптимизирует то, что меряется, и убивает то, что нет. Дивизионализация по метрике ≠ управляемость.
Дашборд без обратной петли. «Горит» загорается, но нет адреса возврата в C2/C4 — диагноз есть, правки нет, лампочка горит вечно.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). Владелец заходит в цех, спрашивает «что по заказам?» — слышит «вроде нормально». О просрочке монтажа узнаёт от злого клиента по телефону.

Стало (4). Один экран с плитками-действиями («что делать сегодня») и план vs факт по сроку цикла.

Пример записи (плитки дашборда):

🔴 SD-...-007: предоплата 19.06, в цех не передан 2 дня — handoff завис → [открыть]
🟡 3 КП отправлены >5 дней назад без ответа — нужен follow-up
🟢 Монтаж SD-...-003 завтра 10:00 — бригада подтверждена
Метрика: срок цикла замер→монтаж — план 21 дн / факт 27 дн
         (где теряем: согласование дизайна +6 дн)

Связи#

← D (Данные → SSOT): вход. C5 не хранит данные, он читает governed-состояние из SSOT и Event Log. SSOT — структурированный store, который агенты обновляют (не read-only RAG).
← C4 (Регламенты → AOP): вход двойной. Агенты C4 поставляют цифровой след; AOP'ы C4 — это «план», с которым process mining сравнивает «факт». → C4 обратная петля: немой отказ агента или drift → правка карточки агента / AOP.
← C2 (Процессы): вход — фактический ход кейсов в логе. → C2 обратная петля: «сломанный процесс» (variance) → тикет на правку процесса.
↔ C3 (Люди): owner'ы метрик — из C3; человек-in-the-loop по решениям — оттуда же.
↔ Governance (сквозное): C5 — место runtime-enforcement, а не комитетов: governed metrics.yml, health-checks и автономия-по-риску (human-in-the-loop на необратимом/тратах) — это и есть governance в действии.
→ СОБСТВЕННИК: выход контура и всей модели — командный центр собственника «приоритизировать / мониторить / симулировать». C5 — последний контур, ради которого собирались все нижние.

(Примечание: в блоке антипаттернов в слове «Антипаттерны» при наборе проскочил мусорный фрагмент — корректное написание «Антипаттерны / грабли».)

🏛️ Сквозное · Правила и контроль (Governance) / Зрелость / Конституция#

Governance · сквозной контроль и конституция: автономия по риску.

Что это#

Это не отдельный контур рядом с остальными, а сквозной слой, который держит все контуры (C1 Карта → C2 Процессы → C3 Люди → +A Агенты → C4 Регламенты/AOP → D Данные/SSOT → C5 Контроль/Дашборд) под единым набором правил. Правила и контроль (governance) отвечают на вопрос «по каким законам живут все узлы фермы», и закрывает он его не комитетами и не PDF-политиками, а через runtime-enforcement — правила вшиты в слой данных и дашборда, нарушение либо физически невозможно, либо мгновенно подсвечено. В хребте Дмитрия это слой УПРАВЛЯЕМОСТИ: то, что превращает набор работающих процессов, людей и агентов в управляемую систему, а не в «зоопарк», где каждый узел живёт по своим правилам.

Роль контура — федеративная конституция: узлы (отделы, процессы, локальные базы знаний 00-CONTEXT, агенты) суверенны в своей внутренней механике, но обязаны соблюдать общий минимум стандартов входа/выхода, чтобы данные сшивались в единый SSOT и дашборд собственника. Это прямой перенос операционного кодекса Дмитрия (проекты суверенны + кодекс = конституция, 00-CONTEXT = локальная база узла) на уровень всей компании. Governance — это то, что делает скачок 3→4 (зоопарк → контур) необратимым: без него стандарты декларируются, но не держатся, и система сползает обратно в зоопарк.

Сущности#

Конкретные артефакты, которые создаются и живут в этом контуре:

КОНСТИТУЦИЯ (CONSTITUTION.md) — корневой документ из ~7 разделов-законов, обязательных для всех узлов. Поля каждого закона: id, правило, обоснование, как проверяется (runtime), владелец. Минимальный набор законов: - Данные ≠ знания — знания (ОПИСАНИЕ как работает, L1) живут отдельно от данных (ФАКТЫ, L3); агент читает L1 → пишет L3, не смешивает. - Детерминизм — расчёт KPI/денег ВНЕ LLM (SQL/metrics layer), LLM не выдумывает цифры и не «знает истину и время». - Стандарт вход/выход — у каждого агента и процесса формализованы вход и выход (карточка-стандарт L2). - Data contract — у каждого потока данных есть контракт (см. ниже). - Runbook — у каждого критического процесса есть исполняемая инструкция «что делать при сбое». - Автономия по риску — необратимое / траты > $0 = human-in-the-loop. - Истину создаёт человек, AI — усилитель — приоритет вовлечения снизу над приказом сверху.
DATA CONTRACT (contracts/<поток>.yml) — машиночитаемый контракт на каждый поток в SSOT. Поля: источник (какой агент/узел пишет), схема (имена и типы полей, обязателен минимум case_id + activity + timestamp + actor — формат event log для process mining), частота обновления, владелец-steward, правила валидации (что отвергается на входе), потребители (кто читает: дашборд, другой агент). Пример строки схемы: lead_id:uuid · stage:enum(new|qualified|won|lost) · ts:datetime · actor:human|agent_id.
РЕЕСТР УЗЛОВ И АГЕНТОВ (registry.csv / таблица) — единая таблица суверенных узлов и агентов. Колонки: узел, тип (отдел|процесс|агент), владелец, вход, выход, статус (active|deprecated), соответствие конституции (✓/✗ по каждому закону), bus-factor. Это карта федерации: кто чему подчиняется, кто что нарушает.
ПОЛИТИКА АВТОНОМИИ-ПО-РИСКУ (autonomy-policy.md + таблица матрицы) — матрица «действие × уровень автономии». Строки — классы действий (читает данные / черновик / отправка наружу / трата денег / необратимое), столбцы — авто, подтверждение человеком, запрещено агенту. Правило-якорь: всё необратимое и любые траты > $0 → human-in-the-loop; обратимое и внутреннее → авто.
HEALTH-CHECK / DRIFT-ПАНЕЛЬ — набор автоматических проверок поверх SSOT, ловящих silent failures (молчаливые сбои хуже ручной работы): «агент X не писал в SSOT N часов», «дрейф AOP: факт разошёлся с регламентом» (process mining: регламент vs Event Log), «контракт нарушен: поле приходит пустым», «память узла гниёт: последняя запись 30 дней назад». Это runtime-enforcement в чистом виде — контроль живёт в дашборде, а не в совещании.
STEWARDSHIP-ПЛАН ПЕРЕХОДА 3→4 (migration-3to4.md) — именованный документ владения миграцией из зоопарка в контур. Поля: steward (конкретный человек, владелец перехода), инвентарь зоопарка (список разрозненных ботов и дублей), карта схлопывания (что во что сводится), этапы, критерий готовности узла к SSOT, % бюджета на change-management (≥20). Фактор stewardship — по MIT CISR именно он отличает зрелость, доказанную деньгами, от пилота-витрины.
РЕЕСТР ПРОТИВОРЕЧИЙ (contradictions/) — место, куда явно пишутся расхождения между узлами (один отдел считает KPI так, другой иначе; регламент говорит одно, факт показывает другое), вместо тихой перезаписи. Каждое противоречие — отдельный файл с двумя позициями и статусом разрешения.
ЧЕК-ЛИСТ СЛЕПЫХ ЗОН ПОД KPI (Минцберг-оговорка) — список того, что метрики не видят («твёрдые данные режут невидимую ценность»): лояльность, репутация, неформальные связи, обучение. Висит рядом с дашбордом как противовес.

Механика (что происходит)#

Поток работы и данных через контур:

Принятие закона. Собственник + steward формулируют закон конституции → каждый закон получает поле «как проверяется (runtime)». Закон без runtime-проверки не считается принятым (иначе он PDF, а не конституция).
Регистрация узла. Новый узел/агент попадает в registry только с заполненными вход/выход и привязанным data contract. Нет контракта → нет права писать в SSOT.
Валидация на входе. Когда агент пишет в SSOT, контракт валидирует данные (схема, типы, обязательные поля event log). Нарушение → запись отвергается и подсвечивается в health-панели, а не молча портит SSOT.
Enforcement в рантайме. Перед необратимым действием или тратой агент сверяется с autonomy-policy → если класс действия требует человека, ставит на паузу и эскалирует (human-in-the-loop). Контроль происходит в момент действия, не на ретро-комитете.
Детекция дрейфа. Process mining непрерывно сравнивает Event Log (факт) с AOP (регламент). Расхождение → drift-алерт: либо чинят процесс, либо обновляют живой AOP (регламент = живой AOP, не застывший PDF).
Разрешение противоречий. Конфликт расчёта/трактовки → запись в contradictions/, не тихая перезапись → steward разводит позиции → решение возвращается в конституцию или metrics layer как governed-определение.
Миграция 3→4. Steward по migration-3to4.md инвентаризирует зоопарк, схлопывает дубли, подводит каждый узел под контракт и SSOT; ≥20% усилий идёт в change-management (Deloitte), потому что 70% успеха — люди и процессы (BCG 10-20-70), а не алгоритмы.

Кто делает#

Задача контура	Человек	AI-агент	Собственник
Формулировка законов конституции	steward готовит проект	—	утверждает, владеет смыслом
Заведение data contract на поток	data-steward узла пишет	агент-валидатор проверяет на лету	—
Регистрация узла/агента в реестре	владелец узла заполняет вход/выход	—	визирует соответствие
Runtime-валидация записей в SSOT	—	агент-валидатор (детерминированно)	—
Health-check / drift-детекция	реагирует на алерт	агент мониторит фоном	смотрит сводку на дашборде
Решение по эскалации (автономия-по-риску)	оператор подтверждает/отклоняет	агент ставит на паузу, эскалирует	задаёт пороги политики
Разрешение противоречий	steward разводит позиции	агент фиксирует расхождение	арбитр при тупике
Stewardship миграции 3→4	steward — единый владелец перехода	агенты переносят/нормализуют данные	финансирует, защищает приоритет
Чек-лист слепых зон	руководители заполняют	—	держит как баланс KPI

Принцип распределения: детерминированную проверку и сбор следа делает агент (фоном); смысловые решения, арбитраж и владение — человек/steward; пороги, законы и приоритеты — собственник. Это операционализирует «70% людей»: человек работает как привык, агент собирает след и сторожит правила в фоне.

Зачем / что ломается без него#

Governance — это то, что превращает «много работающих ботов» в управляемую систему. Без него:

Зоопарк не схлопывается. Стандарты декларируют, но не держат → дубли ботов, у каждого свой формат, данные не сшиваются в SSOT, дашборд собирать не из чего. Система застревает на стадии 3 навсегда.
Silent failures. Агент тихо перестал писать или пишет мусор — никто не замечает, решения принимаются по гнилым данным. Молчаливый сбой хуже ручной работы, потому что ему доверяют.
Scope creep и галлюцинации цифр. Без закона детерминизма LLM начинает «считать» KPI и выдумывать числа («галлюцинирует к шагу 3»); собственник принимает решения по вымышленным метрикам.
Риск ключевого лица и гниль памяти. Без реестра и stewardship знание о том, как работает узел, держится в голове одного человека; память узлов гниёт без обслуживания.
Приказ сверху отторгается. Без вовлечения снизу (Минцберг) конституция воспринимается как навязанная бюрократия, узлы саботируют → формальное соответствие, фактический зоопарк.
Необратимый ущерб. Без автономии-по-риску агент однажды потратит деньги или отправит наружу то, что нельзя отозвать.

Это и есть антидот к статистике провалов: 95% пилотов (MIT) / 80% (RAND) горят потому, что AI лепят AI-first поверх неуправляемого хаоса. System-first governance — выстроить управляемость, и только потом надстроить AI — снимает этот провал.

По этапам зрелости#

1 Awareness. Конституции нет. Правила — устные и противоречивые. «Governance» = собственник в голове держит, как «должно быть». Стандартов входа/выхода нет, данных нет. Контроль = ручная проверка по факту скандала.
2 Active. ChatGPT применяют точечно и ad hoc; правил для его использования нет (кто что куда копирует — никто не знает). Появляется смутное ощущение «надо договориться о стандартах», но артефакта нет. Enforcement отсутствует.
3 Operational (зоопарк). Есть свои боты, но каждый по своим правилам: дубли, расходящиеся форматы, риск ключевого лица. Может существовать пара локальных регламентов (PDF), но они мертвы и расходятся с фактом. Нет конституции, нет контрактов, нет реестра. Боль максимальна — отсюда максимальный скачок ценности при переходе 3→4 (MIT).
4 Systemic (контур). Есть CONSTITUTION.md с runtime-проверками, data contracts на потоки, единый реестр узлов/агентов, health/drift-панель, политика автономии-по-риску, единый SSOT и дашборд. Узлы суверенны, но соблюдают общий минимум — федеративная конституция работает. Steward провёл миграцию. Governance = runtime-enforcement, не комитеты.
5 Transformational. Управляемость существует как система: конституция самоподдерживается (новые узлы заводятся уже compliant by design), drift чинится автоматически, AOP живые, автономия откалибрована по риску динамически. Это AI-native операционка — компания управляется из командного центра собственника, где можно «приоритизировать, мониторить, симулировать».

Как внедряется (SMB без ERP, с нуля)#

Написать конституцию на 1 страницу. 5–7 законов из брифа (данные≠знания, детерминизм, стандарт вход/выход, data contract, runbook, автономия-по-риску, истину создаёт человек). У каждого закона — поле «как проверяется». Без ERP это просто CONSTITUTION.md в репозитории/Notion. Артефакт: CONSTITUTION.md.
Завести реестр узлов в одной таблице. Перечислить отделы/процессы/ботов, у каждого — владелец, вход, выход, bus-factor. Это карта федерации. Артефакт: registry.csv.
Определить SSOT как структурированный store состояния, не RAG. RED FLAG: не строить SSOT чистым векторным RAG (read-only, «не знает истины и времени»). Нужен структурированный store (SQL/Airtable/Google Sheets для SMB), который агенты ОБНОВЛЯЮТ, + RAG поверх для извлечения знаний (L1). Артефакт: SSOT-таблица с минимальной схемой event log (case_id+activity+timestamp+actor).
Написать по одному data contract на 2–3 ключевых потока. Начать с того, что уже считают руками (лиды, заявки, отгрузки). Артефакт: contracts/*.yml.
Поскольку event-логов нет — агенты порождают след с нуля. Уникальность SMB: человек работает как привык (в своём канале), агент встроен в этот канал (integration > innovation, friction audit — не плодить интерфейсы) и фоном пишет цифровой след в SSOT. Артефакт: «клей»-агент L4 (читает L1 → пишет L3).
Поставить health-checks и автономию-по-риску. Простейшие проверки «давно не писал / пусто / трата>$0 = стоп и спроси». Артефакт: health-панель + autonomy-policy.md.
Назначить steward перехода 3→4 и заложить ≥20% усилий в change-management. Один человек владеет миграцией; вовлечение снизу, не приказ сверху (Минцберг). Артефакт: migration-3to4.md.
Свести один дашборд собственнику поверх SSOT с governed-расчётом KPI (один metrics layer, один способ считать каждую метрику). Артефакт: дашборд C5.

Антипаттерны / грабли#

Governance как комитет, а не рантайм. Создают «комитет по AI» и политики-PDF → правила не исполняются, зоопарк продолжается. Лекарство: enforcement в слое данных/дашборда (валидация на входе, drift-алерты), а не на совещаниях.
Унитарное принуждение вместо федерации. Центр диктует узлам всё до мелочей → отторжение, саботаж, формальное соответствие. Дивизионализация ≠ децентрализация: метрический контроль вытесняет неизмеримые цели (Минцберг). Лекарство: суверенитет узлов + только общий минимум стандартов, вовлечение снизу.
SSOT как векторный RAG. Складывают состояние бизнеса в read-only векторную базу → она «не знает истины и времени», агенты не могут обновлять факты. Лекарство: структурированный store состояния (SQL/граф/таблица), RAG только поверх для знаний.
LLM считает деньги. Доверяют расчёт KPI/финансов языковой модели → галлюцинации цифр, решения по вымышленным числам. Лекарство: закон детерминизма — расчёт в metrics layer вне LLM.
Конституция спущена приказом сверху без stewardship. Собственник издаёт «указ», никто не владеет миграцией, change-management не финансируется → буксует, скатывается обратно в зоопарк. Лекарство: именованный steward, ≥20% бюджета на change-management, вовлечение снизу.
Стандарты есть, health-checks нет. Контракты написаны, но никто не следит за их соблюдением в рантайме → silent failures накапливаются. Лекарство: drift/health-панель с первого дня.

🔍 Было → стало (на примере)#

«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP.

Было (3). Две крайности: либо «агентам ничего не доверяем, всё руками» (тогда зачем агенты), либо «бот сам пишет и обещает клиентам» без рамок (репутационный риск). Кто что может делать необратимого — нигде не зафиксировано.

Стало (4). Конституция инвариантов + автономия-по-риску: обратимое агент делает сам, необратимое — через gate человека; все действия агентов в append-only логе.

Пример записи (строка CONSTITUTION):

L3 · Автономия по риску:
  action = «собрать заявку в реестр»   → risk: низкий  → агент автономно
  action = «отправить договор клиенту»  → risk: высокий → подтверждает человек
  action = «вернуть предоплату»         → risk: высокий → подтверждает владелец
  инвариант: каждое действие агента пишется в Event Log (append-only)

Связи#

← C1 Карта бизнеса (фундамент). Карта даёт список узлов и границ → конституция и реестр строятся поверх неё. Вход: карта узлов. Выход: правила, которым эти узлы подчиняются.
↔ C4 Регламенты → AOP. Закон конституции «регламент = живой AOP» делает регламенты исполняемыми; process mining питает drift-детекцию (регламент vs факт по Event Log). Вход: AOP. Выход: drift-алерты, обновлённые AOP.
↔ D Данные → SSOT. Главная стыковка: data contracts и закон «данные≠знания/детерминизм» определяют, что и как попадает в SSOT; SSOT — это место, где governance физически исполняется. Вход: схема и состояние SSOT. Выход: валидация на входе, отвергнутые/принятые записи.
↔ +A Агенты. Карточка-стандарт агента (L2, вход/выход), политика автономии-по-риску и реестр — это governance над агентами. Вход: регистрация агента. Выход: разрешённый класс действий, эскалации.
→ C5 Контроль + Дашборд. Health/drift-панель и чек-лист слепых зон выводятся на дашборд собственнику; metrics layer обеспечивает один governed-расчёт KPI. Вход: события и нарушения. Выход: actionable-дашборд, сводка соответствия.
↔ C3 Люди. Stewardship, вовлечение снизу, change-management (≥20%) — governance человеческого слоя; чек-лист слепых зон балансирует KPI неизмеримой ценностью. Вход: владельцы узлов и steward. Выход: распределение ролей и автономии.

🛠️ Генератор внедрения#

План перехода: 3 шага к контуру (C1-C2 → D,+A → C4-C5).

Контуры — не теория, а станок: каждый раздел детерминированно порождает 3 артефакта внедрения.

ПЛАН — собирается обходом контуров снизу вверх (C1→C2→C3→+A→C4→D→C5, Governance сквозь все): нельзя строить роли без процессов, агентов без ролей, дашборд без данных. Порядок разделов = порядок работ.
ЧЕК-ЛИСТ готовности — да/нет по каждому слою: блок «Как внедряется» каждого раздела → пункты приёмки. Пример инвариантов: Карта помещается на экран и читается за 15 мин? · На каждый шаг ровно один A (RACI)? · У каждого агента есть owner+runbook+health? · KPI считается ВНЕ LLM? · SSOT — store состояния, не read-only RAG?
ВОПРОСЫ для подготовки — извлекаются из «Сущностей» и «Антипаттернов»: каждая обязательная сущность → вопрос собственнику до старта.

Сквозной пример (контур D · Данные), один проход вопрос→чек→шаг:

Вопрос: «Что в вашем бизнесе считается клиентом и по какому ключу опознаётся дубль?» (сущность Ontology/Identity из C1).
Чек (да/нет): есть ли единое определение клиент + уникальный ключ во всех источниках? — Нет (у продаж контакт, у бухгалтерии юрлицо).
Шаг: провести сессию онтологии (C1) → зафиксировать 04-glossary.md → задать схему Event Log case_id+activity+timestamp+actor → поднять State Store (SQL/Airtable) → навесить агента-collector на канал, где люди уже работают, чтобы он порождал след с нуля → governed-расчёт KPI вне LLM → плитка на дашборде.
Замыкание: если дашборд показывает «200 клиентов», а определения нет — это не метрика, а спор; вопрос→чек→шаг прогоняется заново. Так контур D из абстракции превращается в один проверяемый маршрут внедрения.

📚 Глоссарий сущностей#

Карта всех именованных объектов системы (по разделам-источникам).

C1 · Карта бизнеса

Business Map (00-MAP.md) — одностраничная карта бизнеса по слоям Рыбакова (продукт→процессы→люди→управление→инструменты); скелет-модель бизнеса, который повторяют все контуры.
Карточка продукта (Product Definition) — за какой результат и единицу клиент платит; якорь всех потоков.
Реестр ценностных потоков (Value Streams) — список сквозных потоков «триггер → ценность → узлы»; мост к C2.
Реестр узлов и владельцев (Nodes & Owners) — отделы/функции как суверенные узлы, один владелец на узел.
Онтология / Глоссарий идентичности (04-glossary.md) — единые определения сущностей + уникальные ключи дублей; ядро контура, источник case_id.
Границы бизнеса (Boundaries) — что внутри/снаружи контура (своё/подрядчик/смежное).
Карта инструментов (Tooling Inventory) — где физически живут данные каждого узла; вход для D.

C2 · Процессы

Карточка процесса (Process Card) — атомарная единица: триггер→шаги→результат+владелец+статус.
SIPOC-таблица — паспорт процесса: Supplier·Input·Process·Output·Customer.
Карта потока ценности (Value Stream) — цепочка процессов от запроса до денег, со временем ожидания между шагами.
Реестр процессов (Process Registry) — единая таблица всех карточек.
Карта handoffs — точки передачи ответственности; самые хрупкие места разрывов.
Процесс vs проект — правило сортировки: повторяемое регламентируют, уникальное ведут проектом.
Event Log — журнал фактического исполнения, минимум case_id+activity+timestamp+actor; в SMB порождается агентами с нуля.

C3 · Люди

Реестр ролей (Role Registry) — строка = роль (не человек): миссия, процессы, выход, канал.
Карта «роль → человек» (Role-Person Map) — кто какие роли несёт; пометка риска ключевого лица.
RACI-матрица — ответственные на шаги C2; инвариант «ровно один A на шаг».
Карточка роли (Role Card) — паспорт роли: вход/выход, KPI, агенты-помощники, чек-лист слепых зон.
Friction Audit — карта каналов и «двойного ввода»; где встроить агента (integration > innovation).
Реестр span of control — кто кому подчинён, где перегруз.
Карта движения роли по value stack — высота роли (исполнение→надзор→цели) до/после агентов.

+A · Агенты

5 архетипов агентов — Collector (собирает след) · Drafter (черновик) · Qualifier (классифицирует/скорит) · Router (маршрутизирует) · Reconciler (сверяет регламент↔факт).
Карточка-стандарт агента (Agent Card) — исполняемый паспорт: type, mode (помощник/цифровой сотрудник), input/output, autonomy, guardrails, gate, owner, connectors/role_slot, health (L2 zoo).
Режим агента (mode) — assistant (AI-помощник/копайлот поверх человека) или digital-employee (цифровой сотрудник, занимает роль).
Цифровой сотрудник — агент, занимающий роль-слот в оргструктуре и выполняющий работу вместо сотрудника; композиция архетипов + регламент (AOP) + коннекторы + человек-руководитель.
Коннекторы (цифрового сотрудника) — «обвязка» агента-в-роли: кому подчиняется, с кем стыкуется (люди/агенты, handoffs), канал, эскалация; онбординг как у человека.
Реестр агентов (Agent Registry) — единый список карточек; антидот зоопарку.
Инструменты (tools / MCP) — коннекторы агента к каналам и хранилищам, ограничены guardrails.
Guardrails — машинно-проверяемые запреты (куда нельзя писать, потолок трат $0); runtime-enforcement.
Human-in-the-loop gate — точка обязательного подтверждения человеком перед необратимым действием.
Матрица «Автономия-по-риску» — уровень автономии × обратимость/деньги.
Health-check / журнал прогонов — last_run/success/error; ловит silent failures.

C4 · Регламенты → AOP

SOP — человекочитаемый слой контракта (steps, definition_of_done).
AOP (Agent Operating Procedure) — исполнимая проекция SOP для агента (tool, pre/postcondition, autonomy, risk_class).
Чек-лист обязательных пунктов (mandatory checklist) — контроль ПОЛНОТЫ (лечит «пропустил пункт»), не детерминизма.
Drift-detector — сверка event log (факт) с AOP (норма); выдаёт drift_events.
Версия регламента (versioned contract) — semver+changelog; drift меряется против действующей версии.
Decision Memory — лог прецедентов-отступлений от регламента с обоснованием.
Карточка владельца регламента (steward card) — owner + review_cadence (фактор stewardship).

D · Данные → SSOT

Event Log — append-only лента фактов «что произошло» (та же схема, общий с C2/C5).
State Store — структурированный store ТЕКУЩЕГО состояния (SQL/граф), который агенты обновляют; System of Record для SMB.
Context Layer — 5 компонентов Atlan: Semantic/Metrics Layer · Ontology/Identity · Operational Playbooks · Lineage · Decision Memory.
Предметные сущности (domain entities) — типизированные карточки объектов (Сделка, Клиент, Инвойс, Задача…).
Data Contracts — схема-договор на поток: обязательные поля, типы, владелец, свежесть; runtime-валидация.
AI-Ready Data — профиль готовности слоя: unified · governed · contextually meaningful · continuously refreshed.
RAG-индекс — векторный поиск ПОВЕРХ State Store (извлечение, не источник истины о состоянии).

C5 · Контроль + Дашборд

metrics.yml (Metrics layer) — governed-определения KPI (паттерн dbt); один расчёт на метрику.
Карточка KPI — что меряем, формула, target, owner, чек-лист слепых зон.
Плитки дашборда (tiles) — рендер governed-числа + состояние; сами не считают.
Вид «ЧТО ДЕЛАТЬ СЕГОДНЯ» (action queue) — очередь 🔥горит/⏳решение/💰деньги/🔧процесс.
Health-checks — контракты живости следа (против silent failures).
Alerts — правила тревог в канал, где человек уже живёт.
Variance-отчёт (Process Mining) — «регламент/AOP vs факт» по Event Log.
Decision Memory (собственника) — лог управленческих решений и их исходов.

Сквозное · Правила и контроль (Governance)

Конституция (CONSTITUTION.md) — ~7 законов-инвариантов с runtime-проверкой (данные≠знания, детерминизм, стандарт вход/выход, автономия-по-риску…).
Data Contract — машиночитаемый контракт потока (см. D), как объект governance.
Реестр узлов и агентов (registry) — карта федерации + соответствие конституции + bus-factor.
Политика автономии-по-риску (autonomy-policy) — матрица действие × уровень автономии.
Health-check / drift-панель — runtime-надзор поверх SSOT.
Stewardship-план перехода 3→4 (migration-3to4) — именованный владелец миграции из зоопарка в контур; ≥20% на change-management.
Реестр противоречий (contradictions/) — явная фиксация расхождений вместо тихой перезаписи.
Чек-лист слепых зон под KPI — Минцберг-оговорка: что метрики не видят (лояльность, репутация, неформальные связи).

Сшивка с ZOO-фреймворком (приложение для автора — мост к другому фреймворку Дмитрия «зоопарк→контур»; новому читателю можно пропустить):

L0 карта ↔ C1 · L1 база знаний (ОПИСАНИЕ как работает, ≠ данные) ↔ C4/Operational Playbooks · L2 реестр+карточка-стандарт агента ↔ +A · L3 хаб данных (факты) ↔ D · L4 «клей» (агент читает L1 → пишет L3) ↔ collector-агенты +A · L5 actionable-дашборд ↔ C5.

Приложения (для внедренца)#

Готовые к применению артефакты — шаблоны, кейс, диагностика, чек-листы, runbook. Сквозной пример: сервисная компания «РемСервис».

Приложение A · Шаблоны#

Аудитория — внедренец AI-ориентированной организации (SMB без ERP). Каждый шаблон — copy-paste fenced-блок + строка «как пользоваться». Сквозной пример: сервисная компания «РемСервис» (выездной ремонт бытовой техники, 6 человек). Везде один case_id — ось сшивки данных через контуры.

A.1 · Agent Card — паспорт агента (C+A)#

# agent-card · v1 · хранить в registry/agents/<id>.yaml
id: AG-007                       # стабильный ID, не меняется
name: "Сборщик заявок WhatsApp"
type: collector                  # collector|drafter|qualifier|router|reconciler
mode: digital-employee           # assistant (рядом с человеком) | digital-employee (по коннекторам сам)
purpose: >
  Снимает входящие заявки из WhatsApp/телефонии, нормализует в лид,
  заводит case_id, кладёт в Event Log. Человек продолжает работать как привык.
input:  ["whatsapp:incoming", "voip:call_ended"]   # триггеры/источники события
output: ["lead.created", "eventlog.append"]         # что порождает
data_source: ["whatsapp_api", "voip_cdr"]           # откуда читает (read)
data_sink:   ["state_store.leads", "event_log"]     # куда пишет (write)
schedule: "event-driven"          # event-driven | cron:"*/15 * * * *" | manual
runbook: "registry/runbooks/RB-collector-wa.md"     # AOP/SOP, по которому работает
autonomy: L1                      # L0 предлагает · L1 действует+уведомляет · L2 авто в зелёной зоне · L3 полностью авто
guardrails:                       # жёсткие запреты + лимиты
  - "не пишет клиенту от лица компании без gate"
  - "не трогает записи со status=closed"
  - "stop при >50 лидов/час (защита от шторма/дублей)"
gate: human-in-the-loop           # none | human-in-the-loop | dual-control
owner: "Оля (диспетчер)"          # role_slot-владелец, чинит при сбое
role_slot: "Приём заявок"         # роль из Role Card, НЕ конкретный человек
connectors: ["whatsapp-business", "binotel-voip"]
status: active                    # draft | active | paused | retired
health:                           # против silent failures
  heartbeat: "каждые 15 мин"
  alert_if: "0 событий за 2ч в рабочее время"
  last_ok: "2026-06-15T09:40:00+03:00"

Как пользоваться: один файл на агента в registry/agents/; узкий агент = один type + один purpose; перед запуском заполни guardrails/gate/health — без них агент в реестр не принимается.

A.2 · AOP — Agent Operating Procedure (C4: регламент как исполнимый контракт)#

# aop · v1 · исполнимый контракт, НЕ PDF · registry/aops/<name>.yaml
name: "qualify-lead"
sop_ref: "docs/sop/lead-qualification.md"   # человекочитаемый первоисточник
trigger:
  on: "lead.created"
  filter: "source in [whatsapp, voip, site_form]"
steps:                              # детерминированные шаги; LLM только там, где помечено
  - id: s1
    do: "обогатить лид (адрес, тип техники, район)"
    tool: geo-normalizer
  - id: s2
    do: "классифицировать срочность/маржинальность"
    tool: llm-classifier            # ВЫВОД фиксируется, расчёт скоринга — вне LLM
  - id: s3
    do: "посчитать lead_score по metrics.yml"
    tool: metrics-engine            # детерминизм: формула вне модели
  - id: s4
    do: "роутить мастеру по району или в очередь"
    tool: router
tools: [geo-normalizer, llm-classifier, metrics-engine, router]
preconditions:                      # проверяются ДО запуска, иначе abort
  - "case_id присутствует и уникален"
  - "lead.phone валиден (E.164)"
postconditions:                     # проверяются ПОСЛЕ, иначе откат+алерт
  - "lead.status in [qualified, rejected]"
  - "ровно одна запись в event_log с activity=lead_qualified"
autonomy: L2                        # авто в зелёной зоне риска
risk_class: green                   # green (обратимо/дёшево) | amber | red (деньги/клиент/право)
gate:
  amber: human-in-the-loop          # эскалация при amber
  red: dual-control                 # два подтверждения при red
drift_checks:                       # drift-detector вместо «PDF в шкафу»
  - "доля rejected растёт >2σ к недельной базе → алерт владельцу"
  - "среднее время s1→s4 > 5 мин → деградация, проверить коннектор"
  - "schema(lead) != data_contract:lead → стоп, контракт нарушен"
version: "1.3.0"                    # semver; меняешь шаги — бампаешь minor

Как пользоваться: один AOP на процесс из C2; sop_ref — словесный регламент, сам AOP — то, что исполняет агент/движок; risk_class + gate дают автономию-по-риску, drift_checks ловят расхождение план/факт без ручного аудита.

A.3 · Event Log — единый след (D: SSOT)#

-- event_log · append-only · ядро SSOT · сшивка всех контуров по case_id
CREATE TABLE event_log (
  case_id    TEXT        NOT NULL,   -- сквозной ID сущности (лид/заказ/клиент)
  activity   TEXT        NOT NULL,   -- ЧТО произошло (глагол прош. вр., из словаря активностей)
  timestamp  TIMESTAMPTZ NOT NULL,   -- когда (UTC+смещение), для process mining
  actor      TEXT        NOT NULL,   -- КТО: человек / agent:<id> / system
  payload    JSONB                   -- контекст события (суммы, статусы, ссылки)
);
CREATE INDEX ix_eventlog_case ON event_log (case_id, timestamp);
-- append-only: UPDATE/DELETE запрещены гайдрейлом; исправление = новое событие

case_id   | activity         | timestamp                 | actor              | payload
----------+------------------+---------------------------+--------------------+--------------------------------------------
RS-2026-0421 | lead_created   | 2026-06-15T09:12:03+03:00 | agent:AG-007       | {"source":"whatsapp","tech":"стиралка"}
RS-2026-0421 | lead_qualified | 2026-06-15T09:13:48+03:00 | agent:AG-011       | {"score":78,"urgency":"high","district":"центр"}
RS-2026-0421 | visit_scheduled| 2026-06-15T10:05:20+03:00 | Денис (мастер)     | {"slot":"2026-06-16T11:00","price_est":1200}

Как пользоваться: это и есть SSOT — каждый агент и человек дописывают строку (никогда не правят старую); три колонки case_id+activity+timestamp — минимум для process mining (план vs факт), payload свободный, но типы полей фиксирует Data Contract (A.7).

A.4 · CONSTITUTION.md — законы-инварианты с runtime-проверкой (Governance)#

# CONSTITUTION · РемСервис · v1
> Инварианты, проверяемые ИСПОЛНЕНИЕМ (runtime-enforcement), а не комитетом.
> Нарушение = блокировка действия + алерт, не «обсудим на планёрке».

## L1. Единый case_id
Любое событие/запись несёт валидный case_id из единого реестра.
runtime: write в event_log/state_store без case_id → reject.

## L2. Append-only история
Event Log не редактируется и не удаляется; исправление = компенсирующее событие.
runtime: UPDATE/DELETE на event_log → запрет на уровне прав БД.

## L3. Автономия по риску
Действие класса red не выполняется без dual-control; amber — human-in-the-loop.
runtime: agent с autonomy>risk_gate → действие уходит в очередь подтверждения.

## L4. Расчёт вне LLM (детерминизм)
KPI и деньги считаются metrics-engine по metrics.yml, не языковой моделью.
runtime: число в отчёте без ссылки на metric_id → флаг «недоверенный расчёт».

## L5. Данные ≠ знания
Агенты пишут в State Store (он живой), знания — в Context Layer; RAG не источник истины.
runtime: запись факта о состоянии бизнеса только через state_store API.

## L6. Контракт данных обязателен
Каждый поток данных проходит валидацию по своему Data Contract.
runtime: schema-mismatch → стоп потока + алерт владельцу контракта.

## L7. Каждый агент имеет владельца и health-check
Нет owner или heartbeat → агент не активируется; молчание дольше порога → авто-pause.
runtime: registry-валидатор отклоняет карточку без owner/health.

## Поправки
Закон меняется PR в этот файл + обновление соответствующей runtime-проверки. Узлы федерации суверенны, но L1–L2 (case_id, append-only) — общие для всех.

Как пользоваться: храни в корне governance/; каждый закон обязан иметь строку runtime: — если инвариант нельзя проверить исполнением, он не закон, а пожелание (в конституцию не идёт).

A.5 · Role Card — паспорт роли (C3: роль ≠ исполнитель)#

# role-card · v1 · roles/<slot>.yaml · роль отделена от человека и от агента
slot: "Приём заявок"               # имя роли (slot), НЕ ФИО
mission: "Ни одна входящая заявка не потеряна и заведена в систему за <5 мин"
execution_mode: human+ai           # human | human+ai | digital-employee
human: "Оля"                       # текущий исполнитель (сменяем без правки роли)
ai_support: ["AG-007"]             # агенты, усиливающие роль (фоновый сбор)
raci:                              # на ключевых активностях процесса
  lead_created:    {R: AG-007, A: Оля, C: -,        I: РОП}
  lead_qualified:  {R: AG-011, A: Оля, C: мастер,   I: РОП}
  visit_scheduled: {R: Оля,    A: Оля, C: мастер,   I: клиент}
channels: ["whatsapp", "телефон", "crm-очередь"]   # где роль принимает работу
value_stack:                       # исполнение → надзор → цели
  execution: "снять и завести заявку"
  oversight: "проверить очередь, разрулить спорные/дубли (выход агента)"
  goals: "конверсия заявка→визит ≥ 60%"
kpi: ["lead_to_visit_rate", "avg_lead_intake_time"]   # из metrics.yml
backup: "Таня"                     # кто подменяет

Как пользоваться: роль живёт дольше человека и агента — меняя human/ai_support, не трогаешь mission/raci; value_stack показывает, что по мере взросления человек уходит от исполнения к надзору за агентом и к целям.

A.6 · metrics.yml — governed-определение KPI (C5: один расчёт)#

# metrics.yml · semantic/metrics layer · ОДНО governed-определение на метрику
metrics:
  - name: lead_to_visit_rate
    title: "Конверсия заявка → визит"
    formula: "count(case where activity=visit_scheduled) / count(case where activity=lead_created)"
    source: ["event_log"]              # считается ИЗ SSOT, не из «экселя Оли»
    grain: "за период, по району"       # разрез
    target: ">= 0.60"
    owner: "РОП"                        # кто отвечает за определение и цель
    refresh: "hourly"
    blind_spots:                        # Минцберг-чек: что метрика НЕ видит
      - "не учитывает отменённые клиентом визиты (выглядит лучше реальности)"
      - "дубли лидов завышают знаменатель → конверсия занижается"

  - name: avg_lead_intake_time
    title: "Среднее время приёма заявки"
    formula: "avg(ts(lead_qualified) - ts(lead_created)) per case"
    source: ["event_log"]
    grain: "за день"
    target: "<= 5m"
    owner: "Оля (роль: Приём заявок)"
    refresh: "hourly"
    blind_spots:
      - "медиана честнее среднего при единичных ночных заявках"
      - "не показывает заявки, не дошедшие до lead_created (потеря ДО системы)"

Как пользоваться: дашборд и агенты берут число ТОЛЬКО отсюда (никаких параллельных формул в отчётах); formula ссылается на activity из Event Log; blind_spots обязателен — метрика без явных слепых зон вводит в заблуждение и в layer не принимается.

A.7 · Data Contract — контракт потока данных (D: data contracts)#

# data-contract · v1 · contracts/lead.yaml · договор между источником и потребителем
dataset: "lead"
owner: "Оля (роль: Приём заявок)"        # отвечает за качество и изменения схемы
producers: ["AG-007"]                    # кто пишет
consumers: ["AG-011", "metrics-engine", "dashboard"]  # кто читает
case_key: "case_id"                      # связь с Event Log / SSOT
fields:
  - {name: case_id,    type: string,   required: true,  desc: "сквозной ID, формат RS-YYYY-NNNN"}
  - {name: phone,      type: string,   required: true,  desc: "E.164, +380..."}
  - {name: source,     type: enum,     required: true,  values: [whatsapp, voip, site_form]}
  - {name: tech_type,  type: enum,     required: true,  values: [стиралка, холодильник, плита, духовка, другое]}
  - {name: district,   type: string,   required: false, desc: "район выезда"}
  - {name: created_at, type: timestamp,required: true,  desc: "UTC+смещение"}
  - {name: lead_score, type: integer,  required: false, desc: "0..100, ставит metrics-engine"}
freshness: "<= 2m от события до записи"   # SLA свежести
validation:                              # правила; провал → стоп потока + алерт owner
  - "phone matches ^\\+[1-9]\\d{7,14}$"
  - "source in enum"
  - "case_id уникален в пределах dataset"
  - "created_at не в будущем"
on_violation: "reject + alert owner + write activity=contract_violation в event_log"
version: "1.1.0"                          # ломающее изменение схемы → major + миграция

Как пользоваться: один контракт на каждый поток между агентами/системами; validation — это и есть runtime-страж закона L6 конституции; меняешь поля — бампаешь version и предупреждаешь всех consumers, иначе ломаешь их молча.

Связки шаблонов (для внедренца): case_id сшивает A.1–A.7 в один контур; Role Card (A.5) ссылается на Agent Card (A.1) и metrics.yml (A.6); AOP (A.2) исполняет процесс и валидирует по Data Contract (A.7), пишет в Event Log (A.3); CONSTITUTION (A.4) даёт runtime-инварианты, на которые опираются validation контракта и gate AOP; всё считается одним определением из metrics.yml (A.6). Заводи в порядке: Event Log → Data Contract → Agent Card → AOP → metrics.yml → Role Card → Constitution.

Приложение B · Сквозной кейс (end-to-end)#

Кому. Внедренцу. Что это. Один SMB проходит переход 3→4 по одному процессу — «приём заказа» — через все контуры C1→C5+A. Везде формат было (стадия 3) → стало (стадия 4) с реальными экземплярами артефактов. Цифры и имена — примеры, замените на свои.

Объект. Автосервис «Колесо», 14 человек, без ERP. Запись на ремонт идёт через: телефон, WhatsApp, Instagram-директ, форму на сайте, заход «с улицы». ~40 обращений/день, конверсия в заказ-наряд — на глаз, теряются заявки из директа в выходные.

Боль стадии 3 («зоопарк»). Инструменты есть, контура нет: телефон, WhatsApp-Business на телефоне приёмщика, Instagram у маркетолога, форма сайта валится на почту, заказ-наряды — в 1С-подобной программе ремонта, остальное — Google-таблица «Заявки», которую ведут «когда успеваем». Один и тот же клиент = 3 разные записи. Где теряются заявки — никто не знает, потому что нет единого следа.

B.0 · Карта перехода (одной таблицей)#

Контур	Было (3)	Стало (4)
C1 Карта	Процесс «в головах», клиент в 3 системах под 3 именами	Карта с узлом «Приём заказа», единый `case_id` сшивает каналы
C2 Процесс	Шаги непостоянны, handoff устный	Карточка процесса: триггер→7 шагов→результат, SIPOC, явные handoffs
C3 Люди	«Кто свободен, тот и принял»	Роль ≠ исполнитель: приёмщик-человек + 2 collector-агента + 1 цифровой сотрудник на квалификации
+A Агенты	Нет	3 агента: `intake-collector`, `lead-qualifier` (digital-employee), `followup-reconciler`; у каждого Agent Card
D Данные/SSOT	Google-таблица «когда успеем», 3 копии клиента	Event Log (`case_id+activity+timestamp+actor`) + State Store, который агенты обновляют
C4 Регламент	PDF «как принимать» в чате, никто не читал	AOP — исполнимый контракт + drift-detector
C5 Контроль	Собственник спрашивает «как там заявки?» голосом	Дашборд «что делать сегодня»: плитки-действия, план vs факт
Gov	—	Автономия-по-риску: агент сам пишет, но запись клиента на подъёмник — через gate (человек)

B.1 · C1 — Карта бизнеса (фрагмент)#

Было (3). Процесс существует только как навык приёмщика. Клиент Иван Петров заходит в WhatsApp как «+380...», в Instagram как @ivan_p, в программе ремонта как «Петров И.». Три карточки, ноль связи.

Стало (4). Фрагмент карты — ветка от продукта до инструмента, с единой идентичностью:

ПРОДУКТ: Ремонт и ТО легковых авто
  └─ ПРОЦЕСС: P-01 «Приём заказа»  [триггер обращения → заказ-наряд]
       ├─ ЛЮДИ (роли):  R-приёмщик · R-мастер-консультант · R-маркетолог
       ├─ УПРАВЛЕНИЕ:    владелец процесса = Сергей (старший приёмщик)
       └─ ИНСТРУМЕНТЫ:   телефон/АТС · WhatsApp Business API · Instagram · форма сайта
                         → всё нормализуется в SSOT под единым case_id

ИДЕНТИЧНОСТЬ (онтология):
  client_id  = c_00412  ──┬─ канал tel:  +380XXXXXXXXX
                          ├─ канал wa:   +380XXXXXXXXX
                          ├─ канал ig:   @ivan_p
                          └─ канал web:  ivan.petrov@…
  Любое обращение → разрешается в client_id → открывается case_id

Единый case_id. Формат KOL-2026-0617-031 (компания-дата-порядковый). Один обращ = один кейс; повторный контакт того же клиента по тому же авто в окне 14 дней цепляется к открытому кейсу, а не плодит новый.

B.2 · C2 — Карточка процесса P-01 «Приём заказа»#

Было (3). «Берёшь трубку — записываешь — говоришь, когда подъехать». Если приёмщик занят/в обеде — заявка из директа лежит до вечера или теряется. Handoff к мастеру — крикнуть через цех.

Стало (4). Карточка процесса (исполнимый экземпляр):

Поле	Значение
ID / имя	P-01 «Приём заказа»
Триггер	Входящее обращение в любом из 4 каналов
Результат (DoD)	Открыт заказ-наряд ИЛИ зафиксирован обоснованный отказ; клиент получил ответ ≤15 мин в рабочее время
Владелец	Сергей (R-приёмщик, старший)
SLA	Первый ответ ≤15 мин (раб. время) / ≤9:30 след. утра (нераб.)

Шаги (триггер → результат):

#	Шаг	Исполнитель	Тип
1	Захват обращения из канала, нормализация в `case_id`	`intake-collector`	агент (collector)
2	Разрешить `client_id` (новый/повторный), подтянуть историю авто	`intake-collector`	агент
3	Квалификация: что за авто, симптом, срочность, бюджетная вилка	`lead-qualifier`	цифровой сотрудник
4	Черновик ответа клиенту + предложенные слоты	`lead-qualifier`	цифровой сотрудник (drafter-режим)
5	Gate: проверить слот, цену, согласовать запись	Сергей	человек
6	Создать заказ-наряд в программе ремонта	Сергей	человек
7	Закрыть петлю: подтверждение клиенту, напоминание за день	`followup-reconciler`	агент (reconciler)

SIPOC:

S (поставщик)	I (вход)	P (процесс)	O (выход)	C (клиент)
Клиент, реклама, сарафан	Обращение + данные авто	P-01 шаги 1–7	Заказ-наряд + слот	Цех (мастер), сам клиент

Handoffs (явные, с условием):

lead-qualifier → Сергей на шаге 5, когда: собран минимум (авто+симптом+канал связи) ИЛИ автономия исчерпана (см. AOP).
Сергей → цех на шаге 6: заказ-наряд + симптом в State Store, мастеру падает уведомление.

B.3 · C3 — Люди: роль ≠ исполнитель#

Было (3). Роли нет, есть «кто свободен». Надзор отсутствует: никто не видит, сколько заявок не обработано.

Стало (4). Расщепление роли R-приёмщик по value-stack:

Слой value-stack	Кто делает	Режим
Исполнение (рутинный захват, нормализация, черновик)	`intake-collector` + `lead-qualifier`	агенты
Надзор (проверка слота/цены, решение «брать ли»)	Сергей, человек	human-in-the-loop
Цели (конверсия, загрузка цеха, why-метрики)	Владелец	человек

RACI на P-01:

Шаг	R	A	C	I
1–2 Захват/нормализация	`intake-collector`	Сергей	—	—
3–4 Квалификация/черновик	`lead-qualifier`	Сергей	мастер (по сложным)	—
5–6 Gate + заказ-наряд	Сергей	Сергей	—	мастер
7 Follow-up	`followup-reconciler`	Сергей	—	клиент

Каналы: клиент общается там, где написал (WA/IG/тел/web); внутри — единый State Store. Принцип адопшна: Сергей работает как привык (видит карточку, жмёт «подтвердить»), агенты собирают и черновят фоном.

B.4 · +A — Агенты: реестр и заполненная Agent Card#

Было (3). Агентов нет. Автоответчик Instagram «Спасибо, скоро ответим» — и тишина.

Стало (4). Реестр агентов P-01 (3 шт, узкие):

name	архетип	mode	назначение
`intake-collector`	collector	assistant	захват+нормализация обращений в `case_id`
`lead-qualifier`	qualifier	digital-employee	квалификация + черновик ответа со слотами
`followup-reconciler`	reconciler	digital-employee	сверка «ответили/записались/пришли», добивка

Заполненная Agent Card (стандарт, ключевой агент):

name:         lead-qualifier
type:         qualifier
mode:         digital-employee
purpose:      Квалифицировать входящее обращение (авто, симптом, срочность,
              бюджетная вилка) и подготовить черновик ответа клиенту с 2–3 слотами.
input:        case_id (из intake-collector), текст обращения, история авто из State Store
output:       qualification{vehicle, symptom, urgency, budget_band, missing_fields},
              draft_reply{text, proposed_slots[]}
data_source:  State Store (clients, vehicles, slots_free), Context Layer (прайс-вилки, FAQ)
data_sink:    Event Log (activity=qualified / drafted), State Store (case.qualification)
schedule:     event-driven (по новому обращению) + добор раз в 5 мин по очереди
runbook:      RB-P01-Q-v3  (как квалифицировать, что спрашивать, когда эскалировать)
autonomy:     L2 — пишет черновик и отправляет авто-ответ «приняли, уточняю слот»;
              финальную запись/цену НЕ подтверждает (gate человека)
guardrails:   не называет цену вне утверждённой вилки; не обещает слот, пока не gate;
              стоп-темы (ДТП/страховая/буксир) → немедленная эскалация Сергею
gate:         шаг 5 P-01 — подтверждение слота и цены человеком (Сергей)
owner:        Сергей (R-приёмщик)
role_slot:    R-приёмщик / слой «исполнение»
connectors:   WhatsApp Business API (rw), Instagram Graph (rw), сайт-форма webhook (r),
              State Store (rw), Event Log (w)
status:       active
health:       heartbeat 5 мин; alert если 0 обработок за 30 мин в раб. время
              ИЛИ доля эскалаций >60% (признак silent failure / дрейфа)

Автономия-по-риску. intake-collector = L3 (полностью авто: только пишет след, риск нулевой). lead-qualifier = L2 (авто-ответ + черновик, но цена/запись через gate). Запись на подъёмник деньгами клиента — всегда человек. Health-check против silent failure: если агент «молчит» в рабочее время — это инцидент, а не «тихо ок».

B.5 · D — Данные → SSOT (Event Log + State Store)#

Было (3). Google-таблица «Заявки», заполняется выборочно. Нет timestamp, нет actor, нет связи «обращение → заказ-наряд». Восстановить «где упала заявка» нельзя.

Стало (4). В SMB след порождают агенты с нуля — ERP нет, но Event Log есть.

Event Log — 3 реальные строки (один кейс):

case_id	activity	timestamp	actor
KOL-2026-0617-031	intake_captured (ig)	2026-06-17T08:02:11	agent:intake-collector
KOL-2026-0617-031	qualified+drafted (Octavia, стук подвески, срочно, 4–7k)	2026-06-17T08:04:39	agent:lead-qualifier
KOL-2026-0617-031	order_confirmed (слот 18.06 10:00, наряд #4471)	2026-06-17T09:11:50	human:Сергей

State Store (SQL, агенты ОБНОВЛЯЮТ, не read-only RAG):

case        (case_id PK, client_id, vehicle_id, status, channel, opened_at, owner)
client      (client_id PK, name, channels_json)        ← дедуп идентичности из C1
vehicle     (vehicle_id PK, client_id, make, model, plate, history)
slot        (slot_id PK, datetime, bay, status)        ← qualifier читает free, человек ставит booked

Data contract для intake-collector: на выходе обязательны case_id, client_id, channel, raw_text, ts; иначе запись отклоняется (drift в источнике ловится сразу).
Данные ≠ знания: прайс-вилки и FAQ живут в Context Layer (для qualifier), а факты кейса — в State Store. Не смешиваются.

B.6 · C4 — Регламент → AOP (исполнимый контракт)#

Было (3). PDF «Регламент приёма звонка» переслан в рабочий чат полгода назад. Drift никем не отслеживается; по факту каждый принимает по-своему.

Стало (4). AOP P-01 (фрагмент исполнимого контракта):

aop_id: AOP-P01-intake  ·  version: 3  ·  process: P-01  ·  owner: Сергей
goal:   На каждое обращение — ответ ≤15 мин (раб.) / ≤9:30 утра (нераб.);
        квалификация и слот предложены до участия человека.

contract:
  triggers:  [ new_message@(wa|ig|web|tel) ]
  steps_ref: P-01 (1→7)
  roles:
    intake-collector:  { does: [capture, normalize], autonomy: L3 }
    lead-qualifier:    { does: [qualify, draft, auto-ack], autonomy: L2, gate: human@step5 }
    Сергей(human):     { does: [verify_slot, verify_price, create_order] }
  data_contracts:  [ intake.out.required = (case_id,client_id,channel,raw_text,ts) ]
  guardrails:      [ price∈approved_band, no_slot_promise_before_gate,
                     escalate_if(topic∈{ДТП,страховая,буксир}) ]

completeness_checklist:   # «чек-лист полноты» — без этого AOP не активируется
  [x] триггер однозначен
  [x] каждый шаг имеет исполнителя и тип
  [x] каждый handoff с условием
  [x] gate расставлены по риску
  [x] data_source / data_sink заданы
  [x] метрика результата измерима (ответ ≤15 мин, конверсия)
  [x] drift-detector привязан

drift_detector:
  - SLA_breach:   first_reply > 15min (раб.)            → flag + плитка дашборда
  - silent_fail:  agent.health=stale 30min              → инцидент
  - band_drift:   цена названа вне approved_band         → блок + ревью owner
  - bypass:       order_created без qualified в Event Log → расхождение, ревью

AOP — не PDF, а контракт, который читает delivery-слой и сверяет факт. Принцип «research writes, delivery reads»: квалификатор/черновики пишутся, исполнение (запись, наряд) читает и сверяет с AOP.

B.7 · C5 — Контроль + Дашборд «Что делать сегодня»#

Было (3). Контроль = собственник спрашивает голосом «как там с заявками?». Отчёт постфактум, не действие.

Стало (4). Дашборд = actionable, не отчётность. Process mining сверяет план (AOP/P-01) vs факт (Event Log).

Плитка дашборда «Что делать сегодня» (реальный экземпляр):

┌─ ЧТО ДЕЛАТЬ СЕГОДНЯ · 17.06 09:15 ─────────────────────────────┐
│ 🔴 3 заявки ждут вашего gate >12 мин   → [Открыть очередь]      │
│    • KOL-…-031 Octavia, стук, срочно — черновик готов, слот 10:00│
│ 🟡 2 слота завтра пусты (бокс №2)       → [Раздать в follow-up]  │
│ 🟢 Конверсия обращение→наряд: 61% (нед.) ▲ план 55%             │
│ ⚠️ lead-qualifier: эскалаций 18% (норма <60%) — здоров          │
│ ❗ 1 заявка ig субботы без ответа 14ч    → process-mining: SLA-брешь│
└────────────────────────────────────────────────────────────────┘

Каждая плитка → действие (кнопка/очередь), а не цифра «для отчёта».
Semantic / metrics layer: «конверсия обращение→наряд» = один governed-расчёт (count(order_confirmed)/count(intake_captured) за окно), считается вне LLM, детерминированно — одно число для собственника и для дашборда.
Process mining ловит ❗: обращение в Event Log без последующего qualified/order = разрыв план-vs-факт, всплывает как действие, а не теряется.

B.8 · Governance — что осталось у человека#

Конституция узла автосервиса: цена клиенту и запись ресурса (подъёмник, время мастера) — всегда через gate человека, независимо от уверенности агента.
Runtime-enforcement, не комитет: правило «no_slot_promise_before_gate» живёт в guardrails агента и в AOP drift-detector — нарушение блокируется в моменте, а не обсуждается на планёрке.
Stewardship 3→4: владелец процесса (Сергей) отвечает за версии AOP и Agent Card; изменение прайс-вилки = новая версия Context Layer + bump версии AOP.
Слепые зоны (чек-лист Минцберга): проверить, что автоматизация приёма не убила «живой» канал для пожилых клиентов (телефон остаётся человеческим по умолчанию на стоп-темах).

B.9 · Итог перехода 3→4 (что реально изменилось)#

Было (3)	Стало (4)
Заявка из IG в выходные теряется	Авто-ack ≤1 мин, запись в Event Log, утром — в очереди gate
Клиент в 3 системах под 3 именами	1 `client_id`, каналы сшиты
«Где упала заявка?» — не ответить	Process mining показывает разрыв как действие
Конверсия «на глаз»	Governed-метрика 61%, одна для всех
Регламент-PDF, который не читают	AOP-контракт + drift-detector в runtime
Контроль голосом постфактум	Плитка «что делать сегодня» с кнопками

Минимальный порядок внедрения (для повторения): C1 идентичность+case_id → D Event Log+State Store (фундамент следа) → C2 карточка процесса → +A три узких агента с Card → C4 AOP+drift → C5 плитка дашборда → Gov gate-правила. Не наоборот: агенты без SSOT и case_id = ещё один зверь в зоопарке.

Приложение C · Диагностика зрелости (само-оценка)#

Лестница зрелости: уровень 3 «зоопарк» → уровень 4 «контур».

Зачем этот инструмент. За одну встречу с собственником (60–90 мин) определить, где организация находится по каждому контуру системы управления, найти узкое место (самый слабый контур — он тормозит весь поток) и зафиксировать разрыв до стадии 4 (Контур → AI-native), которая является целевой. Инструмент — не аудит ради оценки, а способ выбрать первый контур для внедрения: тянем не самый интересный, а самый слабый.

Как пользоваться (10 шагов на встрече): 1. Объясняешь шкалу 1–5 (см. ниже) — 2 минуты. 2. По каждому из 8 контуров задаёшь 3–4 вопроса. Просишь собственника назвать уровень по фактам, а не по намерениям («как есть сегодня», не «как должно быть»). 3. Внедренец фиксирует уровень в таблицу + одну цитату-доказательство (иначе балл «нарисован»). 4. Считаешь профиль (медиана по контуру), строишь разрыв до 4. 5. Узкое место = контур с минимальным баллом → это кандидат №1 в дорожную карту.

Шкала зрелости (общая, едина для всех контуров)#

Ур.	Имя	Суть одной фразой	Маркер «как узнать»
1	Осознание	«Знаем, что надо, но не делаем»	В голове у собственника, нигде не записано
2	Ad hoc	Делается, но каждый раз заново, руками, без стандарта	Один человек знает «как», уйдёт — встанет
3	Зоопарк	Есть инструменты/документы, но разрозненные, не связаны, дублируют	Excel + чаты + CRM + голова, нет единой точки
4	Контур	Единый связанный процесс/данные, обновляется, есть владелец	Можно показать одну систему, где всё сходится
5	AI-native	Контур + агенты собирают/готовят фоном, человек надзирает	Агент работает, человек проверяет, не наоборот

Правило фактологии: уровень засчитывается, только если собственник может показать артефакт (файл, экран, регламент) или назвать конкретного человека/процесс. «Планируем», «в целом есть», «у нас же все понимают» = уровень не выше 2.

C1 · Карта бизнеса (онтология, идентичность, единый case_id)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
C1.1	Есть ли единая карта «продукт → процессы → люди → управление → инструменты»?	Только в голове собственника	Рисовали раз на салфетке	Куски в разных доках	Одна актуальная карта, поддерживается	Карта живая, агент сверяет с реальностью
C1.2	Есть ли единый идентификатор сделки/заказа (case_id), сквозной от заявки до оплаты?	Нет, каждый отдел зовёт по-своему	Номер есть, но не везде	Номер в CRM, но в чатах/доках теряется	Сквозной id во всех системах	id ведёт агент, связывает события сам
C1.3	Совпадает ли «как мы себя описываем» с тем, как реально работаем?	Не задумывались	Описание устарело	Частично, есть расхождения	Описание = реальность, ревизуется	Расхождения ловит дрифт-детектор
C1.4	Знает ли новый сотрудник за день, «что у нас откуда берётся»?	Нет, учится месяцами	По устной передаче	Читает разрозненное	Есть карта-онбординг	Карта + агент-навигатор

C2 · Процессы (триггер → шаги → результат; handoffs; SIPOC)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
C2.1	Описаны ли ключевые процессы как «триггер → шаги → результат»?	Нет, «и так понятно»	1–2 на бумаге	Есть схемы, но не у всех и устарели	Ключевые процессы описаны, актуальны	Процесс исполняется в системе, агент ведёт шаги
C2.2	Видны ли передачи (handoffs) между людьми/отделами — кто кому что и когда?	Теряются, «у нас всё на согласовании»	Знают «по памяти»	Часть в чатах	Handoffs зафиксированы, видна точка передачи	Агент-router распределяет и логирует передачу
C2.3	Знаете ли вы, где процессы застревают (узкие места, простои)?	Узнаём по жалобам клиента	По ощущениям собственника	Считаем вручную изредка	Есть метрика времени по этапам	Process mining: план vs факт автоматом
C2.4	Для входа/выхода процесса определены поставщик и клиент (SIPOC)?	Нет	Для одного процесса	Частично	Да, для ключевых	Контракты входа/выхода проверяются автоматически

C3 · Люди (роль ≠ исполнитель; RACI; value-stack)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
C3.1	Разделены ли роль и человек (роль может выполнять человек / человек+AI / цифровой сотрудник)?	Роль = конкретный человек, иначе никак	Думали об этом	Кое-где замены прописаны	Роли описаны отдельно от людей	Часть ролей закрыта цифровым сотрудником
C3.2	Есть ли RACI (кто делает / отвечает / согласует / информируется) по ключевым задачам?	Нет, «разберёмся»	В голове собственника	Частично, спорят о зонах	RACI зафиксирован	RACI исполняется системой, эскалации авто
C3.3	Различаете ли вы исполнение → надзор → цели (value-stack) — кто что делает на каком уровне?	Собственник делает всё	Делегировано хаотично	Делегировано, но контроль ручной	Уровни разведены, надзор формализован	Исполнение у агентов, человек — надзор и цели
C3.4	Знаете ли вы, по каким каналам идёт работа роли (где живут задачи и переписка)?	Везде и нигде	Личные чаты	Несколько каналов, дублируют	Каналы закреплены за ролями	Агент собирает из каналов в единый след

+A · Агенты (поверх людей; «человек работает — агент собирает фоном»)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
A.1	Используются ли AI-агенты в работе (не разовый ChatGPT, а в процессе)?	Нет / только пробовали	Сотрудники сами юзают ChatGPT кустарно	Несколько ботов, не связаны с процессом	Агенты встроены в процессы под задачу	Парк узких агентов под архетипы (collector/drafter/qualifier/router/reconciler)
A.2	Есть ли на каждого агента карточка-стандарт и реестр (name, purpose, input/output, owner, guardrails, gate)?	Нет понятия	Знаем, что есть «какой-то бот»	Список в заметке	Карточка + реестр ведутся	Реестр живой, статус и health у каждого
A.3	Заданы ли guardrails, human-in-the-loop и автономия-по-риску (где агент сам, где нужен человек)?	Нет, либо боимся, либо «пусть сам всё»	На усмотрение сотрудника	Где-то проверяем, где-то нет	Правила по риску прописаны, есть gate	Автономия дозирована по риску, эскалация авто
A.4	Есть ли health-checks против тихих сбоев (агент молча перестал работать — узнаете)?	Узнаем, когда клиент пожаловался	Случайно замечаем	Проверяем вручную	Мониторинг статуса агентов	Авто health-check + алерт при silent failure

C4 · Регламенты → AOP (исполнимый контракт, не PDF)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
C4.1	В каком виде живут регламенты ключевых процессов?	В голове	Устные договорённости	PDF/док, который никто не открывает	Регламент-чек-лист, по нему реально работают	AOP = исполнимый контракт, система ведёт по шагам
C4.2	Ловите ли вы отклонение от регламента (drift) — когда стали делать не по правилу?	Не ловим	Узнаём при разборе косяка	Замечаем выборочно при проверке	Сверяем периодически	Drift-detector ловит расхождение автоматом
C4.3	Полны ли регламенты (вход, шаги, исключения, результат, ответственный)?	Нет	Только «нормальный сценарий»	Без исключений и владельца	По чек-листу полноты	Полнота проверяется при изменении
C4.4	Разведены ли «где пишут правила» и «где их читают/исполняют» (research writes, delivery reads)?	Всё в одной куче	Правят все подряд	Путаница версий	Источник правил один, исполнение читает	Изменение правила авто-доезжает до исполнения

D · Данные → SSOT (Event Log, State Store, data contracts)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
D.1	Есть ли единый журнал событий (case_id + действие + время + кто), а не данные по чатам и головам?	Нет, «всё в переписке»	Частично в CRM	В нескольких системах, не сходится	Единый event log по ключевому потоку	Агенты сами пишут след в журнал
D.2	Есть ли актуальное состояние сделки/объекта в одном месте (State Store), которое обновляется?	Спрашиваем у людей	В Excel, отстаёт	В CRM, но дублируется руками	Одно актуальное состояние, обновляется	Состояние обновляют агенты (не read-only RAG)
D.3	Различаете ли вы данные и знания (факты потока ≠ инструкции/контекст)?	Не различаем	Смешано в одном	Частично разделено	Данные и знания разведены, есть контекст-слой	Контекст-слой кормит агентов, данные отдельно
D.4	Есть ли контракты данных (формат входа/выхода между системами/людьми фиксирован)?	Нет, кто как пришлёт	По устной норме	Часто ломается формат	Data contracts на ключевых стыках	Нарушение контракта ловится автоматом

Поправка для SMB без ERP: если систем-источников нет вовсе — это не «ниже 1», а нормальная стартовая позиция. Цель здесь: агенты порождают след с нуля (D.1–D.2 строятся самим внедрением агентов). Балл ставим по тому, есть ли вообще единая точка правды, а не по наличию ERP.

C5 · Контроль + Дашборд (actionable «что делать сегодня», не отчётность)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
C5.1	Есть ли у собственника картина «что делать сегодня / где горит», а не отчёт за прошлый месяц?	Управляю по наитию	Отчёты постфактум, вручную	Несколько разных отчётов	Один actionable-дашборд: где затык сейчас	Дашборд + агент предлагает действие
C5.2	Сверяете ли план vs факт по процессам (process mining)?	Нет	На глаз	Считаем руками изредка	Есть сравнение плана и факта по этапам	Process mining в реальном времени
C5.3	Один ли у вас governed-расчёт метрики (все считают «выручку/конверсию» одинаково)?	У каждого своя цифра	Спорим о цифрах	Несколько версий метрик	Единый semantic/metrics layer	Метрики считаются детерминированно, вне LLM
C5.4	Дашборд ведёт к действию (от цифры к «кому позвонить / что починить»)?	Нет дашборда	Цифры без действий	Смотрим, но не действуем	Цифра → задача → ответственный	Действие предлагается и эскалируется авто

Governance (конституция; runtime-enforcement; stewardship 3→4)#

#	Вопрос	Ур.1	Ур.2	Ур.3	Ур.4	Ур.5
G.1	Есть ли «конституция» — свод базовых правил, как тут всё устроено и решается?	Нет, «по ситуации»	В голове собственника	Разрозненные правила	Зафиксированный свод правил	Правила применяются в runtime, не на словах
G.2	Правила соблюдаются в моменте работы (runtime) или «через комитеты и совещания»?	Никак	Ручной контроль собственником	Совещания, согласования	Часть правил вшита в процесс	Enforcement на уровне системы, не людей
G.3	Есть ли владелец-стюард у каждого контура (кто отвечает за развитие 3→4)?	Всё на собственнике	Назначаем стихийно	Размытая ответственность	У контуров есть владельцы	Стюард + агенты ведут контур к 5
G.4	Проверяли ли вы слепые зоны (Минцберг: не управляем ли мы вслепую какой-то частью)?	Не задумывались	Узнаём по факту проблемы	Разовый аудит был	Регулярная сверка слепых зон	Слепые зоны подсвечиваются системой

Шаблон-таблица для заполнения (на встрече)#

Заполнять по фактам. В колонку «Доказательство» — конкретный артефакт/имя/экран. Без доказательства балл ≤ 2.

Контур	Q.1	Q.2	Q.3	Q.4	Балл (медиана)	Доказательство / что показали	Разрыв до 4
C1 Карта бизнеса
C2 Процессы
C3 Люди
+A Агенты
C4 Регламенты→AOP
D Данные→SSOT
C5 Контроль+Дашборд
G Governance

Итог: средний уровень зрелости = ___ · узкое место (минимум) = ___ · целевой контур №1 для внедрения = ___

Правила скоринга#

Балл контура = медиана его 3–4 вопросов (не среднее — медиана устойчивее к одному выпадающему ответу). При чётном числе ответов берём меньшее из двух средних (консервативно: зрелость не завышаем).
Доказательство обязательно. Нет артефакта/имени/экрана → балл по этому вопросу не выше 2, что бы собственник ни говорил.
«Планируем / собираемся» = текущий уровень, а не будущий. Оцениваем «как есть сегодня».
Разрыв до 4 по контуру = max(0, 4 − балл). Это «сколько ступеней тянуть» до целевой стадии Контур.
+A и D связаны с D как фундамент. Если D ≤ 2, то баллы +A и C5 ограничиваются сверху значением D + 1 (агенты и дашборды не бывают зрелее данных, на которых стоят). Это не штраф, а защита от иллюзии: красивый бот на хаосе данных = уровень данных.
Стадия организации = минимум по контурам, не среднее. Система не сильнее слабого звена в потоке.

Как интерпретировать профиль#

Узкое место = контур с самым низким баллом. Это не «куда хочется», а что тормозит весь поток — начинаем внедрение отсюда. Если минимумов несколько с равным баллом — приоритет по порядку фундамента: D → C1 → C2 → C4 → C3 → +A → C5 → G (данные и карта держат всё остальное; агенты и дашборд — надстройка).

Типовые профили и что делать:

Что видим в профиле	Диагноз	Первый ход
+A высокий (3–4), D низкий (1–2)	«Боты на болоте» — агенты есть, данных под ними нет. Самый частый провал (95% MIT / 80% RAND — пилоты не дают эффекта именно отсюда).	Заморозить наращивание агентов. Строить D: event log + state store по одному потоку.
Всё 2, ровно	Зоопарк по всем фронтам. Не размазывать.	Выбрать один поток (где больше денег/боли) и поднять его C1→C2→D до 4, остальное не трогать.
C3/Governance низкие, процессы выше	Процессы есть, но всё держится на собственнике (роль=человек, нет RACI/стюардов).	Развести роль и человека, назначить стюардов контуров — иначе масштаб упрётся в собственника.
C5 высокий, C2/D низкие	Красивый дашборд на негодных данных — «приборка не подключена к двигателю».	Не верить цифрам. Сначала event log (D) и метрику плана/факта (C2), потом дашборд.
Всё ≥ 4, кроме одного контура	Почти готовая система с одной дырой.	Точечно закрыть дыру до 4 — и только потом думать про скачок к 5 (AI-native).

Главный вывод для собственника (формулировка на встрече):

«Ваша система работает на уровне самого слабого контура — это [X], балл [N]. Разрыв до рабочего состояния (стадии 4) — [4−N] ступени. Любые инвестиции в [сильный контур] не дадут отдачи, пока [X] на [N]. Первый шаг — поднять [X], не трогая остальное. Целевой скачок 3→4 (единый связанный контур), потом — 4→5 (агенты собирают фоном, вы надзираете).»

Что не делать (типовые ошибки внедренца на этой встрече):

Не оценивать «по намерениям» — только по тому, что показали.
Не тянуть самый интересный/модный контур (обычно +A) — тянуть самый слабый.
Не гнаться за 5 там, где нет 4: AI-native без Контура = зоопарк с ботами.
Не размазывать ресурс по всем контурам сразу — один поток до 4, затем следующий.

Приложение D · Матрица приоритизации#

Зачем это приложение. У внедренца на старте — список из 20–40 процессов и соблазн начать с того, что «болит у собственника прямо сейчас» или «технически красиво». Оба критерия ведут в 95% провалов пилотов (MIT) — потому что игнорируют риск необратимости и реальный объём. Это приложение даёт детерминированный decision-tool: посчитал три числа — получил порядок очереди. Расчёт вне LLM (принцип «детерминизм»), скоринг повторяемый, спор с собственником закрывается цифрой, а не вкусом.

D.1 · Правило в одной строке#

Первым агентизируй то, что делается ЧАСТО, ошибку легко ОТКАТИТЬ, и оно реально БОЛИТ. Необратимое и денежное — в конец очереди и только под human-in-the-loop.

Формально: ранжируем процессы по PRIORITY, где высокая частота и высокая боль тянут вверх, а низкая обратимость (высокий риск) тянет вниз.

D.2 · Три оси скоринга#

Каждый процесс оценивается по трём осям, шкала 1–5 (целые числа, никаких «3,5» — это убивает повторяемость).

Ось 1 — ОБЪЁМ / ЧАСТОТА (`V`) — «сколько раз в неделю это происходит»#

Сколько повторяющейся ручной работы агент снимет. Чем чаще — тем выше отдача от автоматизации.

Балл	Частота
1	реже раза в месяц
2	пару раз в месяц
3	несколько раз в неделю
4	ежедневно, единицы раз
5	ежедневно, десятки+ раз / непрерывный поток

Ось 2 — ОБРАТИМОСТЬ (`R`) — «легко ли откатить ошибку агента»#

Это инверсия риска. Высокий балл = ошибку видно и откатить дёшево (черновик, внутренняя заметка). Низкий балл = ошибка уходит наружу/в деньги/в юридику и стоит дорого.

Балл	Обратимость / цена ошибки
5	полностью обратимо: артефакт внутренний, до отправки человеку (черновик, тег, саммари)
4	обратимо с лёгкой правкой; наружу не уходит без гейта
3	частично: затронут внешний контакт, но без денег и обязательств
2	трудно откатить: уходит клиенту/в публичный канал, репутационный след
1	необратимо: платёж, договор, юр-обязательство, удаление данных, отгрузка

Ось 3 — БОЛЬ (`P`) — «как сильно это жрёт людей и тормозит бизнес сейчас»#

Узкое место, ручная рутина, источник просрочек/ошибок, то, что собственник называет первым.

Балл	Боль
1	мелкое неудобство, никто не жалуется
2	раздражает, но терпимо
3	регулярно отъедает время, заметно
4	узкое место: тормозит другие процессы, ошибки, просрочки
5	острая боль: теряем деньги/клиентов, собственник называет это первым

D.3 · Формула#

PRIORITY = (V × wᵥ) + (P × wₚ) + (R × wᵣ)

Веса по умолчанию (SMB без ERP, цель — быстрая победа с низким риском):

Ось	Вес	Почему такой
ОБЪЁМ `V`	wᵥ = 3	объём = главный множитель отдачи; «дробление=качество AI» работает на потоке
БОЛЬ `P`	wₚ = 2	боль обеспечивает адопшн и спонсора, но без объёма даёт разовый эффект
ОБРАТИМОСТЬ `R`	wᵣ = 2	риск — фильтр-предохранитель: тянет необратимое вниз, не глуша всё подряд

Диапазон: min 7 — max 35. Чем выше — тем раньше в очереди.

Подстройка весов под аппетит к риску. Консервативный собственник / зарегулированная ниша → wᵣ = 3 (риск важнее боли, необратимое падает ещё ниже). Агрессивный, «нужен эффект вчера» → wₚ = 3. Веса фиксируются ОДИН раз на весь портфель до начала скоринга — иначе теряется сопоставимость и появляется соблазн «подкрутить под любимый процесс».

D.4 · Жёсткие правила-предохранители (поверх балла)#

Считаются ДО рейтинга и переопределяют его:

R = 1 → НИКОГДА не первый кандидат, какой бы ни был PRIORITY. Платёж, отгрузка, подпись договора, удаление — только режим цифрового сотрудника под human-in-the-loop с гейтом (агент готовит → человек подтверждает). Сначала агентизируется подготовка (reversible-часть: собрать, проверить, заполнить черновик платёжки), а сам необратимый акт остаётся за гейтом.
Деньги наружу = гейт по умолчанию. Любой автономный перевод средств запрещён на уровнях зрелости 1–4.
V ≤ 2 при любом P → не цифровой сотрудник, а максимум AI-помощник. Строить коннекторы и расписание под процесс, который случается дважды в месяц, — перерасход; человек дёргает помощника руками.
Узкий агент. Если процесс набрал высокий балл за счёт того, что «большой и делает 5 вещей» — сначала режем его на под-процессы (по handoffs из C2) и скорим каждый отдельно. Скорим атомарные шаги, не «отделы».
Старт = пилот. Первый кандидат сначала идёт в режиме collector/drafter (фоновый сбор / черновик, R=5), даже если по карте он мог бы быть router. Автономия повышается health-check'ами, а не сразу.

D.5 · Пример: скоринг портфеля (6 процессов SMB)#

Веса: V×3 + P×2 + R×2.

#	Процесс	Архетип	V	P	R	PRIORITY	Очередь	Стартовый режим
1	Квалификация входящих лидов (тег, скоринг, маршрут)	qualifier/router	5	5	5	35	1	digital-employee, фон
2	Сбор статусов заказов из почты/чатов в Event Log	collector	5	4	5	33	2	digital-employee, фон
3	Черновики ответов клиентам по типовым вопросам	drafter	4	4	4	28	3	assistant + гейт
4	Сверка «оплачено vs отгружено» (reconciler)	reconciler	3	5	3	25	4	assistant, human reviews
5	Еженедельный дайджест по проектам собственнику	collector/drafter	2	4	5	24	5	assistant, фон
6	Проведение платежей поставщикам	—	4	3	1	20	последний	HITL-гейт: агент готовит платёжку, человек жмёт «оплатить»

Как читать таблицу:

№1 — образцовый первый кандидат: high-volume (5) + reversible (5) + high-pain (5) = 35. Снимает рутину каждый день, ошибка = неверный тег (откатывается мгновенно), и это первое, что назвал собственник.
№6 имеет неплохой PRIORITY=20, но R=1 сработал предохранителем (правило D.4.1) → выброшен в конец и переведён в HITL, несмотря на то что по голому баллу обгоняет №5. Агентизируем не «платёж», а подготовку платежа; кнопку жмёт человек.
№4 и №5 близки по баллу (25 vs 24), но решает разное: №4 берём раньше из-за боли (P=5, узкое место денежного контура), хотя у него средняя обратимость; №5 — приятный, безопасный, но редкий (V=2), поэтому ниже.

Порядок внедрения: строго сверху вниз по «Очереди», по одному. Следующий процесс берём только когда предыдущий прошёл health-check и не даёт silent failures.

D.6 · Критерий «1 мозг или 3» — сколько систем разворачивать#

Параллельно с очередью внедренец решает архитектурный вопрос: один общий контур на всё или несколько суверенных узлов. Режем по реальным швам бизнеса из карты C1, не по оргструктуре и не по вкусу.

Шов есть (→ отдельный узел), если между двумя зонами различается хотя бы ДВА из:

онтология / case_id — что считается «единицей работы»: заявка vs заказ vs пациент vs объект. Разный case_id = разный State Store = разный мозг.
данные и SSOT — разные источники, разные data contracts, нельзя честно слить в один Event Log.
клиент и P&L — другой рынок, другая выручка, другой собственник результата.
регламенты / AOP — несовместимые процессы и правила (разный «research writes, delivery reads»).

Ситуация	Швов между зонами	Решение	Почему
Общий бэк-офис (один поток заявок, одна касса, одни клиенты, один case_id)	нет / 0–1	1 мозг	один Event Log + один State Store; агенты переиспользуются; дробить = плодить интеграции на пустом месте
Разные бизнесы / юрлица / рынки под одним собственником (напр. 3 направления со своими клиентами и P&L)	2+ по каждой паре	3 мозга (по узлу на бизнес)	разные онтологии и SSOT нельзя слить честно; федерация суверенных узлов под общей конституцией
Один бизнес, но автономные функции (продажи / производство / финансы) с общим клиентом и case_id	0–1	1 мозг, несколько агентов-узкоспецов	шва нет — это handoffs внутри одного контура (C2), а не граница систем

Decision-rule (применять к каждой ПАРЕ зон):

Считаем различия по 4 критериям (онтология/case_id, SSOT, клиент+P&L, AOP).
  0–1 различие  → ОДИН мозг (общий контур, агенты переиспользуются, шов = handoff внутри C2)
  2+ различия   → РАЗНЫЕ мозги (суверенные узлы, федерация под одной конституцией)

Антипаттерн А — переслияние: один гигантский «корпоративный мозг» поверх трёх разных бизнесов. Получаешь конфликт онтологий, грязный Event Log, агента, который не знает, что такое case_id, — и тихие сбои. Антипаттерн Б — передробление: отдельный узел на каждый отдел внутри одного бизнеса. Получаешь интеграционный ад и дубли там, где хватило бы handoff. При сомнении — начинай с 1 мозга, дроби по факту боли (снизу-вверх), а не авансом.

D.7 · Чек-лист внедренца (пройти за один присест)#

[ ] Зафиксировал веса (V/P/R) ОДИН раз на весь портфель — под аппетит к риску собственника
[ ] Разрезал «отделы» на атомарные процессы по handoffs из C2 (узкие агенты)
[ ] Проставил V, P, R (1–5) каждому процессу — цифрами, не на глаз
[ ] Посчитал PRIORITY = V×3 + P×2 + R×2
[ ] Применил предохранители D.4: R=1 → конец очереди + HITL; деньги → гейт; V≤2 → только помощник
[ ] Отсортировал по очереди; первый кандидат стартует как collector/drafter (R=5), не сразу router
[ ] По карте C1 применил «1 мозг или 3»: посчитал швы по 4 критериям на каждую пару зон
[ ] Внедряю строго по одному; следующий — только после health-check предыдущего

Итог: три числа на процесс + правило швов на портфель = повторяемый, защищаемый перед собственником порядок очереди. Объём даёт отдачу, боль даёт спонсора и адопшн, обратимость держит риск — а необратимое и денежное никогда не оказывается первым.

Приложение E · Стартовый стек + экономика#

Экономика: проверка орг-гипотезы — дни, а не месяцы.

Аудитория — внедренец. Контекст — SMB без ERP. Задача приложения: дать конкретный стартовый стек по слоям контура (C1–C5 + A + D), назвать ценовые диапазоны, и перевести это на язык собственника — что каждый контур стоит и что экономит. Принцип фреймворка тот же: system-first, простота инструмента, методология до инструмента. Стек — это «как», а не «зачем»; сначала контур, потом тулза.

E.0 Принцип выбора стека (для внедренца)#

Три правила, которые не дают развалиться в «зоопарк» (зрелость 3):

Один слой — один инструмент-владелец. Не два State Store, не три места для регламентов. Дублирование источника правды = главная причина drift в SMB.
SSOT — это то, что агенты ОБНОВЛЯЮТ, а не read-only база. Если выбранный инструмент нельзя писать по API из оркестратора — он не SSOT, он витрина.
Покупаем «скучное», строим только «клей». Notion/Airtable/Telegram — готовые. Уникальная логика бизнеса живёт в L4-оркестрации и карточках агентов, не в самописном фронте.

Стартуем на managed-SaaS (быстро, дёшево тестировать). На self-host (Supabase/Postgres/n8n own) переезжаем только когда упёрлись в лимит или приватность данных — не раньше.

E.1 Стартовый стек по слоям#

Цены — порядок величины для SMB (1 владелец + 3–15 человек/агентов), USD/мес, на 2026. Это «вход», не «потолок».

Слой контура	Стартовый выбор	Зачем именно он	Альтернатива (когда переезжать)	Порядок цены $/мес
L1 · База знаний (C1 карта, C4 регламенты, онтология)	Notion	Регламенты как живой текст с версиями; человеку читать, AI — парсить через API; дёшево, ноль порога входа. «Research writes, delivery reads» ложится 1:1	Confluence/Obsidian-vault (если нужна жёсткая иерархия прав или offline)	$0–20/чел; типично $30–150
L2 · State Store / SSOT (D данные, единый case_id)	Airtable (старт) → Supabase/Postgres (рост)	Airtable: за день поднять Event Log (`case_id·activity·timestamp·actor`) + State Store, писать по API из n8n/агента. Supabase — когда нужен настоящий SQL, RLS, объёмы, граф-связи и реальные права	Postgres self-host (полный контроль, приватность, нет per-seat)	Airtable $20–100; Supabase $0–25→100+; Postgres-хостинг $10–50
L4 · Клей / оркестрация (C2 процессы, handoffs, расписания)	n8n (self-host) или Make (managed)	Тут живёт детерминизм: триггер→шаги→результат, ретраи, health-checks, расчёты ВНЕ LLM. n8n — дёшево на своём VPS, без лимита операций; Make — если не хотим админить	Собственные скрипты + cron (когда логика переросла визуальный билдер; версионирование в git)	n8n self-host $5–20 (VPS); Make/n8n-cloud $20–80
A · Агенты (collector/drafter/qualifier/router/reconciler)	Claude API + MCP-коннекторы	Качество на дроблении задач; MCP — стандартный способ дать агенту руки (читать L1, писать L2). Узкие агенты по карточке-стандарту, не «один на всё»	Локальные/дешёвые LLM для массовой рутинной классификации (router/qualifier)	API по токенам: пилот $20–100, рабочий контур $100–500+
Каналы (C3 каналы людей и агентов)	Telegram (ядро) + email (IMAP/Gmail API); WhatsApp по нужде клиента	Telegram Bot API — бесплатно, мгновенный канал «агент↔человек» и human-in-the-loop апрувы. Email — там, где живут клиенты. WhatsApp — только если так ходит клиентский поток	WhatsApp Cloud API / Twilio (платный, но обязательный в ряде ниш)	Telegram $0; email $0–10; WhatsApp BSP $30–100+
C5 · Дашборд / Контроль	Notion-дашборд (старт) → лёгкий BI: Metabase / Looker Studio	Старт: actionable-страница «что делать сегодня» прямо над Airtable/Notion. BI — когда нужен process-mining (план vs факт) и governed metrics layer (один расчёт метрики)	Grafana / Superset (на Postgres, для метрик в реальном времени)	Notion $0 (в L1); Metabase self-host $10–30; Looker Studio $0

Минимальный жизнеспособный контур (MVP-стек), типовой счёт собственника:

Что	$/мес
Notion (L1 + дашборд)	30–60
Airtable (SSOT)	20–50
n8n на VPS (оркестрация)	10–20
Claude API (агенты, рабочая нагрузка)	100–300
Telegram + email	0–10
ИТОГО управляемый AI-контур	≈ $160–440/мес

Порядок величины: полноценный AI-контур на отдел = цена одной подписки на CRM enterprise-уровня или ~10–15% оклада одного junior-сотрудника. Это и есть аргумент окупаемости ниже.

E.2 Экономика контуров: что стоит и что экономит#

Считаем на языке денег. «Эффект» — это либо высвобожденные человеко-часы (по ставке роли), либо предотвращённые потери (упущенный лид, просроченный платёж, ошибка). Цифры — типовые для SMB; внедренец подставляет ставки клиента.

Контур	Что СТОИТ ($/мес)	Что ДЕЛАЕТ агент	Что ЭКОНОМИТ / приносит	Окупаемость
C1 Карта + L1 знания	Notion 30–150 + разовая сборка карты	Держит онтологию, единый `case_id`, регламенты как живой контракт	Снимает «знание в голове владельца» как точку отказа; онбординг с недель до дней; убирает разнобой версий регламентов	Окупается на первой замене/болезни ключевого человека
D · SSOT + Event Log	Airtable 20–100 (или Postgres 10–50)	Каждый кейс оставляет след: кто·что·когда. Агенты пишут состояние, не теряют контекст	Видимость «где затык» в процессе → находишь узкое место, которое раньше стоило недель. База для всех остальных контуров	Базовый слой — окупается тем, что без него остальные не работают
C2 Процессы + L4 оркестрация (collector/router)	n8n 10–20 + Claude 50–150	Сбор данных, маршрутизация заявок, ретраи, передача handoff между ролями	15–40 ч/мес ручной маршрутизации и копипасты. При ставке $15–30/ч → $300–1200/мес высвобождено	2–5× от затрат на контур
A · Drafter (черновики ответов, КП, писем)	Claude 50–200	Готовит черновик, человек правит и отправляет (human-in-the-loop)	Скорость ответа клиенту ×3–5; 10–30 ч/мес на письмах/КП. Быстрый ответ = выше конверсия лида	Окупается на 1–2 спасённых сделках/мес
A · Qualifier (квалификация лидов)	Claude 30–150	Скорит входящие, отсекает мусор, фокусирует людей на горячих	Менеджер не тратит время на холодных; меньше упущенных горячих лидов	Один не упущенный лид часто = месяц затрат на весь стек
A · Reconciler (сверки: платежи, остатки, долги)	Claude 30–150 + n8n	Сверяет данные между системами, ловит расхождения и silent failures (health-checks)	Предотвращённые ошибки: незамеченный неплатёж, расхождение склада. Одна пойманная ошибка ≫ годовой стоимости агента	Асимметрия: дёшево стоит — дорого спасает
C5 · Контроль + дашборд	Notion $0 → Metabase 10–30	«Что делать сегодня», план vs факт, governed-метрики	Решения на данных, не на ощущениях; владелец перестаёт быть «ручным диспетчером» — высвобождает собственное время (самое дорогое)	Окупается высвобождением времени собственника

Как внедренец защищает бюджет перед собственником (формула):

Эффект (высвобожденные часы × ставка роли + предотвращённые потери) − Стоимость контура = чистая выгода/мес. Типовой первый рабочий контур (collector+drafter+router на одном отделе): стоит $160–440/мес, высвобождает $1000–3000/мес. ROI — кратный, окупаемость — недели, не годы.

Правило приоритизации внедрения: первым строим контур с худшей асимметрией «дёшево стоит / дорого болит» — обычно это Reconciler (сверки) или Qualifier (упущенные лиды), а не самый «модный» агент.

E.3 Главный экономический тезис: AI как дешёвый испытательный стенд для орг-гипотез#

Это аргумент уровня собственника, ради которого строится весь контур.

Раньше проверить организационную гипотезу — «а если выделить отдельную роль квалификатора лидов?», «а если сверять платежи каждый день, а не раз в неделю?», «а если ввести этот этап в процесс?» — стоило реального эксперимента на 3–4 месяца: нанять/переставить человека, переписать регламент, дождаться, пока процесс «прокрутится» достаточно раз, и только потом увидеть результат. Цена ошибки — квартал и зарплаты. Поэтому гипотезы либо не проверяли, либо проверяли по одной в год.

С AI-контуром гипотеза проверяется иначе и кардинально дешевле:

	Реальный орг-эксперимент	AI-гипотеза на контуре
Срок до результата	3–4 месяца	дни–недели
Стоимость попытки	найм + зарплаты + риск	часы внедренца + токены ($)
Цена ошибки	квартал и люди	откатил карточку агента
Сколько гипотез/год	1–3	десятки

Почему это работает именно на этом стеке:

Event Log (SSOT) уже копит фактический след процесса → у тебя есть данные «как есть», чтобы симулировать «как будет».
Узкий агент по карточке-стандарту = новую роль/правило можно «нанять» за час: завёл карточку (purpose·input·output·guardrails·gate), повесил на процесс, замерил. Не понравилось — status: off, откатил без увольнений.
Детерминизм в L4 даёт честный замер: метрика считается одинаково до/после (governed metrics layer), сравнение план/факт — это не «ощущение владельца».
Дробление и простота → каждую гипотезу тестируешь изолированно, не ломая остальной контур.

Вывод для собственника одной строкой:

AI-контур — это не «робот вместо людей». Это испытательный стенд организации: он превращает дорогой 4-месячный кадровый эксперимент в дешёвый цифровой прогон за недели. Стек за ~$200–400/мес окупается уже на высвобожденных часах и спасённых сделках — а сверх того даёт способность перебирать орг-гипотезы десятками в год там, где раньше хватало сил на одну. Это и есть переход зрелости 3→4: не «купили AI», а получили управляемую, измеримую, дешёвую в эксперименте организацию.

Приложение F · Адопшн-контур (люди/доверие)#

Зачем это приложение. Контуры C1–C5, +A, D и Governance отвечают на вопрос «что строить». Это приложение отвечает на вопрос «как сделать, чтобы этим пользовались». Пилот не падает от плохой модели — он падает, потому что носитель роли не открыл агента, не доверился его выводу или тихо вернулся к Excel. По BCG 70% успеха AI-трансформации — это люди и процессы, и только 30% — алгоритмы/данные/технология. Адопшн — не финальный этап («раскатили — теперь обучим»), а параллельная дорожка, идущая с первого дня рядом с инженерной.

F.1 Базовый тезис: организация — это сообщество, не машина#

Минцберг: организация — не схема из коробочек, а сообщество людей (community), которое держится на вовлечённости и взаимном доверии, а не на приказе. Из этого три следствия для внедренца:

Перемены устойчивее снизу, чем сверху. Спущенное «приказом» внедрение даёт формальное согласие и тихий саботаж (люди кивают, но продолжают «как привыкли»). Изменение, в котором носитель роли поучаствовал, он защищает как своё. → Внедренец не «раскатывает агента на отдел», а выращивает первого носителя-чемпиона и даёт ему стать примером для соседей.
Сопротивление — это сигнал, не помеха. «Не хочу пользоваться» почти всегда означает «не понял выгоды для СЕБЯ» / «боюсь, что меня заменят» / «мне добавили работы». Это диагностируемо и снимается — см. F.4.
Доверие к агенту строится так же, как к новому коллеге: сначала под надзором, на мелких задачах, с правом перепроверить, потом — с расширением автономии. Нельзя выдать цифровому сотруднику полную автономию в день один — это как дать новичку ключи от кассы в первый час.

F.2 Механика, снимающая сопротивление: «человек работает как привык — агент собирает фоном»#

Это не лозунг, а проектное требование к адопшну (зеркало принципа +A). Главная причина, по которой человек отвергает инструмент — инструмент меняет его рабочий день и добавляет шагов. Антидот:

Анти-паттерн внедрения	Адопшн-механика
«Теперь все заявки заводите в новой системе»	Человек продолжает писать в тот же чат/почту/CRM — агент-collector снимает след фоном, ничего нового открывать не надо
«Заполните 12 полей, чтобы агент сработал»	Агент достаёт поля из того, что человек и так пишет; ручной ввод — исключение, не норма
«Сначала переучимся, потом включим»	Включаем на реальном потоке в shadow-режиме (агент пишет, человек работает по-старому) — нагрузки ноль, доверие растёт на глазах
«Агент теперь решает»	Первые недели агент только предлагает черновик (drafter/qualifier), решение и подпись — за человеком

Ключевой ход: первая ценность приходит человеку раньше, чем первая нагрузка. Если носитель роли в первую неделю получил «агент за меня собрал сводку / напомнил / подготовил черновик» и при этом НЕ открыл ни одного нового окна — сопротивление снято до того, как возникло.

F.3 Бюджет, роль и стимулы адопшна#

Правило 20%+ (Deloitte). Закладывай минимум 20% усилий/времени/бюджета проекта на адопшн (коммуникация, обучение, сопровождение носителей, разбор сопротивления), а не на код. Если в плане пилота этой строки нет — пилот в зоне риска по умолчанию. Практически: на каждые 4 дня инженерной работы — 1 день работы с людьми.

Роль: Steward перехода (Transition Steward). Отдельная именованная роль (не «по совместительству у техлида»). Это связка между +A/D-слоем и людьми. Не обязательно отдельный человек на фулл-тайм в SMB — но обязательно названный ответственный. Его зона:

держит карту «кто из носителей где на кривой принятия» (см. F.5);
проводит еженедельный 15-мин разбор сопротивления (кто перестал пользоваться и почему);
ведёт ритуал «агент ошибся → что чиним» (см. F.6), чтобы ошибка агента не убивала доверие;
собирает истории успеха и разносит их (peer-proof работает сильнее приказа).

В терминах Governance это stewardship-уровень 3→4: переход управляется живой ролью с runtime-обратной связью, а не разовым тренингом.

Стимулы (что поощрять). Стимул должен бить в использование и улучшение агента, а не в факт «прошёл тренинг»:

✅ поощряем: носителя, который дал агенту обратную связь / нашёл ошибку / предложил правило — он становится со-автором, а не подопытным;
✅ поощряем чемпиона, чей участок первым вышел на стабильное использование — публично, как пример;
❌ НЕ привязываем стимул к «экономии ФОТ» и НЕ анонсируем сокращение как цель — это мгновенно превращает агента во врага и гарантирует саботаж;
❌ НЕ наказываем за откат к старому способу — откат это диагностический сигнал для Steward, а не проступок.

F.4 Вовлечение носителей в проектирование агента (co-design)#

Агента для роли проектируют вместе с носителем роли, а не для него. Носитель — единственный, кто знает реальные edge-кейсы, негласные правила и «как тут на самом деле». Это одновременно снимает сопротивление (соавторство = собственность) и резко повышает качество guardrails.

Практика co-design на старте агента (заполняет карточку +A руками носителя, не за него):

«Покажи, как ты делаешь это сейчас» — наблюдаем реальный поток, фиксируем input/output/data_source, не идеализируем.
«Где тут самое муторное / что бесит?» — первая автоматизация бьёт в боль носителя, а не в метрику собственника. Так первая ценность достаётся человеку.
«Когда агент НЕ должен решать сам?» — носитель сам называет красные линии → это становится guardrails и gate в карточке. Человек, нарисовавший границы, доверяет тому, что внутри них.
«Как поймём, что агент налажал?» — носитель определяет health-check своими словами → защита от silent failures глазами того, кто заметит первым.

Эффект: к моменту запуска носитель уже считает агента «своим инструментом, который я настроил», а не «штукой, которую мне навязали сверху».

F.5 Кривая принятия и как по ней вести#

Steward держит каждого носителя на одной из стадий и знает следующий шаг:

Стадия	Признак	Ход Steward'а
0. Тревога	«Меня заменят?»	Личный разговор: что освобождается, что остаётся за человеком (F.7). До снятия страха не обучаем
1. Любопытство	«Покажи, что оно может»	Демо на ЕГО задаче, не на абстрактной. Shadow-режим
2. Проба под надзором	пользуется, но всё перепроверяет	Это норма и хорошо. Не торопить с автономией. Фиксируем, где агент стабильно прав
3. Доверие на узком участке	перестал перепроверять рутину	Расширяем автономию агента по риску, точечно. Носитель сам предлагает «это можно отдать»
4. Со-автор	предлагает новые правила/агентов	Поощряем публично, делаем чемпионом, разносим его кейс соседям

Правило: автономию агента двигает не календарь проекта, а стадия носителя. Нельзя перепрыгнуть стадию 2 «потому что дедлайн».

F.6 Доверие после ошибки агента (ритуал)#

Агент ошибётся — это вопрос «когда», не «если». Один разбор «агент налажал → мы тихо это спрятали» убивает адопшн быстрее десяти удачных кейсов. Ритуал Steward'а:

Ошибка фиксируется открыто в Event Log (case_id), не заметается.
Разбор без поиска виноватого: это сбой системы/правила, не вина носителя, что «доверился».
Чиним guardrail/правило/health-check, а не «накажем агента». Носитель видит, что его сигнал → реальное улучшение.
Откатываем автономию на участке на стадию назад, пока правило не подтвердилось. Доверие возвращается дозами, а не объявлением.

F.7 Скрипты: что говорить команде#

Главное сообщение (одно, везде одинаково): «Агент — это помощник, который снимает с тебя муторное, а не замена тебе. Он берёт сбор данных, черновики и напоминания — ты остаёшься на решениях, отношениях с клиентом и сложных случаях. Цель — разгрузить, а не сократить.»

Что говорить (✅) / чего не говорить (❌):

✅ «Освобождает твоё время от рутины» / ❌ «Делает твою работу»
✅ «Ты остаёшься тем, кто решает и подписывает» / ❌ «Теперь система решает»
✅ «Ты его настраиваешь под себя, ты находишь, где он врёт» / ❌ «Просто пользуйся, как сделали»
✅ «Сначала он просто подсказывает, ты проверяешь» / ❌ «С завтра работаем только так»
✅ «Перестало помогать — скажи, починим» / ❌ «Почему не пользуешься?»

Ответы на 3 главных возражения:

«Меня заменят» → «Если бы цель была сократить — не вкладывались бы в то, чтобы ты стал сильнее. Агент снимает то, за что тебя никто не ценит (рутина), и оставляет то, за что ценит (суждение, клиент).»
«Мне добавили работы» → «Если ты открываешь что-то новое или заполняешь поля — это баг, скажи Steward'у. Правильно настроенный агент работает фоном поверх того, что ты и так делаешь.»
«Он ошибается, я ему не верю» → «И правильно, что проверяешь. Доверие — по частям: где он стабильно прав, отдаём ему; где врёт — ты ловишь, мы чиним. Ты не обязан верить ему больше, чем заслужил.»

F.8 Чек-лист готовности адопшна (gate перед раскаткой пилота)#

[ ] Назначен Steward перехода (named, не «по совместительству молча»).
[ ] В плане пилота ≥20% усилий — на людей/адопшн, отдельной строкой.
[ ] У каждого затронутого носителя роли проведён co-design (карточку агента заполняли его руками).
[ ] Есть чемпион — первый носитель, на ком обкатываем и кого делаем примером.
[ ] Старт в shadow-режиме: первая ценность человеку приходит раньше первой нагрузки.
[ ] Стимулы бьют в использование/улучшение, НЕ в экономию ФОТ; сокращение не заявлено целью.
[ ] Есть ритуал разбора ошибки агента (открыто, без виноватых, чиним правило).
[ ] Сообщение «помощник, не замена» проговорено лично каждому, страх замены снят до обучения.
[ ] Автономия агента привязана к стадии носителя (F.5), не к дедлайну проекта.

Анти-паттерн всего контура: запустить технически идеального агента «приказом сверху», без Steward'а, без co-design, с анонсом экономии ФОТ. Технология сработает, адопшн — нет, пилот попадёт в те самые 95% MIT / 80% RAND провалов. Адопшн-контур — это и есть то, что отделяет работающий пилот от «демо, которым никто не пользуется».

Приложение G · Чек-лист готовности (Definition of Done)#

Кому. Внедренцу. Один контур = один лист приёмки. Критерий формулируется как проверяемое «да/нет»: либо артефакт существует и проходит тест, либо контур не готов — частичной готовности нет. Контекст: SMB без ERP. Принцип сквозной проверки — system-first: контур готов не когда «настроен инструмент», а когда работает связка люди + процесс + данные.

Как пользоваться. Идёшь сверху вниз. Контур считается принятым только если отмечены ВСЕ строки блока (П — обязательные) и пройден gate-тест в конце блока. Строки (R) — рекомендованные, не блокируют приёмку, но фиксируются как долг. Легенда: [ ] не сделано · [~] в работе · [x] принято.

C1 · Карта бизнеса — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Карта помещается на 1 экран / 1 лист (продукт → процессы → люди → управление → инструменты) — без скролла и без второго листа.
`[ ]`	2	Незнакомый сотрудник читает и понимает карту за ≤15 мин без устных пояснений (проверено на живом человеке).
`[ ]`	3	Заведена онтология / словарь идентичности: ключевые сущности (клиент, заказ, лид…) названы один раз и однозначно, синонимы сведены.
`[ ]`	4	Определён единый `case_id` — сквозной идентификатор кейса/заказа, проходящий через все процессы.
`[ ]`	5	Каждый блок карты ссылается на владельца (кто отвечает) — нет «ничьих» зон.
`[ ]`	6 (R)	Указан уровень зрелости по каждому блоку (1–5), видна цель скачка 3→4.

Gate-тест C1: дай карту человеку «с улицы» → он за 15 мин называет продукт, 3 ключевых процесса и владельцев. Прошёл → [x].

C2 · Процессы — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Каждый ключевой процесс описан как триггер → шаги → результат (а не «отдел делает X»).
`[ ]`	2	Для каждого процесса есть SIPOC (Supplier–Input–Process–Output–Customer) — заполнены все 5 колонок.
`[ ]`	3	Все handoffs (передачи между ролями) явно помечены: кто → кому → что передаёт.
`[ ]`	4	На каждой передаче зафиксирован критерий «годен/не годен» — что считается корректным входом следующего шага.
`[ ]`	5	Процесс привязан к `case_id` из C1 — видно, как кейс движется по шагам.
`[ ]`	6 (R)	Помечены «узкие места» / точки накопления очереди для будущего process mining (C5).

Gate-тест C2: возьми реальный кейс → пройди его по карте процесса от триггера до результата без «а тут спросим у Васи». Прошёл → [x].

C3 · Люди — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Роль отделена от исполнителя: в карте — роли (role_slot), а не фамилии.
`[ ]`	2	Для каждой роли указан тип исполнения: `человек` / `человек + AI-помощник` / `цифровой сотрудник`.
`[ ]`	3	Построена RACI по ключевым процессам: на каждый шаг — ровно один A (Accountable).
`[ ]`	4	Зафиксированы каналы коммуникации/входа для каждой роли (где роль принимает работу).
`[ ]`	5	Прорисован value-stack: исполнение → надзор → цели (видно, кто исполняет, кто контролирует, чьи цели).
`[ ]`	6 (R)	Нет роли без владельца и без канала; «осиротевшие» задачи не висят между ролями.

Gate-тест C3: для любого шага процесса мгновенно отвечаешь «кто Accountable и каким типом исполнения закрыт». Прошёл → [x].

+A · Агенты (слой поверх людей) — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Заведён реестр агентов — единый список, ничего «теневого» вне реестра.
`[ ]`	2	У каждого агента заполнена карточка-стандарт (все поля): `name · type · mode(assistant\\|digital-employee) · purpose · input · output · data_source · data_sink · schedule · runbook · autonomy · guardrails · gate · owner · role_slot · connectors · status · health`.
`[ ]`	3	У каждого агента есть owner (человек-владелец) — нет агентов «ничьих».
`[ ]`	4	У каждого агента есть runbook (что делает, как перезапустить, что при сбое) и привязка к role_slot из C3.
`[ ]`	5	Прописан mode: `assistant` (помощник при человеке) ИЛИ `digital-employee` (с коннекторами) — без размытости.
`[ ]`	6	Каждый агент относится к одному из 5 архетипов (collector / drafter / qualifier / router / reconciler) и узок — одна задача, не «делает всё».
`[ ]`	7	Заданы guardrails и human-in-the-loop gate на действиях с последствиями.
`[ ]`	8	Автономия выставлена по риску: чем необратимее действие — тем ниже автономия.
`[ ]`	9	На необратимых действиях автономия = 0 (всегда человек на gate). Проверено перечнем необратимых операций.
`[ ]`	10	У каждого агента работает health-check против silent failures: видно «жив/мёртв», а не тишина.
`[ ]`	11	Соблюдён принцип адопшна: человек работает как привык — агент собирает фоном (агент не ломает существующий workflow).
`[ ]`	12 (R)	Для `digital-employee` коннекторы перечислены и протестированы на тестовом кейсе.

Gate-тест +A: выбери случайного агента из реестра → у него есть owner, runbook, health горит «жив», автономия соответствует риску, на необратимом — ноль. Любой «нет» → контур не готов.

C4 · Регламенты → AOP — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Регламент оформлен как исполнимый AOP-контракт (машиночитаемый/исполнимый), а не PDF для чтения.
`[ ]`	2	Пройден чек-лист полноты AOP: вход, шаги, выход, исключения, владелец — ничего не пропущено.
`[ ]`	3	Подключён drift-detector: расхождение «регламент vs реальное исполнение» детектится, а не копится молча.
`[ ]`	4	Соблюдён принцип «research writes, delivery reads»: контур, который пишет регламент, и контур, который его исполняет, разделены.
`[ ]`	5	AOP привязан к процессу из C2 и ролям из C3 (исполнимый контракт лежит на реальном процессе).
`[ ]`	6 (R)	При срабатывании drift есть назначенный owner-реакции (кто чинит расхождение).

Gate-тест C4: внеси заведомое отклонение в исполнение → drift-detector его поймал и указал владельца. Прошёл → [x].

D · Данные → SSOT — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Работает Event Log: каждая запись = `case_id + activity + timestamp + actor`. Все 4 поля заполняются.
`[ ]`	2	Event Log живой — события пишутся в реальном времени по факту работы, не задним числом и не вручную «для галочки».
`[ ]`	3	Есть State Store (SQL / граф), который агенты ОБНОВЛЯЮТ (write), — а не read-only RAG. Проверено: агент пишет состояние, оно меняется.
`[ ]`	4	Заведён Context Layer (слой контекста поверх State Store), к которому обращаются агенты.
`[ ]`	5	Определены data contracts на ключевые потоки: формат/поля/владелец каждого потока зафиксированы.
`[ ]`	6	Соблюдён принцип данные ≠ знания: сырые данные (Event Log/State) отделены от выводов/знаний.
`[ ]`	7	В SMB-режиме (нет ERP): подтверждено, что агенты порождают цифровой след с нуля — данные появляются от работы агентов, не из мифического ERP.
`[ ]`	8 (R)	`case_id` сквозной: один кейс прослеживается из Event Log в State Store и обратно в C1/C2.

Gate-тест D: запусти один кейс → событие появилось в Event Log (4 поля), State Store обновился агентом, контекст доступен. Если State Store read-only/RAG — контур не готов.

C5 · Контроль + Дашборд — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Дашборд actionable: отвечает на вопрос «что делать сегодня», а не «как было в прошлом месяце» (≠ отчётность).
`[ ]`	2	Работает process mining: план vs факт — реальный ход процессов (из Event Log) сверяется с целевым из C2.
`[ ]`	3	Есть semantic / metrics layer: каждая метрика считается один раз, governed (одно определение, один источник расчёта).
`[ ]`	4	Соблюдён детерминизм: расчёт метрик вне LLM (цифры считает движок, не модель).
`[ ]`	5	Дашборд питается из SSOT (D), а не из ручных выгрузок/Excel «на коленке».
`[ ]`	6 (R)	На каждом сигнале дашборда есть «следующее действие» и владелец действия.

Gate-тест C5: открой дашборд → за 1 минуту называешь 3 конкретных действия «на сегодня» с владельцами, и каждая цифра имеет единственное governed-определение. Прошёл → [x].

Governance — `[ ]` контур готов#

✓	#	Критерий приёмки (проверяемо)
`[ ]`	1	Есть конституция — письменный набор правил, выше любого отдельного узла/агента.
`[ ]`	2	Архитектура — федерация суверенных узлов: узлы автономны, но подчинены конституции.
`[ ]`	3	Правила enforced в runtime (исполняются машиной/системой), а не «комитетами» и совещаниями.
`[ ]`	4	Выстроен stewardship-уровень 3→4 (целевой скачок зрелости подтверждён, не остался на «зоопарке»).
`[ ]`	5	Автономия-по-риску действует на уровне governance, не только у отдельных агентов.
`[ ]`	6	Пройден чек-лист слепых зон по Минцбергу — конфигурации/координационные механизмы проверены, белых пятен в управлении нет.
`[ ]`	7 (R)	Конституция версионируется и у неё есть владелец-стюард.

Gate-тест Governance: введи правило в конституцию → оно срабатывает автоматически в runtime на реальном действии (а не «договорились на встрече»). Прошёл → [x].

Сводный лист приёмки фреймворка#

Контур	Готов?	Главный gate (одной строкой)
C1 Карта	`[ ]`	1 экран · читается за 15 мин · онтология + `case_id`
C2 Процессы	`[ ]`	триггер→шаги→результат · SIPOC · handoffs с критерием годности
C3 Люди	`[ ]`	роль≠исполнитель · RACI (1 A на шаг) · value-stack
+A Агенты	`[ ]`	owner + runbook + health у каждого · автономия-по-риску · 0 на необратимом
C4 AOP	`[ ]`	исполнимый контракт + drift-detector · «research writes, delivery reads»
D Данные	`[ ]`	Event Log живой · State Store обновляется агентом, не RAG
C5 Контроль	`[ ]`	actionable «что сегодня» · process mining план/факт · 1 governed-расчёт
Gov	`[ ]`	конституция · федерация узлов · runtime-enforcement (не комитеты)

Definition of Done фреймворка: все 8 строк сводного листа = [x]. Один [ ] → организация не AI-native, а на предыдущем уровне зрелости — точку разрыва ищи в незакрытом контуре.

Приложение H · Опросник подготовки#

Кому. Внедренцу. Заполняется ДО первой настройки — на интервью с собственником (1–2 часа на контур, лучше отдельными сессиями). Цель — вытащить из головы владельца сырьё для каждого контура C1→C5, чтобы не строить систему на догадках. Правило интервью: не объясняй теорию, спрашивай факты и примеры; на каждый ответ проси конкретный кейс из прошлой недели. Если собственник «не знает» — это находка, помечай как пробел и эскалируй.

Как читать таблицы. Вопрос → что спросить дословно. Наполняет → артефакт контура, который ответ заполняет. След. чек/шаг → что внедренец делает/проверяет сразу после ответа. SMB-контекст: ERP нет, агенты порождают след с нуля — поэтому часть ответов фиксирует не «как есть в системе», а «как реально в головах и переписке».

C1 · Карта бизнеса (онтология, идентичность, единый case_id)#

Вопрос (дословно)	Наполняет	След. чек/шаг
Что у вас считается клиентом и по какому ключу ловится дубль (телефон / email / ИНН / связка)?	Онтология сущности «клиент»	Зафиксировать `case_id`-ключ; проверить на 20 реальных записях, что дубли реально схлопываются
Перечислите 5–7 главных сущностей бизнеса (клиент, сделка, заказ, объект, платёж…) и кто из них «корень», вокруг которого крутится всё.	Список сущностей + корневая	Выбрать носитель `case_id` (обычно сделка/заказ); остальное — связи к нему
Один и тот же объект где называется разными словами (лид/заявка/обращение — это одно или разное)?	Глоссарий, разрешение синонимов	Свести синонимы в один термин; занести в `04-glossary`
Что вы продаёте — назовите продукты/услуги списком и как они группируются в линейки.	Уровень «продукт» карты	Сверить с реальными позициями в счетах/прайсе за месяц
Где физически живут данные о клиенте и сделке сейчас (CRM / Excel / WhatsApp / голова менеджера)?	Инвентаризация инструментов (C1→ввод в D)	Список источников → кандидаты в Event Log; пометить «голова/мессенджер» как риск
По какому признаку вы поймёте, что две записи — это один и тот же случай, а не два?	Правило идентичности case_id	Записать правило мёрджа; проверить граничный кейс (повторный клиент / возврат)

C2 · Процессы (триггер→шаги→результат, handoffs, SIPOC)#

Вопрос (дословно)	Наполняет	След. чек/шаг
Возьмём главный процесс (как заявка превращается в деньги): что его запускает (триггер) и чем он заканчивается (результат)?	Границы процесса (вход/выход SIPOC)	Зафиксировать триггер-событие и определение «готово»; это первые и последние `activity` в Event Log
Назовите шаги по порядку — от триггера до результата, своими словами, без идеала.	Цепочка activity	Пронумеровать шаги; каждый шаг = одна `activity` с actor
В каких точках дело переходит от одного человека к другому (handoff) и где чаще всего застревает?	Карта handoffs, узкие места	Пометить handoff-точки как кандидаты на `qualifier/router`-агента и на drift-метрику
Что на входе каждого шага должно быть готово, иначе шаг буксует (поставщик→вход)?	SIPOC supplier/input	Сформулировать входной чек-лист; станет gate в AOP (C4)
Где у процесса есть исключения и развилки («а если клиент…», «а если оплата частями…»)?	Ветки процесса	Отделить happy path от исключений; исключения — отдельные ветки, не замазывать
Как сейчас понимаете, что конкретная заявка зависла — и через сколько дней это «зависла»?	План vs факт (вход в process mining C5)	Задать SLA/норматив на шаг → порог для drift-detector

C3 · Люди (роль≠исполнитель, RACI, каналы, value-stack)#

Вопрос (дословно)	Наполняет	След. чек/шаг
По каждому шагу процесса: кто отвечает (R), кто утверждает (A), кого спрашивают/информируют?	RACI-матрица	Заполнить RACI по шагам C2; найти шаги без A (никто не отвечает) — флаг
Где описана роль, а где — конкретный человек? Что сломается, если этот человек уйдёт завтра?	Разделение роль/исполнитель	Вынести роль в `role_slot`; пометить «bus factor = 1» как риск
Какие шаги человек делает руками, но они тупые/повторяющиеся (копипаст, разнести, напомнить, свести)?	Кандидаты на AI (collector/drafter/reconciler)	Список → вход в реестр агентов; выбрать 1 пилот «человек работает — агент собирает фоном»
По каким каналам реально идёт работа по каждой роли (телефон, WhatsApp, почта, CRM)?	Карта каналов	Сверить с источниками данных C1/D; канал без следа = слепая зона
Что в работе роли — исполнение, что — надзор, а что — движение к целям (value-stack)?	Value-stack по роли	Проверить, не съедает ли исполнение весь день руководителя; цель агентов — снять исполнение
Где роль = человек, где человек+AI-помощник, а где можно цифрового сотрудника (полностью на коннекторах)?	Режим исполнителя (assistant / digital-employee)	Проставить `mode` в карточке агента; цифровому — назначить коннекторы и autonomy-по-риску

+A · Агенты (поверх людей: реестр, карточки, guardrails, health)#

Вопрос (дословно)	Наполняет	След. чек/шаг
Для выбранного шага: что агент берёт на входе, что отдаёт на выходе, и кому отдаёт?	Карточка: `input` / `output` / `data_sink`	Заполнить карточку-стандарт; выход должен быть машиночитаем (не «в чате сказал»)
Откуда агент читает данные и куда их пишет (read-only RAG или обновляет State Store)?	`data_source` / `data_sink`, режим записи	Подтвердить, что агент обновляет SSOT, а не только читает; иначе следа нет
Что агенту делать можно самому, а что — только с подтверждением человека (по риску ошибки)?	`autonomy` + `gate` (human-in-the-loop)	Привязать автономию к риску: дорого/необратимо → gate обязателен
Какие красные линии агент не пересекает никогда (не пишет клиенту сам, не двигает деньги, не удаляет)?	`guardrails`	Записать запреты явно; проверить, что технически невозможно их обойти
Как мы узнаем, что агент молча сломался (перестал собирать, выдал пусто) — и кто получит сигнал?	`health` / health-check против silent failure	Назначить health-метрику и владельца алерта; без неё агента не запускать
Кто владелец агента и в какой роли-слоте он стоит (кого дублирует/разгружает)?	`owner` / `role_slot` / реестр	Внести в реестр агентов; один агент = одна узкая задача (не «универсал»)

C4 · Регламенты → AOP (исполнимый контракт + drift-detector)#

Вопрос (дословно)	Наполняет	След. чек/шаг
Покажите действующий регламент по этому процессу — он есть, его читают, по нему работают?	Базовый AOP-контент	Если PDF в шкафу — переписать в исполнимый AOP; «research writes, delivery reads»
Что в процессе считается «сделано правильно» — измеримый критерий, а не «качественно»?	Definition of Done / acceptance	Превратить в проверяемое условие → вход drift-detector
Что должно произойти, если шаг пропущен или сделан не так — эскалация к кому и когда?	Правила исключений / эскалация AOP	Прописать ветку эскалации; назначить адресата
Какие пункты регламента по факту нарушаются чаще всего — где жизнь расходится с бумагой?	Точки drift	Эти точки — приоритет для drift-метрик; не доверять «по бумаге всё ок»
Чек-лист полноты: для этого процесса заданы триггер, шаги, роли, DoD, исключения, владелец? Чего нет?	Полнота AOP	Закрыть пробелы до запуска; неполный AOP агенту не отдавать
Кто владелец этого AOP и как часто он его пересматривает (drift накапливается)?	Стюардство AOP	Назначить владельца + ритм ревизии; иначе контракт протухнет

D · Данные → SSOT (Event Log, State Store, контракты)#

Спрашивается сквозь все контуры, но фиксируется здесь. В SMB без ERP след порождается с нуля — задача интервью понять, что станет источником событий.

Вопрос (дословно)	Наполняет	След. чек/шаг
По каждому шагу: остаётся ли след «кто-что-когда» (case_id + activity + timestamp + actor) — или только в голове?	Event Log	Где следа нет — назначить агента-collector, чтобы порождал событие
Где лежит текущее состояние дела (статус сделки) и кто его меняет — человек или система?	State Store	Завести State Store (SQL/таблица/граф), который агенты обновляют, не read-only
Когда вы говорите «статус: в работе / оплачено / закрыто» — где этот статус хранится и кто его источник истины?	Контекст-слой, источник истины статуса	Один источник на статус; запретить дубли статуса в разных местах
Какие данные приходят извне (банк, поставщик, площадка) и в каком формате?	Data contracts (вход)	Зафиксировать контракт на формат; кто нарушил формат — алерт
Что у вас «данные» (факты: суммы, даты), а что «знания» (как принимать решение)? Не путаются ли?	Разделение данные≠знания	Знания → в AOP/онтологию, данные → в SSOT; не складывать в одну кучу
Если завтра нужен отчёт «сколько сделок зависло >7 дней» — из чего его собрать прямо сейчас?	Готовность SSOT к метрикам	Если собрать неоткуда — это дыра в Event Log; закрыть до C5

C5 · Контроль + Дашборд (actionable «что делать сегодня», process mining, metrics layer)#

Вопрос (дословно)	Наполняет	След. чек/шаг
Что вы открываете утром первым, чтобы понять «всё ли ок» — и чего там не хватает?	Прообраз дашборда	Отделить «что делать сегодня» (actionable) от отчётности «что было»
Назовите 3–5 чисел, по которым реально управляете (а не «было бы интересно»).	Метрики дашборда	По каждой — один governed-расчёт (semantic layer), одна формула на всех
Для каждой метрики: какое значение — «надо вмешаться сегодня»?	Пороги / триггеры действий	Превратить порог в карточку действия «кому и что сделать»
Где сейчас план расходится с фактом в процессе — и видите ли вы это вовремя?	Process mining (план vs факт)	Сопоставить идеальную цепочку C2 с Event Log D; расхождение = алерт
Одно и то же число (выручка, конверсия) у разных людей считается одинаково? Бывают споры «у меня другая цифра»?	Semantic/metrics layer	Закрепить единый расчёт; убрать локальные версии формулы
Что из дашборда вы хотите получать сам (пуш в нужный момент), а не ходить смотреть?	Режим доставки + кандидаты-агенты	Назначить router/reconciler на пуш; дашборд приходит к собственнику, не наоборот

Governance · Сквозной чек (заполнить по итогам всех контуров)#

Вопрос (дословно)	Наполняет	След. чек/шаг
Кто владелец каждого узла (процесс / агент / AOP / метрика) — на каждый есть имя?	Stewardship 3→4	Карта владельцев; узел без владельца не запускать
Где правила должны исполняться в рантайме автоматически, а не «договорились на словах»?	Runtime-enforcement	Перевести ключевые guardrails/gates в технический контроль, не в комитет
Слепые зоны (Минцберг): где в бизнесе вообще нет ни следа, ни владельца, ни регламента?	Чек-лист слепых зон	Список белых пятен → бэклог следующего этапа
Текущая зрелость 1–5 по каждому контуру — где вы честно сейчас?	Оценка зрелости	Зафиксировать baseline; цель этапа — скачок 3→4, не сразу 5

Итог интервью (внедренцу): на выходе должно быть по каждому контуру — заполненный артефакт + список пробелов («не знает / нет следа / нет владельца»). Пробелы важнее ответов: именно они — карта работ на внедрение. Не запускай ни одного агента, пока для его шага нет case_id (C1), следа в Event Log (D) и владельца health-check (+A).

Файл, на который опирался: дайджест из задания (внешних файлов не читал). Приложение готово к вставке в основной документ фреймворка как «Приложение H».

Приложение I · Runbook / failure-playbook#

Назначение. Операционная инструкция для внедренца: что делать в момент, когда что-то сломалось. Каждый сценарий — по схеме Признак → Немедленные шаги (≤30 мин, остановить кровь) → Как чинить (root cause) → Как предотвратить (встроить в систему). Контекст — SMB без ERP: данные и след агенты порождают с нуля, источник правды — SSOT (Event Log + State Store), контракт работы — AOP, надзор — Дашборд «что делать сегодня».

Общий рефлекс на любой инцидент: (1) объяви severity (P1 деньги/клиент/необратимое · P2 сломан процесс · P3 деградация); (2) зафиксируй в Event Log событие incident_open с case_id; (3) если затронут агент — переведи его autonomy в suggest-only (предлагает, не делает) или status=paused, не удаляй; (4) назначь одного владельца инцидента (не комитет); (5) закрой событием incident_close + строка в журнал инцидентов.

Журнал инцидентов (завести один на организацию): date · case_id · сценарий(1–6) · severity · агент/узел · признак · действие · root cause · превентив · owner · статус.

Сценарий 1 — Агент тихо перестал собирать след (silent failure)#

Самый опасный класс: ничего не падает с ошибкой, агент просто не пишет в Event Log, и вы узнаёте об этом через недели по дырам в данных.

Признаки

В Event Log по case_id нет событий от данного actor-агента за период, где они должны быть (план vs факт по process mining расходится «в ноль»).
health-поле в карточке/реестре давно не обновлялось (нет heartbeat).
Дашборд «что делать сегодня» по этому контуру пуст или подозрительно «чисто».
Растёт ручная работа у человека, чьего агента-collector'а «не слышно».

Немедленные шаги (≤30 мин)

Проверь heartbeat: когда последний раз агент писал ЛЮБОЕ событие (включая run_ok)? Если давно — подтверждён silent failure.
Не доверяй пустоте: вручную дёрни один тестовый прогон (runbook-команда из карточки) на известном входе, посмотри, появляется ли событие в Event Log.
Оцени дыру: за какой период не собирался след, по каким case_id. Помечаем эти кейсы как trail_gap — данные за этот период считаем неполными, не строим на них решения.
Подними autonomy уведомлений: пока агент чинится, ответственный человек собирает след вручную (адопшн-принцип «человек работает как привык» — процесс не встаёт).

Как чинить (root cause)

Триаж по слоям: (a) коннектор отвалился → см. Сценарий 6; (b) изменился вход (формат письма/файла/поля) → агент молча не матчит и выходит «пусто» — почини парсер/контракт входа; (c) сменился schedule/планировщик не триггерит → проверь cron/триггер; (d) тихой ловлей исключения агент глотает ошибку → убери «проглатывание», ошибка обязана стать событием.
Бэкафилл: восстанови потерянный след, где возможно (из писем/CRM/файлов за период trail_gap), и допиши недостающие события в Event Log с пометкой backfilled=true.

Как предотвратить

Heartbeat обязателен. Каждый агент при каждом прогоне пишет событие даже когда «делать нечего» (run_ok, items=0). Отсутствие heartbeat = алерт, а не тишина.
Health-check как отдельный watcher-агент (reconciler-архетип): раз в N часов сверяет «когда каждый агент последний раз отчитывался» против его schedule и поднимает на Дашборд просроченные.
Dead-man's switch: ноль событий там, где план их ждёт > X часов → P2-алерт владельцу.
В карточке агента поле health делаем живым (last_run, last_ok, items_processed), а не декоративным.
Узкие агенты: чем уже агент, тем заметнее его молчание — не лепи «универсала», который частично работает и этим маскирует сбой.

Сценарий 2 — Данные поплыли: дубли / противоречия в SSOT#

Один case_id имеет два конфликтующих состояния; дубли сущностей; State Store разошёлся с реальностью.

Признаки

Один и тот же клиент/сделка/заявка существует под двумя case_id (дубли).
В State Store по одному case_id поля противоречат друг другу или последнему событию Event Log.
Метрики на Дашборде «не бьются» (сумма частей ≠ целому); два агента пишут в одно поле разное.
Жалоба от человека: «в системе не то, что на самом деле».

Немедленные шаги (≤30 мин)

Заморозь запись проблемной сущности: агенты-reconciler/router, пишущие в спорные case_id, → suggest-only. Чтение не трогаем.
Зафиксируй расхождение в contradictions/ (две версии + источник каждой), не перезаписывай тихо одну другой.
Определи «истину»: Event Log — первичен (это лог фактов), State Store — производная проекция. Если они разошлись — прав Event Log.
Останови «кровотечение дублей»: временно включи блокировку создания новой сущности без проверки на дубль (см. ниже dedup-ключ).

Как чинить (root cause)

Дубли: определи естественный ключ дедупа (email+телефон / ИНН / номер заказа). Слей дубли: выбери выживающий case_id, перенаправь события второго на него (merged_into), архивируй дубль. Запиши событие merge.
Противоречия: пересобери State Store из Event Log (replay событий по case_id в хронологии) — это вернёт согласованное состояние. Поле, которое пишут двое, — нарушение data contract: назначь одного владельца записи на поле (single-writer).
Найди источник дрейфа: ручной ввод в обход агента? два агента без разграничения? отсутствие idempotency (повторный прогон создаёт второй экземпляр)?

Как предотвратить

Event Log = append-only, immutable. State Store всегда выводим из него (можно пересобрать) — это и есть страховка от «поплывших» данных.
Data contracts: на каждое поле — один writer-агент (actor), формат, допустимые значения, источник. Поле без владельца записи запрещено.
Dedup-ключ на входе: перед create агент обязан искать существующую сущность по естественному ключу (upsert, не blind insert).
Idempotency: повторный прогон на том же входе не создаёт дубль (ключ идемпотентности на событие).
Reconciler-агент регулярно сверяет State Store ↔ Event Log ↔ внешние источники и поднимает расхождения в contradictions/, а не молча «решает».
Semantic/metrics layer: одна governed-формула на метрику — «сумма не бьётся» обычно значит два разных расчёта, а не битые данные.

Сценарий 3 — AOP нарушен / drift#

AOP — исполнимый контракт процесса (триггер→шаги→результат, handoffs, gate'ы), а не PDF. «Drift» — фактический процесс разошёлся с тем, что записано в AOP.

Признаки

Drift-detector / process mining показывает маршруты, которых нет в AOP (новые шаги, пропущенные шаги, обход gate'а).
Handoff'ы случаются не туда / не тому role_slot, чем предписано.
«Так уже все давно делают» — фактический регламент устно мутировал, AOP не обновлён.
Шаг, помеченный как gate (human-in-the-loop), фактически проскакивается.

Немедленные шаги (≤30 мин)

Классифицируй drift: (A) AOP отстал (реальность лучше, контракт устарел) или (B) процесс деградировал (реальность хуже/опасна, контракт прав). Это разные диагнозы.
Если (B) и затронут gate/деньги/клиент — немедленно верни обязательность gate'а: агенты на этом шаге → suggest-only, шаг проходит только через человека, пока не починим.
Локализуй: на каком шаге и в каком проценте кейсов расхождение (process mining: план vs факт).

Как чинить (root cause)

Случай (A): реальный процесс улучшился — обнови AOP под факт (новая версия контракта, changelog), переразведи handoffs/gate'ы, перепривяжи агентов. AOP — живой документ, обновление = норма.
Случай (B): процесс самовольно срезал углы — верни поведение к контракту: почини маршрутизацию router-агента, восстанови пропущенные шаги/гейты, разбери с исполнителями почему обходили (часто gate тормозит — тогда пересмотри его уместность, а не выключай).
Проверь чек-лист полноты AOP: у каждого шага есть вход/выход, owner (role_slot), gate где нужно, и след пишется в Event Log.

Как предотвратить

Drift-detector включён постоянно (continuous process mining план vs факт), а не разовый аудит. Drift — это сигнал на Дашборд, а не находка раз в квартал.
AOP исполним и версионируем: контракт хранится рядом с процессом, у него changelog; «research writes, delivery reads» — синтез/правила пишутся в одном месте, исполнение читает оттуда (нет двух расходящихся копий).
Runtime-enforcement, не комитеты: gate'ы зашиты в маршрут (router физически не пускает дальше без отметки человека), а не держатся на дисциплине.
Регулярный review дрейфующих шагов: повторяющийся drift в одну сторону = AOP пора обновлять (узаконить факт).

Сценарий 4 — Ушёл ключевой человек (риск ключевого лица / SPOF)#

В SMB критичные знания, доступы и «как тут всё работает» часто завязаны на одном человеке. Уход = провал процесса, потеря следа, осиротевшие агенты.

Признаки (в т.ч. до ухода — это управляемый риск)

Один role_slot держит несколько критичных процессов и не дублирован; нет преемника.
Агенты с owner = этот человек; коннекторы/OAuth заведены под его личный аккаунт.
Знания процесса — «в голове», AOP неполон, на него нет doc.
Доступы (ключи, токены, пароли) персональные, не сервисные.

Немедленные шаги (≤30 мин — режим «человек ушёл»)

Инвентаризируй зону: какие процессы (C2), role_slot'ы (C3), агенты (+A), коннекторы/доступы (C6/OAuth) висели на нём. Реестр агентов + карта бизнеса дают список за минуты.
Спаси доступы первыми: агенты с коннекторами под его аккаунтом отвалятся при отзыве учётки — переведи их на сервисные учётки или зафиксируй, что отзыв сломает интеграцию (синхронизируй с Сценарием 6, чтобы не получить каскад).
Переназначь owner всех его агентов и role_slot'ов на временного держателя; ничего не оставляй без владельца.
Подними AOP затронутых процессов: где не хватает шагов/знаний — пометь как knowledge_gap, временно усиль human-in-the-loop.

Как чинить (root cause)

Перевести персональные интеграции на сервисные/организационные учётки (не личные).
Достроить AOP осиротевших процессов до исполнимого состояния (чтобы преемник работал по контракту, а не по легенде).
Распределить нагрузку role_slot между людьми/агентами; где знание было «в голове» — оцифровать в Context Layer / AOP.

Как предотвратить

Bus-factor аудит (часть Governance / Минцберг-чек-лист слепых зон): для каждого критичного процесса — минимум двое, кто может его вести; для каждого агента — owner + заместитель.
Принцип «агент собирает след фоном» сам по себе снижает SPOF: знание процесса материализуется в Event Log + AOP, а не остаётся приватным у человека. Это ключевая страховка — система переживает уход людей, потому что след и контракт внешние.
Никаких личных учёток в интеграциях — только сервисные (см. Сценарий 6, превентив).
Федерация суверенных узлов: узел не должен быть «одним человеком» — у узла есть конституция и реестр, переживающие смену исполнителя.
Регулярно: «что сломается, если завтра не выйдет X?» — на Дашборд как управляемый риск, не как сюрприз.

Сценарий 5 — Агент сделал необратимое без gate#

Отправил письмо клиенту, провёл платёж, удалил данные, изменил запись у внешнего контрагента — действие, которое нельзя откатить, прошло без человеческой отметки. P1 по умолчанию.

Признаки

В Event Log — событие необратимого действия (sent/paid/deleted/pushed) от агента БЕЗ предшествующего gate_approved.
Жалоба извне: клиент/контрагент получил то, что не должен был.
Автономия агента оказалась выше риска действия (делал сам там, где требовался human-in-the-loop).

Немедленные шаги (≤30 мин)

Стоп-кран: агент → status=paused немедленно (не suggest-only — полная остановка), чтобы исключить повтор/серию.
Оцени масштаб: одно действие или серия? Сколько case_id затронуто? (запрос в Event Log по actor + типу события за окно).
Containment / митигация ущерба: что из необратимого можно частично смягчить — отзыв письма, стоп-платёж, уведомление контрагента, восстановление из бэкапа удалённого. Действуй по приоритету «деньги/клиент».
Уведоми владельца процесса и, если задет клиент/контрагент, подготовь коммуникацию.

Как чинить (root cause)

Найди дыру в gate: в карточке агента autonomy была выставлена выше риска ИЛИ gate для этого действия не был объявлен ИЛИ gate был, но не enforced (декларация без runtime-проверки).
Понизь autonomy агента до уровня действия: необратимые операции = всегда human-in-the-loop (suggest, человек подтверждает).
Зашей gate в маршрут так, чтобы действие физически не выполнялось без события gate_approved (runtime-enforcement).

Как предотвратить

Автономия-по-риску — главный принцип: обратимое и дешёвое → агент сам; необратимое/деньги/внешняя коммуникация → обязательный human gate. Уровень автономии в карточке выводится из риска действия, а не из удобства.
Gate как код, не как договорённость: агент не имеет технической возможности совершить необратимое действие без gate_approved в Event Log. Нет отметки — действие блокируется на уровне коннектора.
Guardrails: для каждого необратимого действия — отдельный guardrail (лимиты сумм, белые списки получателей, dry-run по умолчанию).
Узкие агенты + два режима: агент-drafter готовит, человек/другой шаг отправляет — разделение «готовит ≠ совершает». Цифровой сотрудник с коннекторами получает право на необратимое только под явный gate.
Регулярный аудит карточек: «у какого агента autonomy выше риска его действий?» — на Дашборд.

Сценарий 6 — OAuth / интеграция отвалилась#

Коннектор агента к внешнему сервису (почта, CRM, календарь, платёжка, мессенджер) перестал работать: протух токен, отозван доступ, сменился scope/API, упал rate-limit.

Признаки

Ошибки авторизации (401/403, invalid_grant, token expired) в логах коннектора; health агента = degraded.
Агент перестал собирать/писать через этот коннектор → часто проявляется как Сценарий 1 (silent failure), если коннектор глотает ошибку.
Источник data_source/data_sink агента недоступен; рассинхрон с внешним сервисом.
Массовый отвал нескольких агентов сразу = отозвана/просрочена общая учётка (часто следствие Сценария 4).

Немедленные шаги (≤30 мин)

Подтверди границу сбоя: один коннектор или несколько? Один агент или общая учётка? (если несколько разом — корень в учётке/доступе, не в агенте).
Затронутые агенты → suggest-only/paused, чтобы не копили ошибочные/пустые прогоны и не маскировали дыру.
Включи ручной режим на критичный процесс (человек собирает след вручную за период недоступности — trail_gap пометка), процесс не встаёт.
Переавторизуй, если тривиально (повторный OAuth-flow / обновить refresh-token / поднять лимит). Проверь тестовым прогоном, что событие снова пишется.

Как чинить (root cause)

Классифицируй: (a) истёк/отозван токен → переавторизация, ротация refresh-token; (b) сменился scope/permission → перевыдать доступ с нужным scope; (c) изменился внешний API/формат → обнови контракт коннектора и парсер (часто пересекается с Сценарием 2 — поплывшие данные); (d) rate-limit → бэкофф/троттлинг, разнести расписание; (e) учётка-человек отозвана → перевести на сервисную (Сценарий 4).
Бэкафилл пропущенного за окно недоступности (из внешнего сервиса за период) в Event Log с backfilled=true.

Как предотвратить

Только сервисные/организационные учётки для интеграций — не личные аккаунты сотрудников (это и анти-SPOF, Сценарий 4).
Мониторинг токенов: алерт за N дней до истечения; авто-ротация refresh-token где возможно. Коннектор обязан превращать ошибку авторизации в событие + алерт, а не глотать (анти-silent-failure).
Контракт коннектора в карточке: connectors фиксирует сервис, scope, тип учётки, владельца, срок; ревизия при смене API.
Health-check коннектора отдельно от логики агента: «живость доступа» проверяется пингом, не только при рабочем прогоне.
Graceful degradation: при отвале коннектора процесс падает на ручной режим с явной пометкой, а не делает вид, что работает (тихая пустота — худший исход).

Шпаргалка-матрица (для печати у внедренца)#

#	Сценарий	Мгновенный рефлекс	Главный превентив
1	Silent failure	Проверь heartbeat → тестовый прогон → пометь `trail_gap`	Обязательный heartbeat + health-check watcher + dead-man's switch
2	Дубли / противоречия SSOT	Заморозь запись → в `contradictions/` → replay из Event Log	Event Log append-only + data contracts (single-writer) + dedup-ключ + idempotency
3	AOP drift	Классифицируй A(контракт отстал)/B(процесс деградировал) → верни gate если B	Drift-detector постоянно + AOP исполним/версионируем + runtime-enforcement
4	Ушёл ключевой человек	Инвентаризуй зону → спаси доступы → переназначь owner	Bus-factor ≥2 + сервисные учётки + знание в Event Log/AOP, не «в голове»
5	Необратимое без gate	`status=paused` → масштаб → containment	Автономия-по-риску + gate как код + guardrails + «готовит ≠ совершает»
6	OAuth / интеграция	Граница сбоя → suggest-only → переавторизация → бэкафилл	Сервисные учётки + мониторинг истечения токенов + health-check коннектора

Сквозные правила всех шести сценариев: (1) при сбое агент паузится, не удаляется — карточка и история нужны для разбора; (2) потерянный след помечается trail_gap и по возможности бэкафиллится с backfilled=true — нельзя строить решения на дырявых данных; (3) каждый инцидент = строка в журнале инцидентов с root cause и превентивом; (4) превентив всегда встраивается в систему (heartbeat, contract, gate-as-code, drift-detector), а не в память человека — иначе он не переживёт Сценарий 4.

Приложение J · Метрики-дерево (примеры)#

Назначение. Готовые деревья метрик под 3 типа SMB. Каждая метрика — actionable: ведёт к конкретному решению собственника, не к «отчёту ради отчёта» (C5: actionable ≠ reporting). Все берутся из SSOT (D: Event Log case_id+activity+timestamp+actor → State Store), считаются в metrics layer одним governed-расчётом — никаких LLM в числах (принцип «детерминизм: расчёт вне LLM»). Где метрика связана с агентом — указан источник-агент; «силент-фейл» агента ловится health-check'ом, а не глазами собственника.

Как читать «тревогу». Тревога = триггер для решения, не для нервов. Сработала → собственник делает шаг из колонки, не «принимает к сведению».

Минцберговские «слепые зоны» 🔶 — там, где цифра выглядит здоровой, но прячет управленческий провал (метрика по-среднему маскирует хвост, ведущий показатель отсутствует, либо данные генерит сам исполнитель = конфликт интересов). В дашборде эти строки помечать значком и НЕ агрегировать вслепую.

Структура дерева (одинакова для всех типов): вершина = 1 метрика собственника (деньги/выживание) → 3–4 драйвера (что на неё влияет) → ведущие операционные метрики (на что можно повлиять сегодня). В дашборде: верх — крупно, драйверы — средне, операционка — мелко/по клику.

J.1 · Услуги / сервис (агентство, студия, консалтинг, ремонт-под-ключ услугами)#

Вершина дерева: Маржинальная прибыль за месяц ← объём оплаченных работ − себестоимость часов − простой. Драйверы: загрузка людей · скорость денежного цикла · удержание клиента · качество (переделки).

#	Метрика	Владелец	Источник (SSOT)	Норма / порог	🔔 Тревога → решение	Частота
1	Billable utilization (оплачиваемые часы / доступные часы)	Операционный директор	Event Log: `activity=time_logged`, actor=исполнитель → State Store	65–80%	<60% 2 нед → срезать найм / искать спрос; >90% → нанимать, риск выгорания	Неделя
2	Маржа по проекту (план vs факт часов)	Менеджер проекта	State Store: смета vs `time_logged`; process mining план/факт	факт ≤ 110% плана	факт >130% → стоп-ревью проекта, пересмотр сметы клиенту	По закрытии этапа
3 🔶	Средний срок оплаты счёта (DSO)	Финансы	Event Log: `invoice_sent` → `payment_received` (Δ дней)	≤ 14 дней	>30 дней → стоп новых работ клиенту до предоплаты	Неделя
4	Воронка: лид → счёт → оплата (конверсия по стадиям)	Собственник / РОП	Event Log стадий сделки; агент-qualifier как `data_source`	конверсия лид→сделка ≥ 20%	провал любой стадии −30% м/м → разбор стадии, не «всей воронки»	Неделя
5	Доля переделок / правок сверх контракта	Тимлид	Event Log: `activity=rework`, тег причины	≤ 8% часов	>15% → корневой разбор (бриф? компетенция? клиент?)	Неделя
6 🔶	NPS / повторные обращения (повтор + рекомендации)	Аккаунт	State Store: `repeat_order`, опрос (агент-collector)	повторных ≥ 35%	<20% → программа удержания, личные звонки топ-клиентам	Месяц
7	Pipeline coverage (сумма открытых сделок / план месяца)	Собственник	State Store: сумма сделок в стадиях	≥ 3× плана	<2× → включить лидген/реактивацию сейчас, не в конце месяца	Неделя
8	Концентрация выручки (доля топ-1 клиента)	Собственник	State Store: revenue by client	≤ 25%	>40% → диверсификация, риск потери ключевого	Месяц

🔶 Слепые зоны блока. (3) DSO «по среднему» скрывает 1–2 хронических неплательщиков — рядом всегда держать список счётов >30 дней, не только среднее. (6) NPS, собранный самим исполнителем у клиента, завышен (конфликт интересов) — источник опроса = независимый агент-collector, не аккаунт-менеджер. Ведущий индикатор оттока — снижение частоты заказов, а не сам уход; следить за пунктом 6 как за leading, не lagging.

J.2 · Стройка / монтаж / подряд (объекты, бригады, прорабы)#

Вершина дерева: Прибыль по объекту на момент сдачи ← смета − факт затрат − штрафы за срыв − гарантийные переделки. Драйверы: график (план/факт по этапам) · перерасход материалов · кассовый разрыв (авансы vs закупки) · качество приёмки.

#	Метрика	Владелец	Источник (SSOT)	Норма / порог	🔔 Тревога → решение	Частота
1 🔶	Отклонение графика по этапам (план/факт дни)	Прораб	Event Log: `stage_started/closed`, timestamp; process mining	≤ +5% к плану	>2 этапа подряд просрочены → перебросить бригаду / эскалация заказчику	2–3×/нед
2	Перерасход материалов (факт / смета по позиции)	Снабженец	Event Log: `material_issued`, накладные; State Store	≤ 105%	>115% по позиции → проверка воровства/брака/пересчёта сметы	Неделя
3	Маржа объекта в реальном времени (смета − затраты на дату)	Собственник	State Store: бюджет vs `cost_booked` (труд+материал)	≥ план − 5%	проседание к 0% при незакрытом объёме → стоп-совещание	Неделя
4 🔶	Кассовый разрыв по объекту (полученные авансы − оплаченные закупки/ЗП)	Финансы	Event Log: `payment_in` / `payment_out` по `case_id=объект`	≥ 0 (не уходить в минус)	<0 → стоп-закупки, требовать транш заказчика	Неделя
5	Выработка бригады (объём работ / человеко-смена)	Прораб	Event Log: `work_done` (м²/п.м.) ÷ табель смен	≥ норматив бригады	<80% норматива 2 нед → разбор: простой? материал? люди?	Неделя
6	Простой по причинам (часы: нет материала / нет фронта / погода / люди)	Прораб	Event Log: `idle` с тегом причины (агент-collector с объекта)	≤ 10% времени	>20% → устранить топ-причину простоя по Парето	Неделя
7	Дефекты на приёмке этапа (замечаний / этап)	Технадзор	Event Log: `defect_logged` на приёмке	≤ 3, критических 0	критический дефект → стоп-этап, переделка до подписания	По этапу
8 🔶	Дебиторка заказчиков (подписанные акты без оплаты)	Финансы	Event Log: `act_signed` → `payment_received`	≤ 21 день	>45 дней → юрист / приостановка работ	Неделя

🔶 Слепые зоны блока. (1) График «в среднем по объекту в графике» скрывает критический путь — смотреть отклонение этапа на критическом пути, не среднее по всем. (4) Кассовый разрыв — главный убийца подрядчика, но не виден в прибыли: объект может быть прибыльным «на бумаге» и одновременно банкротить кассу — это отдельная ось, держать рядом с маржой. (8) Данные о готовности и простоях часто заполняет сам прораб (конфликт интересов: он же за это отвечает) — сверять фото-фиксацией/агентом-collector с объекта, а не верить ручному отчёту.

J.3 · Торговля / e-commerce / опт-розница (товарка, склад, закупки)#

Вершина дерева: Валовая прибыль − стоимость замороженного капитала (зарабатываем на обороте, не на складе). Драйверы: оборачиваемость запаса · наличие ходовых SKU · маржинальность с учётом возвратов/скидок · стоимость привлечения.

#	Метрика	Владелец	Источник (SSOT)	Норма / порог	🔔 Тревога → решение	Частота
1 🔶	Оборачиваемость запасов (COGS / средний сток), дни	Закупки	State Store: остатки + `sale`/`purchase` из Event Log	≤ 45 дней (по категории)	>90 дней → распродажа неликвида, стоп-закуп категории	Неделя
2	Out-of-stock по ходовым SKU (% топ-SKU с нулём)	Категорийный менеджер	Event Log: `stock_level` vs ABC-список; агент-reconciler склада	≤ 3% по A-группе	любой A-SKU в нуле → срочный дозаказ, проверка точки заказа	Ежедневно
3	Gross margin после возвратов и скидок (чистая маржа сделки)	Собственник	Event Log: `sale − discount − return − cost`	≥ целевой % категории	падение >5 п.п. м/м → ревизия закупочных цен/промо	Неделя
4 🔶	Доля неликвида (сток без продаж >X дней / весь сток)	Закупки	State Store: SKU с last_sale > порога	≤ 10% капитала	>20% → списание/уценка, заморожен кэш	Месяц
5	Маржа за вычетом CAC (прибыль с заказа − стоимость привлечения)	Маркетинг	Event Log: `order_revenue` + расход на канал	положительная по каналу	канал в минусе 2 нед → отключить/пересобрать	Неделя
6	AOV и доля повторных покупок	Маркетинг	Event Log: `order` by customer	повторных ≥ 30%	повторных <15% → удержание (а не только разгон трафика)	Месяц
7	Точность остатков (учётный − фактический по инвентаризации)	Складом	Event Log: `inventory_count` vs State Store; агент-reconciler	расхождение ≤ 1%	>3% → разбор недостач/пересорта, ревизия процесса	По циклу инв.
8 🔶	Кассовый цикл (CCC) (дни запаса + дни дебиторки − дни кредиторки)	Финансы	Event Log закупок/продаж/оплат	минимизировать; ≤ 30 дней	рост >45 дней → пересмотр условий с поставщиками/клиентами	Месяц

🔶 Слепые зоны блока. (1) Общая оборачиваемость «нормальна» — но среднее по складу маскирует две кучи: ходовое летает, неликвид лежит мёртвым грузом. Считать оборачиваемость по категориям/ABC, не котлом (пункт 4 — обязательная пара к пункту 1). (4) Прибыльный P&L при растущем неликвиде = деньги «съел» склад; неликвид не виден в марже, но виден в кассе. (8) Точность остатков, заполняемая кладовщиком вручную, — конфликт интересов; источник = инвентаризация + агент-reconciler, сверяющий учёт с фактом, а не доверие к ручному вводу.

J.4 · Правила настройки дашборда (общие для всех типов)#

3 уровня на экране. Вершина (1 число, цвет) → драйверы (3–4) → операционка (по клику). Собственник видит «деньги/выживание» сразу; внедренец прокидывает drill-down к Event Log.
Источник = всегда SSOT. Каждая метрика тянется из одного governed-расчёта в metrics layer (semantic layer). Один термин = одна формула на весь дашборд — иначе «маржа» в двух виджетах разойдётся.
Тревога = действие, не цвет. К каждому порогу прикреплён владелец и шаг. Светофор без закреплённого решения = отчётность, не control.
🔶-метрики не агрегировать вслепую. Рядом со средним всегда держать хвост/список (счета >30 дней, A-SKU в нуле, этап на крит-пути). Среднее лжёт — Минцберг-чек-лист слепых зон.
Конфликт интересов в данных. Где цифру генерит тот, кого она оценивает (прораб → график, кладовщик → остатки, исполнитель → NPS) — источник переключить на независимого агента-collector/reconciler + сверку (фото, инвентаризация). В SMB без ERP агенты порождают этот след с нуля (D).
Health-check агентов-источников. Метрика, питаемая агентом, ломается тихо, если агент упал (silent failure). На дашборде у таких строк — индикатор agent.health и last_updated; устаревшие данные подсвечивать, не показывать как «ОК».
Частота = частоте решения. Ежедневные метрики (OOS, отклонение графика) — для оперативки; недельные — для штаба собственника; месячные — для стратегии. Не чаще, чем по ним реально принимают решение.

Файл приложения: /root/Clod Cod/university/ — конкретный путь укажет внедренец при сборке полного фреймворка (это приложение J к основному документу).

План работ (backlog)#

Приложения A–J — это v0 (скелеты). План доведения каждого до рабочего документа (+ новое приложение K · Безопасность/GDPR) — в отдельном roadmap: ai-org-framework-roadmap. Приоритет — A · B · C (ядро применимости).

AI-ориентированная организация

Люди + агенты как единая управляемая структура · глубокий разбор#

📖 Как читать этот документ#

🏷️ Название и позиция#

🧭 Схема контуров#

🪜 Лестница зрелости#

🗺️ C1 · Карта бизнеса (фундамент)#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (для SMB без ERP)#

Антипаттерны / грабли#

🔍 Было → стало (на примере)#

Связи#

⚙️ C2 · Процессы#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (для SMB без ERP)#

Антипаттерны / грабли#

🔍 Было → стало (на примере)#

Связи#

👥 C3 · Люди#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (SMB без ERP, с нуля)#

🔍 Было → стало (на примере)#

Связи#

🤖 +A · Агенты (поверх людей)#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (SMB без ERP, с нуля)#

Антипаттерны / грабли#

🔍 Было → стало (на примере)#

Связи (вход/выход)#

📋 C4 · Регламенты → AOP (исполнимый контракт)#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (SMB без ERP)#

Антипаттерны / грабли#

🔍 Было → стало (на примере)#

Связи#

🗄️ D · Данные → единый источник правды (SSOT, слой данных)#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (SMB без ERP)#

Антипаттерны / грабли#

🔍 Было → стало (на примере)#

Связи#

📊 C5 · Контроль + Дашборд собственнику#

Что это#

Сущности#

Механика (что происходит)#

Кто делает#

Зачем / что ломается без него#

По этапам зрелости#

Как внедряется (SMB без ERP)#

🔍 Было → стало (на примере)#

Ось 1 — ОБЪЁМ / ЧАСТОТА (`V`) — «сколько раз в неделю это происходит»#

Ось 2 — ОБРАТИМОСТЬ (`R`) — «легко ли откатить ошибку агента»#

Ось 3 — БОЛЬ (`P`) — «как сильно это жрёт людей и тормозит бизнес сейчас»#