Протокол міграції з Odoo: досвід виробника електроніки

Суть кейсу

Ситуація: впровадження Odoo тривало понад рік без запуску системи.

Фактичні витрати: 330 000+ грн на рік через дублювання операцій і ручне перенесення даних.

Подальші ризики: 27 500+ грн втрат щомісяця, не враховуючи витрати на доопрацювання, помилки в закупівлях і надлишкові запаси.

Управлінське рішення: перейти з частково кастомізованого Odoo на спеціалізовану виробничу систему.

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

З чого все почалося

Коли компанія-виробник електроніки почала рости, Excel перестав справлятися. З’явилися десятки специфікацій, серійні номери, закупівлі, виробничі замовлення. Керівництво вирішило: потрібна ERP. Вибір припав на Odoo.

Ідея виглядала логічною. Гнучка система, великий набір модулів, можливість налаштувати все під себе. Інтегратор Odoo оцінив запуск у чотири місяці, проте через рік виробництво все ще працювало в Excel.

Симптоми з’являлися один за одним

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

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

Але виробництво продовжувало працювати одразу у трьох системах: Excel, старій програмі та недобудованій ERP. Саме такі ознаки часто свідчать, що проблема вже не у затримці, а у самому підході до проєкту.

Момент, коли потрібно було рятувати проєкт

На виробничій нараді фінансовий директор поставив просте запитання: “Скільки ще потрібно часу?”

Відповіді не було. Була лише нова оцінка бюджету.

Тоді він запропонував порахувати не вартість ERP, а вартість очікування.

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

Разом це 110 людино-годин щомісяця.

Навіть якщо оцінити одну годину роботи лише у 250 грн (зарплата, податки та витрати роботодавця), компанія втрачала:

110 × 250 = 27 500 грн щомісяця.

За рік — 330 000 грн.

І це лише вартість дублювання роботи.

У розрахунок не входили:

• нові рахунки за доопрацювання ERP;
• помилки в закупівлях;
• надлишкові запаси;
• затримки відвантажень;
• рішення, прийняті на основі неповних або застарілих даних.

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

Після цього керівництво порівняло два сценарії:

1) продовжувати проєкт без зрозумілої дати завершення;

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

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

Протокол міграції з Odoo

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

1. У новій системі спочатку запускаємо критичні процеси

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

2. Фільтруємо інформацію перед міграцією

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

3. Архів старої системи залишаємо доступним лише для історичних даних

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

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

Замість вивчення всієї ERP-системи, кожен співробітник опановує виключно свій функціонал (наприклад, тільки приймання на склад чи тільки виписку рахунків). Так, ми знижуємо рівень стресу в команді та забезпечуємо швидкий старт роботи без помилок.

5. Поступово підключаємо фінанси, аналітику та додаткові модулі

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

Через три місяці

Диспетчер більше не відкривав Excel.

Закупівельник бачив реальний дефіцит матеріалів.

Керівник виробництва отримував фактичну собівартість без ручних розрахунків.

А директор вперше за довгий час перестав запитувати: “У якій таблиці зараз правильні цифри?”

Bаш проєкт на Odoo теж постійно потребує нових доопрацювань, а запуск переноситься місяць за місяцем?

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

Іноді найвигідніше рішення — не вкладати ще кілька місяців у проєкт, а перейти на систему, у якій типові виробничі процеси вже працюють із першого дня. Саме це допомагає уникнути пастки «вже стільки інвестували, треба доробити», яка часто робить ERP-проєкти ще дорожчими.