Надмірна кастомізація Odoo: коли доробки вбивають проєкт і бюджет

Бажання отримати в Odoo «усе як у старій системі» або «саме так, як ми завжди робили» часто призводить до великого обсягу доробок. В результаті бюджет роздувається, терміни зсуваються, а підтримувати та оновлювати кастомний код стає дорого і ризиковано. У цій статті — чому «зробити як у старій системі» є ризиком, навіщо спочатку стандарт і лише потім кастом, як оцінити реальну потребу в доробках і як скоротити кастом без втрати необхідного функціоналу.

Чому «зробити як у старій системі» — ризик

Старі процеси могли бути неоптимальними. Той факт, що щось робили в 1С або Excel певним чином, не означає, що так і потрібно в Odoo. Часто це лише звичка. Копіювання таких процесів у нову систему заморожує старі проблеми і додає технічний борг.

Висока вартість підтримки. Кожна доробка Odoo потребує тестування при оновленнях платформи. Якщо кастомних модулів багато, оновлення версії Odoo стає дорогим і небезпечним. Частина інтеграторів взагалі не береться підтримувати сильно перероблені бази.

Залежність від тих, хто писав код. Якщо логіка розкидана по власних модулях, при зміні підрядника або відході розробника нова команда довго розбиратиметься. Надмірна кастомізація знижує можливість передати проєкт іншому інтегратору.

Роздутий scope і строки. Кожна «а давайте ще так» додає години роботи. Без жорсткого фільтра «це дійсно потрібно для запуску» проєкт розростається і ніколи не закривається вчасно.

Стандарт спочатку, кастом — за потреби

Спочатку використати стандартні можливості Odoo. Більшість потреб закриваються налаштуванням полів, прав, workflow і стандартних звітів. Перед тим як замовляти розробку, варто перевірити: чи не можна досягти того ж через конфігурацію без написання коду.

Доробки — лише там, де без них не обійтися. Наприклад, інтеграція з українським сервісом, якої немає в стандарті, або специфічний звіт за законодавством. У такому випадку кастом має бути чітко описанений, оцінений і зафіксований у ТЗ.

Принцип мінімуму змін. Чим менше власного коду, тим простіше оновлення та підтримка. Якщо одну і ту ж задачу можна вирішити стандартним модулем або невеликою доробкою — краще другий варіант лише за наявності обґрунтування.

Як оцінити реальну потребу в доробках Odoo

Чітко сформулювати бізнес-вимогу. Не «зробити як у 1С», а «менеджер має вибирати з списку тільки ті товари, які дозволені для цього клієнта за договором». Після цього можна перевірити: чи є в Odoo права, фільтри, або продуктові шаблони, які це вже закривають.

Перевірити маркетплейс та готові модулі. Багато «доробок» вже реалізовані в Odoo Apps або партнерських рішеннях (наприклад, інтеграція з Нова Пошта, ПРРО). Купити та налаштувати готовий модуль часто дешевше і безпечніше, ніж писати свій.

Оцінити вартість володіння. Доробка — це не лише розробка, а й тести, документація, підтримка при оновленнях. Перед прийняттям рішення варто оцінити сумарні витрати на 1–2 роки. Іноді простіший процес (без доробки) виявляється вигіднішим.

Як скоротити кастом без втрати функціоналу

Переглянути список доробок. Після аудиту конфігурації часто виявляється, що частину «обов’язкових» кастомів можна замінити налаштуванням або зміною процесу. Проведіть переоцінку кожного пункту: чи дійсно без цього неможливо працювати.

Фазувати. Що потрібно до go-live, а що можна зробити у другій фазі після запуску? Запуск на стандарті з мінімумом доробок дає швидший результат; додаткові зручності можна впроваджувати поступово, коли буде видно реальне використання.

Документувати та зберігати код централізовано. Якщо доробки залишаються — вони мають бути в репозиторії, з описом та тестами. Це дозволяє новому інтегратору або підтримці швидше розібратися і не дублювати розробку.

Реальні приклади: коли кастом виявився зайвим

Кастомний модуль ціноутворення. Компанія замовила розробку складного модуля знижок, бо «в 1С так було». Після аналізу виявилося, що стандартний Odoo Pricelists покриває 90% сценаріїв. Кастомний модуль обійшовся в 3× дорожче і ускладнив оновлення.

Кастомний звіт по залишках. Замовник хотів звіт у специфічному форматі Excel. Розробка зайняла 2 тижні. Через рік при оновленні Odoo звіт перестав працювати і потрібна була повторна розробка. Альтернатива — стандартний звіт з фільтрами або простий Excel-експорт.

Кастомний workflow затвердження. Замовник хотів 5-рівневе затвердження замовлень. Після запуску виявилося, що 80% замовлень проходять лише 2 рівні. Стандартний Odoo Approval покрив би більшість кейсів без розробки.

Висновок: перед замовленням будь-якої доробки варто провести демо стандартних можливостей Odoo з реальними сценаріями вашого бізнесу. Часто «кастом» виявляється непотрібним після 30-хвилинного показу стандарту.

Як управляти кастомізацією в довгостроковій перспективі

Реєстр доробок. Ведіть список усіх кастомних модулів з описом: що робить, хто розробив, коли оновлювався, чи є тести. Без цього при зміні команди або оновленні Odoo ніхто не знає, що є і навіщо.

Тести для кастомного коду. Кожен кастомний модуль має мати хоча б базові автоматичні тести. Це дозволяє виявити поломки при оновленнях Odoo до того, як вони потраплять на продакшн.

Регулярний перегляд. Раз на рік або перед мажорним оновленням Odoo переглядайте список доробок: чи всі ще потрібні, чи не з'явилося стандартне рішення, чи можна щось прибрати. Накопичений «мертвий» кастом уповільнює систему та ускладнює підтримку.

Документація для передачі. Якщо ви плануєте змінити інтегратора або взяти підтримку in-house, кастомний код має бути задокументований так, щоб нова команда могла розібратися без автора.

Чек-лист: чи потрібна ця доробка?

Перед затвердженням будь-якої кастомізації дайте відповідь на ці питання:

Чи є стандартне рішення в Odoo або готовий модуль на Apps?
Чи можна змінити процес замість того, щоб змінювати систему?
Яка вартість розробки + підтримки на 2 роки?
Хто буде підтримувати цей код при оновленні Odoo?
Чи є ТЗ та тести для цієї доробки?
Чи можна запустити без цього і додати пізніше?

Якщо на більшість питань немає чіткої відповіді — доробку варто відкласти або переосмислити.

Підозрюєте, що проєкт Odoo роздутий через надмірну кастомізацію? Замовте аудит конфігурації: визначимо, що можна замінити стандартними засобами, а що варто залишити або спростити, і дамо рекомендації щодо зниження ризиків та витрат на підтримку.

Читайте також:

Надмірна кастомізація Odoo: коли доробки стають пасткою