ERP і CRM на замовлення чи готовий SaaS: як вибрати

Більшість компаній, що зростають, доходять до моменту, коли таблиці, пошта й групи в месенджерах уже не тримають бізнес купи. Тоді постає складніше запитання: підписатися на готовий SaaS-продукт чи замовити програмне забезпечення під те, як працюєте саме ви? У цьому гайді пояснюємо, що роблять ERP, CRM і системи документообігу, як чесно зважити варіанти і як упровадити той, який ви оберете.

Головне

Для більшості малих і середніх компаній найбезпечніший шлях гібридний: купувати підтримуване ПЗ чи SaaS для стандартних задач на кшталт бухгалтерії й виставлення рахунків і розробляти на замовлення лише ті процеси, які вирізняють вас з-поміж інших. Вирішуйте за шістьма критеріями (унікальність процесу, інтеграції, користувачі й права доступу, право власності на дані, довгострокові витрати й залежність від постачальника), упроваджуйте через опис процесів, MVP і етапи та переконайтеся, що дані й код лишаються вашими, хоч би який шлях ви обрали.

Ознаки того, що таблиць і чатів уже не вистачає

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

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

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

ERP, CRM і системи документообігу: що робить кожна

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

ERP (планування ресурсів підприємства) керує операціями й грошима: закупівлі, склад, замовлення клієнтів, рахунки, а часто й бухгалтерія, виробництво та кілька складів.
CRM (керування взаєминами з клієнтами) керує клієнтами й продажами: контакти, ліди, воронка, комерційні пропозиції, нагадування й історія кожної розмови.
Системи електронного документообігу й погоджень (СЕД) керують внутрішніми процесами: погодження закупівель, витрат чи відпусток, спільні документи й задачі. Частину цього вже покривають пакети на кшталт Microsoft 365, Google Workspace, DingTalk чи Feishu.

Найважливіше, щоб ці системи мали спільні дані: одна картка клієнта, один список товарів, один набір цін.

Три шляхи: готове рішення, розробка на замовлення чи гібрид

Шляхів три: підписатися на готове ПЗ чи SaaS, замовити розробку системи або поєднати обидва варіанти в гібриді.

Готове ПЗ і SaaS. Ви підписуєтеся на наявний продукт, наприклад Odoo чи NetSuite як ERP або HubSpot чи Salesforce як CRM, і налаштовуєте його. Він перевірений і швидко запускається, оновленнями й безпекою займається постачальник, а платите ви зазвичай за користувача чи модуль. Компроміс: ви підлаштовуєтеся під продукт, а його дорожня карта належить постачальнику.

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

Гібрид. Використовуйте стандартне ПЗ для стандартних задач, а розробляйте там, де ви відрізняєтеся. Бухгалтерію, рахунки й зарплату зазвичай краще лишити підтримуваним продуктам, бо податкові правила й правила електронних рахунків різняться між країнами й змінюються. У ЄС, наприклад, пакет «ПДВ у цифрову епоху» (ViDA) (англійською), ухвалений 2025 року, з 1 липня 2030 року запроваджує цифрову звітність на основі електронних рахунків для транскордонних B2B-операцій. Навколо такого бухгалтерського ядра можна розробити синхронізацію з інтернет-магазином, портал замовлень для оптових клієнтів чи мобільний додаток для працівників складу. Платформу для самого магазину допоможе обрати наше порівняння Shopify, WooCommerce і розробки з нуля. ERP із відкритим кодом, як-от Odoo Community (ліцензія LGPLv3) чи ERPNext, — проміжний варіант: їх можна розгорнути на власному сервері й змінювати, але ваші зміни доведеться переносити через кожне оновлення.

Для багатьох малих і середніх компаній гібрид — розумний вибір за замовчуванням.

Шість критеріїв, які вирішують

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

Наскільки унікальний процес? Якщо це те, чим ви конкуруєте, наприклад індивідуальні ціни для клієнтів чи нестандартний виробничий процес, заганяти його в типове ПЗ буде дорого. Якщо він стандартний, як бухгалтерський облік, не винаходьте його заново.
Інтеграції. Випишіть усі системи, які мають обмінюватися даними: інтернет-магазин, маркетплейси, платежі, перевізники, бухгалтерія, банк, форми на сайті. Перевірте, чи є готові конектори й задокументовані API з прийнятними лімітами. Наприклад, правила використання API HubSpot (англійською) встановлюють денний ліміт викликів для приватно поширюваних застосунків залежно від тарифу: 250 000 на акаунт на Free і Starter, 625 000 на Professional і 1 000 000 на Enterprise. Саме в інтеграціях часто ховається справжня складність. Чистий API також значно спрощує подальше підключення ШІ-асистентів, наприклад через Model Context Protocol (MCP) (англійською), відкритий стандарт для підключення ШІ-застосунків до зовнішніх систем (див. також статтю що таке MCP-сервер і наші рішення зі ШІ).
Користувачі й права доступу. Оплата за кожне робоче місце дорожчає, коли систему час від часу використовують працівники складу, водії чи зовнішні партнери. Заздалегідь перевірте детальні права доступу (менеджери бачать лише своїх клієнтів, собівартість прихована від деяких ролей): деякі SaaS-продукти відкривають їх лише на дорожчих тарифах.
Право власності на дані. Де зберігаються дані і чи можете ви вивантажити їх усі, разом з історією та вкладеннями, у придатному форматі? Що станеться, коли ви скасуєте підписку? Якщо ви обробляєте персональні дані людей у ЄС, діє GDPR: провайдер, який обробляє ці дані від вашого імені, є обробником, і в посібнику для малого бізнесу (англійською) Європейської ради із захисту даних сказано, що відносини між контролером і обробником «мають регулюватися договором», який зазвичай називають угодою про оброблення даних (DPA).
Довгострокові витрати. Порівнюйте загальну суму за весь очікуваний строк роботи системи. Витрати на SaaS зростають через нові робочі місця, додаткові модулі, дорожчі тарифи (заради функцій на кшталт доступу до API) і зміну цін під час продовження. Витрати на ПЗ на замовлення складаються з початкової розробки (залежить від обсягу, ролей, бізнес-правил та інтеграцій), хостингу, оновлень безпеки й нових функцій. В обох випадках потрібні перенесення даних, навчання й час вашої команди.
Залежність від постачальника. У SaaS ризики — закриті формати даних, підвищення цін і скасовані функції. У ПЗ на замовлення — прив’язаність до одного розробника, бо ніхто інший не розуміє коду. Ліки від обох ризиків однакові: перевірене повне вивантаження даних, документація, поширені технології й договір, що передбачає ваш вихід.

Обсяг системи на замовлення: процеси, потім MVP, потім етапи

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

Опишіть поточні процеси. Простежте замовлення, закупівлю й запит клієнта від початку до кінця. Говоріть із людьми, які виконують роботу, а не лише з керівниками, і зберіть реальні бланки замовлень, рахунки й таблиці. Саме у винятках і обхідних шляхах ховаються вимоги.
Спростіть, перш ніж оцифровувати. Автоматизація заплутаного процесу лише змушує хаос працювати швидше.
Визначте MVP. Мінімально життєздатний продукт — найменша версія, що від початку до кінця замінює один реальний процес, наприклад замовлення, оновлення залишків і видаткову накладну для одного складу. Запишіть ролі, права доступу, ключові екрани, інтеграції та ті кілька звітів, якими люди справді користуються.
Упроваджуйте поетапно. Почніть із пілотної команди чи локації, виправте те, що вони знайдуть, а потім розширюйте. Кожен наступний етап додає модуль: закупівлі, CRM чи погодження.

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

Перенесення даних і залучення команди

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

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

Прийняття системи командою:

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

Вибір підрядника й пастки, яких варто уникати

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

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

Типові пастки:

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

Поширені запитання

Чи завжди ПЗ на замовлення дорожче за SaaS?

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

Чи можна почати із SaaS, а згодом перейти на систему на замовлення?

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

Кому має належати вихідний код системи на замовлення?

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

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

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