Головне, що змінилося порівняно зі старими системами
Коротка відповідь. У Business Central доробки не змінюють саму систему. Вони живуть окремо — як розширення, написані мовою AL. Саме тому оновлення від Microsoft двічі на рік не перетворюються на проєкт.
У локальних системах попереднього покоління доробка правила конфігурацію, і кожне оновлення означало ручне злиття змін. Через кілька років компанія просто переставала оновлюватися — оновлення коштувало дорожче за користь. Розширення цю проблему знімають, але не роблять доробки безкоштовними.
Чому кожна доробка коштує двічі
Перша вартість очевидна — розробка. Друга проявляється через півроку.
| Стаття | Коли виникає | Що впливає на суму |
|---|---|---|
| Розробка | Одразу | Складність логіки, кількість зачеплених процесів |
| Тестування | Одразу | Скільки сценаріїв треба перевірити |
| Супровід оновлень | Двічі на рік | Кількість розширень і глибина втручання |
| Доопрацювання | При зміні процесів | Наскільки код прив'язаний до конкретного сценарію |
Третій рядок — той, який не закладають у бюджет. Microsoft випускає два великі релізи на рік, і кожне розширення перевіряється на сумісність. Одна невелика доробка — це кілька годин двічі на рік. П'ятнадцять доробок — це вже постійна стаття витрат, порівнянна з підтримкою.
Критерії: коли доробка справді потрібна
Робоче правило: доробка виправдана, якщо процес дає конкурентну перевагу й не закривається стандартом. Усе інше — привід переглянути процес, а не писати код.
| Ситуація | Рішення | Чому |
|---|---|---|
| Процес унікальний і приносить гроші | Доробка виправдана | Це ваша перевага, підлаштовуватися під стандарт немає сенсу |
| Друкована форма під вимоги контрагента | Доробка виправдана | Дешево, ізольовано, не зачіпає логіку |
| Інтеграція з банком, сайтом, обладнанням | Зазвичай виправдана | Часто є готові рішення — спершу перевірити ринок |
| «У нас завжди так робили» | Спершу перегляньте процес | Часто звичка, а не потреба; стандарт може бути кращим |
| Зручніше розташувати поля | Не потрібна | Персоналізація сторінок робиться налаштуванням |
| Нестандартний звіт | Часто не потрібна | Перевірте фінансові звіти, розмірності й Power BI |
Ознака здорового проєкту: 80–90 % процесів закриваються стандартом. Якщо доробок більше — питання не до системи, а до того, чи правильно вона обрана під ваші задачі.
Що замовнику варто знати про технічний бік
Не для того, щоб писати код, а щоб ставити правильні питання підряднику.
- Розширення ізольовані. Одне не може зламати інше й не змінює базові об'єкти системи.
- Код можна прочитати. AL — звичайна мова програмування, будь-яка компетентна команда розбереться в чужому розширенні.
- Розробка ведеться в окремому середовищі. Тестова база відокремлена від робочої, тому експерименти не зачіпають продакшн.
- Пісочниця безкоштовна. Перевірити ідею можна без ліцензійних витрат.
Головне питання підряднику звучить так: чи залишиться у нас вихідний код розширень. Відповідь «ні» означає, що змінити підрядника ви не зможете без переписування доробок з нуля.
Як зменшити вартість володіння кастомізацією
- Спочатку запустіть стандарт. Половина «обов'язкових» доробок відпадає, коли команда попрацює місяць у системі.
- Фіксуйте, який процес закриває кожна доробка. Через рік буде видно, які з них уже не потрібні.
- Не дублюйте стандартний функціонал. Найдорожчі доробки — ті, що повторюють наявне, але «зручніше».
- Розділяйте великі розширення на малі. Дрібні простіше перевіряти при оновленнях і дешевше змінювати.
- Закладайте супровід у бюджет одразу. Двічі на рік розширення потребують перевірки — це не непередбачені витрати, а норма.
Часті запитання
Чи ламають доробки оновлення Business Central?
Ні. Розширення на AL живуть окремо від базової системи й не блокують оновлення. Але після кожного великого релізу їх перевіряють на сумісність — це закладається в підтримку.
Скільки коштує кастомізація?
Залежить від складності логіки й кількості зачеплених процесів. У структурі бюджету впровадження кастомна розробка займає від 0 до 25 %: нуль, якщо все закривається стандартом, чверть — якщо процеси справді нетипові.
Чи можна обійтися зовсім без доробок?
У багатьох компаніях так, особливо в торгівлі та послугах зі стандартними процесами. Персоналізація сторінок, розмірності й фінансові звіти закривають більшість запитів без коду.
Як зрозуміти, що доробок забагато?
Орієнтир простий: якщо стандартом закривається менше 80 % процесів, це сигнал перевірити, чи правильно обрана система або чи не намагаєтесь ви відтворити в ній логіку старої.
Чи потрібен власний розробник у штаті?
Для більшості компаній ні. Розширення розробляє й супроводжує партнер, а всередині достатньо людини, яка розуміє процеси й може сформулювати задачу.
Хочете навчитися це налаштовувати?
Ця стаття пояснює логіку й типові помилки. Розробку розширень: об'єкти, таблиці, сторінки й публікацію в середовищі — розбираємо на курсі «Базове програмування мовою AL». Заняття онлайн у режимі реального часу, з розбором ваших робочих ситуацій.
Ця стаття входить до добірки Розробка та кадровий облік — там зібрано повний розбір теми та решта матеріалів.