Як перейти з 1С/BAS на Odoo?

Враховуючи складну економічну ситуацію в Україні та негативний вплив війни, бізнеси зазвичай відкладають перехід з ворожого ПЗ та вважають міграцію з 1С не найважливішим питанням на порядку денному. Ба більше, воно не постає навіть після введення санкцій та прямої заборони на використання. Проте затягування цього переходу призводить до зростання витрат, а відвертно небезпечні ризики загрожують блокуванням, кібератаками та погіршенням репутації в інфопросторі.

Наш гайд по міграції з 1С/BAS на Odoo це можливість оцінити весь процес, щоб перехід не виглядав як “теорія великого вибуху”. Він складається з 13 кроків — всіх етапів переходу на новий софт. Ви дізнаєтеся про організацію аудиту, вибір архітектури, підготовку даних, тестування та стабілізацію системи після запуску. Деталі нижче.

Хочете ознайомитися з основними ризиками використання 1С/BAS у короткому форматі? Перегляньте відеоверсію матеріалу.

Що означає міграція з 1С/BAS на Odoo?

Кожен власник чи керівник по різному уявляє проєкт міграції, а дехто навіть і не розуміє, яким він має бути. Насамперед, запуск має починатися не з огляду нового ПЗ, а з аналізу поточної системи. Важливо на старті з'ясувати, які дані використовують працівники та які інтеграції пов’язані з обліком. Після цього можна переходити до проєктування архітектури Odoo. 

Планування проєкту корисно розподілити три масштаби зміни:

1. Перенесення даних, що включає імпорт контрагентів, товарів, рахунків, залишків та інших погоджені записів у відповідні об’єкти Odoo. На цьому етапі потрібно зіставити структури двох систем, очистити інформацію та зберегти зв’язки між записами.
2. Заміна облікової системи. До перенесення даних додається налаштування функцій, потрібних для щоденної роботи. Серед них зазвичай є продажі, закупівлі, складський облік, взаєморозрахунки, фінансові операції та управлінська звітність.
3. Перегляд бізнес-процесів. Перехід на Odoo з 1С супроводжується скороченням ручних операцій, відмовою від окремих Excel-файлів, зміною маршрутів погодження та автоматизацією повторюваних завдань. Переваги такого підходу особливо помітні на тлі застарілої архітектури 1С, основи якої закладалися ще за часів Windows 95. 

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

Далі розбираємо кожен крок окремо.

Крок 1. Визначення цілей

Чітке формулювання навіщо компанія переходить на нову систему допомагає окреслити зрозумілу мету для всієї команди. Крім цього, без конкретних цілей складно визначити обсяг робіт та вимірювати результат після запуску. Загального наміру просто “замінити ПЗ” недостатньо. 

Приклади вдалих цілей, які радимо застосовувати: 

• замінити систему, яку складно підтримувати або розвивати, окрема 1С чи BAS;
• об’єднати кілька баз, облікових програм та Excel-файлів;
• скоротити ручне введення й повторне перенесення інформації;
• пов’язати продажі, закупівлі, склад та фінанси в одному процесі;
• керувати кількома юридичними особами або підрозділами;
• підтримати роботу з іноземними контрагентами та різними валютами.

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

Наприклад: 

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

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

Крок 2. Аудит поточної системи

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

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

2. Дані та звітність. Перевірте довідники контрагентів, товарів, складів, підрозділів і статей обліку: кількість записів, заповненість полів, дублікати та помилки у зв’язках між даними тощо.

Регістри та інші внутрішні структури в 1С/BAS не слід автоматично відтворювати в Odoo. Тут важливо прослідкувати, які показники вони формують і з яких бізнес-операцій ці показники мають виникати в новій системі.

3. Обміни та інтеграції — перелік усіх систем, які обмінюються даними з 1С/BAS. До нього входять сайт, інтернет-магазин, банк, каси, електронний документообіг, маркетплейси, складські сервіси тощо. Для кожного обміну потрібно зафіксувати:

• які дані передаються;
• у якому напрямку;
• як часто відбувається обмін;
• хто контролює помилки.

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

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

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

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

Залучіть представників кожного напряму (бухгалтерія, склад, продажі, закупівлі), бо саме вони знають, які звіти й обробки реально критичні, а які існують “за традицією” і ніхто вже не пам'ятає, навіщо.

Корисною буде стаття на тему ERP для MilTech-виробництва: основні терміни та їх значення

Крок 3. Опис процесів

Для цього етапі рекомендована методика, відома як AS-IS / TO-BE. AS-IS показує, як процес виконується сьогодні; TO-BE описує, як процес має виконуватися після переходу.

Для кожного процесу зафіксуйте наступну інформацію: 

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

Важливо! Головна помилка тут — механічно відтворити логіку 1С/BAS в Odoo, тобто спробувати відтворити в новій системі точно ту саму послідовність дій, яка існувала в старій, замінивши інтерфейс. При такій умові ви лише переносите всі обмеження в нову оболонку, що надалі призводить відчуття “нова система гірша за стару”.

Для кожного процесу розгляньте чотири варіанти функціональності:

• Використати стандартний процес Odoo без змін, якщо стандартна логіка роботи системи покриває потребу бізнесу.
• Змінити внутрішній регламент, а не систему. Якщо зайвий крок не має облікової, юридичної або операційної потреби, доцільніше змінити порядок роботи працівників, а не відтворювати стару схему. 
• Налаштувати систему (конфігурація без програмування) — стандартний сценарій можна адаптувати через параметри модулів, ролі доступу, складські маршрути, правила погодження тощо. 
• Розробити окремий модуль чи доопрацювання, якщо процес критичний для бізнесу і жодний зі стандартних механізмів Odoo, включно з Odoo Studio, його не покриває.

Практична порада: Додайте до кожного опису колонку з питанням “Чому потрібен цей крок?” Якщо на нього немає чіткої відповіді, не переносіть його в TO-BE без додаткового аналізу.

Крок 4. Формування переліку функцій 

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

• обов’язкові для запуску (Must have) — без них компанія не зможе виконувати основні операції;
• важливі (Should have) — потрібні для зручної роботи, але певний час можна працювати без них;
• додаткові (Could have) — покращують процес, проте не впливають на запуск;
• відкладені (Won’t have на першому етапі) — свідомо переносяться на наступний етап.

Для кожної визначте, як вона буде реалізована в Odoo: стандартними функціями, налаштуванням, інтеграцією або окремою доробкою. Рекомендуємо звести все в одну робочу таблицю на кшталт:

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

Крок 5. Редакція та архітектура Odoo

Odoo пропонує кілька версій та форматів розгортання, і жоден із них не є універсально “правильним”, адже вибір залежить від конкретних потреб компанії. Розглянемо коротко основні критерії, в яких важливо визначитися до запуску.

Odoo Community vs Odoo Enterprise

1. Odoo Community — безкоштовна версія ERP-системи з відкритим кодом, яка підходить малому та середньому бізнесу, компаніям зі специфічними процесами та тим, хто працює з українським обліком і документами. Вона містить базові модулі CRM, продажів, запасів, проєктів, бухгалтерії та виробництва й дає змогу гнучко адаптувати систему під потреби бізнесу. Community зазвичай обирають компанії, які хочуть більше контролю над ERP та готові інвестувати в її налаштування й підтримку. 
2. Odoo Enterprise — платна версія системи, яка розширює можливості Community додатковими застосунками та функціями, а також передбачає регулярні оновлення й офіційну підтримку Odoo S.A. Її можна використовувати у хмарі — через Odoo Online або Odoo.sh — чи розгорнути на власному сервері. Enterprise доцільно обирати компаніям, яким потрібні функції та сервіси, недоступні у Community. 

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

Варіанти розгортання: Odoo Online, Odoo.sh, on-premise

Odoo визначає три варіанти хостингу: Odoo Online, Odoo.sh, та on-premise.

1. Odoo Online — хмарний сервіс, який повністю обслуговує Odoo. Компанії не потрібно адмініструвати сервери, але є суттєве обмеження, зокрема на встановлення власних та сторонніх модулів з програмним кодом не можна. Тому такий варіант підходить насамперед для проєктів, які можна реалізувати стандартними функціями та налаштуваннями. 
2. Odoo.sh — хмарна платформа Odoo для проєктів із власними модулями та активною розробкою. Вона підтримує окремі середовища для розробки, тестування й продуктивної роботи, а також інструменти для розгортання та резервного копіювання. Зручний варіант, коли системі потрібні доопрацювання, але компанія не хоче самостійно підтримувати всю серверну інфраструктуру. 
3. On-premise означає розміщення Odoo на власній або орендованій інфраструктурі. Бізнес отримує більше контролю над середовищем та може використовувати власні модулі, але сама відповідає за сервери, безпеку, резервне копіювання тощо. 

Окремо потрібно врахувати майбутні оновлення.Odoo надає стандартну підтримку кожній основній версії протягом трьох років, включно з технічною підтримкою, виправленням помилок та оновленнями безпеки. Правила переходу на нові версії залежать від типу хостингу. Для Odoo Online оновлення основної версії є обов’язковим щонайменше раз на два роки, тоді як on-premise дозволяє залишатися на старій версії довше, хоча Odoo не рекомендує працювати на непідтримуваних релізах.

Практична порада: Визначте, чи потрібні власні модулі. Якщо так, Odoo Online можна одразу виключити з основних варіантів та порівнювати Odoo.sh з on-premise.

Дізнайтеся більше про функціональність популярних бухгалтерських систем у матеріалі MASTER:Бухгалтерія чи Oblik-ERP: порівняльний аналіз

Крок 7. Стратегія перенесення даних

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

! Зауважте, що чим більший обсяг історії, тим більше даних потрібно очистити, зіставити зі структурою Odoo та перевірити після імпорту. Тому рішення про повну міграцію має ґрунтуватися на конкретній потребі, а не на бажанні “мати все в одній системі”. Можна залишити 1С/BAS як архів із доступом лише для перегляду. 

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

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

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

Практична порада: Не видаляйте сумнівні записи одразу. Спочатку винесіть їх в окремий список і передайте на перевірку відповідальному працівнику.

Крок 8. Налаштування системи 

Наступний етап — налаштувати Odoo так, щоб структура відповідала погодженим процесам TO-BE. Важливо зробити це до масового імпорту, тому що частина даних залежить від уже створених компаній, рахунків, складів, податків та правил доступу.

На цьому етапі зазвичай налаштовують:

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

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

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

Oblik-ERP для українського обліку

Oblik-ERP — рішення на базі Odoo Enterprise, адаптоване до вимог українського бізнесу. Набір модулів доповнює стандартні можливості Odoo функціями для бухгалтерського й податкового обліку, ПДВ, взаєморозрахунків із контрагентами, кадрового обліку та розрахунку зарплати, регламентованої звітності та інші. Також система поєднує цей контур з операційними модулями Odoo — CRM, продажами, закупівлями, складом і виробництвом.

Бажаєте детальніше обзнайомитися з рішення, залишайте контакти. Команда зв'яжеться та допоможе розібратися. 

Крок 9. Інтеграції та доопрацювання

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

• Odoo Studio для додавання полів, зміни форм, автоматизацій, погоджень і звітів без окремого програмування;
• Готовий модуль — функція вже реалізована стороннім розробником. Odoo App Store наразі нараховує понад 80 тисяч застосунків і модулів для різних версій та бізнес-задач, тому в багатьох випадках потрібне рішення можна знайти без розробки з нуля. 
• Інтеграція. Odoo має обмінюватися даними із зовнішньою системою. Наприклад, Odoo може обмінюватися даними з банком, службою доставки, сайтом, маркетплейсом, платіжною системою чи іншою обліковою програмою. 
• індивідуальна розробка — потрібну логіку неможливо реалізувати стандартними інструментами.

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

Крок 10. Тестування системи

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

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

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

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

Радимо звернути увагу на кейс Перехід з 1С на Odoo з модулем “Облік для України” у виробництві дронів

Крок 11. Навчання користувачів

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

• короткі покрокові інструкції;
• практичні сценарії в тестовій базі;
• короткі відео для повторюваних операцій;
• FAQ із типовими питаннями.

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

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

Крок 12. Модель та план запуску

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

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

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

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

• коли припиняється введення нових даних у 1С/BAS;
• коли виконується фінальне вивантаження;
• хто завантажує залишки й відкриті операції в Odoo;
• хто перевіряє перенесені дані;
• коли перемикаються інтеграції;
• коли користувачі отримують доступ до робочої бази;
• хто відповідає за підтримку після запуску;
• за яких умов запуск зупиняється або відкочується.

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

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

Крок 13. Запуск системи та стабілізація роботи

Вітаємо, ви вже на новому рівні автоматизації та розвитку свого бізнесу! 

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

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

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

Радимо також до прочитання статтю Цифрова трансформація бізнесу починається з команди. Сила внутрішньої підтримки у змінах

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

Хто має входити до команди проєкту з міграції з 1С на Odoo?

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

Для складних проєктів окремо можуть знадобитися QA-фахівець, DevOps або інфраструктурний спеціаліст. У невеликій команді одна людина може поєднувати кілька ролей. 

Практична порада. До старту проєкту складіть таку таблицю для розуміння, хто за що відповідає та до кого варто безпосередньо звернутися. Якщо за один результат відповідають “усі”, найімовірніше, фактично за нього не відповідає ніхто.

Підсумковий чекліст

Завантажте компактний робочий чекліст усіх етапів міграції для використання як контрольний список проєктуЗавантажити

Якщо у вас залишились питання, залишайте його у форму. Ми оперативно зв'яжемося та надамо необхідну інформацію.