Self-hosted CRM в 2026 году: как выбрать между EspoCRM, SuiteCRM, YetiForce, Odoo и Frappe CRM

Self-hosted CRM выбирают не по рейтингу, а по сценарию: нужна ли вам в одной системе ещё и учёт склада и закупок. Если нет, смотрите EspoCRM или SuiteCRM; если да, Odoo или ERPNext. Ниже шесть критериев, таблица пяти систем, дерево решений и двухнедельный пилот.

Когда CRM на своём сервере лучше облака, а когда нет

Вопрос «какую self-hosted CRM выбрать» я задаю клиенту вторым. Первым идёт другой: а зачем вам свой сервер? Если ответ «чтобы не платить за каждого менеджера», это уважительная причина, но половинная. Деньги экономятся на местах, а взамен появляется человек или подрядчик, который отвечает за обновления, резервные копии и безопасность. Эту строку бюджета нужно видеть сразу, до выбора продукта. Если хотите посмотреть, как выглядит готовый self-hosted вариант с AI-продавцом, у нас есть CRM + AI-отдел продаж; но выбор начинается не с него, а с ваших условий.

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

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

Есть и промежуточный вариант: self-hosted у подрядчика, когда сервер ваш или арендованный, а обновлениями и копиями занимается внешний инженер по договору. Для компании на 20–40 человек это обычно разумнее найма. Дальше в статье я исхожу из того, что администрирование вы закрыли одним из способов, и сравниваю уже сами системы.

Шесть критериев выбора: что сравнивать до демо

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

Вот мои шесть критериев и что за каждым стоит: | Критерий | Что проверяю | Почему важно | |---|---|---| | Лицензия | Тип лицензии, ограничения на коммерческое развёртывание, платные пакеты | От неё зависит, кто вправе ставить систему вам | | Склад и закупки | Есть ли в той же системе, или нужна внешняя учётная | Решает, одна система или две с обменом | | Платные расширения | Какие функции спрятаны за пакетами | Бесплатная база часто урезана в нужном месте | | Порог администрирования | Сколько часов в месяц и какой квалификации | Определяет реальную стоимость владения | | Интеграция с 1С | HTTP-сервисы, OData, готовые коннекторы | Для российского бизнеса почти всегда нужна | | Зрелость | Свежесть релизов, документация, сообщество | Показывает, чем рискуете через два года |

Критерий «лицензия» новички пропускают чаще всего, а он потенциально самый болезненный. В тексте лицензии YetiForce, которую я открывал в архивном репозитории проекта (версия 6.5, имя файла LICENSE), прописаны обязательная регистрация и ограничение: развёртывание для других организаций как коммерческая услуга возможно только у партнёра производителя или с его согласия. Для компании, которая ставит систему себе силами собственных сотрудников, это допустимо. Для интегратора, который ставит её клиенту, нет. Репозиторий помечен архивным, поэтому актуальные условия проверяйте на сайте производителя до подписания любых договоров.

Остальные системы в этом плане проще. EspoCRM и SuiteCRM распространяются под AGPLv3, Frappe CRM под AGPL-3.0, Odoo Community под LGPLv3, ядро ERPNext под GPLv3. Эти лицензии разрешают коммерческое использование; обязательства возникают, если вы изменяете код и распространяете сервис другим. Для обычного внутреннего использования они вопросов не создают.

• Лицензию читайте сами, а не по пересказу в обзоре.
• Склад и закупки: если они нужны, критерий исключает EspoCRM и SuiteCRM как единственную систему.
• Платные расширения: у EspoCRM платными называют Advanced Pack и Sales Pack, состав и цены смотрите на сайте вендора.
• Часы администратора записывайте, а не оценивайте на глаз.

EspoCRM, SuiteCRM, YetiForce: когда нужна именно CRM

Если в одной системе вам нужны только клиенты, сделки, задачи, письма и отчёты по продажам, выбирать стоит из «чистых» CRM. Их три в нашем списке: EspoCRM, SuiteCRM и YetiForce. У каждой своя манера, и разница видна уже на второй день работы, а не на первом.

EspoCRM проще остальных в администрировании: Entity Manager позволяет заводить свои сущности и поля без кода, а портал клиентов и правила автоматизации доступны из интерфейса. По README проекта система требует PHP 8.3–8.5 и MySQL 8.0+, MariaDB 10.6+ или PostgreSQL 15+, то есть современный стек, на котором удобно жить в Docker. Минус для нашего круга задач: в ней нет склада, закупок и счетов. Платные пакеты Advanced Pack и Sales Pack закрывают часть процессов, но не превращают её в учётную систему. Подробнее смотрите в обзоре EspoCRM.

SuiteCRM старше и функциональнее. Это ветка, выросшая из SugarCRM, лицензия AGPLv3; текущая линейка 8.x по документации работает на PHP 8.2–8.4, MariaDB 10.6–11.8 или MySQL 8.0 и 8.4 под Apache 2.4. Цена за зрелость: порог администрирования выше, а мелкие настройки заставляют лезть глубже, чем в EspoCRM. Для отдела с сильным администратором и сложной логикой это хороший выбор. Свои впечатления и ограничения я описал в обзоре SuiteCRM.

YetiForce самая «модульная»: в её составе несколько десятков модулей, от CRM до сервис-деска. Для моего круга клиентов её главная особенность не функциональная, а юридическая: лицензия, о которой я писал выше. Если вы внедряете её в собственной компании, это решаемо. Если вам её ставит подрядчик, уточните его статус партнёра. Системные подробности есть в обзоре YetiForce.

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

Odoo и ERPNext с Frappe CRM: когда CRM — часть учётной системы

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

Odoo объединяет CRM со складом, проектами и выставлением счетов. Community-редакция бесплатна и опубликована под LGPLv3, расширенные функции сосредоточены в платной Enterprise. Что именно входит в вашу редакцию и как устроены обновления между мажорными версиями, проверяйте в документации вендора перед стартом, потому что мажорный переход у Odoo оформляется как отдельный проект. С нашей практикой есть обзор Odoo CRM Community.

ERPNext содержит собственный модуль CRM: цепочка Lead, Opportunity, Quotation идёт в ядре системы, лицензия GPLv3 без платных редакций. Его слабые места я знаю по проектам: встроенный Email Inbox уступает профильным решениям, а в v15 по умолчанию включена настройка CRM Settings → Auto Creation of Contact, и каждый лид порождает контакт, что засоряет справочник, если её не выключить. Лёгкая отдельная CRM на том же стеке, Frappe CRM, имеет интерфейс на Vue, разделяет Lead и Deal и поставляется по AGPL-3.0. По README проекта ветка main (v1.x) помечена стабильной и совместима с Frappe и ERPNext v15 и v16, а develop (v2.x) нестабильна. В сообществе встречались жалобы на проблемы при установке нестабильной ветки рядом с ERPNext, поэтому ставлю только main и всё равно сначала прогоняю её на стенде с копией базы.

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

Какую систему брать по сценарию: короткое дерево решений

Сводя всё в схему, я иду по четырём вопросам. Первый: нужны ли склад и закупки в той же системе? Если да, выбираем между ERPNext (процессы стройки, опта, услуг) и Odoo (когда важен широкий каталог приложений). Если нет, второй вопрос: нужна ли простая воронка и портал клиента? Тогда EspoCRM.

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

Таблица сценариев в сжатом виде: | Сценарий | Первый кандидат | Что проверить на пилоте | |---|---|---| | Только продажи, 10–30 человек | EspoCRM | Entity Manager, импорт, почта | | Сложные процессы, сильный админ | SuiteCRM | Время администрирования | | Продажи плюс склад и закупки | ERPNext или Odoo | Сквозная цепочка документов | | CRM в стеке Frappe | Frappe CRM | Стабильность main на вашей версии | | Админа нет | Облако или подрядчик | Условия выгрузки данных |

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

«Станочный Двор»: выбор для дистрибьютора станков на 34 рабочих места

Разбираю условный пример: дистрибьютор станков «Станочный Двор», 34 рабочих места, из них 11 менеджеров по продажам, шесть человек в сервисе, остальные склад, закупки и бухгалтерия. Цифры придуманы для иллюстрации; реальный проект такой компании выглядел бы иначе, но логика выбора сохраняется. Учёт и склад ведутся в 1С, и менять это никто не собирается.

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

Кандидатов осталось два: EspoCRM и SuiteCRM. Сервисные заявки и свои сущности (станок, серийный номер, гарантия) в EspoCRM заводятся через Entity Manager без разработчика, а в SuiteCRM потребовали бы работы со Studio и более долгой настройки. Администратором у них становится один из двух системных администраторов по совместительству, и порог входа для него решающий. Выбирают EspoCRM, SuiteCRM остаётся резервным вариантом, если выяснится, что не хватает отчётности.

Обмен с 1С строят через HTTP-сервисы: контрагенты и статусы оплаты ходят по расписанию, и в тестовом режиме две недели сверяются вручную. Прямую запись в базу 1С не используют, потому что обновление конфигурации ломает такую интеграцию без предупреждения. Бюджет на этом этапе складывается из сервера, настройки и обучения; платные расширения EspoCRM они сознательно откладывают до конца пилота, чтобы решать по факту, а не по презентации.

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

Что проверить в двухнедельном пилоте, прежде чем подписывать

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

С четвёртого по седьмой день три менеджера ведут по одной реальной сделке в тестовой системе и фиксируют, где им неудобно. Не спрашивайте «нравится ли», спрашивайте «где вы остановились». С восьмого по десятый день подключаются почта и обмен с 1С по HTTP или OData. С одиннадцатого по двенадцатый проверяется бэкап: сделать копию, удалить тестовую запись, восстановить, убедиться, что запись вернулась.

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

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

• День 1: установка в Docker на тестовом сервере.
• Дни 2–3: тестовый импорт 20–30 записей.
• Дни 4–7: три реальные сделки у менеджеров.
• Дни 8–10: почта и обмен с 1С по HTTP/OData.
• Дни 11–12: бэкап и проверка восстановления.
• Дни 13–14: решение по списку критериев.

Частые вопросы