Зачем разбираться в редакциях, если внедрением занимается подрядчик
Когда компания принимает решение о переходе с облачного Битрикс24 на коробочную версию или сразу стартует с self-hosted решения, вопрос выбора редакции кажется техническим — «пусть интегратор скажет, что нужно». На практике всё наоборот: цена ошибки в выборе редакции коробочного Битрикс24 ложится на бизнес, а не на подрядчика. Купленная «с запасом» лицензия — это замороженные деньги и переплата за модули, которыми никто не пользуется. Купленная «впритык» — это упор в лимиты через полгода-год, когда отдел продаж уже привык работать в системе, а миграция данных и доработок на старшую редакцию превращается в отдельный проект с бюджетом и простоем.
Руководителю не нужно знать техническую архитектуру модулей, но полезно понимать логику, по которой редакции отличаются друг от друга, и какие вопросы задавать подрядчику до подписания счёта. Это тем более важно для коробочной версии, потому что здесь, в отличие от облака, редакцию не меняешь одним кликом в личном кабинете — переход требует переустановки модулей, а иногда и работы с базой данных.
Ситуация усложняется тем, что коробочную версию чаще выбирают компании с уже сложившейся ИТ-инфраструктурой и требованиями к хранению данных — производственные предприятия, компании с обязательствами по защите персональных данных, бизнес с собственным дата-центром или контрактом на выделенный сервер. У таких компаний, как правило, есть внутренний ИТ-специалист или отдельный подрядчик по инфраструктуре, и решение о редакции CRM принимается не изолированно, а в связке с бюджетом на серверные мощности, резервное копирование и информационную безопасность. Поэтому разговор о выборе редакции полезно вести не только с интегратором Битрикс24, но и с тем, кто отвечает за ИТ-инфраструктуру внутри компании — иначе решение о программной части может разойтись с возможностями и планами по железу.
Линейка редакций коробочного Битрикс24: что внутри у каждой
Коробочная версия Битрикс24 построена по тому же принципу, что и облако: базовый функционал есть везде, а более дорогие редакции открывают дополнительные модули и снимают ограничения по числу пользователей. Разница в том, что на коробке вы платите не абонентскую плату «за компанию», а стоимость лицензии на определённое количество пользователей с ограниченным сроком технической поддержки и обновлений.
Условно линейку редакций коробочного Битрикс24 можно разложить по трём уровням.
Начальный уровень (CRM и небольшие отделы продаж). Здесь есть базовая CRM: сделки, лиды, контакты, компании, простая автоматизация в виде роботов и триггеров, интеграция с почтой и телефонией через готовые коннекторы. Этого достаточно, если у компании один отдел продаж, процесс продажи линейный и не требует сложных согласований между отделами.
Средний уровень (проекты и командная работа). Добавляются модули управления проектами и задачами с диаграммой Ганта, расширенная аналитика по сделкам, конструктор бизнес-процессов, который позволяет строить многошаговые сценарии с согласованиями, а не только простые роботы. Это уровень, на который переходят компании, где в процесс продажи и последующего обслуживания клиента вовлечены несколько отделов: продажи, производство или закупки, бухгалтерия.
Старший уровень (компания и корпоративный контур). Здесь открывается полный набор: HR-модуль с оргструктурой и электронным документооборотом, BI-аналитика и конструктор дашбордов, расширенные права доступа с гибким разграничением по подразделениям, интеграция с внешними системами через API без ограничений, поддержка кластерной установки для высоких нагрузок. Эта редакция рассчитана на компании от полусотни пользователей и выше, где ИТ-отдел или подрядчик способен самостоятельно вести конфигурацию и доработки.
Важный нюанс: количество пользователей в лицензии коробочной версии — это не то же самое, что количество сотрудников в компании. Лицензируются именно активные пользователи портала, поэтому производственный персонал, который не заходит в Битрикс24, в расчёт можно не включать. Ошибка многих закупщиков — покупать лицензию на весь штат компании, хотя реально с системой работает только отдел продаж, маркетинг и руководство.
Как соотнести редакцию с реальной структурой компании
Прежде чем смотреть таблицу сравнения редакций, полезно ответить на несколько вопросов о том, как устроен бизнес-процесс в компании.
Первый вопрос — сколько отделов реально участвует в процессе от заявки до закрытия сделки. Если это только отдел продаж, а бухгалтерия и производство работают в отдельных системах без интеграции, достаточно начального или среднего уровня. Если же нужен сквозной процесс — заявка попадает в CRM, после оплаты автоматически создаётся задача на производство, а бухгалтерия получает данные для выставления счёта без ручного дублирования, — потребуется конструктор бизнес-процессов и, скорее всего, интеграция с 1С, что тянет за собой средний или старший уровень редакции.
Второй вопрос — нужен ли гибкий контроль доступа. В компаниях с несколькими филиалами или направлениями бизнеса часто требуется, чтобы менеджер одного филиала не видел сделки другого, а руководитель видел сводную картину по всем. Такое разграничение прав по умолчанию доступно только в старших редакциях.
Третий вопрос — насколько глубоко компания планирует интегрировать CRM с учётной системой. Если 1С уже используется для бухгалтерии и склада, а в будущем планируется избавиться от двойного ввода данных менеджерами, стоит сразу закладывать редакцию с полноценным открытым API и достаточным лимитом запросов в час — на младших редакциях этот лимит рассчитан на единичные интеграции, а не на постоянный обмен данными между двумя системами в реальном времени.
Пример из практики: как пересчёт пользователей изменил выбор редакции
Типичная ситуация, с которой сталкиваются интеграторы: производственная компания на 40 сотрудников обращается за коробочным Битрикс24 и по умолчанию запрашивает редакцию, рассчитанную на весь штат, потому что в первоначальном брифе фигурирует именно эта цифра. При детальном разборе бизнес-процесса выясняется, что реально с CRM работает только отдел продаж из 8 человек, два менеджера по закупкам и руководитель — итого 12 активных пользователей. Остальные 28 человек — это производственный персонал, который получает задания через мастера или бумажные наряды и никогда не заходит в систему напрямую.
В такой ситуации закупка лицензии на 40 пользователей вместо 12 означает переплату в разы за пользователей, которые физически не будут авторизовываться в системе. Правильная последовательность действий — сначала провести короткое интервью с руководителями отделов о том, кто именно должен получить доступ и зачем, и только после этого выбирать редакцию по количеству реальных пользователей и по требуемому набору модулей, а не по общей численности штата. Тот же принцип работает в обратную сторону: если через несколько месяцев после внедрения производственный директор захочет видеть статусы заказов в системе, для него можно докупить точечные лицензии, не переплачивая заранее за весь штат «на всякий случай».
Отдельный урок из подобных проектов — считать пользователей не по штатному расписанию, а по факту участия в процессе, который автоматизируется. Это снижает стартовый бюджет проекта и оставляет пространство для последующего расширения по мере того, как в системе действительно появляется потребность у новых отделов, а не по предположению на старте.
Что подрядчики часто продают «с запасом» и почему это не всегда оправдано
Интеграторы объективно заинтересованы в продаже более дорогой редакции — это большая маржа с одной сделки и меньше работы по повторному апгрейду в будущем. Отсюда типичный аргумент: «берите редакцию с HR-модулем и BI сразу, потом дороже мигрировать». Аргумент не лишён логики, но применим не ко всем.
Разумный подход — сопоставить стоимость владения избыточной редакцией в первый год с вероятностью того, что функциональность действительно понадобится в этот период. Если компания планирует органический рост на 10–15% в год без структурных изменений, переплата за HR-модуль и BI-конструктор, которые включат в работу условно через два года, не окупается процентной ставкой альтернативных вложений этих денег в маркетинг или найм. Если же на горизонте полугода запланировано открытие нового филиала или слияние с другой командой, старшая редакция может оказаться дешевле, чем два отдельных проекта миграции подряд.
Отдельно стоит проверять другой перекос — когда подрядчик, наоборот, предлагает минимальную редакцию, чтобы выиграть тендер по цене, зная, что через несколько месяцев компания вернётся за апгрейдом и дополнительными работами по доработке интеграций. Здесь стоит прямо спросить на этапе коммерческого предложения: какие ограничения редакции могут стать критичными в перспективе 12 месяцев, и попросить письменно зафиксировать эту оценку.
Признаки того, что текущая редакция уже тормозит рост
Если коробочный Битрикс24 уже внедрён и работает, есть несколько практических сигналов, что редакция стала узким местом, а не вопрос удобства интерфейса.
- Менеджеры или руководители отделов регулярно просят «сделать автоматически», но конструктор роботов не позволяет реализовать сценарий с условными ветвлениями и согласованиями — нужен полноценный конструктор бизнес-процессов.
- Компания физически упирается в лимит пользователей лицензии, и каждый новый сотрудник отдела продаж требует докупки лицензий по разовой цене, вместо перехода на редакцию с более выгодной стоимостью пользователя.
- Руководство просит сводные отчёты по нескольким направлениям бизнеса одновременно, а стандартная аналитика CRM не даёт нужных срезов — типичный признак того, что пора смотреть в сторону BI-конструктора.
- Кадровая служба продолжает вести учёт отпусков, больничных и оргструктуры в Excel параллельно с Битрикс24, потому что HR-модуль не входит в текущую редакцию.
- Интеграция с 1С или внешними сервисами делается через самописные скрипты и вебхуки, потому что стандартные коннекторы редакции не покрывают нужный сценарий, а полноценный REST API с высокими лимитами запросов доступен только в старшей редакции.
Если совпадают два и более пункта, апгрейд редакции обычно окупается быстрее, чем кажется на этапе принятия решения — потому что скрытые издержки на ручной труд и самописные обходные решения уже накапливаются, просто их не видно в одной строке бюджета.
Есть и обратный сигнал, который стоит держать в голове: если ни один из перечисленных пунктов не актуален, а редакция уже старшая, стоит честно оценить, не переплачивает ли компания за модули, которыми фактически не пользуется. Практика показывает, что через год-полтора после внедрения часть купленных с запасом функций так и остаётся невостребованной — это нормально, если решение принималось осознанно ради будущего роста, но не нормально, если выбор редакции изначально был продиктован только рекомендацией подрядчика без обсуждения реальных сценариев использования.
Лицензия и подписка: как на самом деле устроена оплата
В отличие от облачной версии, где компания платит абонентскую плату каждый месяц или год за доступ к сервису, коробочная версия Битрикс24 покупается как бессрочная лицензия на использование программного обеспечения на своём сервере. Отдельно от самой лицензии оплачивается подписка на обновления и техническую поддержку — обычно на срок в один год.
Это разделение критично для планирования бюджета. Сама лицензия — это разовая инвестиция, но если не продлевать подписку на обновления, система продолжит работать в том виде, в котором была на момент окончания подписки, однако перестанет получать патчи безопасности, новые функции и совместимость с актуальными версиями PHP и других серверных компонентов. Для бизнеса, который хранит в CRM персональные данные клиентов и платёжную информацию, отказ от продления подписки на обновления безопасности — это не экономия, а риск.
При выборе редакции стоит сразу закладывать в бюджет не только стоимость самой лицензии, но и ежегодное продление, а также затраты на сервер: чем старше редакция и чем больше пользователей, тем выше требования к производительности хостинга или собственного оборудования. Экономия на редакции при заниженных требованиях к серверу — частая причина жалоб на то, что «Битрикс24 тормозит», хотя на самом деле проблема не в софте, а в несоответствии инфраструктуры реальной нагрузке.
Ещё один момент, который редко проговаривают на этапе продажи, — стоимость технической поддержки после окончания первого года подписки на обновления часто отличается от цены при первичной покупке лицензии в комплекте. Стоит заранее запросить у подрядчика или напрямую у вендора условия продления на второй и третий год, чтобы полная стоимость владения редакцией не стала сюрпризом при бюджетировании на следующий финансовый период. Это особенно важно для компаний, которые закладывают бюджет на ИТ-инфраструктуру на несколько лет вперёд и не хотят пересматривать смету из-за недооценённых расходов на продление.
Переход на старшую редакцию: что происходит с данными и доработками
Хорошая новость в том, что апгрейд редакции коробочного Битрикс24 — это не миграция на новую систему, а активация дополнительных модулей поверх существующей установки. Данные о сделках, контактах, задачах и настроенных бизнес-процессах сохраняются полностью, потому что физически это одна и та же база данных с расширенным набором доступных функций.
Но есть нюансы, которые стоит обсудить с подрядчиком заранее, до того как переход станет срочным. Во-первых, если на текущей редакции уже были сделаны кастомные доработки, которые обходили ограничения (например, самописная интеграция вместо штатного модуля), после апгрейда их стоит пересмотреть — иногда штатный модуль старшей редакции закрывает задачу лучше и стабильнее, чем обходное решение, и его стоит внедрить вместо старого кода, а не поверх него. Во-вторых, апгрейд редакции обычно требует технологического окна для обновления самой платформы до актуальной версии, потому что новые модули могут быть недоступны на устаревшей сборке. Это стоит планировать на нерабочее время или выходные, чтобы не прерывать работу отдела продаж в течение дня.
Разумная практика — не ждать, пока ограничения текущей редакции станут критичными, а закладывать ревизию использования системы раз в полгода: смотреть, какие функции сотрудники запрашивают чаще всего, и заранее прикидывать, оправдан ли переход на следующий уровень или лучше донастроить то, что уже есть в рамках текущей лицензии.
Полезно также заранее договориться с подрядчиком о формате технологического окна: делается ли апгрейд на копии базы с последующим переключением или напрямую на рабочем сервере, есть ли план отката, если после обновления модуля обнаружится конфликт с одной из существующих доработок. Компании, которые фиксируют такой регламент заранее, а не в момент аварийного апгрейда под давлением бизнеса, проходят переход на старшую редакцию без потери рабочего времени отдела продаж и без нервотрёпки для ИТ-службы.
Частые вопросы
Можно ли перейти с облачного Битрикс24 на коробочную версию без потери данных?
Да, официальный инструмент миграции переносит CRM, задачи, диск и настройки бизнес-процессов из облака в коробочную установку. Перед переносом стоит провести тестовую миграцию на резервном сервере, чтобы проверить корректность переноса кастомных полей и интеграций.
Что выгоднее для компании из 15–20 человек — облако или коробка с младшей редакцией?
Для такого масштаба чаще выгоднее облако: коробочная версия требует собственного сервера, администрирования и разового вложения в лицензию, что окупается заметно позже, чем абонентская плата за облако. Коробка становится экономически оправданной, когда компания растёт за пределы стандартных лимитов облачных тарифов или когда требования безопасности обязывают хранить данные на собственной инфраструктуре.
Можно ли купить лицензию не на всех сотрудников, а только на часть отдела?
Да, лицензируются только реальные пользователи портала, у которых есть логин и пароль для входа. Производственный, складской или обслуживающий персонал, не работающий в системе напрямую, в расчёт количества лицензий не включается.
Что будет, если не продлить подписку на обновления коробочного Битрикс24?
Система продолжит работать в текущем виде без каких-либо блокировок, но перестанет получать обновления безопасности, новые модули и совместимость с новыми версиями серверного окружения. Для компаний, работающих с персональными данными клиентов, это увеличивает риски и обычно не рекомендуется дольше одного-двух циклов обновлений.
Кто должен администрировать коробочную версию после покупки лицензии — свой ИТ-специалист или подрядчик?
Для младших редакций небольшая компания часто справляется силами штатного администратора при разовой настройке подрядчиком. Для средних и старших редакций с интеграциями, бизнес-процессами и высокой нагрузкой практичнее заключить договор на техническую поддержку с интегратором — это дешевле, чем держать в штате узкого специалиста по конкретной CMS-платформе.