Более 70% недавно внедренных ERP-инициатив не достигнут в полном объеме первоначальных бизнес-целей — такую оценку дает Gartner на горизонте до 2027 года (Gartner, «What IT Leaders Must Do to Avoid Disappointing ERP Initiatives», аналитик Denis Torii). Причина редко бывает в самом продукте. Масштабируемость ERP-системы закладывается на этапе выбора платформы и модели кастомизации — за годы до того, как компания почувствует боль. Ниже — шесть архитектурных решений, которые определяют, выдержит ли ваша система удвоение объемов, покупку нового юрлица или выход в новую страну. Каждое из них дешево принять на старте и дорого переиграть на третий год.

Business Central online имеет жесткие количественные границы, и Microsoft описывает их открыто. В одном окружении может существовать максимум 300 компаний. База данных одного окружения вмещает до 3 ТБ сжатых данных вместе с индексами и BLOB.

Емкость хранения рассчитывается по другой логике — 80 ГБ на тенант по умолчанию плюс надбавка за каждую лицензию: 3 ГБ за Premium, 2 ГБ за Essential, 1 ГБ за Device. Этот объем общий для всех окружений тенанта. Превышение квоты не прерывает проведение транзакций в существующих окружениях — но блокирует создание новых окружений и копирование существующих, пока вы не освободите место или не докупите емкость.

Для компании с одним юридическим лицом эти цифры выглядят недостижимыми. Для дистрибуционного холдинга, который каждый год добавляет три-пять юрлиц и открывает новый рынок, картина иная: ограничение на количество компаний в окружении превращается в вопрос нарезки ландшафта еще до первой миграции данных. Finance & Operations строился вокруг другой модели — юридические лица внутри одного приложения со сквозными финансовыми аналитиками. Выбор между двумя продуктами — это выбор профиля нагрузки на пять лет вперед, а не сравнение списков функций. Детальное сравнение — в материале Business Central или Finance & Operations.

Самые дорогие доработки — не те, что стоили больше всего в разработке, а те, что сделаны вопреки модели расширяемости платформы.

В Finance & Operations выбора уже нет. Оверлеинг кода Microsoft не поддерживается; начиная с версии 8.0 все модели приложения hard-sealed, и попытка перекрыть стандартный код дает ошибку компиляции. Единственный поддерживаемый механизм — расширения. В Business Central доработки живут как per-tenant extensions или аппы из AppSource, и Microsoft прямо возлагает на партнера-разработчика ответственность за соответствие кода релизному ритму продукта.

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

Ритм обновлений Finance & Operations задает Microsoft, а не проектная команда. Клиент может взять до четырех сервисных обновлений в год, как минимум два из них обязательны, а пауза берется по одному обновлению за раз. Два из ежегодных обновлений — крупные релизы, привязанные к весенней и осенней релизным волнам; остальные несут преимущественно платформенные и регуляторные изменения. Обновления обратно совместимы, поэтому сливать код не требуется.

Для каждого обновления Microsoft дает два окна автообновления с разницей в четыре недели — выбор между ними и есть ваш бюджет на валидацию. Дальше арифметика проста. Объем кастомного кода прямо конвертируется в объем регрессионного тестирования, и делать его приходится несколько раз в год, а не раз в три года. Архитектура с 200 часами доработок и архитектура с 2 000 часами одинаково хорошо выглядят на демонстрации — и дают разную стоимость владения на горизонте трех лет.

Вопрос «сколько мы кастомизируем» должен задаваться в паре с вопросом «кто и чем будет проверять это ежеквартально».

Классический симптом выхода за пределы архитектуры — мастер-планирование, которое не успевает отработать до утра. Microsoft решил это не наращиванием мощности, а переносом нагрузки: расчет мастер-планирования выполняется вне Supply Chain Management и ее базы данных SQL. Встроенный движок мастер-планирования выведен из эксплуатации.

Следствие для планировщиков конкретное. Прогоны больше не привязаны к ночному окну — их можно запускать в рабочие часы и реагировать на изменение спроса в тот же день.

Остальные узкие места остаются на стороне проектирования, и указания Microsoft здесь тоже однозначны: более короткие транзакции уменьшают эскалацию блокировок и повышают количество одновременно работающих пользователей; с ростом объема данных систему приходится донастраивать, чтобы удержать то же время отклика. Вторая формулировка стоит перечитывания. Время отклика не держится само — его держат, и эту работу нужно закладывать в модель эксплуатации сразу, а не тогда, когда начнут жаловаться пользователи.

Каждый процесс, дописанный в ядро ERP, увеличивает стоимость следующего обновления. Поэтому вопрос не в том, автоматизировать ли новый процесс, а в том, в каком слое он должен жить.

Dual-write дает тесно связанную двунаправленную интеграцию near-real-time между Finance & Operations и Dataverse: изменение в приложении F&O записывается в Dataverse, изменение в Dataverse — обратно. Это открывает отдельную поверхность для развития: процессы, которые раньше пришлось бы реализовывать внутри ERP, строятся на Power Platform поверх тех же данных.

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

Выход в новую страну ломает архитектуру тогда, когда под локальные требования создают отдельную систему или отдельный форк конфигурации.

Microsoft поставляет локализацию не для всех рынков. Там, где не поставляет, локализацию строят партнеры — аппами поверх международной версии продукта. Модель слоистая, и это принципиально: локальные требования живут отдельно от ядра и отдельно от кастомизации клиента.

Украинская локализация OntargIT построена именно так: базовая функциональность Dynamics 365, поверх нее пакет локализации Microsoft для Восточной Европы, далее пакет для Украины, и уже потом кастомизация под конкретного клиента. Каждый слой обновляется собственным циклом.

Ни одно из шести решений выше не является технически сложным в момент принятия. Сложным становится их отмена. Компания, выбравшая платформу под сегодняшний профиль нагрузки, сделавшая доработки в обход модели расширений и вынесшая новые процессы в ядро вместо Dataverse, получит счет не сразу — а тогда, когда появится новое юрлицо или новый рынок. Проверьте действующую архитектуру против этих шести пунктов. Если ответ хотя бы на два из них непонятен, начните с ERP-аудита, а не с нового проекта.