Своя CRM или готовая: когда писать на заказ

Готовой CRM достаточно, когда процесс продаж типовой, нужен быстрый старт и нет жёстких требований к хранению данных. Своя CRM оправдана, когда в центре учёта стоит не клиент и сделка, а объект, договор или заявка, когда нужны сложные роли, закрытый контур или нестандартные интеграции, а доработки готового продукта по цене сопоставимы с новой системой.

Выбор не идеологический. Его определяют пять вопросов: чем ваш процесс отличается от типового, какие нужны интеграции, сколько пользователей и ролей, где должны храниться данные и сколько стоит владение за несколько лет. Ниже критерии, таблица признаков, расчёт, перенос данных и промежуточный вариант. Цен и тарифов готовых продуктов здесь нет намеренно: они меняются, а логика выбора остаётся. Услуга описана на странице «Разработка CRM и внутренних систем на заказ».

Пять вопросов, которые решают выбор

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

1. Чем процесс отличается от типового

Опишите путь клиента или заявки от первого обращения до закрытия по шагам. Сколько шагов укладывается в цепочку «обращение, сделка, оплата» без искажений? Если почти все, нужна готовая. Если половина шагов про объекты, согласования, выезды, партии и договоры, то это уже не сделка, и воронку придётся растягивать.

2. Какие интеграции нужны

Составьте список систем: 1С, сайт, телефония, склад, оборудование. По каждой выясните, есть ли в готовой CRM типовой обмен и закрывает ли он вашу схему: нестандартные поля, несколько складов, комплекты, несколько юридических лиц. Для 1С такие связки описаны на страницах интеграции 1С с amoCRM и Битрикс24 с 1С, а общая схема обмена — в статье «Интеграция 1С с CRM: типовые схемы».

3. Сколько пользователей и какие роли

Сколько людей будет работать сейчас и через три года. Сколько из них заходят каждый день, а сколько раз в неделю. Какие подразделения видят записи друг друга. Эти ответы определяют и цену (если она зависит от числа пользователей), и то, хватит ли модели прав, которую заложил производитель.

4. Где должны храниться данные

Есть ли требования службы безопасности. Персональные данные граждан России обычно должны храниться на серверах в России. Нужны ли вход через корпоративный каталог, журнал действий, ограничения на выгрузку. Проверьте, какие варианты поставки предлагает производитель, до сравнения всего остального.

5. Сколько стоит владение

Не цена покупки, а сумма за три-пять лет: лицензии или разработка, доработки, интеграции, сопровождение, инфраструктура, выход. Как считать, разобрано ниже и в статье «Как считать стоимость владения».

Правило для первого разговора, а не приговор. Жёсткое требование решает вопрос само: например, данные нельзя держать у производителя, или модель данных нестандартная и не укладывается в справочники. Без жёстких требований считайте так: если по трём и более вопросам из пяти ответ склоняется к своей системе, считайте её всерьёз; если по одному-двум, сначала проверьте, закрывает ли эти места настройка готовой CRM или отдельный сервис рядом (он описан ниже); если ни по одному, берите готовую.

Таблица признаков: готовая CRM или своя

Возможности конкретного продукта проверяйте по его документации и на пробном доступе с тестовыми или обезличенными данными. Таблица описывает свойства задачи, а не продуктов.

Стоимость владения за несколько лет без цен продуктов

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

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

Как проверить чувствительность расчёта и записать допущения, разобрано в статье про расчёт стоимости владения, здесь это не повторяется. Для CRM отдельно проверьте две угаданные величины: число пользователей через три года и число изменений процесса в год.

Условный пример рассуждения

Компания с отделом продаж и сервисной службой. Продажи идут по воронке, а сервис ведёт договоры обслуживания и выезды на объекты клиентов. Для продаж готовая CRM подходит без доработок, спор только про сервис. Сравниваем два варианта.

• Всё в готовой CRM. Объекты лежат в дополнительных полях сделки, график выездов ведётся в таблице рядом. Старт дешевле, но каждое изменение сервисного процесса — доработка внутри чужой системы, и после обновлений её приходится проверять заново.
• Продажи в готовой CRM, сервис отдельно. Разработки на старте больше. Зато нет доработок внутри чужой системы: при обновлении CRM проверять нужно точки обмена по API, а не все внутренние доработки, а данные об объектах лежат в вашей базе и выгружаются без обращения к производителю. Зависимость от интерфейса производителя остаётся: если он изменится, обмен придётся поправить.

Какой вариант выгоднее, решают две величины: сколько изменений сервисного процесса вы ждёте в год и сколько стоит одно изменение в каждом варианте. Эти числа ваши, мы их не придумываем.

Промежуточный вариант: готовая CRM плюс доработки и интеграции

Бывает, что подходит связка. Готовая CRM остаётся для того, для чего она создана, а особенность бизнеса выносится в отдельный сервис, подключённый по API (как проектировать такой обмен, разобрано в статье про проектирование API для интеграций).

• В готовой CRM остаются клиенты, сделки, задачи, история общения и телефония.
• В отдельном сервисе живут объекты обслуживания, договоры, согласования и специальные расчёты. Он хранит свои данные и общается с CRM по идентификатору клиента.
• Ссылки и вход. Из карточки клиента в CRM есть ссылка на объект в сервисе: без неё сотрудник будет искать одного клиента в двух системах. Общий вход возможен, если обе системы поддерживают общий каталог или стандартный протокол входа (OIDC, SAML); для облачной CRM это зависит от тарифа и настроек производителя и проверяется на обследовании. Если общего входа нет, остаются два входа, и это учитывается в расчёте.
• Источник истины назначен. По каждому объекту сказано, где он создаётся и кто побеждает при расхождении. Из данных клиента сервис хранит только идентификатор и название для отображения, главной остаётся CRM, иначе получится две базы клиентов.

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

Миграция данных: что проверить до решения

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

Что проверить до решения

• Полноту выгрузки. Можно ли выгрузить из текущей системы все данные, в каком формате, включая историю общения, вложения, связи между записями и права доступа.
• Срок действия лицензий и доступа к API. Если доступ закончится раньше, чем завершится перенос, выгружать будет нечем.
• Владельца данных. Кто в компании решает, какая карточка клиента правильная, когда в базе три дубля.
• Ответ на вопрос о выходе из новой системы. Если вы выбираете готовую CRM, спросите, как из неё потом выгрузить всё. Если свою, исходники и данные у вас, и ответ такой: обычной выгрузкой.

Что переносить, а что оставить в архиве

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

Что теряется при переносе

• Настройки, а не записи: автоматизации, шаблоны писем и права пользователей могут не переноситься выгрузкой данных, их описывают и собирают заново.
• Ключи сопоставления с 1С: ссылки из 1С на карточки старой CRM перестают работать, если не перенести идентификаторы или не пересобрать соответствие.
• Соответствие статусов: сделки старой воронки попадают не на те стадии новой.

Порядок самого переноса (инвентаризация, объединение дублей, таблица соответствия полей, пробный перенос, параллельная работа) описан на странице про разработку CRM. Критерии проверки результата записываются до начала переноса.

Признаки, что выбран не тот вариант

Выбрана готовая, а нужна своя

• В карточках десятки дополнительных полей с названиями вроде «Доп. 3», смысл которых знает один человек.
• Отчёты собираются вручную в таблице из выгрузки.
• Каждое изменение процесса требует интегратора и проверки всей системы.
• Параллельно ведётся учёт в таблицах, потому что в CRM не помещается.
• Расходы на доработки за год сопоставимы с разработкой нового.

Выбрана своя, а хватило бы готовой

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

Что делать: вернуться к пяти вопросам и ответить на них на текущих числах. Переход возможен в обе стороны, но стоит денег: это перенос данных и параллельная работа. Он проще, если данные выгружаются, а схема обмена с 1С записана.

Как принять решение: порядок проверки

1. Выпишите пять-семь сценариев с реальными примерами за прошлый месяц, включая неудобные.
2. Прогоните три самых сложных через пробный доступ к готовой CRM. Не слайды, а записи, повторяющие структуру ваших: тестовые или обезличенные. Реальные персональные данные клиентов в пробный аккаунт не загружайте, пока не проверили, где он размещён и на каких условиях.
3. По каждому месту, где готовая не справилась, оцените объём доработки или отдельного сервиса.
4. Посчитайте владение по таблице выше. Пометьте числа: известно, оценено, угадано.
5. Проверьте чувствительность: что будет, если число пользователей вырастет вдвое, а изменений процесса станет больше.
6. Запишите решение вместе с условиями пересмотра: например, число пользователей выросло, сменились требования безопасности.

Задачу такого размера можно разобрать самостоятельно за несколько дней. Если процесс сложнее, а внутри нет человека, который готов провести разбор, проще заказать его снаружи.

Что делаем мы и с чего начать

Мы разрабатываем CRM и внутренние системы на заказ и делаем обмен готовых CRM с 1С. Мы зарабатываем и на разработке своих систем, и на обмене готовых CRM с 1С, поэтому не привязаны к одному исходу. Проверить это можно по документу обследования: допущения и числа в нём записаны, и пересчитать их можно без нас. Если хватает готовой, мы так и скажем, а вы заплатите только за обследование. Описание услуги: разработка CRM на заказ. Обмен готовых систем с 1С: amoCRM и Битрикс24.

Начните со сценариев и пяти вопросов выше. Если разбора за несколько дней недостаточно, обследование стоит 200 000 ₽ за один-два процесса и 350 000 ₽, когда есть старая система для переноса и несколько обменов. Оно вычитается из первого этапа, если продолжаете с нами. На выходе вывод «готовая или своя», расчёт стоимости владения на несколько лет для обоих вариантов, требования и вилка бюджета. Отчёт пригоден для другого интегратора: по нему можно заказать настройку готовой CRM не у нас. Цены и сроки ступеней — на странице тарифов; исходники и документация передаются вам по акту.