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

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

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

Сначала опишите то, что система обязана делать

Фраза «у нас нестандартный бизнес» мало что объясняет разработчику. Продажи почти везде отличаются деталями. Нужно понять, какие из этих деталей влияют на расчёт, исполнение заказа и ответственность сотрудников.

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

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

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

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

Что реально закрывается готовой CRM

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

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

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

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

Когда разумна доработка

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

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

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

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

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

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

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

Когда обсуждать собственную систему

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

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

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

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

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

Как сравнить предложения на одинаковом горизонте

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

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

Одинаковый горизонт и состав расходов позволяют сопоставить разные предложения.

Заполняйте таблицу подтверждёнными условиями предложений, а неизвестное отмечайте отдельно. Особенно полезно спросить про обычную будущую задачу: «Мы добавляем новый тип заказа. Что потребуется изменить и кто это оценит?» Так становится видно, насколько выбранный вариант удобен для развития именно вашего процесса.

После сравнения нужен порядок внедрения с результатами каждого этапа. Его разбираю в материале об этапах внедрения CRM и приёмке. Выбор продукта без плана запуска оставляет слишком много вопросов на потом.

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