Чому я іноді рекомендую закрити ERP-проєкт. Досвід аудиту невдалих впроваджень Odoo

Дев'ять місяців тому в одній сервісній компанії стартувало впровадження ERP. Запуск обіцяли через чотири-п'ять місяців. На дев'ятому місяці компанія все ще не могла оформити в новій системі жодного замовлення — весь облік, як і раніше, вівся в Excel. Інтегратор укотре повідомив: «Ще два місяці — і вже точно буде запуск». Проблема в тому, що фразу «вже точно» керівник чув уже втретє.

Саме в цей момент він звернувся до мене з питанням, яке я чую найчастіше: продовжувати чи зупинятися?

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

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

Як зрозуміти, що ERP-проєкт зайшов у кризу

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

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

Три кейси з моєї практики

Кейс 1. Сервісна компанія: 9 місяців без базового результату

Компанія з обслуговування кавового обладнання, близько 25 користувачів. До впровадження весь облік вели в Excel. Завдання було простим: клієнти, замовлення, статуси, базові операції.

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

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

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

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

Кейс 2. Виробник електроніки: бюджет ×2 і зміна системи

Виробнича компанія, близько 20 користувачів. Облік — Excel плюс частково 1С. Гострої кризи не було: компанія просто відчула межі масштабування і вирішила переходити на ERP планово, за 6–8 місяців.

Підписуйтеся на наші соцмережі

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

Тут питання «зупиняти чи ні» вже не стояло: тренд витрат був очевидним. Питання було інше — що робити далі і як вийти з ситуації з максимальною користю.

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

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

Кейс 3. Виробник дронів: із Google Таблиць до запуску за місяць

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

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

Клієнт поставив питання руба: яку систему обирати. Для серійного виробництва з високими вимогами до безпеки даних я порадив BIMP — на сьогодні це система, яка найактивніше з відомих мені розвиває функціонал саме під виробників безпілотних систем.

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

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

Кейс 4. Коли я рекомендую продовжити впровадження

Щоб не склалося враження, що моя відповідь завжди «міняйте систему»: були кейси, де я рекомендував саме дотиснути поточний проєкт.

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

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

Проблема не в Odoo

У всіх трьох перших кейсах впроваджували Odoo, і тут потрібно сказати прямо: проблема була не в Odoo як платформі.

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

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

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

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

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

Як проходить ERP реанімація. Моя методика

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

Етап 1. Інтерв'ю із замовником. Що компанія хотіла вирішити, що ставила інтегратору як задачу, що зараз найбільше заважає бізнесу, чого система досі не вміє.

Етап 2. Аналіз бізнесу. Галузь, масштаб, тип виробництва, складність процесів, реальний рівень необхідної кастомізації. Головне питання цього етапу: чи відповідає обрана система реальній складності бізнесу?

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

Етап 4. Порівняння двох шляхів. Компанія отримує чесне зіставлення: скільки часу, грошей і ризиків коштує завершення поточного проєкту — і скільки коштує альтернатива. З конкретними датами та roadmap, а не з «ще трохи».

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

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

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

Відповім на питання, які мені часто задають

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

Як зрозуміти, що ERP-проєкт провалюється, якщо інтегратор запевняє, що все за планом? Дивіться на факти, а не на звіти: чи називається конкретна дата запуску, чи можете ви вже сьогодні виконати в системі базові операції, скільки разів переносилися терміни, як змінився бюджет відносно початкового. Якщо «план» існує лише на словах — це і є ознака проблеми.

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

Коли обирати вертикальну (галузеву) ERP замість універсальної? Якщо ваші бізнес-процеси типові для галузі, ви переходите з Excel, Google Таблиць чи стандартної 1С і вам важливі швидкий запуск та прогнозований бюджет — галузева система майже завжди буде кращим вибором. Універсальна платформа виправдана за справді унікальних процесів, які не покриває жодне готове рішення.