Практическое руководство по выбору команды для разработки 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-проектов ведётся удалённо. Важнее качество процесса коммуникации, чем физическое присутствие. Еженедельные созвоны + система задач вполне заменяют офис.
Что делать если проект идёт не так как ожидалось?+
Фиксируйте проблемы письменно сразу как они появляются. Требуйте встречи для обсуждения. Если разработчик уклоняется — апеллируйте к договору и срокам. Эскалируйте до руководителя студии.
Стоит ли брать разработчика, предложившего минимальную цену?+
Только если понимаете почему цена ниже: меньший скоуп, другой стек, другой уровень команды. Если скоуп одинаковый, а цена втрое меньше — скорее всего, это нереалистичная оценка которая вырастет после подписания.
Нужен ли нам собственный технический директор или менеджер проекта?+
Желательно иметь человека на стороне клиента который понимает процессы и может принимать решения быстро. Это ускоряет разработку и снижает стоимость. Не обязательно технический специалист — достаточно вовлечённого менеджера.