Эта книга собрана под одну задачу: спроектировать с нуля безлюдный бизнес-движок — операционный бэк-офис холдинга, в котором операции, учёт, данные, процессы и решения выполняются машинами по умолчанию, а люди работают по исключению. Задача выглядит как инженерная, но первый же честный вопрос — «а как это вообще делается?» — упирается в неожиданную трудность: целостного учебника по этой теме не существует. Не потому, что тема новая. Наоборот — потому что она очень старая, и знание о ней накоплено огромное, но оно разложено по десятку профессиональных сообществ, которые почти не читают друг друга.
Операционные менеджеры сто лет считают вариабельность и пропускную способность — но не знают, что такое event sourcing. Архитекторы данных строят золотые записи и семантические слои — но никогда не открывали Голдратта. BPM-сообщество двадцать лет исполняет процессы кодом — но смотрит на бухгалтерский журнал как на чужую территорию. Бухгалтеры хранят самую старую формальную модель бизнеса — и не подозревают, что их двойная запись предвосхитила журналируемые архитектуры распределённых систем. А новая волна AI-инженеров переизобретает дзидоку, андон и контрольные карты Шухарта на оркестрации LLM-агентов, искренне считая, что открывает всё это впервые.
Каждое из этих сообществ владеет своим фрагментом ответа. Ни одно не владеет целым. Поэтому книга устроена так: десять глав — десять традиций знания, каждую копал отдельный исследователь на её собственных источниках (конференции, книги, статьи, блоги практиков), а две главы — эта и финальная — сшивают фрагменты в одну конструкцию. Эта глава даёт карту: что такое предмет, кто им владеет, по каким осям его раскладывать и какие сквозные темы будут возвращаться из главы в главу.
1.1. Предмет: что такое безлюдный бизнес-движок
Определим предмет через отличия — что движок не есть.
Это не ERP-система. ERP — это система записи с экранами для клерков: она предполагает, что операции выполняют люди, а софт хранит результаты их работы. Движок переворачивает предположение: операции выполняет сам движок, а люди подключаются к меньшинству кейсов. От ERP движок наследует строгость (документ, проводка, аудит-трейл — глава 4), но не наследует главного интерфейса — экранной формы, за которой сидит человек.
Это не программа автоматизации. Программа автоматизации — портфель проектов, в котором к существующим, выполняемым людьми процессам приделывают роботов и скрипты. История RPA (глава 7) показала, куда это ведёт: хрупкая плёнка автоматизации поверх ручного хаоса, «мощение коровьих троп». Движок строится наоборот — от целевого состояния, по логике zero-based design (глава 11): не «что автоматизировать в текущем», а «как должна выглядеть операция, если её проектировать сегодня, без наследия».
Это не «компания без людей». Ни один из разобранных в главе 9 образцов — от завода FANUC до Renaissance Technologies — не безлюден на сто процентов. Люди остаются в трёх спроектированных ролях: строители системы, пограничники исключений и аудиторы. «Безлюдный» в этой книге означает: машина по умолчанию, человек по исключению, и обе роли спроектированы явно. Мера безлюдности — не штатное расписание, а метрика: доля кейсов, прошедших без касания человека (straight-through processing rate), и её спутники.
И это не один продукт, который можно купить. Движок — это архитектура из нескольких слоёв (данные, события, записи, процессы, агенты, люди) плюс дисциплина их эксплуатации. Части покупаются, целое — проектируется.
Итоговое рабочее определение: безлюдный бизнес-движок — это событийная система записи ERP-строгости, у которой слой вовлечения заменён API и событиями, слой исполнения заселён детерминированными процессами и LLM-агентами, а человек встроен как спроектированный обработчик исключений и носитель надзора. Каждый элемент этой формулы будет развёрнут в своей главе и собран в главе 12.
1.2. Десять традиций знания
Карта сообществ, по которой нарезаны главы книги. По каждой традиции — чем она владеет, где живёт и чего систематически не видит.
Операционный менеджмент (глава 2) — самая старая научная традиция: Тейлор, Форд, Toyota, Голдратт, теория очередей, Factory Physics. Владеет математикой потока: законом Литтла, формулой Кингмана, законом буферизации вариабельности. Живёт в бизнес-школах (POMS, MSOM) и на заводах. Слепая зона: почти не думает о софте и данных; её «сервисный» поворот случился, но бэк-офис как фабрику документов она освоила поверхностно.
Учёт и контроллинг (глава 3) — хранитель самой старой формальной модели бизнеса: двойная запись, управленческий учёт, REA-онтология Маккарти, внутренний контроль. Владеет главным: как события бизнеса становятся деньгами и как система проверяет сама себя. Живёт в профессиональных ассоциациях (IMA, ACCA), больших аудиторских фирмах и — в России — в экосистеме 1С. Слепая зона: технологический консерватизм; учёт десятилетиями оптимизировал ручной труд клерка вместо того, чтобы его устранить.
Enterprise software / ERP (глава 4) — индустрия, которая сорок лет превращает предприятие в конфигурацию: SAP, Oracle, 1С, NetSuite и кладбище провалившихся внедрений. Владеет анатомией сквозных процессов (order-to-cash, procure-to-pay) и жёсткими уроками моделирования («adopt vs adapt»). Живёт на вендорских конференциях (SAP Sapphire, SuiteWorld) и в консалтинге. Слепая зона: экраноцентризм — вся её конструкция предполагает клерка за формой.
Архитектура данных (глава 5) — сообщество, отвечающее за «что истинно»: MDM, хранилища, event sourcing, data mesh, семантические слои, онтологии. Владеет дисциплиной единственного источника правды и её честной критикой. Живёт на dbt Coalesce, Data Council, в DAMA и в блогах инженеров. Слепая зона: склонность к аналитическому уклону — данные для отчётов, а не для операционных действий; операционная онтология (объекты+связи+действия, паттерн Palantir) для неё до сих пор экзотика.
Распределённые системы и интеграция (глава 6) — инженеры, соединяющие системы: Enterprise Integration Patterns, Kafka, событийные архитектуры, гарантии доставки, API-экономика, MCP. Владеют тем, без чего безлюдность рассыпается: идемпотентностью, outbox-паттерном, dead letter queue — механикой, заменяющей человеческую внимательность. Живут на QCon, InfoQ, в инженерных блогах Netflix/Uber/LinkedIn. Слепая зона: равнодушие к бизнес-семантике — «мы доставим сообщение, а что в нём — не наше дело».
BPM-сообщество (глава 7) — двадцать лет исполняет процессы как код: BPMN, workflow-движки, process mining, RPA и его перерождение. Владеет паттернами human-in-the-loop (очереди задач, эскалации, четыре глаза), выстраданными задолго до LLM. Живёт на CamundaCon, в академии процессной науки (BPM Conference, ван дер Аалст) и вокруг Celonis. Слепая зона: долго жило внутри «автоматизации существующего» и опоздало к событийно-агентной конвергенции, которую теперь догоняет.
Кибернетика и социотехника (глава 8) — теоретики систем управления: Винер, Эшби, Стаффорд Бир, Тавистокский институт, Бейнбридж, исследователи Amazon-механизмов. Владеют пределами: закон необходимого разнообразия (что вообще может быть автоматизировано), иронии автоматизации (почему оставшийся человек становится важнее), уровни автономии. Живут в академии (системные науки, human factors, HCI) и в редких корпоративных практиках. Слепая зона: дефицит инженерной конкретики — принципы без чертежей.
Индустрия экстремальной эффективности (глава 9) — не сообщество, а набор живых образцов: FANUC и dark factories, Amazon, HFT-фирмы, Visa, необанки, микрокоманды от WhatsApp до Cursor. Владеет доказательствами существования: безлюдные и почти безлюдные бизнесы работают, и их механика описана. Живёт в инженерных блогах, деловой прессе, книгах-расследованиях. Слепая зона: выжившие охотно рассказывают о себе, а погибшие молчат — поэтому глава специально разбирает и провалы (Tesla-2018, Zume, Watson Health).
AI-инжиниринг и агентные системы (глава 10) — самое молодое сообщество: LLM-агенты, оркестрация, guardrails, evals, MCP, service-as-software. Владеет фронтиром: как строить стохастических исполнителей и что с ними ломается (таксономии отказов мультиагентных систем, уроки Klarna и Project Vend). Живёт в блогах лабораторий (Anthropic, OpenAI), на arXiv, в дискорд- и реддит-сообществах, на конференциях AI Engineer. Слепая зона: историческая амнезия — переизобретает операционную науку и BPM, не зная их имён; и хайп, который приходится фильтровать.
Трансформационный консалтинг и бенчмаркинг (глава 11) — McKinsey/MGI, Hackett, APQC, история shared services: методологии инвентаризации работы, оценки автоматизируемости, метрик и последовательности перехода. Владеет вопросом «с чего начать и как мерить прогресс». Живёт в отчётах фирм и клубах GBS-практиков. Слепая зона: конфликт интересов (консалтинг продаёт трансформации) и привычка к большим организациям — рецепты для 50 000 человек не всегда масштабируются вниз.
Десять традиций — десять глав. Читатель, привыкший к одной из них, найдёт «свою» главу самой очевидной, а наибольшую ценность извлечёт из чужих.
1.3. Оси классификации
Чтобы фрагменты складывались, зафиксируем четыре оси, по которым в книге раскладывается любое решение об автоматизации.
Ось 1. Слой стека. Безлюдный движок — слоёная конструкция, и каждый слой обсуждается своей традицией: онтология и мастер-данные (что существует) → событийный журнал и шина (что произошло) → системы записи (что это значит для денег и обязательств) → процессный слой (что должно произойти дальше) → агентный слой (кто выполняет недетерминированную работу) → слой людей (кто разбирает исключения и надзирает) → приборная панель (как мы узнаём, что всё работает). Порядок слоёв — не только логика изложения, но и, как покажет глава 12, порядок строительства.
Ось 2. Степень автономии. Не бинарная («автоматизировано / нет»), а ступенчатая — от «машина советует» до «машина решает и не спрашивает» (уровни Шеридана, глава 8). Ключевая тонкость: уровень назначается не процессу целиком, а каждой из четырёх стадий — сбор информации, анализ, выбор решения, исполнение — отдельно. Большинство провалов автоматизации — это средние уровни автономии без предохранителей.
Ось 3. Оцифрованность объекта труда. Главный предиктор достижимой безлюдности (глава 9): финансы автоматизировались первыми, потому что их объект труда — записи о деньгах — полностью цифровой. Документооборот, код, контент — высокая оцифрованность; переговоры, физический мир, доверие — низкая. Ось подсказывает, где движку сопротивляться будет материя, а где — только привычка.
Ось 4. Режим отказа. Как система ошибается: громко (запрос невозможен, процесс остановлен, исключение в очереди) или тихо (правдоподобный неверный результат ушёл дальше). Для системы без человека-проверяющего это различие важнее точности (глава 5): всё, что может отказывать тихо, должно быть обёрнуто в то, что отказывает громко.
1.4. Пять сквозных тем
Пять нитей, которые прошивают все десять традиций. Замечать их — значит читать книгу как целое.
Экстернализация знания предшествует автоматизации. От тейлоровских хронометражей до промптов агента: автоматизировать можно только ту работу, знание о которой извлечено из головы исполнителя и записано в проверяемый стандарт. SOP, регламент, схема данных, промпт — одна и та же сущность в разных эпохах (главы 2, 7, 10).
Событие — первичный факт, состояние — производное. Бухгалтерский журнал, event sourcing, лог Kafka, event history в Temporal, аудит-трейл действий агента — одна идея, открытая минимум четырежды: истина — это неизменяемый журнал того, что произошло; любые «остатки» и «статусы» — кэш, пересчитываемый из журнала (главы 3, 5, 6, 7).
Человек по исключению — спроектированная роль, а не остаток. Наивная модель «автоматизируем 90%, люди сделают остальное» проваливается, потому что оставшиеся 10% — самые сложные кейсы, а человек, выключенный из рутины, теряет навык и бдительность (иронии Бейнбридж, глава 8). Роль пограничника исключений требует проектирования: очереди, SLA, бюджет исключений, тренировка навыка.
Вариабельность оплачивается буфером — всегда. Запасом, мощностью или временем (Factory Physics, глава 2). Движок не отменяет закон, а меняет цены: машинная мощность дешевеет, человеческое время дорожает, значит буферизовать надо машиной и никогда — очередью к человеку, загруженному на 100%.
Экономика решает, а не техническая возможность. ABC-костинг умер от стоимости ручного кормления данными; RPA упёрлось в стоимость сопровождения; агентные пилоты гибнут без юнит-экономики процесса (главы 3, 7, 10, 11). Каждая автоматизация — обязательство сопровождения, и граница «машина дешевле человека» — не константа, а быстро ползущая величина, которую надо пересчитывать.
1.5. Карта книги и маршруты чтения
Книга сгруппирована в четыре блока. Блок I «База» (главы 2–4) — как работает операционная машина: наука об операциях, учёт как контур управления, ERP как накопленный опыт моделирования предприятия. Блок II «Слои» (главы 5–7) — из чего строится движок: данные, интеграционная ткань, исполняемые процессы. Блок III «Организация» (глава 8) — пределы автоматизации и место человека. Блок IV «Фронтир и переход» (главы 9–11) — работающие образцы, агентный слой и методология перехода. Глава 12 — синтез: архитектура безлюдного движка RMR, семь несущих решений, дорожная карта, анти-паттерны.
Маршруты чтения. Экспресс для CEO (полдня): главы 1 → 12 → 9 → 11 — карта, итоговая архитектура, доказательства существования, методология перехода. Маршрут архитектора: главы 5 → 6 → 7 → 4 → 3 → 12 — слои снизу вверх, затем уроки ERP и финядро. Маршрут методолога перехода: главы 11 → 2 → 8 → 9 → 12 — как мерить, законы потока, место человека, образцы. Внутри каждой главы врезки «💡 Что взять для безлюдного движка RMR» собирают перенос на задачу проектирования; спорные факты в тексте честно помечены «(непроверено)».
Одно предупреждение перед стартом. Книга писалась в момент (середина 2026 года), когда агентная волна находится одновременно на пике возможностей и на пике хайпа: рядом с реальными безлюдными контурами живут отчёты о 95% провалившихся пилотов. Мы сознательно держим обе линии: каждая глава фронтира уравновешена главой базы, каждый восторженный кейс — разобранным провалом.