ERP и системы записи

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

4.1. Генеалогия: от MRP к ERP, или как список деталей стал моделью компании

История ERP начинается не с учёта денег, а с учёта деталей. В конце 1950-х — начале 1960-х инженер Джозеф Орлицки (Joseph Orlicky), работавший в J.I. Case, а затем в IBM, формализовал подход, который в 1975 году опишет в классической книге «Material Requirements Planning». Идея MRP (планирование потребности в материалах) проста и глубока одновременно: если у вас есть три структуры данных — главный производственный план (Master Production Schedule: что и когда мы обязались произвести), спецификация изделия (Bill of Materials, BOM: из каких компонентов состоит каждый продукт, рекурсивно, уровень за уровнем) и состояние запасов (Inventory Records: что лежит на складе и что уже заказано), — то потребность в каждой детали можно не угадывать, а вычислить. Алгоритм «разузлования» (BOM explosion) спускается по дереву спецификаций: чтобы собрать 100 тракторов к 1 марта, нужно 100 двигателей к 15 февраля, значит 400 поршней к 1 февраля, значит заказ литья — 10 января, с учётом времени поставки (lead time) и уже имеющихся остатков (netting). Это был переворот: впервые операционное решение («что заказать и когда») стало детерминированной функцией от данных, а не от опыта снабженца. Ключевое различение Орлицки — зависимый и независимый спрос: спрос на готовые тракторы приходит извне и его надо прогнозировать, а спрос на поршни полностью выводится из спроса на тракторы, и прогнозировать его — методическая ошибка.

MRP работал, пока данные были точны, и разваливался, когда цех жил своей жизнью. Ответом стал MRP II — Manufacturing Resource Planning, термин и методологию которого продвигал Оливер Уайт (Oliver Wight), консультант и соратник Орлицки (вместе с Джорджем Плосслом их называют «крестными отцами MRP»). MRP II замкнул контур: к расчёту материалов добавились планирование мощностей (Capacity Requirements Planning), цеховое управление (shop floor control), закупки, а главное — финансовый слой: каждое движение материала стало порождать стоимостную запись. План в штуках и план в деньгах стали двумя проекциями одной базы данных. Уайт также ввёл культуру дисциплины данных — его «ABCD-чеклист» оценивал не софт, а зрелость процессов компании: система класса A — та, где план в компьютере и реальность в цеху совпадают, и люди верят цифрам в системе больше, чем слухам в курилке.

Термин ERP (Enterprise Resource Planning) закрепила аналитическая компания Gartner в начале 1990-х, зафиксировав то, что уже происходило на рынке: логика «единая база + встроенные процессы» вышла за пределы производства и поглотила финансы, кадры, сбыт, снабжение. Формула ERP состоит из двух обещаний. Первое — единая база данных: заказ клиента, складской остаток, проводка в главной книге и запись о сотруднике живут в одной СУБД, в согласованных таблицах, и цифра выручки в отчёте финансового директора по построению совпадает с суммой отгрузок в модуле сбыта. Никаких сверок между отделами — сверка встроена в схему данных. Второе — встроенные процессы: система поставляется не пустой, а с зашитыми в неё «лучшими практиками» — готовыми цепочками транзакций, статусов и проверок, отражающими то, как «правильная» компания принимает заказ, отгружает, выставляет счёт и закрывает период. Именно второе обещание, как мы увидим в разделе о провалах, оказалось и главной ценностью ERP, и главным источником катастроф: покупая ERP, компания покупает не инструмент, а чужую модель самой себя.

• 1964MRP.

  Джозеф Орлицки (IBM) формализует планирование потребности в материалах: MPS + BOM + запасы → потребность вычисляется, а не угадывается.

• 1975«Material Requirements Planning».

  Классическая книга Орлицки; зависимый спрос выводится из обязательств — прогнозировать его — методическая ошибка.

• 1980-еMRP II.

  Оливер Уайт замыкает контур: мощности, цех, закупки и финансовый слой; план в штуках и деньгах — две проекции одной базы.

• ~1990Термин ERP.

  Gartner фиксирует выход логики «единая база + встроенные процессы» за пределы производства: финансы, кадры, сбыт, снабжение.

• 1992SAP R/3.

  Трёхзвенная клиент-серверная архитектура; стандарт де-факто корпораций 1990-х и самая полная формальная модель «предприятия вообще».

• 1998NetSuite.

  Эван Голдберг основывает NetLedger — первую облачную бухгалтерию через браузер, задолго до слова SaaS.

• ~2014Postmodern / composable ERP.

  Gartner фиксирует распад монолита: административное ядро + best-of-breed облака + iPaaS как интеграционная подложка.

• 2015S/4HANA.

  Universal Journal (ACDOCA): одна строка истины на позицию документа, агрегаты оказались костылём под медленное железо.

• 2024–26AI-native волна.

  Campfire, Rillet, Light, DualEntry: «агенты вместо экранов» — LLM-конвейер порождает документы, детерминированное ядро проводит.

Для нашего курса важно увидеть в этой генеалогии главный сдвиг: софт перестал быть калькулятором при бизнесе и стал его исполняемой моделью. MRP смоделировал материальный поток, MRP II добавил деньги и мощности, ERP объявил моделью всё предприятие целиком. Всё дальнейшее — облака, микросервисы, агенты — это споры о том, как эту модель хранить, разрезать и кто с ней работает, но сама идея «предприятие = данные + правила переходов» родилась здесь.

4.2. SAP R/3 как архетип: документ, проводка, оргструктура в системе

Если MRP — это идея, то SAP R/3 — это собор, в котором она достигла готической полноты. Компания SAP была основана в 1972 году пятью выходцами из IBM (Хассо Платтнер, Дитмар Хопп, Клаус Чира, Ханс-Вернер Гектор, Клаус Велленройтер); её первая система R/1, затем мейнфреймовая R/2, а в 1992 году — R/3, трёхзвенная клиент-серверная архитектура (презентационный слой SAPGUI — сервер приложений — реляционная СУБД), которая идеально попала в волну даунсайзинга с мейнфреймов и стала стандартом де-факто для крупных корпораций 1990-х. R/3 стоит разобрать подробно не из ностальгии: это самая полная из когда-либо построенных формальных моделей «предприятия вообще», и почти каждое её проектное решение — ответ на реальную проблему, с которой столкнётся и проектировщик безлюдного движка.

Документный принцип: Beleg как атом бизнес-реальности

Сердце R/3 — немецкое бухгалтерское понятие Beleg (документ, «оправдательный документ»). Принцип звучит как заповедь: keine Buchung ohne Beleg — «нет проводки без документа». В системе это означает: любое изменение состояния предприятия существует только как проведённый документ — структурированный объект с заголовком (номер, дата, тип, кто создал) и позициями (строки со счетами, суммами, количествами, ссылками). Заказ клиента — документ. Отгрузка — документ. Счёт-фактура — документ. Платёж — документ. Документы не редактируются задним числом: проведённый (posted) документ неизменяем, ошибки исправляются новым документом — сторно (reversal), которое не стирает историю, а добавляет компенсирующую запись. Так возникает главное свойство системы записи: состояние (остаток на счёте, остаток на складе) — это всегда свёртка журнала документов, и любую цифру в любом отчёте можно раскрутить назад до породивших её первичных документов (drill-down по цепочке ссылок). Это и есть аудит-трейл (audit trail), встроенный в саму физику системы, а не прикрученный сбоку логгер.

Проводка документа (posting) — транзакционный акт в строгом смысле: в момент проведения система проверяет целостность (баланс дебета и кредита, открыт ли период, есть ли полномочия, заполнены ли обязательные аналитики), записывает документ и одновременно обновляет все производные регистры — сальдо счетов главной книги, позиции контрагента, складские количества, контроллинговые объекты. Либо всё, либо ничего: ACID-транзакция, натянутая на бухгалтерскую семантику. Двойная запись здесь работает как инвариант целостности: сумма дебетов равна сумме кредитов в каждом документе, поэтому баланс не может не сойтись — расхождение невозможно синтаксически, а не отлавливается сверкой постфактум.

Оргструктура в системе: company code, plant и модель холдинга

Второе великое решение R/3 — предприятие описывается в системе явной организационной структурой, и все документы к ней привязаны. Верхний уровень — клиент/mandant (client), изолированное пространство данных. Внутри него — балансовые единицы (company code, Buchungskreis): каждая соответствует юрлицу, ведущему самостоятельный баланс и сдающему отчётность. Ниже и рядом — заводы (plant, логистическая точка: производство или склад), склады (storage location), сбытовые организации (sales organization), закупочные организации (purchasing organization), контроллинговые единицы (controlling area, которая может объединять несколько company code для сквозного управленческого учёта). Один экземпляр системы штатно обслуживает холдинг из десятков юрлиц: межфирменные операции (intercompany) порождают зеркальные документы в двух балансовых единицах автоматически, а консолидация становится вычислимой процедурой, а не квартальным подвигом в Excel. Для Алексея, проектирующего движок «управляющая компания + несколько чистых активов», это прямой прототип: мультиюрлицевость должна быть измерением схемы данных с первого дня, а не надстройкой.

Customizing против модификации: два способа изменить систему

Третий урок R/3 — жёсткое разделение трёх способов адаптации. Настройка (customizing) — изменение поведения через данные конфигурации: в справочнике IMG (Implementation Guide) — тысячи таблиц-настроек, определяющих типы документов, схемы проводок, статусные схемы, правила определения цен. Код не трогается; поведение системы — функция от конфигурационных таблиц. Расширение (enhancement) — код в предусмотренных вендором точках (user exits, BAdI), переживающий обновления. Модификация (modification) — правка кода вендора; официально возможна, фактически проклята: каждая модификация превращает обновление версии в ручную трёхстороннюю сверку и годами копится в «долг кастомизации», который в итоге и хоронит проекты (см. раздел 4.6). Язык ABAP и открытость кода делали соблазн модификаций постоянным — и лучшие SAP-команды мерились не тем, сколько они докрутили, а тем, сколько им удалось не докручивать.

4.3. System of record, system of engagement, system of intelligence

В 2011 году Джеффри Мур (Geoffrey Moore) — автор «Crossing the Chasm» — опубликовал для ассоциации AIIM небольшой манифест «Systems of Engagement and the Future of Enterprise IT», давший индустрии словарь, которым она пользуется до сих пор. Мур заметил: всё корпоративное ПО XX века — это системы записи (systems of record). Их предмет — транзакции и факты; их ценность — единственная достоверная версия истины (single source of truth); их метрики — целостность, полнота, соответствие регуляторике; их эстетика — «скучно и надёжно». ERP, биллинг, главная книга, кадровый учёт — всё это системы записи. Но потребительский интернет (Мур писал под впечатлением от Facebook и смартфонов) породил другой класс — системы вовлечения (systems of engagement): их предмет — взаимодействия людей, контекст, коммуникация в моменте; их метрики — скорость, удобство, adoption. CRM в части ведения сделок, мессенджеры, порталы, мобильные приложения — это слой вовлечения, живущий поверх систем записи и меняющийся на порядок быстрее них.

Позже аналитики (в развитие идей Мура) достроили третий этаж — системы интеллекта (systems of intelligence): слой, который сидит между записью и вовлечением, агрегирует данные и превращает их в предсказания и решения — аналитика, ML-модели, а сегодня и агенты. Трёхслойная картинка полезна не как классификация продуктов, а как разделение режимов требований. Система записи обязана быть консервативной: схема меняется редко и осознанно, транзакции атомарны, история неудаляема, время жизни — десятилетия. Система вовлечения обязана быть пластичной: интерфейсы переделываются под пользователя (или агента) хоть еженедельно. Система интеллекта обязана быть вероятностной: она имеет право ошибаться, потому что её выводы — гипотезы, а не факты. Катастрофы начинаются при смешении режимов: когда в систему записи тащат «удобные» правки задним числом ради вовлечения, или когда вероятностному слою дают писать в главную книгу напрямую, минуя документный протокол.

Для архитектуры безлюдного движка эта трёхслойность — вероятно, самая практичная рамка всей главы. В классической компании слой вовлечения — это люди за экранами: формы, дашборды, согласования. В безлюдной компании именно этот слой схлопывается первым: агентам не нужны экраны, им нужны API и события. Слой интеллекта, наоборот, разрастается: агенты и есть системы интеллекта, ставшие действующими лицами. А слой записи остаётся почти неизменным по своим требованиям — и это главный консерватизм, который следует сохранить. Формула безлюдного движка: тонкая, строгая, маленькая система записи + богатый агентный слой интеллекта + почти исчезнувший слой вовлечения (несколько дашбордов для владельца и регулятора).

4.4. Анатомия сквозных процессов: order-to-cash, procure-to-pay, record-to-report

ERP-мир мыслит не функциями и не отделами, а сквозными процессами (end-to-end processes) — цепочками документов, пересекающими границы модулей. Три канонических цепочки покрывают почти всю хозяйственную жизнь компании, и их анатомию нужно знать наизусть, потому что безлюдный движок будет исполнять ровно их же.

Order-to-cash (O2C, «от заказа до денег») — доходный цикл. Заказ клиента (sales order) фиксирует обязательство: что, кому, почём, когда; при создании система проверяет кредитный лимит клиента и доступность товара (ATP-check, available-to-promise). Отгрузка/поставка (delivery) — логистический документ: списание с конкретного склада, момент перехода права собственности; при проведении рождается материальный документ (движение запаса) и, автоматически, финансовый (проводка: себестоимость → отгружено). Счёт-фактура (billing/invoice) превращает отгрузку в дебиторскую задолженность: проводка «дебиторка / выручка». Входящий платёж (payment) закрывает дебиторку, и здесь живёт вечная боль — сопоставление (cash application / clearing): пришедшие на счёт деньги нужно привязать к конкретным открытым позициям, а клиенты платят частями, объединяют счета и путают назначение платежа. Каждый следующий документ создаётся со ссылкой на предыдущий (document flow), поэтому в любой момент можно спросить: «какие заказы отгружены, но не отфактурированы?», «какие счета просрочены?» — это запросы к цепочке ссылок, а не расследование.

Procure-to-pay (P2P, «от закупки до оплаты») — расходный цикл, зеркальный O2C: заявка (purchase requisition) → заказ поставщику (purchase order) → поступление товара (goods receipt) → входящий счёт (invoice receipt) → платёж. Центральный механизм здесь — трёхстороннее сопоставление (three-way match): прежде чем счёт поставщика попадёт в оплату, система сверяет три независимых документа — что мы заказали (PO), что реально получили (goods receipt) и что нам выставили (invoice). Совпало в допусках — счёт проводится и уходит в платёжный календарь без участия человека; разошлось — блокировка и разбор. Three-way match — это готовый, отточенный десятилетиями протокол защиты от ошибок и фрода, и он же — идеальный кандидат на полную агентизацию: правила формальны, исключения классифицируемы. Технический приём под капотом — транзитный счёт GR/IR (goods receipt / invoice receipt): поступление кредитует его, счёт дебетует, ненулевое сальдо по конкретному заказу — сигнал расхождения. Обратите внимание на общий приём: несоответствие делается видимым как ненулевой остаток на специальном счёте — контроль встроен в план счетов, а не в регламент.

Record-to-report (R2R, «от записи до отчётности») — учётный цикл: накопление проводок → закрытие периода (period-end closing) → отчётность. Закрытие — это регламентированная последовательность: начисления (accruals), амортизация, переоценка валютных позиций, распределение косвенных затрат, сверка вспомогательных книг с главной (subledger-to-GL reconciliation), блокировка периода от новых проводок, формирование баланса и P&L. В классической компании закрытие месяца — марафон бухгалтерии на 5–10 рабочих дней; движение последних лет — continuous close (непрерывное закрытие), когда сверки и начисления выполняются ежедневно и автоматически, и «закрыть месяц» означает лишь проставить флаг. Для безлюдного движка continuous close — не оптимизация, а естественное состояние: если каждый документ проводится в момент события, отчётность в реальном времени — побочный эффект архитектуры.

4.5. Мастер-данные и конфигурация как «ДНК» системы

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

Материал/номенклатура (material master, item master) — самый структурно богатый объект: один и тот же материал описан десятками «ракурсов» (views) для разных служб — базовые данные (единицы измерения, вес), сбытовые (цены, налоговая классификация), закупочные (поставщики, сроки), складские (места хранения, стратегии отбора), учётные (метод оценки себестоимости: стандартная цена или скользящая средняя, счёт учёта запасов через класс оценки). Заведение материала — междисциплинарный акт: пока учётный ракурс не заполнен, материал нельзя ни купить, ни продать, потому что система не знает, какими проводками отражать его движение.

Контрагент (customer/vendor master, в S/4HANA объединённые в business partner) — носитель платёжных условий, кредитных лимитов, банковских реквизитов, налоговых атрибутов и контрольного счёта (reconciliation account), через который все операции с ним автоматически отражаются в главной книге. Дубли контрагентов — классическая гниль мастер-данных: две карточки одного поставщика означают, что кредитный лимит, история платежей и three-way match работают вполсилы.

План счетов (chart of accounts) — система координат финансового учёта. В мультиюрлицевом ландшафте он трёхэтажный: операционный план счетов, общий для всех компаний группы (чтобы консолидация была сложением, а не маппингом), локальные планы для национальной отчётности (в России — ПБУ/налоговый учёт), групповой — для консолидации. Рядом — управленческие измерения: места возникновения затрат (cost centers), носители затрат, внутренние заказы, центры прибыли.

Отдельный слой — конфигурация: те самые тысячи настроечных таблиц (типы документов, схемы ценообразования, статусные схемы, допуски three-way match, правила определения счетов). Конфигурация — это «ДНК» системы: два экземпляра одной и той же ERP с разной конфигурацией — это два разных предприятия. Важное следствие: конфигурация — тоже данные, и к ней применимы все дисциплины данных — версионирование, перенос между средами (в SAP — транспортная система: настройка едет из development в quality и production как упорядоченный набор изменений), аудит «кто и когда изменил правило». Индустрия управления мастер-данными (MDM, master data management) выросла именно из боли ERP: когда справочники расползаются по нескольким системам, нужен согласованный процесс governance — кто владеет справочником, кто утверждает изменения, как меряется качество (полнота, уникальность, актуальность). Подробно мы разберём это в главе о данных; здесь зафиксируем главное: в ERP мастер-данные и конфигурация — это медленные данные, ошибки в которых тиражируются каждой транзакцией, тысячи раз в день.

4.6. Почему внедрения проваливаются: кладбище ERP-проектов

ERP — единственный класс корпоративного софта, у которого есть собственный жанр литературы: некрологи внедрений. Оценки частоты провалов расходятся в зависимости от определения «провала», но неизменно удручают: Gartner в разные годы оценивал долю ERP-инициатив, не достигающих бизнес-целей, в 55–75%, а в свежем прогнозе ожидает, что к 2027 году около 70% внедрений не выполнят исходный бизнес-кейс полностью; исследования Standish Group (CHAOS) и опросы Panorama Consulting десятилетиями показывают, что большинство проектов выходят за бюджет и сроки, а треть-половина не приносит и половины ожидаемых выгод (цифры зависят от методологии опроса — относитесь к точным процентам как к порядку величины, не как к измерению). Важно понять не цифры, а механизмы провала — они удивительно однотипны, и четыре канонических кейса дают полную типологию.

FoxMeyer (1996): провал как банкротство. Четвёртый дистрибьютор лекарств США с оборотом ~$5 млрд запустил проект Delta III — SAP R/3 плюс автоматизированный склад Pinnacle — и через два года стал хрестоматией: компания обанкротилась, а конкурсный управляющий подал иски на $500 млн к SAP и на столько же к консультанту Andersen Consulting. Механизм: R/3 середины 1990-х был спроектирован под производственные компании с тысячами заказов в день, а FoxMeyer как дистрибьютор обрабатывал сотни тысяч строк заказов ежесуточно — система упёрлась в пропускную способность; параллельный запуск склада-робота дал каскад ошибок отгрузки; а контрактные обязательства перед клиентами были подписаны в расчёте на экономию, которая так и не наступила. Урок: система записи — операционная инфраструктура; её отказ — это отказ бизнеса, и запас по производительности под ваш профиль транзакций — вопрос выживания, а не тюнинга.

Hershey (1999): провал как невыполненные заказы. Кондитерский гигант внедрял одновременно SAP R/3, CRM Siebel и планирование Manugistics ($112 млн бюджета) и, отставая от графика, сжал внедрение и включил всё «большим взрывом» (big bang) в июле 1999-го — прямо перед пиковым сезоном Хэллоуина. Заказы перестали проходить сквозь новый контур: товар лежал на складах, но система «не видела» запасы и не могла собрать отгрузки; около $100 млн заказов не было выполнено, квартальная прибыль упала на 19%, акции — на 8% в день объявления. Механизм: срезанное тестирование (особенно интеграционное — стыки трёх систем) и go-live в пик нагрузки. Урок: момент переключения — самостоятельное проектное решение; тестировать нужно не модули, а сквозные цепочки на реальных объёмах.

Lidl (2011–2018): провал как столкновение моделей. Ритейлер потратил ~7 лет и, по сообщениям прессы, около €500 млн на проект eLWIS (SAP for Retail) и в 2018 году отменил его, вернувшись на собственную legacy-систему. Ядро конфликта элегантно в своей фатальности: Lidl вёл учёт запасов по закупочным ценам, а стандарт SAP for Retail — по розничным; Lidl отказался менять свою практику, и модель «докручивали» модификациями по всей глубине системы. Каждая доработка тянула следующую, апгрейды становились дороже, пока совокупная стоимость догоняния собственной кастомизированной версии не превысила ценность проекта. Это чистый эксперимент по дилемме «adopt vs adapt»: пересадка процессов вендора (перестроить компанию под систему) против кастомизации до смерти (перестроить систему под компанию). Lidl выбрал второе и заплатил полмиллиарда за доказательство теоремы: покупая пакет и отвергая его модель, вы получаете худшее из обоих миров — чужое ядро и свою уникальность, враждующие друг с другом.

Birmingham City Council (2022–…): провал как потеря контроля над учётом. Крупнейший муниципалитет Европы мигрировал с SAP (работавшего с 1999 года) на Oracle Fusion Cloud; бюджет ~£20 млн вырос, по оценкам аудиторов, до £131–216 млн полной стоимости восстановления, а совет — на фоне и других обязательств — выпустил в 2023 году уведомление о фактической неплатёжеспособности (section 114). Самое поучительное: после запуска в апреле 2022-го система не могла корректно выполнять банковские сверки — муниципалитет буквально утратил способность достоверно знать собственные финансы, и аудиторы годами не могли подписать отчётность; сроки полного исправления сдвигались и в 2025–2026 годах. Механизм: совет сначала обещал внедрение «ванильного» Oracle, затем — под давлением привычных процессов — накастомизировал критические участки, потеряв и стандартную поддержку, и работоспособность. Урок: провал системы записи — это не «неудобный софт», это слепота: организация перестаёт знать о себе правду.

Сведём типологию. Провалы почти никогда не бывают «техническими» в узком смысле; это провалы моделирования: (1) несоответствие модели вендора и модели компании, решаемое силой (Lidl, Birmingham); (2) недооценка транзакционного профиля (FoxMeyer); (3) сжатие тестирования сквозных цепочек и рискованный момент переключения (Hershey); (4) политэкономия проекта — консультанты, продающие часы, вендор, продающий лицензии, и заказчик без внутренней компетенции, чтобы им возражать. Заметьте: все четыре механизма — про отношения между формальной моделью и реальной компанией. Именно поэтому глава называется так, как называется.

4.7. Ландшафт: от S/4HANA до 1С

Современный ландшафт ERP — это несколько поколений, живущих одновременно, и по каждому крупному игроку видно, какую эпоху он несёт в своей архитектуре.

SAP S/4HANA (2015) — переписывание R/3 (точнее, его наследника ECC) под собственную in-memory СУБД HANA. Архитектурно самое интересное — Universal Journal (таблица ACDOCA): десятилетиями финансовый учёт (FI) и контроллинг (CO) жили в отдельных таблицах с агрегатами и требовали сверки; колоночная in-memory база позволила убрать предрассчитанные агрегаты и держать одну строку истины на каждую позицию документа, из которой любой отчёт считается на лету. Это важный прецедент для проектировщика: агрегаты и «вторые копии для отчётности» — не сущность учёта, а костыль под медленное железо; при достаточной вычислительной мощности система записи сводится к одному журналу событий. Миграция парка клиентов с ECC на S/4 (дедлайн поддержки — 2027 год с платными продлениями) — крупнейшая принудительная перестройка в истории корпоративного ИТ и источник нынешней волны недовольства SAP.

Oracle NetSuite — исторически первый облачный ERP: основан в 1998 году Эваном Голдбергом как NetLedger (при раннем инвестировании Ларри Эллисона), задолго до слова SaaS предлагал бухгалтерию через браузер; в 2016-м Oracle купил NetSuite за $9,3 млрд. NetSuite доказал две вещи: что компании готовы держать главную книгу в чужом дата-центре и что мультиарендная (multi-tenant) модель радикально меняет экономику владения — все клиенты на одной версии, обновления приходят всем сразу, «кастомизация до смерти» технически затруднена (расширения только через SuiteScript в песочнице). Сегодня это дефолтный ERP американских растущих компаний между «переросли QuickBooks» и «ещё не SAP».

Microsoft Dynamics 365 — два продукта под одним брендом: Finance & Operations (наследник датской Axapta) для крупных и Business Central (наследник Navision) для среднего бизнеса; сила Microsoft — не в глубине учётного ядра, а в обвязке: Power Platform (low-code), Copilot, Teams и Azure как гравитационное поле, втягивающее ERP в общий стек.

Odoo — самый поучительный кейс для малых компаний: бельгиец Фабьен Пинкерс с 2005 года строит open-source ERP (TinyERP → OpenERP → Odoo) как платформу приложений: единый ORM и объектная модель, поверх которых — десятки модулей (учёт, склад, CRM, сайт, производство, HR) и тысячи коммьюнити-аддонов. Модель монетизации — open core: Community-версия бесплатна, Enterprise — по подписке; оценка компании в раундах 2024–2025 годов превысила €5 млрд (непроверено в деталях, порядок подтверждён несколькими сообщениями прессы). Odoo интересен как экзистенциальное доказательство: полноценная система записи для компании в 10–200 человек может стоить почти ноль и разворачиваться за недели — если принять её модель процессов.

1С — российская специфика, которую Алексею предстоит учитывать в любом сценарии с российскими юрлицами. Архитектура 1С concept-for-concept повторяет разделение SAP «ядро vs конфигурация», но доводит его до логического конца: платформа «1С:Предприятие» — это, по сути, специализированная среда исполнения (метаданные, встроенный язык, объекты «документ», «регистр накопления», «регистр сведений», «план счетов» как примитивы платформы), а конфигурация («Бухгалтерия», ERP, ЗУП, УТ) — прикладная модель, написанная на этой платформе и открытая для изменения. Регистры 1С — прямое воплощение принципа «состояние = свёртка документов»: документ при проведении пишет движения в регистры, отчёты читают регистры. Вторая опора — экосистема франчайзи: тысячи партнёрских компаний внедряют и дорабатывают конфигурации, что сделало 1С фактическим монополистом учёта в РФ (регламентированная отчётность обновляется вендором под каждое изменение законодательства — это её незаменимая функция). Оборотная сторона той же медали: лёгкость доработки конфигураций порождает национальный спорт «снять с поддержки и переписать», после чего обновления встают колом — «кастомизация до смерти» в миниатюре, тиражированная сотнями тысяч инсталляций. Практический вывод для холдинга: 1С почти неизбежна как шлюз регламентированной отчётности российских юрлиц, но делать её центром безлюдного движка не обязательно — она может быть подчинённой системой, в которую движок публикует документы.

4.8. Postmodern и composable ERP: распад монолита

К 2010-м монолитная мечта «одна система на всё предприятие» надломилась под собственным весом, и Gartner зафиксировал сдвиг термином postmodern ERP (постмодернистский ERP, ~2014): вместо единого пакета — федерация из административного ядра (финансы, закупки) и лучших в своём классе (best-of-breed) облачных приложений вокруг: Salesforce для продаж, Workday для людей, Coupa для закупок, специализированные системы для склада и производства. Дальше Gartner же эволюционировал идею в composable ERP (композируемый ERP): предприятие собирает свою систему из взаимозаменяемых компонентов — упакованных бизнес-возможностей (packaged business capabilities) — на общей интеграционной подложке. Роль подложки взяли на себя iPaaS (integration platform as a service — Workato, Boomi, MuleSoft, Celigo, n8n): платформы, где интеграции между SaaS описываются как конфигурируемые потоки «событие → трансформация → действие», а не как заказной код.

Механика распада важнее лозунгов. Монолит давал бесплатно три вещи, которые в композируемом мире надо строить руками. Первое — транзакционную целостность через границы: внутри R/3 отгрузка и проводка себестоимости — одна транзакция; между WMS-облаком и учётным облаком — две системы, сеть и очередь между ними, значит нужны идемпотентность, повторы, компенсации и мониторинг рассинхронизации (сага вместо транзакции). Второе — единые мастер-данные: в федерации клиент существует в пяти системах, и вопрос «кто мастер по контрагенту» становится архитектурным решением с процессом синхронизации. Третье — сквозной документооборот: document flow внутри монолита — ссылки в одной базе; в федерации трассировка заказа через четыре SaaS требует сквозного идентификатора и дисциплины его протаскивания. Composable — это не «проще», это осознанный размен: скорость замены компонентов против инженерной стоимости связности.

Логическое завершение тренда — headless ERP (безголовый ERP): учётное ядро без собственного интерфейса, «сервис учёта с API». Симптоматичны здесь не столько классические вендоры, сколько инфраструктурные примитивы новой волны: ledger-as-a-service и учётные движки с API-first дизайном (open-source Formance Ledger, Modern Treasury Ledgers для финтех-платежей, Twisp и другие), где главная книга — это программируемый примитив, к которому продукт обращается как к базе данных с бухгалтерскими инвариантами (двойная запись, неизменяемость, идемпотентные транзакции). ERP перестаёт быть «местом, где работают люди» и становится «сервисом, на который ссылаются программы» — ровно та эволюция, которую предполагает безлюдный движок.

4.9. ERP для малых команд: конструктор из SaaS

У компании в 10–30 человек — а именно такими Алексей планирует держать «чистые бизнес-активы» — есть три реалистичных пути к системе записи, и все три поучительны.

Путь первый — лёгкий полноценный ERP: Odoo, NetSuite, для российских юрлиц — 1С:Fresh (облачная 1С по подписке, где вендор сам обновляет конфигурации — что автоматически дисциплинирует: в облаке нельзя «снять с поддержки»). Ключевая экономика: Odoo Community — бесплатно плюс хостинг, 1С:Фреш — тысячи рублей в месяц, NetSuite — от ~$1–2 тыс. в месяц. Компания из 10 человек получает те же документные принципы, что и корпорация, — вопрос лишь в том, сколько модулей включить и хватит ли дисциплины вести данные.

Путь второй — «ERP из SaaS-конструктора»: то, как реально живёт американский стартап. QuickBooks или Xero как главная книга; Stripe как биллинг и мерчант-учёт; Ramp или Brex как корпоративные карты и управление расходами (расходы категоризируются автоматически и синкаются в книгу); Gusto/Deel — зарплата и подрядчики; Bill.com — счета поставщиков. Каждый сервис — лучший в своей нише, интеграции штатные, суммарная стоимость — сотни долларов в месяц. Это composable ERP, собравшийся снизу, стихийно. Его сильная сторона — каждая часть отполирована; слабая — никто не отвечает за целое: план счетов в QuickBooks становится свалкой автоматических категоризаций, выручка по Stripe и выручка по книге расходятся на возвраты и комиссии, и к series B компания нанимает контролёра, чья работа — руками сшивать швы конструктора. Момент, когда конструктор рвётся, хорошо изучен: мультивалютность, несколько юрлиц, признание выручки по контрактам (revenue recognition, ASC 606), потребность в консолидации — четыре всадника «переросли QuickBooks».

Путь третий, самый интересный для нашего курса, — осознанный конструктор с движком-надстройкой: те же дешёвые SaaS-примитивы, но поверх них — собственный тонкий слой оркестрации (в нашей терминологии — движок), который владеет сквозными идентификаторами, правилами и сверками, а SaaS-ы использует как исполнительные механизмы. Холдинговая специфика добавляет требование, которого нет ни в одном коробочном сценарии для малых команд: консолидация и intercompany между активами — и именно она обычно решает выбор в пользу пути три: дешевле построить тонкий консолидирующий слой над пятью дешёвыми книгами, чем загонять пять юрлиц в один тяжёлый ERP.

4.10. AI-native ERP и тезис «агенты вместо экранов»

Критика ERP-мышления стара как сам ERP. Ещё в 1998 году Томас Дэвенпорт в классической статье HBR «Putting the Enterprise into the Enterprise System» предупреждал: внедряя пакет, компания импортирует чужую логику ведения бизнеса, и для многих это плата за конформизм, а не за эффективность. Полвека спустя к идеологической критике добавилась интерфейсная: современный ERP — это сотни экранных форм, спроектированных для клерков, которых становится всё меньше; данные вводят люди, переносящие цифры из писем и PDF в поля форм, — и именно этот ручной ввод остаётся главным источником ошибок и затрат. Волна 2024–2026 годов атакует ровно эту точку.

AI-native ERP стартапы — уже не гипотеза, а профинансированная категория (все цифры ниже верифицированы по двум и более источникам на середину 2026 года). Campfire (Сан-Франциско) — AI-книга и ERP для стартапов, выигрывающий клиентов у NetSuite: $35 млн Series A от Accel (июнь 2025) и уже через четыре месяца $65 млн Series B — редкий темп, показывающий аппетит рынка. Rillet — AI-native главная книга для mid-market: $25 млн Series A от Sequoia (май 2025), $70 млн Series B от Andreessen Horowitz и ICONIQ (август 2025); тезис — автоматическое закрытие книг «за часы, не недели». Light (Копенгаген) — «AI-powered general ledger» для мультинациональных компаний: $13 млн сид, $30 млн Series A (сентябрь 2025); архитектурно интересен ставкой на единый глобальный ledger с локальными регуляторными представлениями. Doss — «adaptive resource platform», данные и операции mid-market: $18 млн Series A от Theory Ventures (апрель 2025). DualEntry — заявленные $90 млн Series A при оценке $415 млн (октябрь 2025; нетипично крупный для Series A раунд — непроверено в деталях) с обещанием миграции с легаси-книг «за 24 часа». Отдельная ветка — агенты поверх существующих ERP: от тестировщика изменений Opkey до армии стартапов, автоматизирующих ввод счетов и сверки в SAP/NetSuite, не претендуя на само ядро.

Общий тезис новой волны формулируется как «агенты вместо экранов ERP»: если данные рождаются в письмах, договорах и банковских выписках, то пусть их читает и превращает в проводки LLM-конвейер, а не человек за формой; экран остаётся только для исключений и утверждений. Инкумбенты отвечают тем же языком: SAP на Sapphire 2025–2026 продвигает Joule и сотни бизнес-агентов, обещая «autonomous enterprise», McKinsey публикует «The end of ERP as we know it», а скептики резонно замечают, что агент, кликающий по тем же транзакциям, — это автоматизация музея, а не новая архитектура. Трезвый взгляд на ограничения новой волны обязателен: молодые AI-книги пока закрывают учёт компаний со стандартной моделью (SaaS-выручка, немного юрлиц); им ещё предстоит пережить первую волну аудитов, регуляторных проверок и клиентов с грязными данными; и главный вопрос к ним — тот же, что к любому вероятностному слою: где проходит граница между «агент предлагает проводку» и «агент проводит документ». Лучшие из них отвечают канонически: LLM извлекает и классифицирует, но в книгу пишет детерминированный движок с правилами, а человек утверждает пороговые случаи — то есть под AI-фасадом живёт всё тот же Beleg-принцип. Это, пожалуй, центральный вывод раздела: новая волна меняет способ порождения документов, но не природу системы записи.

4.11. Уроки для проектирования с нуля: что взять, что оставить в прошлом

Подведём итог главы в форме, пригодной для технического задания. Пятьдесят лет ERP-истории оставили два наследства, и их надо разделить хирургически.

Обязательное ядро — то, что выстрадано и не зависит от того, кто оператор, человек или агент. Первое: документ как единственный носитель изменений. Всякий факт хозяйственной жизни входит в систему как типизированный документ с заголовком, позициями и ссылкой на родителя; состояние — вычислимая свёртка журнала; исправление — сторно, а не правка. Второе: проводка как атомарный транзакционный акт с встроенными инвариантами (баланс дебета и кредита, открытость периода, полномочия), выполняемая детерминированным кодом — никогда вероятностной моделью. Третье: статусная модель: каждый документ живёт в явном конечном автомате (черновик → проверен → проведён → закрыт/сторнирован), и все разговоры агентов о «состоянии дел» — это запросы к статусам, а не мнения. Четвёртое: аудит-трейл по построению: кто (какой агент, какой версией промпта, на каком основании) создал и провёл каждый документ — неотъемлемые атрибуты записи; в безлюдной компании аудит-трейл становится ещё важнее, потому что спросить «а почему ты так сделал?» у уволившегося клерка нельзя было и раньше, а у перезапущенного агента — тем более. Пятое: оргструктура и мастер-данные как медленные данные с governance-процессом, версионированием и человеческой подписью на изменениях. Шестое: сверка с внешним миром (банк, налоговая, контрагенты, платёжные системы) как ежедневный автоматический ритуал — единственная защита от тихого расползания модели и реальности.

Наследие эпохи экранных форм — то, что можно и нужно оставить в музее. Экранные транзакции и «роли пользователей» как первичный интерфейс — агентам нужны API, события и документные схемы; интерфейс для человека остаётся только на исключениях и утверждениях. Пакетная обработка по расписанию (ночные джобы, месячное закрытие как событие) — рудимент дорогих вычислений; движок живёт в режиме continuous close. Монолитная связность «всё в одной базе» как догма — при дисциплине сквозных идентификаторов и сверок ядро может быть маленьким, а периферия — сменной. Армия консультантов и многолетний проект внедрения — следствие того, что конфигурация была закрытым искусством; в движке, где конфигурация — читаемые машиной декларации, её пишет и проверяет тот же класс агентов, что и исполняет. И наконец, само слово «внедрение»: у компании, спроектированной вместе со своей системой записи, внедрения не бывает — бывает рождение.

Формула главы, которую мы унесём в синтез: безлюдный бизнес-движок — это система записи ERP-строгости, у которой слой вовлечения заменён API и событиями, а слой интеллекта — заселён агентами. ERP-канон отвечает на вопрос «что есть истина о предприятии и как она меняется»; всё остальное в этом учебнике — о том, кто и как с этой истиной работает.

Источники и куда копать глубже