Понад 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-аудиту, а не з нового проєкту.