Як обрати виконавця для впровадження Odoo: питання, гарантії та червоні прапорці

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

Нижче — те, що варто зʼясувати до підписання. Порядок не випадковий: перше питання найважливіше.

Хто саме працюватиме над вашим проєктом

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

Що ви хочете почути у відповідь — і бажано мати це в договорі:

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

Якщо відповідь на це загальна («у нас сильна команда») — решту питань можна не ставити.

ШІ в розробці: не привід платити менше і не привід відмовлятися

ШІ — це інструмент. Потужний, але інструмент. Він пришвидшує написання коду, і в цьому немає нічого поганого — я сама ним користуюся. Питання не в тому, чи використовує підрядник ШІ, а в тому, хто ухвалює рішення.

Програмувати з ШІ має програміст — той, хто розуміє Odoo, бачить архітектуру цілком і здатен відхилити згенероване рішення, бо воно не лягає в систему. Коли такої людини немає, ШІ просто швидше виробляє те, що потім довго розплутувати: дубльований код, кілька різних методів на одну задачу, мертві поля й моделі, логіку, несумісну з механікою Odoo або з реальним бізнес-процесом.

Що питати:

• чи проходить згенерований код людську рецензію і хто її робить;
• хто ухвалює архітектурне рішення до того, як код написано;
• чи є тести на критичну логіку — саме вони показують, що код зрозуміли, а не просто вставили.

Найпростіша перевірка: попросіть пояснити будь-який фрагмент коду з попереднього проєкту. Той, хто його продумав, пояснить за хвилину.

Докладніше про те, як має бути влаштований процес розробки з ШІ і чому тепер важливе повне покриття тестами — в окремій статті.

Питання про архітектуру — до початку, а не після

• Що ви пропонуєте робити стандартним функціоналом Odoo, а що кастомним кодом — і чому саме такий розподіл?
• Як ви плануєте оновлюватися на майбутні версії з цими доопрацюваннями?
• Чи використовуватиметься Studio — і що з ним станеться, коли база переїде на інший сервер?
• Як розділені продакшен і staging, і як виглядає деплой?

«Зробимо в Studio, так швидше» для системи, яка має жити роками, — це відкладений рахунок, а не економія.

Питання про інтеграції: не «підключимо API», а «як ви гарантуєте повноту»

Найдорожчі проблеми інтеграцій — не помилки, а тиша: конектор працює, але частина документів просто не доходить. Тому формулюйте так:

• як поводиться конектор, коли зовнішній сервіс недоступний — дані втрачаються чи чекають у черзі?
• чи можна переграти період без створення дублів документів?
• як ви перевіряєте, що за місяць перенесено рівно стільки документів, скільки було?
• чи логуються запити і скільки зберігаються логи?

Чому це критично і до чого призводить архітектура на хуках — тут: технічний аудит Odoo-проєкту.

Що має бути в договорі

• Код у вашому репозиторії — не «передамо в кінці», а з першого дня. Це найпростіший захист від залежності від підрядника.
• Акаунти, зареєстровані на вас : сервер, домен, хостинг, поштові сервіси, кабінети платіжних систем.
• Гарантія кваліфікації людей на проєкті та порядок заміни розробника.
• Гарантійний період на виправлення дефектів у зданому функціоналі.
• Прозорий звіт по годинах : що саме зроблено за ці години, а не «розробка — 40 год».
• Документація , щонайменше опис кастомних модулів та інтеграцій.

Червоні прапорці

• Фіксована ціна без обстеження процесів. Це не гарантія бюджету, а гарантія того, що все не прописане випаде з обсягу.
• «Зробимо все в Studio, так швидше». Швидше сьогодні, дорожче на першій же міграції чи оновленні.
• Немає git. Якщо код живе лише на сервері — його фактично немає.
• Один розробник без підстраховки і без документації.
• Строки, обіцяні до будь-якої розмови про ваші процеси. «Впровадимо за два тижні» без жодного питання про ваш облік — це продаж, а не оцінка.
• Небажання показати попередній код , бодай знеособлений.

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

Працюють два підходи. Перший — пілотна задача : невелика, але справжня, узята з вашого ж списку. Вона показує все — як питають, як оцінюють, як здають, чи є тести.

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

Погодинно чи фіксована ціна

Фіксована ціна виглядає безпечніше, але працює лише там, де обсяг справді визначений — окремий модуль із чітким технічним завданням. Для впровадження ERP обсяг уточнюється на ходу: половина реальних вимог зʼявляється тоді, коли люди вперше бачать систему зі своїми даними.

Тому для впровадження чесний формат — погодинна оплата з прозорим звітом та етапами : ви бачите, куди йдуть години, і можете зупинитися або переставити пріоритети на будь-якому етапі.

Якщо ви шукаєте підрядника

Що я роблю в Odoo і як працюю — у розділі Послуги Odoo . Якщо систему впроваджували до вас і треба зрозуміти її стан, почніть із технічного аудиту.

Часті питання

Чи обовʼязково наймати офіційного партнера Odoo?

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

Скільки має коштувати впровадження Odoo?

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

Чи можна почати з малого?

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

Підрядник використовує ШІ — це погано?

Ні, за умови, що код рецензує людина, яка знає Odoo, а архітектурні рішення ухвалюються до написання коду, а не після.

Ми вже почали з іншим підрядником і маємо сумніви. Пізно?

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