Verify and Do Not Retire. Почему SAP - говно

## 1. Что в SAP незаменимо, если убрать придыхание

**Вопрос:** Если проанализировать SAP без придыхания — с точки зрения системы, основополагающие столбы которой можно или нельзя заменить конкурентами с меньшей стоимостью поддержки, покупки и развёртывания — то что существенное и незаменимое от неё останется?

**Поправка категории (определяет весь ответ):** SAP — не СУБД и не CRM. Это ERP-ядро (исторически R/3, сейчас S/4HANA). СУБД у неё под низом (раньше Oracle/DB2, теперь своя HANA), CRM — один из боковых модулей. Дешёвые конкуренты существуют почти для каждого *модуля* по отдельности. Незаменимое — не в модулях.

**Что заменяется легко (и потому не столб).** База данных — заменяема, это давно товар. Отдельные функции — склад, расчёт зарплаты, CRM, закупки, BI — у каждой есть более дешёвый специализированный конкурент, часто лучше самой SAP в своей нише. UI, отчётность, workflow — тоже. Если бы SAP был суммой модулей, он бы уже проиграл по цене везде.

**Столб 1. Единая транзакционная модель данных, где всё сходится на одной проводке.** Незаменимое — не таблицы, а то, что заказ на продажу, движение склада, бухгалтерская проводка, налог, себестоимость и управленческий учёт — это *одно* событие в одной согласованной модели, а не пять систем, которые потом сверяют. Лоскут из дешёвых лучших-в-классе систем эту согласованность теряет и платит за неё вечной интеграцией и сверками. Это single-source-of-truth, поднятый на уровень всего предприятия. Заменить можно каждую деталь; нельзя дёшево заменить *свойство «всё бьётся в одной точке»*.

**Столб 2. Воплощённый процесс и compliance — десятилетия edge-case'ов.** Внутри SAP зашиты налоговые режимы десятков юрисдикций, отраслевые регламенты, аудиторские следы, разделение полномочий, требования регуляторов. Это не код, который можно переписать за квартал — это накопленный реестр того, «как именно нельзя ошибиться», оплаченный чужими авариями. Это `safety-invariant`-слой, а не `compensating`. Он родился реактивно, выглядит как раздутость, но стережёт катастрофические отказы — провал аудита, штраф регулятора, остановку отгрузок. Дешёвый конкурент дёшев ровно потому, что эту цену ещё не заплатил.

**Столб 3. Switching cost как актив — но это столб клетки, а не ценности.** Процессы предприятия переписаны *под* SAP, обучены тысячи людей, интеграции, кастомизации, риск миграции измеряется остановкой бизнеса. Реальный столб, но честный анализ обязан отделить его от первых двух: столбы 1 и 2 — ценность, которую дорого воспроизвести; столб 3 — издержки выхода, которые дорого *понести*. Vendor lock-in — не доказательство ценности, это его маскировка.

**Сухой остаток.** Если обнулить switching cost, по-настоящему незаменимым осталось бы ровно одно: **согласованная сквозная модель данных предприятия плюс воплощённый compliance** (столбы 1+2). Всё остальное — БД, модули, UI, аналитика — заменяемо дешевле и часто лучше. Оставшееся незаменимое — это *не* функции, а два свойства: «всё сходится в одной точке» и «накопленная защита от редких дорогих отказов». SAP дорог не потому, что делает много; он дорог потому, что эти два свойства по природе нельзя купить дёшево — их можно только накопить и сцентрализовать, а это берёт годы и аварии.

**Оговорка:** это структурный разбор, а не оценка «брать/не брать». Для многих средних бизнесов оба столба избыточны, и тогда лоскут из дешёвых систем объективно выигрывает.

---

## 2. Сквозная согласованность: почему она недостижима в QuickBooks

**Вопрос:** Подробнее про сквозную согласованность. Почему это недостижимо в QuickBooks или системах, поддерживающих слой истины через связность транзакций в US GAAP-датафрейме — баланс, P&L, cash flow, интегрированный со складским учётом?

**Должное рамке:** QuickBooks **имеет** слой истины. Три отчёта в нём articulate — баланс, P&L и cash flow сходятся через двойную запись, склад привязан к GL через perpetual inventory. Вопрос не «есть ли согласованность», а **какого она охвата**.

**Ключ — инверсия первичного объекта.**
- В QuickBooks первичен финансовый документ (счёт, проводка, bill). Операционная реальность висит на нём атрибутами. Баланс — система записи, операции описаны ровно настолько, чтобы баланс получился.
- В SAP наоборот: первичен **операционный документ** (movement материала, производственный заказ, отгрузка), а проводка — его *производное следствие* по конфигурируемому account determination. Операционная реальность — система записи, отчёт — её проекция.

Двойная запись механически гарантирует, что три отчёта между собой бьются — это **дешёвая** согласованность, встроенная в арифметику дебет=кредит. Дорогая согласованность — между отчётом и **операционной реальностью**, через субледжеры, юрлица и валюты. Её QuickBooks не держит — не потому что плохо сделан, а потому что **не моделирует операционный слой достаточно глубоко, чтобы там вообще могла возникнуть рассогласованность**. Это согласованность через *неполноту*: нечему противоречить, потому что детали нет.

Где это вскрывается:

1. **Трёхсторонний матч.** Заказ-поставщику ; приёмка ; счёт. В SAP инвойс не проведётся, если не сматчился с PO и приёмкой в допуске, GR/IR-счёт авто-расчищается. В QuickBooks bill можно завести без связи с тем, приехал ли товар. Баланс может быть финансово корректен и операционно лжив.

2. **Глубина себестоимости.** US GAAP-методы (FIFO/LIFO/средневзвешенная) QuickBooks умеет. Чего нет: standard costing с разложением отклонений (PPV/usage/mix), material ledger с actual costing через многоуровневый BOM, split valuation. Для производителя «интегрированный» COGS в QuickBooks — приближение, а не выводимая истина.

3. **Проблема субледжера — сердце слоя истины.** В SAP AR/AP/основные средства/material ledger — отдельные субледжеры, каждый держит детализацию и в реальном времени сходится с reconciliation-счётом GL. В QuickBooks AR/AP — скорее представления поверх той же книги. На миллионах открытых позиций, частичных оплатах, валютной переоценке именно *инженерная гарантия сверки субледжера с GL* стоит денег и отсутствует.

4. **Cash flow — самый острый пример.** QuickBooks строит его косвенным методом: трансформирует P&L и дельты баланса. Это реконструкция из двух других отчётов, всегда «сходится» — и потому операционно плоская. Не скажет денежный поток по продуктовой линии/проекту/объекту затрат. SAP может — потому что измерения (cost center, profit segment, project) прикреплены к документам в момент события, а не восстанавливаются задним числом.

5. **Мульти-юрлицо / интеркомпани.** QuickBooks одноюрлицов. Продажа A;B требует: продажу в A, закупку в B, элиминацию, трансфертную цену, консолидированный cash flow после элиминаций — связанно. QuickBooks не моделирует интеркомпани как одну истину; прикручивается консолидационный инструмент и ручная сверка. SAP моделирует связанными документами — элиминации выводятся.

**Тезис.** QuickBooks гарантирует согласованность, держа домен маленьким (три отчёта, одно юрлицо, финансовая гранулярность). SAP гарантирует над гораздо большим доменом (операции + финансы + субледжеры + юрлица + валюты + глубина костинга). Незаменимо в SAP **расширение домена single-source-of-truth до масштаба, где он перестаёт быть дешёвым**. QuickBooks — тоже single-source-of-truth, просто над доменом, маленьким настолько, что согласованность достаётся почти бесплатно.

---

## 3. Идеологический риск: топят ли крупные учётные системы экономику

**Тезис владельца:** Рост компании ведёт к деградации качества управления. В SAP заложена бомба — он подталкивает компанию к неограниченному росту, поскольку инфраструктурно для этого всё предусмотрено. И нет механизмов, сигнализирующих, что система начала пожирать саму себя. Аналог — налоговое законодательство Канады: разбухло так, что расходы на поддержание системы налогообложения сжирают бонусы от корректности следования её правилам. В остатке: SAP хорош, но Германия — в жопе.

**Хребет верен — это Коуз.** Фирма растёт, пока стоимость внутренней координации не сравняется со стоимостью рыночной сделки. ERP обрушивает стоимость внутренней координации ; двигает наружу эффективную границу фирмы. SAP буквально позволяет компании быть больше, чем она управлялась бы без него. Природная диз-экономия масштаба, которая раньше сама тормозила рост на пороге управляемости, у SAP-фирмы анестезирована.

**Механизм, который «не виден», — есть, но того же типа, что слепое пятно QuickBooks.** Сигнал «качество управления деградирует» живёт в домене, который SAP не моделирует. SAP гарантирует согласованность внутри своего домена: транзакции бьются, всё зелёное. А «фирма переросла управляемость» — не транзакция, не объект модели данных. Система физически не может показать этот отказ — нет поля под него. Деградацию ловит боль (падающий ROIC, маржа) — но боль приходит **снаружи** и **с лагом**, через финрезультат, тогда как операционное ядро рапортует green. Это асимметрия сигнала: провал ловится, перерост — нет, by design.

**Сильная форма тезиса: у SAP нет verify-or-retire на организационном уровне.** Вся машина — promotion ladder вверх: добавить юрлицо, модуль, дивизион, страну — для всего предусмотрена инфраструктура. Обратной ступени — «эта часть фирмы переросла управляемость, свернуть scope» — в идеологии системы нет. «Бомба» названа точно: не раздутость сама по себе, а **отсутствие нисходящего рельса** при идеально смазанном восходящем.

**Усиление (пропущенное в исходном тезисе) — захваченная петля обратной связи.** Налоговая сложность разбухает не случайно: у неё внутренний бенефициар — индустрия комплаенса, кормящаяся сложностью и лоббирующая её. У SAP-сложности аналог — имплементационно-консалтинговый комплекс. Те, кто *должен бы* сказать «слишком сложно, сверните» — ровно те, кто зарабатывает на том, что сложно. Механизм торможения не просто отсутствует — он **выкуплен**.

**Точка перегиба — финальный прыжок «Германия в жопе» не следует из посылок.**
- SAP **permissive**, а не **forcing**. Он снимает потолок, но не толкает. Толкают капитал-рынок, бонусы за размер, империастроительство CEO. SAP — соучастник и анестезиолог, не водитель. Лекарство разное: ограничивать надо incentives, а SAP — перестать читать как доказательство здоровья.
- Категориальный перепрыг с микро (граница фирмы) на макро (ВВП страны). На макро доминируют энергия, демография, Китай, проспанный переход в авто.

---

## 4. Проверка фактами: буксуют ли SAP-насыщенные гиганты

**Вопрос:** Раскрой тезис «SAP-насыщенные DAX-гиганты (авто, химия, банки) — та часть, что сейчас буксует».

**Проверено веб-поиском на 31 мая 2026 — и тут понадобилась коррекция предыдущего хода.**

**Тезис про гигантов подтверждается жёстко.** SAP-насыщенное ядро (автопром, химия) в структурном кризисе. VW режет 35 000 рабочих мест в core-бренде и до 50 000 к 2030, переносит Golf в Мексику; Bosch, MAN, Salzgitter — сокращения; BASF — массовые увольнения и вывод мощностей из Германии. За I квартал 2026 страна потеряла 486 000 рабочих мест; 4 из 10 промышленных компаний планируют сокращения в 2026. Это профиль, под который ERP-сквозная согласованность и создавалась.

**Но причинная стрелка на SAP — снимается (отзыв ленивого хода).** Гиганты буксуют по причинам, к SAP отношения не имеющим: цена энергии после отрезания от российского газа, проспанный переход на EV, экспозиция на Китай (из покупателя стал конкурентом). SAP — не причина болезни, в лучшем случае **анестетик**: позволял структурам разрастись до текущего размера, рапортуя green, и не дал нисходящего сигнала «вы переросли управляемость». Но спусковой крючок внешний. Приписать падение ERP-системе — тот самый категориальный перепрыг.

**«Mittelstand цветёт» — свежими данными опровергается.** Структурные преимущества реальны (;; немецкого экспорта, низкий долг, реинвест вместо роста-в-кредит, исторически стабильнее в Great Recession). Но в 2025-26 им тоже плохо: банкротства +8,3% за 2025 (~23 900 фирм), >80% — малые компании до 10 человек. CBAM добивает именно SME. «Лин-в-нише цветёт, пока жирные тонут» — ложная симметрия. Тонет вся обрабатывающая база; крупные — громко и заголовками, малые — тихо и массово.

**Честный остаток.** Различие Mittelstand vs DAX-гиганты — **не** «здоров/болен», а **тип уязвимости**. Mittelstand страдает от **внешних** ударов (энергия, CBAM, спрос) — раны снаружи на здоровом теле. Гиганты страдают от внешних ударов **плюс** собственной разросшейся неуправляемости, которую ERP-инфраструктура позволила накопить, ничего об этом не сигналя. SAP не *топит* гигантов — но он причина, по которой у гиганта **нет внутреннего тормоза**, и удар снаружи он встречает переразмеренной структурой без нисходящего рельса. Тезис «отсутствует verify-or-retire на организационном уровне» переживает проверку фактами, в отличие от надстройки про «цветущий Mittelstand».

**Сухой остаток.** Верная часть интуиции — *не* «SAP топит экономику» и *не* «маленькие выигрывают у больших». Верная часть единственная и точная: **координационная технология даёт восходящий рельс без нисходящего, поэтому крупная фирма встречает внешний шок переросшей и без встроенного сигнала об этом.** Всё остальное — макро, и там правят энергия, Китай и углеродное регулирование, а не модель данных.

**Источники (проверка макро-фактов):**
- [Volkswagen to cut 35,000 jobs, shift Golf production to
- [Crisis in German industry deepens on Volkswagen, Bosch cuts (Detroit
- [Germany lost 486,000 jobs in Q1 2026 (Pravda - [Is the German Mittelstand more resistant to crises? (Small Business Economics, - [German economy 2025: analysis of the crisis (Markus
- [How Germany's Family Firms Power The
---

## 5. Транзакционность: можно ли дотыкаться до детализации любого уровня

**Вопрос:** Правильно ли понял про транзакционность SAP — могу ткнуть в любой леджер, посмотреть, из каких транзакций он собран, и далее, тыкая по каждой, дойти до детализации любого уровня, включая накладную по доставке материала и фамилию водителя грузовика?

**Концептуально — да; практически — с двумя оговорками.**

**Механизм реален — drill-down через document flow.** Тыкаешь в строку GL ; бухгалтерская проводка ; ссылка на исходный документ (material document приёмки, отгрузка, инвойс) ; по цепочке document flow назад: счёт поставщика ; приёмка ; заказ поставщику ; заявка. Это следствие инверсии: проводка производна от операционного документа и хранит ссылку на родителя. Каждая сумма прослеживается до породившего её физического события.

**Оговорка 1 — граница по линии «материальное vs финансовое».** Накладная на доставку, номер партии, серийный номер, дата/место приёмки, склад, количество — **внутри** домена SAP, дотыкаешься. Фамилия водителя — **почти наверняка нет**: это не объект финансово-операционной модели, а деталь логистического исполнения; живёт в системе перевозчика (TMS) и попадает в SAP только при специально настроенной интеграции. По умолчанию цепочка истины SAP кончается там, где кончается **его** домен: «материал X, партия Y, принят в количестве Z на склад W такого-то числа по delivery note N». Чтобы фамилия водителя оказалась в drill-down, домен должен быть расширен интеграцией — «кто-то заплатил за расширение домена».

**Оговорка 2 — теоретическая прослеживаемость ; практическая.** Цепочка цела ровно настолько, насколько дисциплинированно её вводили. Приёмка «оптом» без привязки к PO, ручная корректирующая проводка прямо в GL в обход операционного документа, миграция суммами без истории, summarization ради производительности — на этом узле document flow обрывается. Дотыкаешься до «корректировка 40 000 €, провёл бухгалтер, причина: reclass» — и дальше физической детали нет, потому что её и не было в момент ввода.

**Точный ответ:** *способность* провалиться до материальной детализации — да, архитектурное свойство, настоящее. *Фактическая* глубина в конкретной точке зависит от того, ввели ли данные чисто или срезали угол — а в реальной компании углы срезаны во множестве мест. Граница в любом случае по краю домена предприятия: до delivery note и партии — да; до человека за рулём — только за отдельную интеграцию.

---

## 6. Слепое пятно: контроль смысловой связности при раздувании доменов

**Вопрос (дословно):**

> Ага. Вот тут то я тебя и поймаю за хвост.
> *SAP кончается там, где кончается его домен: «материал X, партия Y, принят в количестве Z на склад W такого-то числа по delivery note N». Кто физически крутил руль — за границей модели.*
> В реальности ЛЮБАЯ организации стремится к неконтролируемому росту границ доменов контроля. Все известные мне разработчики этим и заняты — они до бесконечности добавляют в систему *новые поля* — с условными именами водителей грузовиков.
> А есть ли в Сапе внутренний механизм контроля за тем, чтобы раздувание доменов управляющими кластеров в этой системе не превращалось в ненужную бессмыслицу — либо груз, теряющий осмысленность из-за горизонтальной несогласованности.

**Прямой ответ: нативного механизма контроля за смысловой связностью у SAP нет.** Есть три похожих, и ни один не делает названного.

**1. Управление формой добавления — но поощряет добавление, а не тормозит.** Доктрина «clean core» в S/4HANA: кастомные поля и логику велят выносить наружу, в side-by-side расширения (BTP). Звучит анти-раздувающе, но это ловушка: clean core борется с раздуванием, ломающим **апгрейдоспособность**, а не спрашивает «нужно ли поле вообще». Он делает бесконечное добавление более аккуратным и потому устойчивым. Рельс, смазывающий восходящее движение, а не нисходящий тормоз. Водитель грузовика в чистеньком BTP-расширении проживёт вечно и переживёт каждый апгрейд.

**2. Управление качеством мастер-данных — про дубликаты, не про смысл.** SAP MDG следит, чтобы не было трёх карточек одного поставщика, чтобы поля заполнялись по правилам. Это гигиена *значений* внутри полей. Осмысленно ли само *поле* — не спрашивает. Поле может быть идеально чистым по MDG и быть мёртвым грузом.

**3. Единственное близкое — но это агрегатор без петли суждения.** Usage & Procedure Logging (UPL) и Custom Code Lifecycle Management измеряют, что из кастомного кода/полей фактически не используется. Настоящий retirement-сигнал: «это Z-поле никто не читал 18 месяцев». Но это report-only список кандидатов без лестницы, классификации и owner-routed снятия; опционален, по умолчанию выключен; и ловит только **«не используется»**, а не **«используется, но потеряло смысл»**.

**Худший случай — горизонтальная несогласованность — невидим для всех трёх разом.** Поле, которое активно пишут и читают, но которое разные кластеры заполняют по разошедшимся смыслам: «приоритет доставки» у логистики — срочность, у продаж — маржинальность клиента, у склада — третье. UPL: green (используется интенсивно). MDG: green (значения валидны). Clean core: green (лежит правильно). Все три рельса зелёные — а поле уже **груз, потерявший осмысленность из-за горизонтального расхождения**. Никто не следит, потому что «смысл поля относительно других полей» — не объект модели данных SAP. Слепое пятно того же типа, что «фирма переросла управляемость»: реальность, для которой в схеме нет поля.

**Замыкание круга.** SAP воспроизводит на уровне собственной схемы ту же патологию, которую создаёт на уровне фирмы. **Восходящий рельс смазан и трижды охраняется (clean core, MDG, extensibility framework); нисходящего рельса — суждения «это поле стало бессмыслицей, снять» — нет.** Есть измерительный примитив (UPL), но он ловит «мёртвое», а не «гниющее», и не подключён ни к какой петле снятия. Бенефициар раздувания тот же: разработчики и консультанты, которые «до бесконечности добавляют новые поля» — те самые, кто *должен бы* сказать «хватит», и именно они кормятся тем, что не говорят.

Иными словами: то, чего у SAP нет для самого себя, — это нисходящий рельс. Verify-or-retire с тройной таксономией и планкой стресс-доказательства — в точности недостающий механизм. SAP его не имеет — поэтому любой достаточно старый SAP-ландшафт превращается в музей полей, каждое из которых когда-то что-то значило.