Владелец малого бизнеса понял, что 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 — после короткой консультации по конфигурации.

Часто задаваемые вопросы