Как выбрать разработчика ERP: 8 критериев которые реально важны

📅 7 июля 2025 г.⏱ 10 мин чтения

Практическое руководство по выбору команды для разработки ERP. Что проверять, какие вопросы задавать, на что обратить внимание в договоре.

Выбор разработчика ERP — одно из самых важных решений в проекте. Ошибка здесь стоит дорого: потраченные деньги, потраченное время и система которая не работает. Как отличить надёжного подрядчика от того кто «возьмёт деньги и пропадёт»?

Критерий 1: Опыт именно в ERP, а не «мы делаем всё»

ERP-разработка — специфичная область. Разработчик должен понимать учёт, бизнес-процессы, интеграции с бухгалтерскими системами. Студия которая делает «сайты, мобильные приложения, ERP, блокчейн» — красный флаг. Спросите: сколько ERP проектов сделали за последние 2 года? Можете показать?

Критерий 2: Портфолио с реальными деталями

Хороший портфолио — не скриншоты интерфейсов, а описание задачи, решения и результата. Что именно автоматизировали? Какие бизнес-проблемы решили? Можно ли поговорить с клиентом? Разработчик уверенный в своей работе даст контакт заказчика.

Критерий 3: Процесс аналитики перед оценкой

Если компания называет цену за ERP-систему за 30 минут разговора — она либо не понимает задачу, либо даёт заведомо нереалистичную оценку. Качественная оценка требует изучения процессов: вопросов о структуре, объёмах данных, интеграциях. Если этого нет — бегите.

Критерий 4: Фиксированная цена и детальное ТЗ

Хороший разработчик предложит фиксированную цену после составления детального ТЗ. Формат «время и материалы» (T&M) переносит финансовый риск на вас. Это не значит что T&M плохой — он подходит для гибких проектов — но требует доверия и прозрачности.

Критерий 5: Кому принадлежит код

Исходный код должен принадлежать вам — это прямо прописывается в договоре. Некоторые разработчики пишут что передают «право использования», но не исходный код. Это создаёт зависимость: вы не можете нанять другого разработчика без потери всего написанного.

⚠️

Проверьте договор: ищите пункт о передаче исключительных прав на результаты разработки. Без этого пункта код технически остаётся у разработчика.

Критерий 6: Технический стек

Современный надёжный стек: Python (FastAPI/Django) или Node.js для бэкенда, React или Vue для фронтенда, PostgreSQL для базы данных. Экзотический или устаревший стек (PHP 5, .NET Framework 2.x, proprietary платформы) — риск для будущей поддержки и развития.

Критерий 7: Гарантийная поддержка

Минимум 6–12 месяцев гарантийной поддержки с исправлением ошибок — стандарт. Если разработчик не даёт гарантию — это сигнал о неуверенности в качестве своей работы.

Критерий 8: Поэтапная сдача и прозрачность

Хороший разработчик сдаёт работу итерациями: каждые 2–4 недели вы видите работающий функционал, можете проверить и дать обратную связь. Не «пропадает на 6 месяцев и показывает результат». Поэтапная сдача снижает риски и позволяет своевременно скорректировать направление.

Вопросы которые стоит задать потенциальному разработчику

Как будет организован процесс — этапы, демонстрации, обратная связь?
Кто конкретно будет работать над нашим проектом, можно познакомиться с командой?
Что происходит с кодом если мы расстанемся в середине проекта?
Как вы обрабатываете изменения в ТЗ?
Есть ли клиент которому мы можем позвонить напрямую?
На каком стеке будет написана система и почему именно на нём?

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

Стоит ли выбирать крупную студию или небольшую команду?+

Крупная студия — выше накладные расходы (офис, менеджмент), ваш проект может быть «небольшим» для них. Небольшая команда — больше вовлечённости, но проверьте стабильность: команда 3 человека уязвима к уходу ключевых людей.

Как проверить компанию до подписания договора?+

Попросите тестовое задание (небольшую задачу за оплату), изучите публичные репозитории на GitHub, поговорите с реальными клиентами, проверьте юридическое лицо (ИНН, история компании).

Можно ли выбрать разработчика из другого города?+

Да. Большинство ERP-проектов ведётся удалённо. Важнее качество процесса коммуникации, чем физическое присутствие. Еженедельные созвоны + система задач вполне заменяют офис.

Что делать если проект идёт не так как ожидалось?+

Фиксируйте проблемы письменно сразу как они появляются. Требуйте встречи для обсуждения. Если разработчик уклоняется — апеллируйте к договору и срокам. Эскалируйте до руководителя студии.

Стоит ли брать разработчика, предложившего минимальную цену?+

Только если понимаете почему цена ниже: меньший скоуп, другой стек, другой уровень команды. Если скоуп одинаковый, а цена втрое меньше — скорее всего, это нереалистичная оценка которая вырастет после подписания.

Нужен ли нам собственный технический директор или менеджер проекта?+

Желательно иметь человека на стороне клиента который понимает процессы и может принимать решения быстро. Это ускоряет разработку и снижает стоимость. Не обязательно технический специалист — достаточно вовлечённого менеджера.