Перші 90 днів після впровадження Odoo

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

Одразу зазначимо, що 90 днів в даному контексті – це більше управлінська рамка для планування. Нормативу тривалості стабілізації системи не існує. Мова може йтися про кілька тижнів, тому радимо орієнтуватися на показники, а не на дату.

Що насправді відбувається після запуску ERP?

Отже, проєкт перейшов на етап go-live: Odoo працює, користувачі виконують операції, але поступово можуть виявлятися помилки в даних, налаштуваннях або перенесених процесах.

Найчастіше команда стикається з такими сценаріями:

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

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

Корисно буде перейти та ознайомитися зі статтею Впровадження ERP: покроковий посібник для бізнесу

Що таке Hypercare?

Після go-live важливо розрізняти кілька форматів підтримки, оскільки вони мають різні цілі та зони відповідальності.

1. Early Life Support – період, коли команда перевіряє, як налаштовані процеси працюють уже на реальних операціях і даних.
2. Hypercare – посилена підтримка в перші тижні після запуску. Команда швидко розбирає інциденти, виправляє помилки та стежить за критичними процесами.
3. Warranty – гарантійні умови проєкту, які визначають, які дефекти виправляє виконавець і які роботи входять у його відповідальність.

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

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

Early Life Support: перевірка системи після запуску

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

Наскрізна перевірка процесів

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

У першу чергу перевіряють основні операційні цикли:

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

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

Звірка перенесених даних

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

Насамперед перевіряють:

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

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

Українська локалізація потребує окремої перевірки

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

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

Дізнайтеся більше про Українське виробництво під час війни: Адаптація, автоматизація та нові точки зростання

Права доступу й підтримка користувачів

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

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

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

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

Hypercare: аналіз проблем і роботи користувачів

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

Перше закриття місяця

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

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

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

Шукаємо причини повторюваних проблем

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

Як зрозуміти, чи команда справді працює в Odoo?

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

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

Такі обходи не завжди означають проблему системи. Причини можуть бути різними:

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

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

"Навіть технічно добре реалізований проєкт може зупинитися через опір команди, якщо робота зі змінами ведеться несистемно. Тому внутрішня підтримка, комунікація і залучення людей мають бути частиною самого впровадження", – зазначає Олена Кузмічова, співзасновниця Ukrainian ERP Forum

Формування беклогу

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

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

Якщо раптом вперше чуєте про ERP переходьте та читайте Практичний гайд по ERP-системах. Як працює, кому потрібна та що дає бізнесу

Warranty: перехід від стабілізації до розвитку

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

Порівняння показників у динаміці

Один показник фіксує стан системи в конкретний момент, але не показує, чи стає робота кращою. Тому після появи даних хоча б за два періоди варто порівняти ті самі KPI.

Наприклад, можна відстежувати:

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

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

Перегляд доробок після запуску

Для кожної доробки можна прийняти одне з трьох рішень:

• залишити без змін;
• замінити стандартною функціональністю Odoo;
• прибрати, якщо вона більше не потрібна.

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

План наступних змін

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

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

Планування оновлень Odoo

Після стабілізації системи варто включити оновлення версій у довгостроковий план. Odoo надає стандартну підтримку основним версіям протягом трьох років. За актуальним календарем Odoo 19.0, випущена у вересні 2025 року, планово підтримується до вересня 2028 року. Для Odoo 17.0 завершення стандартної підтримки заплановане на вересень 2026 року.

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

Актуальні строки підтримки версій Odoo можна перевіряти в офіційній документації Odoo.

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

KPI після запуску Odoo: що вимірювати та з чим порівнювати

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

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

Дослідження McKinsey на вибірці 82 публічних компаній показує, що навіть успішні трансформації реалізують ефект поступово: близько 28% очікуваної вартості – за три місяці, 57% – за шість і 74% – за дванадцять.

Обовязково до прочитання Як працює аналітика в Odoo? Покроковий туторіал по BI

Чекліст завершення перших 90 днів: 12 кроків

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

1. критичні бізнес-процеси проходять від початку до кінця без системних збоїв;
2. початкові залишки та перенесені дані звірені й погоджені;
3. перше закриття місяця виконано без критичних помилок;
4. кількість повторюваних інцидентів зменшується;
5. основні операції виконуються в Odoo без постійних обхідних таблиць і ручних сценаріїв;
6. права доступу переглянуті після запуску;
7. користувачі знають, куди звертатися з типовими питаннями;
8. внутрішня команда може самостійно опрацьовувати більшість стандартних звернень;
9. доробки розділені на обов’язкові виправлення та задачі для подальшого розвитку;
10. сформований пріоритетний беклог наступних змін;
11. визначені KPI, за якими команда відстежуватиме роботу системи далі;
12. майбутні оновлення Odoo враховані в плані розвитку.

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