Власник МСБ зрозумів, що Excel вже не справляється. Прибуток на папері не сходиться з реальністю, склад живе своїм життям, кожен звіт — це година ручної праці. Час обирати ERP-систему. Він відкриває Google, читає 5-7 порівнянь — і губиться. Одні статті — рекламні від вендорів. Інші — академічні переліки на 30 критеріїв, де “інтуїтивний UI” стоїть поруч з “архітектура мікросервісів”.

Цей пост — спроба дати інший формат. Не 30 критеріїв, а 10 конкретних питань, які власник повинен задати собі і вендору перед тим, як підписувати договір. Якщо хоча б на 3 з них відповідь “не знаю” або вендор уникає прямої відповіді — це сигнал зупинитися і подивитися ще варіанти.

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

З чого почати — з вибору вендора чи з аналізу свого бізнесу?

Спочатку — аналіз свого бізнесу. Без розуміння власних процесів будь-яка демо виглядає однаково красиво. Перш ніж дивитися на вендорів, треба самому собі відповісти на питання 1-3 нижче. Інакше демо вас зачарує дизайном, а потім виявиться, що ключового модуля немає або він “буде у наступній версії”.

Блок 1. Питання, які треба задати собі

1. Які процеси автоматизуємо в першу чергу?

Коротко: Один процес чи декілька? Якщо все одразу — це класична помилка, через яку провалюються ERP-проекти.

Малий бізнес зазвичай має 2-4 ключові процеси: склад, продажі, фінанси, виробництво, сервіс, оренда. Вибір “які з них автоматизувати в першу чергу” визначає не лише модулі ERP, а й бюджет та терміни.

Сигнал ризику: “автоматизуємо все одразу за 1 місяць”. У реальності так не буває. Адекватний підхід — фаза 1 (один-два критичні процеси, базовий облік), фаза 2 і далі — нарощування.

2. Скільки користувачів сьогодні і через 2 роки?

Коротко: 3, 10, 30 чи 100? Різні системи оптимізовані під різну кількість, і ціна по-різному “вистрелює” при рості.

Кількість користувачів визначає не лише модель ліцензування (за користувача, за модуль, flat), а й архітектурні вимоги. Більшість вендорів має ціну, яка росте нелінійно — за рахунок додаткових модулів і платних опцій при певних порогах. Деякі (включно з ERPJS) тримають пряму пропорційну ціну за користувача без зміни тарифу.

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

Сигнал ризику: вендор не питає про планований ріст. Це означає, що ціна може “вистрелити” пізніше, коли ви вже застряли в системі.

3. Які 3-5 звітів власник хоче бачити щодня?

Коротко: Назвіть 3-5 звітів, які хочете бачити щодня. Якщо не можете — це перша задача перед вибором ERP.

Конкретні приклади звітів власника: маржинальність по групах товарів, оборотний капітал, top-10 боржників, рух коштів за тиждень, продажі по менеджерах. У кожного бізнесу — свій набір.

Важливий нюанс: не питайте вендора “чи є у вас такий звіт?” — навіть якщо є, у вас він буде свій (інші розрізи, інші фільтри). Запитайте інакше: попросіть показати на демо, як саме вводяться дані для вашого ключового звіту — побачите чи передбачені в інтерфейсі розрізи, аналітики, об’єкти, які вам потрібні. Якщо дані вводяться у потрібній структурі — побудувати звіт це питання техніки (1-3 дні роботи). Якщо ні — звіт не з’явиться навіть якщо вендор обіцяє: будуть прогалини, неточності.

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

Блок 2. Питання, які треба задати вендору

4. Чи покриває система мої критичні процеси без кастомізації?

Коротко: Якщо так — стандартний шлях. Якщо ні — наскільки гнучко доопрацьовується? Скільки коштує допрацювання?

Жодна ERP-система не покриває 100% потреб конкретного бізнесу з коробки. Питання — скільки відсотків покриває, і як добудовується решта. У ERP-світі є дві крайні моделі: “монолітні” системи з закритим кодом (доопрацювання можливе тільки через вендора, часто дорого) і гнучкі платформи з відкритою архітектурою.

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

5. SaaS чи on-premise — яка модель для вас критична?

Коротко: SaaS — швидко стартувати, мінімум IT-витрат, але дані у вендора. On-premise — повний контроль і безпека, але потрібен власний сервер.

Деякі вендори дають тільки одне з двох — це обмеження. Якщо вендор пропонує лише SaaS — ви назавжди залежите від його сервера, цін і існування. Якщо лише on-premise — у вас немає легкого старту “спробувати малою кров’ю”.

Найгнучкіший варіант — коли є обидві опції, і клієнт може почати з SaaS, а перейти на on-premise коли стане критично, або навпаки. Або одразу стартувати з on-premise, якщо бізнес серйозний і дані критичні. Деталі — у пості Відкритий код в ERPJS: SaaS чи on-premise з контролем.

Сигнал ризику: вендор каже “SaaS — єдиний правильний шлях, on-premise це минуле століття” АБО навпаки “on-premise — це безпека, SaaS не годиться”. Обидві моделі мають своє місце.

6. Чи відкритий код бізнес-логіки? Що буде, якщо вендор закриється?

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

Це питання здається теоретичним, поки не стає реальним. SaaS-сервіси для бізнесу закриваються регулярно. Що далі — залежить від поєднання трьох факторів: SaaS чи on-premise, відкритий чи закритий код, і як працює ліцензування:

• SaaS, закритий код: повна зупинка. Дані теоретично можна забрати у вигляді бекапу БД, але без UI вони безкорисні. У підсумку — місяці хаосу і перенавчання.
• On-premise з онлайн-ключем, закритий код: коли ключ перестає поновлюватися, система може взагалі не запуститися. Без оновлень і підтримки — навіть якщо вдалося запустити, будь-яка проблема залишається без вирішення.
• On-premise з відкритим кодом бізнес-логіки і офлайн-fallback ліцензії: доступ до даних збережено навіть без вендора (наприклад, базовий read-only або обмежений однопользовательський режим). Цього достатньо щоб не залишитися без даних і мати час спокійно підготуватися до переходу на іншу систему. Це не “повна свобода”, але реальний план Б на випадок проблем з вендором.

Сигнал ризику: вендор каже “у нас закритий код і немає on-premise” — повна залежність. Або є on-premise, але “ключ онлайн, без поновлення нічого не запускається” — на практиці теж залежність, тільки прихована. Питайте конкретно: “що буде з моїм доступом до даних, якщо ми завтра припинимо співпрацю?”

7. Які інтеграції вже готові у вендора, і скільки коштуватимуть ті, які треба робити під вас?

Коротко: Не існує вендора, у якого готові ВСІ інтеграції. Важливе питання — які 1-2 інтеграції критичні для вашого бізнесу: вони вже є чи їх треба робити з нуля.

Критично-важливі для більшості МСБ:

• Банк-клієнт — для будь-якого бізнесу з банківськими операціями
• Нова Пошта / Укрпошта — для торгівлі з доставкою (детальніше про інтеграцію Нової Пошти)
• ПРРО (Чекбокс або подібне) — для роздрібу
• Маркетплейси (Rozetka, Prom) — для онлайн-торгівлі

Якщо ваш ключовий сервіс уже інтегрований — це 1-2 тижні економії на впровадженні. Якщо ні — рахуйте: години програміста × ставка + час тестування.

Сигнал ризику: вендор каже “інтегруємо з будь-чим” без переліку готових. Питайте конкретно: “З чим у вас вже працює інтеграція? Можете показати приклад роботи у клієнта?” Чесна реальність — жоден вендор не покриває увесь ринок. Розумна стратегія — кілька реально працюючих інтеграцій плюс готовність допилити ваш кейс.

Блок 3. Питання про економіку проекту

8. Скільки реально коштує перший рік?

Коротко: Не “ліцензія”, а “ліцензія + впровадження + кастомізація + навчання”. Часто впровадження дорівнює 1-2 річним ліцензіям.

Три статті витрат, які часто приховують при першій консультації:

1. Впровадження — налаштування системи під ваші процеси, міграція даних. Може бути від кількох тисяч до десятків тисяч гривень залежно від обсягу.
2. Кастомізація — доопрацювання модулів, специфічні звіти, нестандартна логіка. Зазвичай оплачується погодинно.
3. Навчання користувачів — реальний час, який треба закласти. Без навчання система простоюватиме.

Як рахується ціна: за користувача, за модуль, чи flat? Це теж впливає на загальну вартість при рості.

Сигнал ризику: “ціна тільки після консультації” без верхньої планки. Адекватний вендор може назвати хоча б діапазон (“від X до Y за конфігурацію подібного бізнесу”).

9. Скільки часу від договору до того моменту, коли я почну реально працювати в системі?

Коротко: Не плутайте “тривалість впровадження” з “часом до старту роботи”. Адекватний вендор ділить проект на фази: базовий облік стартує за 2-4 тижні, повна функціональність добудовується наступні 3-12 місяців.

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

Краще почати працювати в системі у обмеженому функціоналі і нарощувати, ніж 6 місяців налаштовувати “ідеальну” систему перед першим логіном. Раннє використання — це ще й шанс зрозуміти, що насправді потрібно (часто на старті здається одне, а в реальній роботі виявляється інше).

Сигнал ризику не “2 тижні”, а:

• Вендор обіцяє запустити весь функціонал за місяць — буде халтура.
• Вендор не ділить проект на фази — застрягне процес (“ще трохи допрацюємо, ще трохи”).

Адекватний вендор скаже: “Базовий облік — 2-4 тижні до старту. Далі модуль X — місяць, модуль Y — два, всього орієнтовно 4-6 місяців до повного скопа залежно від темпу з вашого боку.”

10. Як буде виглядати вихід з системи, якщо вирішу мігрувати?

Коротко: Чи можу забрати свої дані? У якому форматі? Чи можу продовжити користуватися, якщо припиню платити вендору?

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

У on-premise моделі з відкритим кодом і офлайн-fallback ліцензії — система фізично у вас і базовий доступ до даних залишається навіть без вендора. Не обов’язково в режимі “як раніше з усіма користувачами одночасно”, але достатньо, щоб не залишитися без даних і мати час спокійно підготуватися до міграції на іншу систему.

Сигнал ризику: ухильна відповідь на пряме питання про вихід.

Що робити, якщо співпало 3+ червоних прапорців?

Не підписувати договір “поки знижка”. Тиск часом — стандартний прийом, на який спокушаються власники під емоцією: “та що там, з’явилася знижка, поспішимо”. Реальність — система буде з вами 3-5 років мінімум, тиждень-два на додаткові питання не змінять нічого.

Конкретні кроки:

1. Просіть письмово відповіді на спірні питання — не “у консультанта в чаті”, а в комерційній пропозиції.
2. Подивіться хоча б 2-3 інші системи для порівняння. Робиться це не для того, щоб обрати найдешевшу, а щоб зрозуміти ринок і калібрувати ціни/терміни.
3. Попросіть референси чинних клієнтів і самостійно з ними зв’яжіться — телефоном, не через організовану зустріч під наглядом вендора. Питайте конкретно: що болить через рік користування, що довелось доробляти, чи виправдалися початкові обіцянки за термінами і бюджетом.

Як ці 10 питань виглядають у ERPJS?

Коротко по блоках — щоб ви могли порівняти з іншими вендорами:

• Бізнес-процеси: документообіг (продажі, закупівлі, склад, виробництво, оренда, сервіс), фінансовий і управлінський облік, проектний менеджмент. CRM є, але це не наша основна сильна сторона.
• SaaS і on-premise — обидві опції з самого початку, без перепідписання договору. Можна почати з SaaS і перейти на on-premise, або одразу стартувати з on-premise.
• Звіти. Стандартний набір (оборотно-сальдові, рух коштів, продажі) є. Реальний підхід — спочатку правильно збираємо дані, потім будуємо ті звіти, які потрібні саме вашому бізнесу. Часто це 1-3 дні роботи на звіт.
• Інтеграції. Готові: Нова Пошта (ТТН за 20 секунд), банк-клієнт (вивантаження виписки з коробки; створення платежів — робили під проекти), Чекбокс (ПРРО), маркетплейси Rozetka та Prom. ЕДО і деякі інші — поки немає, робимо під кейс клієнта з прозорою оцінкою годин.
• Код бізнес-логіки відкритий в on-premise — можна найняти стороннього JS-розробника. Деталі: Відкритий код в ERPJS.
• Доступ до даних при розриві співпраці. Навіть без активного ліцензійного ключа у клієнта залишається базовий доступ: один користувач з повним read+write режимом, решта — read-only. Це не “робота як раніше”, але гарантія що ви не залишитеся без своїх даних, навіть якщо з нами щось трапиться.
• Терміни: базовий облік стартує за 2-4 тижні, повна функціональність — 3-12 місяців залежно від скопу. Працюємо фазами.
• Ціна: SaaS — на сторінці тарифів, без “приховайте до консультації”. On-premise — після короткої консультації по конфігурації.

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