Архитектура безлюдного движка RMR

Эта глава — то, ради чего собиралась книга. Десять традиций знания разобраны; теперь из пятидесяти их главных инсайтов собирается одна конструкция: безлюдный бизнес-движок для холдинга, который строится по стратегии «новое рядом, чистым» — управляющая компания и несколько бизнес-активов на AI-рельсах, обслуживаемых общим операционным ядром с минимумом людей. Глава написана как проектный документ: определение продукта, семь несущих архитектурных решений (каждое — со ссылками на главы-доноры), слоёная архитектура, контур качества, экономика, дорожная карта, анти-паттерны и конвейер проверки.

12.1. Определение продукта: что мы строим

Соберём определение из отличий, накопленных книгой.

Движок — это событийная система записи ERP-строгости (глава 4): каждый значимый факт хозяйственной жизни существует как типизированный документ в неизменяемом журнале, состояние всегда выводимо из журнала, исправление — только сторно. Но, в отличие от ERP, у движка нет экранов для клерков как основного интерфейса: слой вовлечения заменён API, событиями и агентами; человеческий интерфейс — это очередь исключений и приборная панель, а не форма ввода.

Движок мультиюрлицевый по построению (главы 3, 4): юрлицо — измерение схемы данных, как company code в SAP, а не отдельная инсталляция. Новый актив холдинга подключается конфигурацией, а не интеграционным проектом. Именно это делает движок шаблоном «актива на AI-рельсах»: то, что для одного бизнеса — бэк-офис, для холдинга — тиражируемая платформа, а для инвестора — второй этаж оффера («доля в движке ×100»).

Движок безлюден в строгом смысле: машина по умолчанию, человек по исключению, обе роли спроектированы (главы 8, 9). Его зрелость измеряется не численностью штата, а метрикой: STP-rate (доля кейсов без касания человека) × FTR (доля сделанного правильно с первого раза), бюджетом исключений и «юрлиц на сотрудника УК» (глава 11).

И движок — не проект автоматизации существующего. Он проектируется zero-based, от целевого состояния (глава 11), рядом со старым, и притягивает из старого только данные — в полном соответствии со стратегией pull. Реестр из 255 процессов старой компании — не техзадание, а карта миграции и проверка полноты: каждая строка реестра должна либо умереть (Eliminate), либо упроститься и стандартизоваться, либо найти своё место в движке.

12.2. Семь несущих решений

Семь архитектурных решений, на которых движок стоит. Каждое — вывод из нескольких глав сразу; это и есть места, где традиции сходятся.

Р1. Журнал экономических событий — единственная истина

Ядро движка — append-only журнал типизированных событий: продали, купили, оказали, начислили, оплатили, наняли, подписали. Идея открыта четырежды: двойная запись Пачоли (глава 3), event sourcing (глава 5), лог Kafka (глава 6), event history workflow-движков (глава 7) — и это конвергентное доказательство её правильности. Всё остальное — остатки, статусы, отчёты, консолидация — проекции, пересчитываемые из журнала. Следствия: аудит-трейл существует по построению, а не как отдельная подсистема; новый отчёт, агент или контур контроля подключается чтением журнала, а не интеграционным проектом; журнал с многолетним retention — «единственный сотрудник, который помнит всё» (глава 6). Для действий агентов журнал — то же самое, что для денег: каждое действие агента — событие с полным контекстом (кто, что, на каком основании, с каким confidence).

Р2. Онтология с действиями: мир меняется только через типизированные документы

Поверх журнала — онтология холдинга: объекты (контрагент, договор, сотрудник, юрлицо, продукт, обязательство), связи и — критично — действия (Palantir-паттерн, глава 5). Ни человек, ни агент не «правит остаток» и не пишет в базу напрямую: единственный легальный способ изменить состояние мира — провести типизированный документ-действие с валидацией, правами и записью в журнал (Beleg-принцип SAP, глава 4). REA-модель (глава 3) даёт готовую грамматику: экономическое событие с ресурсами, агентами и двойственностью, из которого проводки, аналитика и контроль выводятся posting-правилами автоматически. Онтология — одновременно карта мира для агента и его клетка безопасности: набор доступных действий и есть периметр того, что агент вообще может натворить.

Р3. Детерминированное ядро + агентные острова

Главный водораздел ответственности (главы 4, 7, 10): LLM предлагает — движок проводит. Всё недетерминированное (извлечение из документов, классификация, черновики, маршрутизация сложных случаев, переписка) делают агенты; всё, что меняет состояние мира (проводка документа, платёж, подписание, необратимые действия), делает детерминированное ядро с инвариантами — либо человек. Несущая конструкция процессного слоя — durable execution (Temporal/Camunda-класс, глава 7): журнал шагов + replay, детерминированный оркестратор снаружи, стохастические исполнители внутри шагов. Автономность агента — не цель, а расход (глава 10): большинство процессов бэк-офиса — workflow с агентными островами, а не свободный агент. Повышение автономии — только по «лестнице» (глава 7): LLM-активность → LLM-маршрутизатор → агент в ограждении → выше, и каждая ступень — по статистике качества из журнала, а не по вере.

Р4. Три разъёма у каждой системы: API, события, MCP

Мандат Безоса, обновлённый на агентную эпоху (глава 6): каждый сервис движка и каждый актив холдинга обязан иметь три интерфейса — REST/gRPC API (для кода), поток событий (для реактивности и памяти) и MCP-сервер (для агентов). События — сенсорика агентов, MCP — их моторика, оркестратор — дисциплина. Интеграционная ткань — один «тупой» сверхнадёжный транспорт событий на холдинг плюс логика строго на стороне доменов; любая умная шина — зародыш ESB 2.0 с очередью на изменения, которую в безлюдной компании некому разгребать. Обязательная четвёрка надёжности, заменяющая внимательность сотрудников: at-least-once + идемпотентные потребители + outbox + DLQ с владельцем и алертом — потерянное сообщение в компании без людей это молчаливая дыра в реальности. Побочный стратегический эффект: актив с чистыми тремя разъёмами отчуждаем — его можно продать, не вырезая из тела холдинга, что напрямую обслуживает инвест-логику «Операции сборки».

Р5. Человек по исключению — спроектированная подсистема

Человеческий слой проектируется с той же строгостью, что и машинный (главы 7, 8). Механизм — human task двадцатилетней BPM-выдержки: очередь исключений с claim, SLA, эскалацией и four-eyes; «вызов человека как сервиса». Уровень автономии назначается каждой из четырёх стадий (сбор — анализ — решение — исполнение) отдельно, необратимые действия получают архитектурное вето и откат. Против иронии Бейнбридж (глава 8) — явные контрмеры: оставшийся человек в движке дороже и квалифицированнее, а не дешевле; его бдительность поддерживается слепыми проверками и синтетическими ошибками-учениями; пассивное «подтверди, что всё ок» запрещено как гарантированно деградирующее в резиновый штамп. Закон Эшби задаёт рамку: движок покрывает смоделированное разнообразие, человек — спроектированный носитель остаточного (хвост возмущений), и если хвост никому явно не отдан — система не «почти готова», а не спроектирована.

Р6. Мультиюрлицевость и финядро — с первого дня

Учёт — не отчётность, а контур обратной связи и схема данных с самопроверкой (глава 3). Финядро движка: subledger-архитектура поверх журнала событий, posting engine с декларативными правилами, все «книги» (управленческая, РСБУ, налоговая, при необходимости МСФО) — параллельные проекции одного потока событий. Интеркомпани — пара зеркальных документов, создаваемых атомарно; консолидация — сложение, а не квартальный подвиг. Закрытие месяца схлопывается в непрерывную сверку: оптимальный размер батча при нулевой стоимости транзакции — одно событие; KPI финядра — доля автосверенного и возраст старейшего исключения. Периферия остаётся дешёвой и локальной: 1С как «принтер регламентированной отчётности» на краю, истина — в ядре. Контроль переворачивается с выборочного постфактум на тотальный превентивный: policy-as-code на каждой транзакции, сегрегация обязанностей — в том числе между агентами на разных моделях (глава 3).

Р7. Приборная панель безлюдности — метрики в контуре с первого дня

Что не измерено — то не спроектировано. Панель движка (главы 9, 10, 11): STP-rate × FTR по каждому процессу (пара обязательна: STP без FTR — конвейер быстрых ошибок); бюджет исключений (норматив доли кейсов к человеку и его тренд); span of automation — доля часов реестра работ, переведённых на машину (единица измерения перехода — задача и её часы, не «количество процессов»); cost per transaction против бенчмарков Hackett/APQC; выручка и валовая прибыль на сотрудника — метрика конструкции бизнеса ($100–200 тыс. — сервисная гравитация, ~$1 млн — продукт, выше — безлюдное ядро, глава 9); юрлиц на сотрудника УК — метрика тиражируемости движка. Урок Klarna (глава 10): метрики качества исхода обязаны стоять в контуре управления с первого дня, и измеряться объективно, а не самооценкой (урок METR: расхождение самооценки и факта — до 40 п.п.).

12.3. Слоёная архитектура: семь этажей

Решения Р1–Р7 складываются в слоёную конструкцию. Порядок этажей — одновременно порядок строительства: каждый следующий слой опирается на предыдущий, и попытка строить сверху вниз (начать с агентов, добавить данные потом) — самый частый провал агентных пилотов (главы 5, 10, 11).

Этаж 0. Онтология и мастер-данные. Словарь холдинга: сущности, атрибуты, действия; золотые записи контрагентов, людей, договоров, продуктов; карта «сущность → система записи». Без этого этажа агенты «быстро и уверенно отвечают неправильно».

Этаж 1. Событийный журнал и шина. Append-only журнал экономических и операционных событий; транспорт с гарантиями (идемпотентность, outbox, DLQ); реестр схем и контракты данных.

Этаж 2. Системы записи. Финядро (subledgers + posting engine + проекции-книги), кадровые и договорные записи; мультиюрлицевость как измерение; непрерывная сверка с внешним миром (банк, ЭДО, налоговый мониторинг) как священный ритуал.

Этаж 3. Процессный слой. Durable-оркестратор; исполняемые сквозные процессы (order-to-cash, procure-to-pay, record-to-report, hire-to-retire) как код; human tasks; событийный лог каждого процесса — первичный артефакт, метрики и conformance по построению.

Этаж 4. Агентный слой. Агентные острова внутри процессов; MCP-доступ к данным и действиям через онтологию; evals и guardrails; лестница автономии с повышением по статистике.

Этаж 5. Слой людей. Очередь исключений с SLA и four-eyes; роли: строители (инженеры движка), пограничники (разбор исключений), аудиторы (надзор, слепые проверки); «оператор оркестра агентов» как новая профессия УК.

Этаж 6. Приборная панель. Метрики Р7 по каждому процессу и юрлицу; семантический слой — единые определения метрик для людей и агентов (глава 5: режим отказа важнее точности — панель обязана отказывать громко).

12.4. Контур качества: SPC для стохастических исполнителей

Агент — стохастический исполнитель, и управлять им нужно так, как Деминг и Шухарт учили управлять процессами со встроенной вариабельностью (глава 2). Конкретно: контрольные карты ключевых метрик каждого агентного процесса (STP, FTR, доля эскалаций, стоимость кейса); различение общих и особых причин вариации; запрет «тамперинга» — переписывания промптов после единичного сбоя без статистического основания; PDSA-цикл как штатный режим улучшения. Дзидока как принцип автономности (глава 2): у каждого агентного процесса — встроенный детектор аномалий и право остановиться («цифровой андон»); четыре шага при остановке — обнаружить, остановиться, исправить, устранить корневую причину. Conformance checking (глава 7) поверх журнала — автоматический контроль того, что исполнение соответствует модели процесса. Отказы мультиагентных конструкций — это отказы оргдизайна: ролей, контекста, фиктивной верификации (таксономия MAST, глава 10), поэтому проектирование агентной системы движка и есть проектирование организации.

12.5. Экономика движка

Четыре экономических правила из книги. Первое — закон буферизации с новой ценовой политикой (глава 2): за вариабельность всегда платят запасом, мощностью или временем; машинная мощность дешева — буферизуйте ею щедро; человеческое время — самый дорогой буфер, людей нельзя грузить выше ~70–85%, а очередь к перегруженному человеку-подписанту убивает STP всего конвейера (ограничение движка почти всегда человеческое, глава 2). Второе — юнит-экономика на каждый агентный процесс (глава 10): паспорт процесса с полной стоимостью (токены + амортизация инженерии + стоимость эскалаций и ревью) против стоимости человеческого исполнения; пересчёт ежеквартально — граница выгодности дрейфует в пользу агентов на порядок за год-два (LLMflation), поэтому «сегодня невыгодно» — это дата, а не вердикт. Третье — экономика фиксированных затрат (глава 9): движок переводит операционные расходы из переменных (люди × объём) в фиксированные (инженерия) — маржа растёт с масштабом, и именно это делает «×100» вторым этажом инвест-оффера математически осмысленным. Четвёртое — каждая автоматизация есть обязательство сопровождения (главы 7, 11): RPA-долг переносится на агентов целиком; бюджет продуктизации в 3–5 раз больше бюджета пилота, и пилот без обязательства продуктизации запрещён.

12.6. Дорожная карта: пять этапов

Этап 0. Онтология и реестр (недели). Онтология холдинга v1 (сущности, действия, юрлица); маппинг реестра 255 процессов на целевые сквозные процессы движка с разметкой ESSA: что умирает, что упрощается, что переезжает; выбор первого чистого юрлица как носителя ядра; паспорт метрик (базовые значения STP/FTR/стоимости — чтобы было с чем сравнивать).

Этап 1. Ядро на первом юрлице (месяцы 1–3). Этажи 0–2: мастер-данные, журнал, шина, финядро с posting engine, непрерывная банковская сверка; три разъёма у первых сервисов; панель v1. Критерий выхода: первый сквозной процесс (например, order-to-cash сервисного контракта) идёт через движок от договора до денег с измеряемым STP.

Этап 2. Процессный слой и первые агентные острова (месяцы 3–6). Этажи 3–4 на трёх–пяти самых частых процессах: durable-оркестрация, human tasks, агенты на извлечении/классификации/черновиках; evals с первого дня; очередь исключений как рабочее место. Критерий: STP ≥ 60–70% на пилотных процессах при FTR не ниже человеческого бейзлайна.

Этап 3. Тиражирование на холдинг (месяцы 6–12). Подключение остальных чистых юрлиц конфигурацией; консолидация как проекция; лестница автономии — первые процессы переходят на уровень «агент в ограждении»; вывод людей из решений по формуле Amazon (глава 8): алгоритм решает по умолчанию, человек вмешивается по исключению с логированием, передача — ступенчато (советник → исполнитель с вето → автономия с аудитом). Критерий: «юрлиц на сотрудника УК» растёт, стоимость подключения юрлица падает от раза к разу.

Этап 4. Движок как продукт (месяцы 12+). Шаблон «актив на AI-рельсах» отчуждаем: онбординг нового актива (купленного или созданного) — недели; движок упакован как второй этаж инвест-оффера с собственными цифрами (STP, cost per transaction, юрлиц/чел, время онбординга). Здесь же — решение о внешней продаже движка как сервиса, если холдинг захочет монетизировать сам навык пересборки.

Параллельно всем этапам — трек Б стратегии: старые процессы не переносятся, а календарно доживают в старом контуре; движок притягивает только данные и переконтрактованные обязательства.

12.7. Анти-паттерны: сводный каталог граблей

Собранные по всем главам, в порядке убывания цены.

• Автоматизация хаоса: агент, обученный текущему беспорядку, воспроизводит беспорядок быстрее; ESSA-порядок (устрани → упрости → стандартизируй → автоматизируй) не отменяется LLM, а сжимается по времени (глава 11).
• Свободный агент там, где нужен workflow: автономность как самоцель; большинство задач бэк-офиса — детерминированный процесс с агентными островами (глава 10).
• Средняя автономия без предохранителей: уровни 5–7 по Шеридану — худшая конфигурация; либо ниже с явным человеком, либо выше с архитектурным вето (глава 8).
• Второй ввод факта: любые данные, вводимые дважды, порождают вечную ручную сверку — то есть людей (глава 3).
• Логика в шине: умная интеграционная прослойка становится организационным горлышком — ESB 2.0 (глава 6).
• Пилот-витрина: демо без встройки в поток, без владельца, без памяти процесса и без записанных критериев масштабирования — 95% провалов агентных пилотов ровно здесь (главы 10, 11).
• Локальная оптимизация против потока: ускорение неузкого места не даёт ничего, кроме роста WIP (глава 2).
• Метрика штук вместо часов: «автоматизировали 40 процессов» — манипулируемо; честно — доля часов реестра (глава 11).
• Резиновый штамп: человек-подтверждатель без слепых проверок деградирует за месяцы (глава 8).
• Кастомизация до смерти либо слепой adopt: обе крайности ERP-эпохи воспроизводимы и в движке — нужен единый инвариант ядра при конфигурируемой периферии (глава 4).
• Экраны для клерков как рефлекс: каждый экран ввода — признание, что процесс спроектирован под человека; интерфейс движка — очередь исключений и панель, а не формы (глава 4).

12.8. Конвейер проверки проекта

Прежде чем строить, проект движка проверяется вопросами-тестами; «нет» на любой — дыра в проекте. По истине: существует ли для каждого факта ровно одно место записи, и выводимо ли любое состояние из журнала? По действиям: можно ли изменить мир мимо типизированного действия — и если да, кто и когда это закроет? По отказам: для каждого компонента известен ли режим отказа, и всё ли тихо-отказывающее обёрнуто в громкое? По исключениям: у каждого процесса есть ли владелец очереди исключений, SLA и бюджет исключений? По людям: кому явно отдан хвост непокрытого разнообразия; чем поддерживается навык и бдительность пограничников? По метрикам: стоит ли пара STP×FTR в контуре с первого дня; объективно ли меряется качество (не самооценкой)? По экономике: есть ли у каждого агентного процесса паспорт юнит-экономики и дата пересчёта? По необратимости: перечислены ли необратимые действия, и на каждом ли — вето, четыре глаза или откат? По тиражу: подключается ли следующее юрлицо конфигурацией — и проверено ли это вторым юрлицом, а не обещанием? По наследию: точно ли движок не импортирует ни одного процесса «как есть» из реестра 255 — только через ESSA-разметку?

12.9. Чего в этой книге нет

Честные границы. Книга не проектирует фронт-офис: продажи, маркетинг, продукт — там своя автоматизация и своя литература; движок обслуживает бэк. Она не решает юридическую механику конкретного холдинга (переконтрактация, ликвидация старых юрлиц — трек Б идёт своим проектом). Она сознательно осторожна с прогнозами моделей: всё написанное верно для уровня агентов середины 2026 года, и главный совет по фронтиру — пересчитывать границы ежеквартально, а не верить ни скептикам, ни евангелистам. И она не заменяет проектирование: следующий шаг после чтения — не внедрение, а концепт движка на один сквозной процесс одного чистого юрлица, с паспортом метрик и датой первой проводки через журнал. Всё остальное в книге уже есть.

Главы-доноры синтеза

Вместо списка источников — карта происхождения: двенадцать глав книги и то, что каждая отдала этой конструкции.