Попередній інтегратор не впорався або зник: як врятувати проєкт Odoo

Ситуація, коли підрядник з впровадження Odoo перестав відповідати, не виконує зобов’язань або ви зрозуміли, що він не тягне проєкт, — не рідкість. Щоб врятувати проєкт Odoo, потрібні чіткі кроки: забезпечити доступ до бази та коду, оцінити стан системи і вирішити, доробити поточне рішення чи перезапустити з новим інтегратором. У цій статті — що зробити спочатку, як оцінити стан бази, які варіанти продовження і на що дивитися при виборі нового партнера.

Що спочатку зробити: доступ, бекопи, документація

Поки ви ще маєте контакт з попереднім інтегратором або адмін-доступ до сервера, критично зафіксувати все необхідне для продовження роботи.

Доступи. Зберіть у надійному місці: логін і пароль до Odoo (супер-адмін), доступ до сервера (SSH, панель хостингу), доступ до бази даних (PostgreSQL), FTP або інший спосіб доступу до файлів. Якщо доступ надавався тільки інтегратору — вимагайте передачі або зміні паролів на тих, кого ви контролюєте. Без цього новий підрядник не зможе ні проаналізувати, ні виправити систему.

Резервні копії. Зробіть повний бекуп бази даних та файлового сховища Odoo (filestore) і зберігайте його у себе. Це страховка на випадок поломки під час діагностики або подальших змін. Переконайтеся, що копія відкривається (наприклад, тестовий імпорт на інший інстанс).

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

Якщо попередній інтегратор зник і доступу немає — доведеться відновлювати доступ через хостера або адміністратора інфраструктури. Це перший крок перед будь-яким «рятуванням» проєкту Odoo.

Як оцінити стан бази та конфігурації

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

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

Перевірка бізнес-логіки. Чи відповідають налаштування модулів (склад, продажі, CRM, бухгалтерія) вашим процесам? Чи збережені дані консистентні (наприклад, залишки не «мінусові» там, де не повинні)? Часто під час поспішного «запуску» залишаються недороблені сценарії або помилки в конфігурації, які потім ламають звіти та операції.

Інтеграції. Якщо підключені Нова Пошта, ПРРО, банки — перевірити, чи вони працюють, чи є логи помилок, чи не змінилися API. Зламані інтеграції часто стають причиною «система не працює» після зміни підрядника.

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

Варіанти: доробити чи перезапустити

Доробити поточну базу. Має сенс, якщо архітектура адекватна, кастомних модулів небагато, основні дані вже перенесені і проблеми зводяться до виправлення помилок, доналаштування та завершення інтеграцій. Новий інтегратор підключається, виправляє виявлені проблеми і доводить систему до go-live. Термін і бюджет зазвичай менші, ніж при повному перезапуску.

Перезапустити з нуля. Може бути доцільним, якщо база сильно пошкоджена (хаотичні дані, неконсистентні налаштування), кастомізація надто глибока і її підтримувати дорого, або версія Odoo застаріла і оновлення складніше, ніж нове впровадження. У такому разі визначається мінімальний scope для запуску (наприклад, склад + продажі + одна інтеграція), міграція лише необхідних даних з старої бази, і проєкт Odoo йде як новий, але з урахуванням минулих помилок.

Рішення приймається після технічного аудиту та порівняння оцінок «доробити» проти «перезапустити» за термінами та вартістю.

Як обрати нового інтегратора для рятування проєкту

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

Аудит перед договором. Оптимально спочатку замовити технічний аудит бази (за фіксовану суму або невеликий бюджет). За результатом аудиту ви отримаєте план робіт і реалістичну оцінку. Підписувати великий договір на «рятування» без такого аудиту — ризиковано.

Прозорість і комунікація. Новий інтегратор має чітко пояснити, що буде зроблено на кожному етапі, які ризики і що буде, якщо виявиться щось непередбачене. Регулярні звіти та демо — обов’язкова умова, щоб проєкт Odoo знову не завис.

Ми спеціалізуємося на саме таких кейсах: приймаємо в роботу проєкти, де попередній інтегратор не впорався або зник, проводимо технічний аудит бази і пропонуємо план виходу з ситуації — доробити чи перезапустити.

Типові стани «проблемної» бази Odoo

Часткове впровадження. Встановлені модулі, налаштовані базові довідники, але бізнес-процеси не налаштовані або налаштовані неправильно. Дані є, але система «не працює» як ERP. Зазвичай найпростіший для виправлення стан.

Зламані інтеграції. Основна система Odoo працює, але інтеграції (НП, ПРРО, банки) не функціонують або дають помилки. Причини: зміни API, застарілі ключі, несумісність версій. Виправляється оновленням модулів та налаштувань.

Некоректні дані. В базі є дублікати клієнтів, від'ємні залишки, незакриті документи, помилки в бухгалтерських записах. Потрібне очищення даних та виправлення логіки проведення. Найскладніший стан — іноді простіше перезапустити з чистою базою.

Застаріла версія Odoo. Система працює на Odoo 12 або 13, яка вже не підтримується. Оновлення до актуальної версії складне через кастомні модулі. Потрібна оцінка: оновлювати чи розгортати нову версію паралельно.

Відсутність документації та доступів. Попередній інтегратор не передав доступи, немає ТЗ, незрозуміло, що і навіщо налаштовано. Перший крок — відновлення доступів та аудит конфігурації.

Скільки часу займає «рятування» проєкту Odoo

Терміни залежать від стану бази та обсягу робіт:

Стан	Орієнтовний термін
Виправлення налаштувань та інтеграцій	2–4 тижні
Очищення даних + донастроювання	4–8 тижнів
Часткове перезапровадження (нові модулі)	6–12 тижнів
Повний перезапуск з міграцією даних	3–6 місяців

Реальні терміни визначаються після технічного аудиту бази. Без аудиту будь-які оцінки — це здогадки.

Як уникнути повторення ситуації з новим інтегратором

Фіксуйте все письмово. Договір, ТЗ, протоколи зустрічей, листування — все зберігайте. При виникненні суперечок або зміні підрядника це безцінно.

Вимагайте доступи з першого дня. Адмін-доступ до Odoo, SSH до сервера, доступ до бази — все має бути у вас, а не тільки у підрядника. Це ваша система.

Регулярні демо та звіти. Раз на 1–2 тижні підрядник має показувати прогрес на реальній системі. «Ми ще розробляємо» без демо — тривожний сигнал.

Поетапна оплата. Прив'язуйте оплату до конкретних результатів (milestone), а не до часу. Це мотивує підрядника рухатися вперед і дає вам важіль при затримках.

Тестовий доступ для ключових користувачів. Залучайте майбутніх користувачів до тестування на ранніх етапах. Вони виявлять невідповідності процесам до того, як вони стануть дорогими виправленнями.

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

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

Інтегратор не впорався — як врятувати проєкт