10 вопросов, которые нужно задать поставщику ERP до подписания
Подписание договора с поставщиком ERP — одно из самых долгосрочных решений в бизнесе. Средняя словацкая SMB-компания остаётся со своим поставщиком ERP 7 – 9 лет. Развод обычно дорог, болезнен и сопровождается потерей данных. Поэтому стоит до подписания провести несколько часов, задавая правильные вопросы, и ещё больше времени — внимательно читая ответы.
В этой статье вы найдёте 10 вопросов, которые наши консультанты рекомендуют всем клиентам. Это не «карманные» вопросы вроде «Какая цена?» (на это любой продавец ответит без раздумий), а более глубокие вопросы, которые отделяют серьёзных поставщиков от тех, с кем вы потом проведёте пять лет мучений.
1. «Какое API вы предоставляете и что через него можно делать?»
API — фундаментальный камень современной компании. Если у вашего ERP нет полноценного API, вы заперты в силосе, а будущая интеграция с интернет-магазином, бухгалтерией или зарплатной системой будет дорогой и хрупкой.
На что обращать внимание в ответе:
- REST или GraphQL? (Современные ERP обычно поддерживают оба)
- Какие операции доступны? Идеал — всё, что Вы видите в UI, можно сделать и через API. Если поставщик говорит «API есть, но только для некоторых функций», осторожно.
- Webhook? Event-driven интеграции в 2026 году — стандарт.
- Rate limiting и лимиты. Сколько API-вызовов в день? Платите ли за дополнительные?
- Документация. Запросите ссылку — если её не могут показать (или она «после подписания»), бегите.
Modulario предоставляет полностью документированное REST API со всеми CRUD-операциями, webhook и бесплатным лимитом 10 000 вызовов в день для каждого клиента.
Совет: В договоре требуйте гарантию, что API не будет отключён без 12-месячного предварительного уведомления. Некоторые поставщики в прошлом отключали старую версию API «немедленно», и у клиентов было 30 дней на реакцию. Это критично.
2. «Кому принадлежат данные и как я в любой момент могу их выгрузить?»
Владение данными — самый важный договорный вопрос. Данные, которые вы создаёте в ERP — счета, клиенты, склад, сотрудники, производство — ваши. Не поставщика. Но не всегда это явно прописано в договоре.
На что обращать внимание в ответе:
- «Данные ваши» (ничего иного не приемлемо)
- Какие форматы экспорта — идеал CSV, JSON, SQL dump плюс структурированные PDF-счета
- Как часто можно экспортировать — идеал неограниченно и в любой момент
- Есть ли «кнопка экспорта» в UI или только по запросу
- Включает ли экспорт исторические данные, логи и audit trail
Красные флаги:
- «Экспорт за плату»
- «Экспорт только по истечении гарантийного срока»
- «Формат экспорта наш проприетарный»
3. «Какова exit-стратегия — как это будет выглядеть, если я через 5 лет захочу уйти?»
Этот вопрос продавцы не любят слышать — поэтому Вы должны его задать. Серьёзный поставщик имеет exit-стратегию задокументированной и может показать её в стандартном договоре.
На что обращать внимание в ответе:
- Поэтапный план: сколько дней на экспорт, формат, помощь поставщика
- Стоимость миграции прочь: идеал бесплатно в первый год, номинальная плата в следующие
- Когда удаляются ваши данные: обычно 90 дней после окончания, но это должно быть чётко прописано
- Кто подписывает «данные переданы»: сертификат о приёме важен для вашего compliance
DORA и NIS2 в 2026 году требуют от финансовых учреждений и поставщиков критической инфраструктуры письменную exit-стратегию как условие договора. Даже если вы не банк, требуйте этого и вы.
4. «Какое у вас SLA и какова компенсация при его нарушении?»
Service Level Agreement (SLA) определяет, как часто система должна работать и что вы получите, когда не работает. Многие поставщики предлагают красивые «99,9 %», но в мелком тексте есть исключения (плановое обслуживание, форс-мажор, изменение инфраструктуры), которые превращают SLA в маркетинговое число.
На что обращать внимание в ответе:
- Реальное число uptime. 99,9 % = 8,7 часа простоя в год. 99,95 % = 4,4 часа. 99,99 % = 52 минуты.
- Что считается, а что нет. Плановое обслуживание вне рабочих часов обычно не учитывается. Справедливо. Но «форс-мажор» не должен включать проблемы облачного провайдера.
- Response time и resolution time. P1 критическая проблема — уведомление в течение часа, решение в течение 4 часов? Или просто «как можно скорее»?
- Компенсация. Service credit (скидка со следующего счёта) — стандарт. Конкретно — при 99,8 % получаете 10 %, при 99 % получаете 30 %.
5. «Что у вас в roadmap на ближайшие 18 месяцев?»
Хороший поставщик имеет публичный roadmap и может его показать. Не каждую деталь, но хотя бы основные оси развития — новые модули, интеграции, платформенные улучшения.
На что обращать внимание в ответе:
- Конкретность: «Q3 2026 — обновление мобильного приложения, Q4 2026 — модуль AI reporting» — хорошо. «Работаем над многим» — плохо.
- Фокус: Решает ли поставщик ваш сектор? Если вы строительная компания, а в roadmap видите только e-commerce модули, вы для них не целевая аудитория.
- Инновационность: В 2026 году roadmap должен содержать AI-ассистенцию, улучшения compliance (DORA, NIS2), mobile-first функции.
6. «Как вы решаете вопросы безопасности и где это аудитировано?»
Безопасность в 2026 году — не опциональная функция. Если у поставщика нет хотя бы базовых сертификаций и процессов, уходите.
На что обращать внимание в ответе:
- Сертификации: ISO 27001 сегодня — минимум. SOC 2 Type II — плюс. ISO 27701 (privacy) — бонус.
- Тесты на проникновение: минимум раз в год внешней компанией, отчёт по запросу (хотя бы управленческое резюме).
- Шифрование: AES-256 в покое, TLS 1.3 в движении.
- MFA: обязательно для администраторов, рекомендовано для всех.
- Backups: правило 3-2-1 (3 копии, 2 носителя, 1 off-site). RPO и RTO в часах, не в днях.
- Incident response: 24-часовое уведомление клиентов, 72-часовое уведомление органов по NIS2.
7. «Сколько клиентов из моей отрасли / моего размера используют вашу систему?»
Референсы — золото. ERP, который хорошо работает для маркетингового агентства, может быть адом для производственной компании — и наоборот. Спрашивайте конкретно.
На что обращать внимание в ответе:
- Поставщик охотно предоставит 3 – 5 референсных контактов из вашего сектора и размера.
- Идеал — некоторые доступны для прямого звонка, не только текстовый референс.
- Когда позвоните, спрашивайте: «Что вас в системе больше всего раздражает?» и «Если бы вы выбирали снова, купили бы снова?»
8. «Как выглядит типичный onboarding и внедрение у компаний моего размера?»
Плохое внедрение убьёт даже лучшую систему. Хорошее внедрение спасёт даже среднюю систему.
На что обращать внимание в ответе:
- Длительность: 2 – 8 недель для SMB, 3 – 6 месяцев для средней компании. Что-либо короче или дольше требует объяснения.
- Фазы: kick-off, миграция данных, настройка, тестирование, обучение, go-live, стабилизация.
- Команда: руководитель проекта на вашей стороне + консультант на стороне поставщика + технический специалист. Если всё на одном человеке, ничего хорошего не будет.
- Метод: Agile с 2-недельными спринтами или waterfall. Оба работают при правильном управлении.
- Цена: фиксированная или T&M? Фиксированная даёт предсказуемость, T&M даёт гибкость. Гибрид (фикс для стабильных частей, T&M для кастомизации) — идеал.
9. «Что вы делаете, когда клиент просит кастомизацию, которую вы не планируете?»
Отличный вопрос, который раскрывает культуру поставщика. Одни игнорируют (жёсткий монолит), другие всё «запрограммируем вам» (но тогда у вас кастомная версия, которую нельзя обновлять).
На что обращать внимание в ответе:
- Product roadmap: если запрос актуален для нескольких клиентов, идёт в roadmap (3 – 12 месяцев).
- Кастомизация через конфигурацию: хороший современный ERP имеет богатую конфигурацию — кастомные поля, кастомные workflows, кастомный reporting — без вмешательства в код.
- Plugin / script: для специфических нужд возможность написать собственный плагин или скрипт (или через партнёра).
- Hard-coded кастомизация: последний вариант, только если действительно нет другого пути, и должно быть в договоре прописано, как это поддерживается при обновлениях.
10. «Что произойдёт, если ваша компания обанкротится или её кто-то купит?»
Неприятный, но ключевой вопрос. Ваш ERP — критическая инфраструктура: если поставщик падает, вы тоже падаете.
На что обращать внимание в ответе:
- Финансовая стабильность: запросите две последние бухгалтерские отчётности (они в публичном реестре, так что показать не проблема).
- Количество сотрудников и год основания. Если у поставщика 3 сотрудника и год на рынке, риск иной, чем у компании с 50 людьми и 10 годами опыта.
- Escrow: некоторые поставщики предлагают source code escrow — в случае банкротства у вас право на исходный код. Для критических систем рекомендуем.
- M&A сценарий: что произойдёт, если их купит более крупная компания? Гарантия преемственности продукта минимум 36 месяцев — справедливое требование.
Бонус — как проверить ответы
Недостаточно услышать ответ. Нужно его проверить. Четыре техники, которые работают:
- Trial или sandbox. Минимум 14 дней, идеал 30 дней с реальными данными.
- Proof of Concept (PoC). Для важных интеграций потребуйте, чтобы поставщик показал рабочий PoC ещё до подписания.
- Техническое due diligence с собственным IT или внешним консультантом. 4 – 8 часов работы, 500 – 1 500 EUR, может сэкономить десятки тысяч.
- Визит к референсу. Проведите полдня у существующего клиента. Видите систему в продуктиве, общаетесь с пользователями, чувствуете реальность.
Заключение — честность важнее коммерческого таланта
При выборе ERP не начинайте с доверия — начинайте с вопросов. Поставщик, который честно отвечает и на неприятные вопросы (что произойдёт, если обанкрочусь, как выглядит exit-стратегия), надёжнее того, кто всё «переключает на маркетинговое видео». Десять вопросов выше помогут Вам в течение одной 90-минутной встречи понять, с кем имеете дело.
Если хотите быть уверены, что входите в договор с открытыми глазами, скачайте наш детальный чек-лист с местом для заметок — мы подготовили его именно для этих десяти областей. Если вас интересует, как на эти вопросы отвечает Modulario, забронируйте 45-минутное демо — ответы получите письменно и подписанные.