CRM под конкретный процесс: как понять, что готовое решение не подходит

Когда в компании появляется мысль «нам нужна CRM», почти всегда первым делом смотрят на готовые решения — Битрикс24, amoCRM, что-нибудь ещё из топ-5. Это правильный первый шаг: 8 из 10 задач малого и среднего бизнеса такие системы закрывают за недели и разумные деньги. Но есть процессы, которые в готовую воронку не влезают в принципе, и тогда каждая доработка превращается в костыль на костыле. Мы в FLATCOM регулярно ведём проекты разработки CRM под конкретный процесс именно потому, что клиенты сначала честно пробуют типовые решения — и в какой-то момент упираются в стену. В этой статье — конкретные признаки, по которым понятно, что вы подошли к этой стене, а не просто плохо настроили готовую систему.

Сначала — когда готовая CRM действительно достаточно

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

Признак 1: процесс — это не одна сделка, а сеть связанных объектов

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

Признак 2: бизнес-логика важнее интерфейса

Готовая CRM хороша тем, что даёт готовый интерфейс: карточки, канбан-доски, фильтры. Но если ценность вашей системы не в том, чтобы красиво показать сделки, а в том, чтобы посчитать что-то по нетривиальным правилам — распределить нагрузку между исполнителями с учётом квалификации и загрузки, рассчитать стоимость по формуле с десятком переменных, автоматически подобрать материалы под параметры заказа — вы упираетесь в то, что в CRM-конструкторах называется «бизнес-процессами» или «роботами». Это условные конструкторы if-then, и для простых сценариев их достаточно. Но если логика требует циклов, обращения к внешним справочникам, версионирования правил во времени («до апреля считали так, с апреля — иначе») — вы упрётесь в потолок конструктора и начнёте городить обходные пути через вебхуки и внешние скрипты, которые дергают CRM как чёрный ящик.

Признак 3: интеграции превращаются в отдельный проект сами по себе

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

Признак 4: стоимость владения растёт быстрее пользы

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

Признак 5: команда обходит систему, а не работает в ней

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

Практический вывод: как принять решение

Не нужно решать «готовое или своё» на глаз. Есть рабочий способ проверить гипотезу за один-два дня, до того как тратить деньги на разработку.

• Опишите процесс так, как он реально идёт, а не так, как хотелось бы — включая все обходные пути и параллельные таблицы, которыми пользуется команда.
• Посчитайте текущую стоимость владения CRM за год: лицензии, доработки, ремонт интеграций, ручной труд на компенсацию того, что система не умеет.
• Оцените, сколько из пяти признаков выше действительно про вас — один-два признака обычно решаются доработкой готовой системы, три и больше — сигнал считать разработку.
• Сделайте черновую смету обоих путей: доработка готовой CRM до нужного уровня против разработки своей системы под процесс, с учётом поддержки на 2–3 года вперёд, а не только на старте.
• Проверьте, кто будет отвечать за систему дальше — если критичная бизнес-логика держится на связке из трёх подрядчиков без единой документации, это риск независимо от того, готовая система или своя.

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