Хотим кастомную CRM под себя — как устроен процесс разработки и что нужно подготовить с нашей стороны?

Своя CRM — звучит заманчиво, но пилить всё с нуля вместо допила готовых платформ — это дикий риск. Кто будет поддерживать код, когда команда разработки сменится? Куча компаний через пару лет просто выбрасывают свои самописные админки на помойку, потому что не могут накатить патчи безопасности или дописать функционал под новых сотрудников.

Мы в UK с оптовой компанией на 14 человек пошли ровно по этим граблям. На старте договаривались на 35.000 GBP, а из-за постоянных «хотелок» в процессе и затыков с интеграцией бухгалтерии улетели в 52.000 GBP, и вместо 5 месяцев всё растянулось на 11. Не зафиксируете жестко скоуп — ценник улетит в космос моментально.

С агентством сразу прописывайте в договоре демонстрацию промежуточных рабочих версий каждые пару недель. Ни в коем случае не соглашайтесь на вариант «мы ушли кодить и вернемся через 5 месяцев с готовым». Если сами не будете регулярно кликать живые экраны, то в финале выяснится, что согласованное на бумаге ТЗ на практике заставляет менеджеров рвать на себе волосы.

P.S.: вопрос уже задавали ниже, ответ во втором сообщении.

Сразу внесите в ТЗ отдельными пунктами структуру базы данных и документацию по REST API. Должно быть четко зафиксировано, как хранятся реляционные таблицы и по каким стандартам система будет общаться с бухгалтерией или логистикой. И обязательно требуйте разработку на популярном современном фреймворке, чтобы не сесть на иглу одного подрядчика.

А сколько у вас сейчас колонок и зашитых формул в текущих таблицах? И еще: продажникам нужен доступ с телефонов «в полях», чтобы на ходу выставлять КП или хватит обычной десктопной веб-версии? Только эти два нюанса могут запросто удвоить сложность базы и количество человеко-дней на разработку.

Обязательно внесите в договор регламент управления изменениями (change request). Любая хотелка, высказанная на словах, идти в код не должна, а стоимость дополнительных доработок в человеко-днях должна быть зафиксирована на старте. Иначе каждая мелкая правка будет сдвигать дедлайны и раздувать итоговый чек.

проходили такое, наша главная ошибка была в том что не подключили линейных сотрудников. мы как руководство нарисовали на бумаге идеальный флоу а менеджеры по продажам открыли интерфейс офигели от сложности и втихаря вернулись в свои старые эксельки. без согласования макетов с теми кто реально будет работать ничего не подписывайте.

бюджет у вас вполне адекватный но главный совет — не пытайтесь запихнуть всё в первый релиз но сделайте сначала простой MVP: ведение клиентов, расчет скидки и формирование КП... в общем пусть команда обкатает, вылезут первые кояки а склад и логистику накатите уже вторым этапом.

Появились три разных мнения, они дополняют друг друга. Ошибка, сделанная на стороне процесс разработки crm, обычно исправима, но дорого.

Когда пытаешься изменить всё сразу, ничего не приживается. Надеюсь, это будет полезно.

Поделюсь своим опытом. При принятии решений записывайте и худший сценарий, а не только лучший.

Частично согласен, частично нет. Если в договоре не прописано право собственности на код при уходе у вас нет переговорной позиции.

Если не зафиксировать это письменно с самого начала потом возникнут споры. кстати пишите если есть вопросы отвечу по мере возможности.

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

конечно если ваша ситуация отличается, всё меняется.

Вопрос будет немного наивным извините заранее... Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Сохранил.

Очень актуальная тема.

согласен.. и главное не цифра а то на основе чего она получена.

если напишете результат здесь, это поможет и другим.

Сведу тему в кучу, так как ответов было несколько разных. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Проверено опытом.

Абсолютно. Если добавить к этому: Ошибка, сделанная на стороне процесс разработки crm, обычно исправима, но дорого.

Это мое мнение не утверждаю, что оно единственно верное.