Своя CRM или готовая система: как принять решение

Определите, какую проблему решает CRM

CRM помогает организовать работу с клиентами, контактами и сделками. Такое базовое назначение описывает и Salesforce. Но список функций продукта ещё не отвечает на вопрос, что нужно вашей компании. Начните с конкретного сбоя: заявки теряются, менеджеры дублируют данные, руководитель не видит следующий шаг или согласование предложения занимает слишком много времени.

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

Опишите путь одной сделки от входа до завершения. Какие роли участвуют? Где возникают документы? Что происходит при отказе, возврате и смене ответственного? Берите и обычные, и проблемные примеры. Демонстрация только идеальной сделки скрывает ограничения, которые проявятся после внедрения.

Сравните три варианта, а не два

Промежуточный вариант часто заслуживает отдельного исследования. Основная работа с клиентами может оставаться в готовой системе, а сложный расчёт комплектации — в специализированном модуле. Это не универсально дешевле: появляется граница обмена, которую нужно обслуживать. Сравнивайте её сложность с пользой отказа от полной замены.

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

Как подтвердить критическое ограничение

Подготовьте пять–семь обязательных сценариев с обезличенными тестовыми данными. Например: менеджер ведёт только свои сделки, руководитель видит подразделение, финансовые поля доступны выделенной роли. Затем попросите показать выполнение каждого сценария в кандидате на внедрение, включая запрет недоступного действия.

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

Разделите результаты на «работает настройкой», «нужна поддерживаемая доработка», «требуется обходной процесс» и «не реализуется в принятых условиях». Последний вывод требует доказательства, а не первого впечатления от интерфейса. Уточните ограничения конкретной версии, тарифа и способа размещения.

Считайте стоимость владения

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

Условный пример: у готового продукта ниже начальный платёж, но нужные права доступны на другом тарифе, а обмен требует отдельного модуля. Заказная система не имеет той же лицензионной модели, однако нуждается в обновлениях и сопровождении. Без этих строк сравнение «подписка против единовременной разработки» искажает решение.

Не пытайтесь получить одну точную сумму на много лет при неизвестном росте. Сделайте базовый и расширенный сценарий: больше пользователей, больше записей, новая интеграция. Покажите, какие предположения меняют результат сильнее всего. Это даст полезный вопрос поставщику вместо ложной точности расчёта.

Проверьте данные и возможность выхода

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

Уточните API: доступность нужных сущностей, лимиты, фильтры изменений, обработку удаления и права сервисной учётной записи. Подробный план обмена есть в руководстве по API-интеграции. Если доступ к критическому действию зависит от будущего обещания поставщика, отметьте эту зависимость до принятия решения.

Опишите, кто отвечает за качество исходных записей. Дубликаты контактов, пустые поля и разные названия компаний не исчезнут от смены программы. Нужны правила сопоставления, пробный перенос и проверка выборки сотрудником, который понимает данные.

Проведите ограниченный пилот

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

Во время пилота собирайте проблемы по сценариям, а не общий рейтинг «нравится — не нравится». Где пользователь остановился? Каких данных не хватило? Как часто приходилось выходить в другую систему? Отдельно учитывайте ошибки обучения и технические дефекты, чтобы не переделывать продукт вместо понятной инструкции.

• Обязательные сценарии пройдены обычными пользователями.
• Ограничения прав проверены на чужих записях и прямых запросах.
• Пробный импорт и экспорт сохраняют нужные связи.
• Есть ответственные за данные, эксплуатацию и развитие.
• Трудоёмкость доработок и зависимости записаны в решении.
• Определены условия продолжения, изменения или остановки пилота.

Когда переходить к заказной разработке

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

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