З досвіду команди, під час вибору Odoo-партнера варто заздалегідь врахувати кілька умов, які можуть вплинути на подальшу підтримку та вартість системи. Зокрема, кастомний код партнера не входить у стандартний сервіс оновлення Odoo й потребує окремого обслуговування. Крім того, стандартна підтримка кожної мажорної версії триває три роки, після чого використання застарілої версії передбачає додаткову плату.
Обидві умови відомі партнеру ще до старту проєкту, але саме на етапі переговорів потрібно з'ясувати, як вони вплинуть на майбутні витрати, оновлення та підтримку системи. У цьому матеріалі розбираємо 11 запитань, які варто поставити Odoo-партнеру до підписання договору, щоб заздалегідь зрозуміти ці ризики.
Чому статус Gold в Odoo не є гарантією якості проєкту?
Рівні Ready, Silver і Gold часто сприймають як оцінку якості партнера, але вони вимірюють інше. Згідно з Odoo Partnership Agreement, статус залежить від кількості нових користувачів Odoo Enterprise, сертифікованих співробітників і retention rate — частки клієнтів, які залишаються активними.
Показник | Ready | Silver | Gold |
Нові користувачі Enterprise за рік | 10 | 75 | 300 |
Сертифіковані співробітники | 1 | 3 | 6 |
Мінімальний retention rate | — | 70% | 80% |
Джерело: Odoo Partnership Agreement
Ці показники дають уявлення про масштаб і досвід партнера, але не описують, як саме буде організований ваш проєкт. Статус не визначає склад команди, методологію, строки, порядок приймання робіт або обсяг підтримки після запуску. Retention rate також показує продовження підписок, а не безпосередньо задоволеність клієнтів результатом впровадження.
На практиці під час вибору варто дивитися ширше за партнерський рівень: на досвід у схожих проєктах, склад команди, підхід до впровадження, підтримки та майбутніх оновлень. Детальніше ці критерії ми розбирали у матеріалі «Як обрати партнера Odoo?».
Тому статус Gold варто використовувати як один із початкових орієнтирів. Але вже на переговорах важливіше з'ясувати, хто саме працюватиме над вашим проєктом, який досвід має ця команда і як партнер організовує роботу після старту.
Дізнайтеся більше про Перші 90 днів після впровадження Odoo: чекліст як стабілізувати систему після go-live
Що перевірити до першої зустрічі з партнером Odoo?
Частину інформації про партнера можна перевірити ще до першої розмови. Зокрема такі дані як:
- Офіційний статус. Перевірте компанію в каталозі партнерів Odoo, де можна зазначено її поточний рівень партнерства та базова інформацію про команду.
- Актуальність сертифікацій. Сертифікація Odoo прив'язана до конкретної версії системи. У партнерських вимогах враховуються сертифікати на одній із трьох останніх мажорних версій, тому варто дивитися не лише на кількість сертифікатів, а й на їх актуальність.
- Публічні розробки. Модулі в Odoo Apps Store або внески до OCA дають можливість побачити частину технічної роботи команди ще до початку проєкту. Їх відсутність сама по собі нічого не доводить, але наявність може бути додатковим аргументом під час оцінки партнера.
- Кейси. Найбільш корисні кейси містять конкретику: галузь, масштаб проєкту, впроваджені модулі, строки та обсяг кастомізації. Чим більше таких деталей, тим легше зрозуміти, чи має партнер досвід зі схожими задачами.
Після такої перевірки першу зустріч можна присвятити вже конкретним питанням про ваш проєкт, команду та умови співпраці.
ТОП-11 запитань до Odoo-партнера перед підписанням договору
Нижче — короткий чекліст із 11 запитань, які варто поставити Odoo-партнеру ще до підписання договору. Вони допоможуть швидко перевірити команду, підхід до впровадження, бюджет, підтримку, локалізацію та умови роботи з кастомним кодом.
№ | Питання Odoo-партнеру | Що варто з’ясувати |
1 | Який у вас статус партнера, скільки сертифікованих спеціалістів і хто працюватиме над нашим проєктом? | Хто саме входить у команду, які має ролі, досвід і актуальні сертифікації. |
2 | Покажіть 2–3 схожі проєкти. Чи є можливість поспілкуватися з клієнтом зі схожим проєктом? | Наскільки досвід партнера відповідає вашій галузі, масштабу та складності процесів. |
3 | Яка ваша методологія впровадження і що ми отримаємо після етапу аналізу? | Які результати дає аналіз, як формуються бюджет, строки, ризики та межі проєкту. |
4 | Як ви вирішуєте, що залишити у стандарті, що зробити через Studio, а що винести в кастомний модуль? | Як партнер мінімізує зайві доробки та враховує майбутню вартість підтримки й оновлень. |
5 | Що саме з українського обліку та звітності ви закриваєте і хто підтримує ці модулі? | Що є стандартом Odoo, що локалізацією, хто її оновлює та відповідає за зміни законодавства. |
6 | Які дані ми переносимо, хто відповідає за їх якість і як будуть підтримуватися інтеграції? | Який обсяг міграції, хто перевіряє дані та хто підтримує інтеграції після запуску й оновлень. |
7 | Де ми тестуватимемо систему і за якими критеріями ухвалюється рішення про запуск? | Яке буде тестове середовище, які сценарії перевіряються та що вважається критичною помилкою. |
8 | Як ви навчаєте користувачів і що наша команда зможе робити самостійно після запуску? | Як передаються знання, хто навчає команду та які дії не потребуватимуть постійної участі партнера. |
9 | Як працює підтримка після запуску і хто відповідає за кастомний код? | Що входить у підписку Odoo, що оплачується окремо та хто супроводжує кастомізації. |
10 | Як формується бюджет проєкту і як погоджуються додаткові роботи? | З чого складається оцінка, що в неї не входить і як зміни впливають на вартість та строки. |
11 | Кому належать код, документація та дані, і як відбувається перехід до іншого партнера? | Які права ви отримуєте, до чого матимете доступ і як виглядає передача проєкту іншому підряднику. |
Такод корисною буде стаття на тему Що таке База знань Odoo та як вона працює в бізнес-процесах компанії?
Що варто почути від Odoo-партнера і які відповіді мають насторожити?
Самі запитання — лише половина перевірки. Важливо розуміти, навіщо ставити кожне з них, яку відповідь можна вважати змістовною і які формулювання мають насторожити. Нижче розбираємо всі 11 питань детальніше з поясненням, що саме варто уточнити у партнера до початку проєкту.
1. Який у вас статус партнера, скільки сертифікованих спеціалістів і хто працюватиме над нашим проєктом?
Чому важливо: Партнерський статус характеризує компанію загалом, але результат проєкту залежить від конкретної команди. Тому ще до підписання договору варто зрозуміти, хто відповідатиме за аналіз, налаштування, розробку та управління проєктом і який досвід мають ці спеціалісти.
Що варто почути: Конкретні імена та ролі ключових учасників команди, їхній досвід зі схожими проєктами та актуальні сертифікації Odoo. Також варто уточнити, хто замінить відповідального спеціаліста у разі відпустки, звільнення або тривалої відсутності.
Що насторожує: компанії немає в офіційному каталозі партнерів; замість конкретного складу проєктної команди ви чуєте лише про “великий штат”; партнер не може пояснити, хто саме відповідатиме за ключові етапи проєкту; сертифікації команди стосуються лише застарілих версій Odoo.
2. Покажіть 2-3 схожі проєкти. Чи є можливість поспілкуватися з клієнтом зі схожим проєктом?
Чому важливо: Досвід у вашій галузі корисний, але ще важливіша схожість самих процесів: масштабу, кількості користувачів, складності обліку, виробництва чи документообігу. Кейси показують, із якими задачами партнер уже працював, а розмова з чинним клієнтом допомагає зрозуміти, як команда веде проєкт на практиці.
Що варто почути: Приклади проєктів, близьких до вашого за масштабом і задачами, з конкретикою про впроваджені модулі, строки та кастомізації. Добрий сигнал — готовність організувати референс-дзвінок із клієнтом і відкрито розповісти не лише про успіхи, а й про складнощі, які виникали під час впровадження.
Що насторожує: кейси без цифр, строків і зрозумілого опису задач; усі приклади дуже загальні; партнер не може показати жодного схожого проєкту або організувати референс-розмову; у кейсах немає згадок про складнощі, зміни чи компроміси.
3. Яка ваша методологія впровадження і що ми отримаємо після етапу аналізу?
Чому важливо: Саме на етапі аналізу партнер має зрозуміти ваші процеси, визначити межі проєкту та оцінити обсяг робіт. Чим конкретніше описаний результат цього етапу, тим менший ризик, що бюджет і строки суттєво зміняться вже під час впровадження. У методології Odoo аналіз займає окреме місце і має завершуватися зрозумілим планом подальших робіт.
Що варто почути: Які етапи проходить проєкт, скільки приблизно триває аналіз і які матеріали ви отримаєте на виході. Це можуть бути опис поточних і майбутніх процесів, перелік розривів між вимогами та стандартним функціоналом Odoo, попередній бюджет, план робіт і основні ризики. Важливо також зрозуміти, як партнер працює з вимогами, які можуть бути зайвими або надто дорогими для реалізації.
Що насторожує: оцінка бюджету без попереднього аналізу; незрозуміло, що саме ви отримаєте після цього етапу; методологія описується лише словами «Agile» чи «гнучкий підхід» без конкретних результатів і критеріїв; партнер погоджується на всі вимоги, не обговорюючи їхню доцільність і вартість.
4. Як ви вирішуєте, що залишити у стандарті, що зробити через Studio, а що винести в кастомний модуль?
Чому важливо: Спосіб реалізації впливає не лише на бюджет розробки, а й на подальшу підтримку та оновлення системи. Налаштування у стандарті, зміни через Studio і окремі кастомні модулі мають різну вартість володіння, тому це варто обговорити ще до розробки. Особливо важливо розуміти, які доробки створюватимуть додаткові витрати під час наступних оновлень Odoo.
Що варто почути: Партнер може пояснити, за якими критеріями обирає між стандартним функціоналом, Studio і кастомним кодом. Для кожної суттєвої доробки він оцінює не лише розробку, а й майбутню підтримку. Хороший підхід — спочатку перевірити, чи можна вирішити задачу стандартними засобами, а частину необов’язкових доробок перенести на наступні етапи.
Що насторожує: пропозиція відтворити всі поточні процеси без перегляду; окрема доробка під кожен виняток; оцінюється лише розробка без подальшої підтримки; партнер не пояснює, як кастомізації вплинуть на майбутні оновлення.
5. Що саме з українського обліку та звітності ви закриваєте і хто підтримує ці модулі?
Чому важливо: Стандартна українська локалізація Odoo не закриває весь набір вимог українського бухгалтерського та податкового обліку. Тому частина функціоналу зазвичай реалізується окремими локалізаційними або партнерськими модулями. Важливо заздалегідь розуміти, кому належать ці рішення, хто їх підтримує і як вони оновлюються після змін законодавства.
Що варто почути: Чіткий поділ між стандартним функціоналом Odoo, власними модулями партнера, сторонніми рішеннями та доробками під ваш проєкт. Партнер має пояснити, хто відповідає за оновлення локалізації, у які строки вносяться зміни та чи входить це в поточну підтримку. Заявлені можливості обліку й звітності варто побачити на демо, а умови доступу до коду та зміни постачальника — зафіксувати в договорі.
Що насторожує: загальна обіцянка «повної локалізації» без переліку функцій; незрозуміло, хто розробляє і підтримує модулі; немає відповіді, як система адаптується до змін законодавства; партнер не готовий показати заявлену звітність у роботі.
Рекомендуємо до прочитання Що таке "Облік для України" від Self-ERP? Повний огляд функціоналу
6. Які дані ми переносимо, хто відповідає за їх якість і як будуть підтримуватися інтеграції?
Чому важливо: Міграція даних часто стає одним із найскладніших етапів ERP-проєкту. Переносити всю історію не завжди потрібно: зазвичай окремо визначають довідники, залишки, відкриті документи та дані, які мають залишитися у старій системі для довідок. Те саме стосується інтеграцій — ще до запуску варто розуміти, хто їх підтримуватиме і що потрібно буде перевіряти після оновлення Odoo.
Що варто почути: Чіткий перелік даних, які переносяться, і відповідальних за їх підготовку, очищення та перевірку. Для міграції мають бути визначені критерії приймання: звірка залишків, контрольних сум і кількості записів. Для кожної інтеграції варто зафіксувати, які дані вона передає, хто за неї відповідає, як обробляються збої та хто адаптує її під час переходу на нову версію.
Що насторожує: обіцянка "перенести все" без оцінки обсягу; відсутність тестової міграції та критеріїв звірки; дані очищаються без участі ваших відповідальних співробітників; інтеграції описані лише як «налаштуємо обмін» без зрозумілого власника та умов подальшої підтримки.
7. Де ми тестуватимемо систему і за якими критеріями ухвалюється рішення про запуск?
Чому важливо: Перед запуском систему потрібно перевірити в окремому тестовому середовищі, максимально наближеному до робочого. Це дозволяє пройти ключові бізнес-сценарії без ризику для реальних даних і операцій. В Odoo.sh для цього передбачені окремі середовища для розробки, тестування та продуктивної роботи.
Що варто почути: Партнер пояснює, де саме проходитиме тестування і хто матиме доступ. Приймання системи будується на реальних наскрізних сценаріях — наприклад, від замовлення до оплати й відвантаження. До запуску мають бути погоджені сценарії перевірки, перелік критичних помилок і чіткі критерії, за яких система готова до go-live.
Що насторожує: тестування без окремого середовища; приймання у форматі демонстрації від партнера; немає письмових сценаріїв і критеріїв запуску; критичність помилок визначається вже в останній момент; дата go-live фіксується незалежно від результатів тестування.
8. Як ви навчаєте користувачів і що наша команда зможе робити самостійно після запуску?
Чому важливо: Після запуску більшість щоденних дій у системі має виконувати ваша команда без постійної участі партнера. Тому ще до старту варто домовитися, кого саме навчатимуть, у якому форматі та які знання мають залишитися всередині компанії.
Що варто почути: Чіткий план навчання: кого навчає партнер, хто відповідатиме за підготовку інших користувачів і коли проходитимуть сесії. Варто також заздалегідь визначити, які дії команда зможе виконувати самостійно — наприклад, керувати користувачами та правами доступу, змінювати прості налаштування, працювати зі звітами чи Studio. Корисно, якщо після навчання залишаються інструкції та записи ключових сесій.
Що насторожує: усе навчання зводиться до однієї сесії перед запуском; немає плану передавання знань; партнер не може пояснити, що команда зможе робити самостійно; будь-яка базова зміна після запуску потребує окремого платного звернення.
9. Як працює підтримка після запуску і хто відповідає за кастомний код?
Чому важливо: Після go-live частина питань стосується стандартного функціоналу Odoo, а частина — налаштувань, інтеграцій і кастомних модулів. Вони можуть обслуговуватися за різними правилами, тому межі відповідальності варто зафіксувати ще до підписання договору.
Що варто почути: Партнер чітко пояснює, що входить у підписку Odoo, а що покривається його окремими послугами. Також мають бути визначені канали підтримки, час реакції, пріоритети звернень і порядок ескалації. Для кастомного коду важливо розуміти, хто його підтримує, як він адаптується під нові версії та як формується бюджет на оновлення.
Що насторожує: формулювання «усе включено в ліцензію» без деталізації; підтримка без зрозумілих строків реакції; немає окремої відповідальності за кастомний код; тема майбутніх оновлень і їх вартості взагалі не обговорюється.
10. Як формується бюджет проєкту і як погоджуються додаткові роботи?
Чому важливо: Початкова оцінка ERP-проєкту майже завжди базується на певних припущеннях щодо обсягу робіт. Якщо під час впровадження з’являються нові вимоги, інтеграції або доробки, вони можуть вплинути і на бюджет, і на строки. Тому ще до старту варто зрозуміти, як партнер оцінює роботи та за якою процедурою погоджуються зміни.
Що варто почути: Зрозумілу структуру бюджету за етапами та окремий перелік того, що в оцінку не входить. Ліцензії Odoo, хостинг, послуги партнера, сторонні модулі та додаткові розробки мають бути розділені. Для нових вимог повинна діяти письмова процедура погодження із попередньою оцінкою їхнього впливу на вартість і строки.
Що насторожує: одна сума "під ключ" без деталізації; незрозуміло, на яких припущеннях побудована оцінка; додаткові роботи погоджуються усно; партнер не розділяє вартість ліцензій, власних послуг і сторонніх рішень; зміна обсягу робіт не має зрозумілого процесу погодження.
11. Кому належать код, документація та дані, та як відбувається перехід до іншого партнера?
Чому важливо: Клієнт Odoo може змінити партнера, але це не означає автоматичний доступ до всього, що було створено під час проєкту. Права на кастомний код, документацію, репозиторії, резервні копії та технічні доступи визначаються вашим договором із партнером. Якщо ці умови не прописані заздалегідь, зміна підрядника може виявитися складнішою й дорожчою, ніж очікувалося.
Що варто почути: У договорі чітко визначено, які права ви отримуєте на створений код і документацію. Ви маєте доступ до репозиторію, резервних копій, технічної документації, схем інтеграцій та адміністративних доступів. Також має бути описана процедура завершення співпраці: що саме передається, у які строки і чи потребує це додаткової оплати.
Що насторожує: код зберігається лише на стороні партнера; немає доступу до репозиторію та резервних копій; права на доробки не визначені в договорі; процедура передачі проєкту іншому партнеру не описана; ключові адміністративні доступи контролює лише підрядник.
Обовязково до ознайомлення стаття Інвестиція чи витрати? Гід по розрахунку ROI в ERP
Висновок
Вибір Odoo-партнера впливає не лише на саме впровадження, а й на подальші витрати, підтримку та оновлення системи. Найважливіші умови варто з’ясувати ще до старту: хто працюватиме над проєктом, кому належать доробки, як вони підтримуються і що відбувається при переході на нову версію або до іншого партнера.
Тому перед підписанням договору поставте ключові запитання, отримайте відповіді письмово й зафіксуйте істотні умови в договорі або додатках.