Короткий ответ: заказная CRM нужна не тогда, когда компании просто хочется «свою систему», а когда готовый продукт уже заставляет менять рабочий процесс. Проект стоит начинать с карты операций: кто создаёт запись, какие данные обязательны, кто принимает решение, что происходит при ошибке и какие системы должны обмениваться данными. Только после этого можно выбирать модули, стек и объём первой версии.
CRM должна повторять процесс, а не каталог функций
В типовой CRM есть сделки, контакты и задачи. Но бизнес-процесс редко ограничивается карточкой клиента. В нём бывают несколько ролей, согласование скидки, контроль сроков, повторные обращения, документы, права доступа и интеграции. Если перенести такой процесс в готовую систему без настройки, сотрудники начинают вести параллельные таблицы и мессенджеры.
Заказная CRM оправдана, когда различия процесса влияют на деньги, сроки или ответственность. Это может быть собственная модель заказа, сложная маршрутизация, несколько юридических лиц, особые правила доступа или необходимость связать CRM с внутренним сервисом. Сам факт нестандартного интерфейса ещё не является достаточной причиной.
С чего начать: карта процесса и границы MVP
Первый артефакт — не макет экрана, а схема процесса. На ней должны быть роли, входные данные, решения, статусы, исключения и ожидаемый результат. Полезно отдельно отметить, какие действия выполняются человеком, а какие можно автоматизировать.
- один основной сценарий от входящей заявки до результата
- перечень ролей и разрешений
- обязательные поля и источники данных
- статусы, переходы и причины отказа
- интеграции, без которых процесс не закрывается
После карты задают границу MVP. В первую версию обычно попадает сквозной путь, который можно проверить на реальных данных, а не десяток разрозненных справочников. Необязательные отчёты, сложная кастомизация интерфейса и редкие сценарии лучше вынести в backlog.
Из чего складывается объём разработки
Цена и срок зависят не от слова CRM, а от состава работ. Один проект может быть внутренним кабинетом с простой ролью администратора, другой — системой с несколькими организациями, журналом изменений и интеграциями.
| Блок | Что проверить | Риск |
|---|---|---|
| Процесс | статусы, исключения, ручные решения | переписывание логики |
| Данные | источники, импорт, дубли, история | потеря контекста |
| Доступ | роли, организации, видимость полей | утечка данных |
| Интеграции | API, webhooks, повторная отправка | рассинхронизация |
| Эксплуатация | логи, резервные копии, поддержка | дорогой запуск |
Безопасность и доступность закладываются сразу
Для CRM недостаточно проверить форму входа в конце проекта. Нужно заранее описать границы доступа: что видит менеджер, руководитель, партнёр и администратор; кто может выгружать данные; как фиксируется изменение записи. OWASP ASVS даёт проверяемую основу для требований к безопасности веб-приложения, а NIST SSDF рекомендует встраивать безопасные практики в жизненный цикл разработки.
Доступность также относится к качеству процесса. WCAG 2.2 содержит тестируемые критерии для клавиатурной навигации, фокуса, ошибок и подписей. Для внутренней CRM это не декоративный пункт: если часть команды не может быстро работать с формами и таблицами, процесс снова уходит в обходные каналы.
Как строить первую версию
Надёжная последовательность — discovery, прототип ключевого пути, техническая схема, вертикальный срез, тестирование ролей и запуск с наблюдаемостью. Вертикальный срез означает, что одна операция проходит через интерфейс, сервер, базу, уведомление и журнал. Так раньше обнаруживаются проблемы интеграции и прав доступа.
- зафиксировать владельца каждого решения
- проверить прототип на сценариях ошибок
- собрать один рабочий путь целиком
- добавить роли и аудит до расширения модулей
- согласовать критерии готовности и план отката
Как проверить предложение подрядчика
Сравнивать нужно не только сумму. Попросите показать допущения, состав MVP, список интеграций, критерии готовности, формат передачи исходников и что считается поддержкой. Если в предложении нет вопросов о процессе и данных, оно может быть предварительным шаблоном, даже если выглядит подробно.
Paladin Engineering может подключиться на discovery, аудит текущего процесса, прототипирование или реализацию согласованного MVP. Такой вход полезен, когда нужно сначала отделить обязательную логику от пожеланий и только потом считать разработку. Обсудить задачу можно через контакты или раздел веб-разработки. Напишите в Telegram, если хотите обсудить задачу.
Перед стартом подготовьте заявку: кто пользуется CRM, где теряется информация и какой один процесс нужно улучшить первым.
Часто задаваемые вопросы
Когда готовой CRM недостаточно?
Когда её ограничения вынуждают вести критичные данные вне системы или когда процесс нельзя выразить настройками без постоянных обходов.
Нужно ли сразу делать все модули?
Нет. Безопаснее выбрать один сквозной сценарий, доказать его ценность и расширять систему по очереди.
Что дороже всего в CRM?
Чаще всего не экран, а правила, миграция данных, роли, интеграции и исключения.
Как избежать потери данных при миграции?
Сначала описать источники, правила сопоставления, тестовый импорт, контроль дублей и обратимый план переключения.
Нужен ли прототип?
Да, если есть несколько ролей, статусов или спорных решений: прототип дешевле исправлять до кода.
Как Paladin Engineering может помочь
Мы можем начать с короткого discovery: разложить процесс, определить границы MVP, проверить интеграции и подготовить понятную техническую основу для оценки. Это не заменяет решения владельца процесса, но помогает принять их до того, как команда свяжет себя дорогой архитектурой. Отправьте заявку через контакты или Telegram.
Практический вывод: заказная CRM становится понятнее, когда каждое поле, статус и интеграция привязаны к конкретному действию пользователя. Такой разбор помогает не переплатить за ненужные экраны, заранее увидеть риски миграции и подготовить понятный план запуска. Чем раньше зафиксированы правила доступа и критерии готовности, тем меньше вероятность, что команда будет исправлять фундамент уже после релиза.
Комментарии