Готовая CRM, доработка или собственная система: как выбрать

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

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

Почему привычная развилка вводит в заблуждение

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

Это подтверждает и российская практика. В обследовании ИСИЭЗ НИУ ВШЭ, проведённом в 2023 году и охватившем более четырёх тысяч организаций из десяти отраслей, 85,4% компаний использовали готовые пакетные решения, 58,2% — инсорсинг, а 53,3% — программное обеспечение в формате SaaS. Показатели пересекаются: одна организация может сочетать все три подхода. Следовательно, выбор формата — не идеологическое решение, а проектирование границ между системами.

У каждой из трёх моделей есть нормальная область применения:

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

Сначала опишите не интерфейс, а движение работы

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

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

При проектировании CRM или ERP-системы под процессы компании (https://synchroweb.ru/crm-erp/) имеет смысл отдельно зафиксировать:

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

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

Что обычно стандартно, а что действительно уникально

Карточка контакта, список задач, базовая воронка, комментарии и календарь редко являются конкурентным преимуществом. Их можно реализовать по-разному, но сама логика хорошо известна. Разрабатывать такие функции заново только ради владения кодом обычно невыгодно.

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

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

Таблица выбора подхода

Критерий Готовая CRM Платформа с доработками Собственная система
—————— ————————————— —————————————— ——————————————————————————
Основной процесс Типовая продажа или обслуживание Типовая основа со своими маршрутами Уникальный сквозной процесс нескольких подразделений
Исключения Редкие и обрабатываются вручную Повторяются и описываются правилами Являются существенной частью операционной модели
Роли Менеджер, руководитель, администратор Несколько команд с настроенными правами Клиенты, партнёры, исполнители и сотрудники с разными рабочими интерфейсами
Интеграции Готовые коннекторы Несколько адаптеров и доработок Система координирует множество источников и событий
Данные Укладываются в стандартные сущности Нужны дополнительные объекты и связи Требуется собственная предметная модель
Изменения Компания принимает логику продукта Процессы меняются в пределах платформы Система должна развиваться вместе с операционной моделью
Поддержка Вендор и интегратор Вендор плюс команда доработки Ответственная команда разработки и понятный регламент сопровождения

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

Когда готовой CRM достаточно

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

В пользу готовой CRM говорят следующие признаки:

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

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

Когда разумнее доработать платформу

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

Однако у доработок должен быть предел. Перед каждым изменением полезно спросить:

1. Это постоянное правило бизнеса или временная привычка?
2. Можно ли решить задачу штатной настройкой?
3. Не создаёт ли изменение второй источник одних и тех же данных?
4. Как оно будет работать после обновления платформы?
5. Кто отвечает за тестирование и поддержку?

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

Когда собственная система действительно оправданна

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

Сигналами могут быть:

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

Отдельные рабочие кабинеты и порталы при этом ближе к разработке веб-сервиса (https://synchroweb.ru/veb-servisy/), чем к настройке обычной CRM. Они требуют своей модели прав, состояний и действий. Например, клиент видит только собственные заказы и документы, исполнитель — назначенную работу, а менеджер — полную историю и исключения.

Не обязательно переносить всё в одну программу

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

У 1С есть стандартный REST/OData-интерфейс, через который внешнее приложение может работать с каталогами, документами, регистрами, задачами и бизнес-процессами. Это не делает интеграцию автоматической, но позволяет проектировать её на документированном механизме. Важно заранее назначить владельца каждого объекта: где создаётся клиент, кто хранит итоговый счёт, откуда приходит статус оплаты и какая система имеет право его изменить.

Такой подход снижает объём разработки. Собственная CRM не обязана повторять бухгалтерию, складской движок или телефонию. Она должна соединять нужные данные в рабочем контексте и запускать автоматизацию бизнес-процессов (https://synchroweb.ru/avtomatizaciya-biznesa/) там, где событие требует следующего действия.

Почему список экранов — ещё не техническое задание

Запрос «нужны клиенты, сделки, задачи и отчёты» описывает меню, но не поведение системы. Два проекта с одинаковыми разделами могут отличаться в несколько раз по сложности из-за правил перехода, прав доступа, истории изменений и интеграций. Поэтому оценивать подход по прототипу главного экрана рано.

Полезнее описывать проверяемые ситуации. Что делает система, если один клиент обращается повторно? Может ли исполнитель увидеть финансовые данные? Кто вправе отменить уже оплаченный заказ? Как меняется маршрут, если требуется согласование? Что считается источником суммы в отчёте? Сохраняется ли предыдущая версия после изменения документа?

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

Как сравнивать стоимость честно

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

Но есть и внутренняя стоимость текущего процесса:

— повторный ввод одних данных;
— время ожидания между подразделениями;
— ручная проверка статусов;
— исправление дублей и расхождений;
— поиск истории в нескольких каналах;
— ошибки из-за неактуальной версии документа;
— зависимость процесса от памяти конкретного сотрудника.

Эти расходы нельзя превращать в выдуманный процент экономии. Их можно измерить на собственных операциях: посчитать ручные касания, длительность ожидания, количество возвратов на доработку и число заказов, для которых руководителю пришлось собирать состояние вручную. Такая база позволяет сравнивать варианты без рекламных обещаний.

Как запускать индивидуальное решение без попытки охватить всё

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

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

Критерии приёмки должны описывать работу, а не наличие экранов. Не «есть карточка заказа», а «заявка с сайта создаётся один раз, получает ответственного, передаётся на исполнение, возвращает статус оплаты и сохраняет журнал действий». Такой критерий можно проверить.

Вопросы, которые стоит задать до выбора

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

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

Документация и данные по теме

— ИСИЭЗ НИУ ВШЭ: «Инсорсинг, коробочные решения и облачные сервисы» (https://issek.hse.ru/news/903061428.html)
— ИСИЭЗ НИУ ВШЭ: «Цифровые технологии в бизнесе: практики и барьеры использования» (https://issek.hse.ru/news/890550436.html)
— «Индикаторы цифровой экономики: 2025» (https://issek.hse.ru/news/1026730357.html)
— Официальная документация платформы 1С: REST-интерфейс (https://v8.1c.ru/platforma/rest-interfeys/)