1С-Битрикс «Малый бизнес» или «Бизнес»: какую редакцию выбрать

01

Выбор редакции начинается со сценария, а не с названия лицензии

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

Типовой кейс из практики ICONICA: компания планировала один интернет-магазин с выгрузкой номенклатуры из учётной системы. На встрече выяснилось, что маркетинг уже готовит отдельный сайт для оптовых клиентов, а продажи хотят разные цены и правила оформления. Мы не подменяем выбор лицензии обещанием «потом как-нибудь доработаем», а сначала раскладываем маршрут: сколько сайтов будет в ближайшие 12–18 месяцев, откуда приходят товары, кто меняет цены и где фиксируется заказ.

Редакция «Малый бизнес» рациональна, когда этот маршрут укладывается в один самостоятельный магазин и стандартные механики каталога. «Бизнес» выбирают не ради статуса, а когда нужна многосайтовая архитектура, более широкий набор возможностей для масштабирования торговли или когда это прямо следует из технического задания. Актуальный состав модулей и ограничения перед покупкой нужно сверять с официальным сравнением редакций 1С-Битрикс: состав продукта и условия лицензирования могут меняться.

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

03

Где проходит практическая граница между «Малым бизнесом» и «Бизнесом»

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

Редакция «Бизнес» становится предметной, если в проекте появляются несколько независимых сайтов или витрин, региональные домены, разные юридические лица, отдельные B2B- и B2C-направления, сложные правила управления ассортиментом и запасами. Не все эти признаки автоматически требуют старшей редакции: например, региональные посадочные страницы могут существовать в рамках одного сайта. Поэтому требование нужно переводить из маркетинговой формулировки «хотим отдельный регион» в техническую: отдельный домен, отдельная база, отдельный каталог, своя цена, свой заказ или только отдельный контент.

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

04

Сравните не функции в списке, а последствия ограничений

В коммерческом предложении часто встречается строка «лицензия 1С-Битрикс» без редакции и расшифровки. Для руководителя это риск: после запуска может оказаться, что нужная возможность не входит в выбранный вариант, а её нельзя заменить одной настройкой. Правильный вопрос подрядчику звучит так: «Какие из наших требований закрывает редакция штатно, что потребует доработки и что невозможно без перехода?»

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

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

05

Как посчитать бюджет без иллюзии «лицензия решит всё»

Цена редакции — только одна строка бюджета. Для сайта на 1С-Битрикс отдельно возникают дизайн и вёрстка, настройка модулей, перенос каталога, обмен с учётной системой, подключение оплаты и доставки, SEO-подготовка, тестирование и дальнейшая поддержка. Если в сравнении редакций есть разница в стоимости, сравнивайте её с полной стоимостью сценария, а не с ценой разработки на первом месяце.

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

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

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

06

Мини-кейс: один магазин, два будущих направления

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

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

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

1. 1

   Описать текущий заказ. Укажите источник товара, поля покупателя, оплату, доставку, статусы и сотрудника, который принимает решение.

2. 2

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

3. 3

   Проверить матрицу редакций. Сопоставьте подтверждённые требования с актуальными условиями поставки и модулями.

4. 4

   Оценить доработки. Отдельно посчитайте обмены, роли, цены, личный кабинет и тестирование интеграций.

5. 5

   Зафиксировать решение. Внесите в ТЗ редакцию, допущения и условие, при котором выбор пересматривается.

07

Что проверить маркетологу и руководителю до подписания сметы

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

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

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

08

Ошибки, которые дорого исправлять после запуска

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

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

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

09

Как принять решение и не переделывать сайт через полгода

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

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

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