B2BPRO.KZ | Рекламное агентство в Алматы

Стоимость владения коробочным Битрикс24: из чего складывается бюджет

Руководитель за ноутбуком считает бюджет владения коробочным Битрикс24, рядом серверная стойка

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

Почему счёт за лицензию — это не бюджет проекта

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

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

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

Слой первый: лицензия и её ежегодное продление

Лицензии коробочного Битрикс24 выдаются на 12 месяцев. Это относится ко всем актуальным редакциям — «CRM», «Интернет-магазин + CRM», «Корпоративный портал» в вариантах на 50, 100, 250 и 500 пользователей и «Энтерпрайз». По истечении года лицензию нужно продлевать на следующие 12 месяцев, и именно здесь возникает первая регулярная статья бюджета.

С 1 ноября 2025 года вендор изменил правила продления, и разница между двумя сценариями стала принципиальной. Льготное продление стоит 30% от полной стоимости лицензии и оформляется в определённом окне: не раньше чем за 90 дней до окончания срока и не позднее 15 дней после его истечения включительно. Если после окончания лицензии прошло больше 15 дней, продление становится стандартным — то есть 100% полной стоимости лицензии.

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

Второй нюанс — количество пользователей. Редакции «Корпоративный портал» продаются пакетами, и переход с пакета на 100 пользователей на пакет на 250 — это не плавное увеличение платежа, а ступенька. Если вы планируете рост штата, закладывайте в бюджет на CRM не текущее число сотрудников, а прогнозное на конец следующего года, и уточняйте условия перехода между редакциями заранее, а не в момент, когда 101-й сотрудник уже вышел на работу.

Слой второй: сервер и системное окружение

Коробка живёт на вашем железе или на вашем арендованном сервере, и это самая недооценённая часть бюджета. Официальные технические требования задают нижнюю границу, которая для боевой эксплуатации почти всегда мала: минимум 2 ГБ оперативной памяти и минимум 10 ГБ дискового пространства без учёта операционной системы.

Реальные рекомендованные конфигурации выглядят иначе и зависят от числа пользователей. Для портала до 50 человек вендор ориентирует на сервер уровня 8-ядерного процессора с 16 ГБ оперативной памяти и связкой из HDD большого объёма и SSD под систему. Для 50 — 100 пользователей — те же ядра, но уже 24 ГБ памяти, для 100 — 500 — 32 ГБ. Для 500 — 1000 пользователей рекомендация повышается до 12 ядер и 64 ГБ памяти, для 1000 — 5000 — до 128 ГБ, а свыше 5000 пользователей речь идёт уже о двух серверах.

Дальше — системное ПО. Продукт работает на PHP, и минимальная поддерживаемая версия — PHP 8.2. Это не рекомендация, а условие: без обновления PHP до актуальной версии вы просто не сможете устанавливать обновления продукта. Из баз данных поддерживается MySQL 8.x, причём в качестве рекомендованной сборки называется Percona Server; PostgreSQL версии 11 и выше доступен только в связке с отдельной Enterprise-лицензией под Postgres. Oracle и MSSQL не поддерживаются вовсе — если у вас корпоративный стандарт на MSSQL, это нужно знать до подписания бюджета, а не после.

В качестве веб-сервера рекомендован Apache 2.4.x; nginx версии 1.16 и выше тоже работает, но требует самостоятельной настройки, то есть дополнительных часов администратора. Нужен набор расширений PHP — GD, XML, FreeType, поддержка регулярных выражений, Zlib; рекомендуется включённый OPcache, а параметр memory_limit имеет смысл держать не ниже 256 МБ. Чтобы не собирать всё это вручную, вендор предлагает готовое веб-окружение BitrixEnv и виртуальную машину BitrixVM; окружение рассчитано на Linux-дистрибутивы девятого поколения — CentOS Stream 9, AlmaLinux 9.x, Rocky Linux 9.x, Oracle Linux 9.x в архитектуре x86_64.

Отдельная строка — SSL-сертификат и публично доступный адрес портала. Это не косметика: без валидного сертификата (самоподписанный не подойдёт) и корректно настроенного внешнего адреса вы не получите доступ к технической поддержке вендора. То есть экономия на сертификате автоматически обнуляет часть того, за что вы уже заплатили в лицензии.

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

Слой третий: администрирование и цикл обновлений

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

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

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

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

Слой четвёртый: внедрение, доработки и интеграции

Открытый исходный код — главная причина, по которой компании выбирают коробку. В облаке доступен REST API и не более того; в коробке вы можете писать собственные модули, менять поведение системы через PHP и JavaScript, встраиваться в бизнес-логику на уровне, недоступном в облачной версии. Это огромное преимущество и одновременно самый непредсказуемый слой бюджета.

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

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

Интеграции считаются отдельно: телефония, 1С, сайт, мессенджеры, платёжные шлюзы. Здесь важно заранее понимать, какие из них реализованы через облачные сервисы вендора — этот момент напрямую влияет на то, что произойдёт с системой, если лицензия окажется непродлённой. Мы обычно проектируем эту часть на этапе аудита процессов: если вам нужен разбор конкретного контура, посмотрите внедрение и настройка Битрикс24 — там описан наш подход к предпроектному обследованию и к тому, как мы фиксируем объём работ до старта, а не по факту.

Слой пятый: люди, обучение и сопровождение пользователей

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

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

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

Что произойдёт, если лицензию не продлить

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

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

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

Как посчитать бюджет на три года: пример

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

Год первый. Лицензия соответствующей редакции — разовый платёж. Сервер: аренда выделенного сервера, укладывающегося в рекомендации для 50 — 100 пользователей, помесячно; плюс тестовый контур меньшей мощности; плюс SSL-сертификат. Внедрение: обследование процессов, настройка воронок и прав доступа, перенос данных из старой системы, интеграция с 1С и телефонией, обучение двух групп сотрудников. Администрирование: настройка окружения, регламент бэкапов, первичная установка обновлений.

Год второй. Лицензия — льготное продление, то есть 30% при условии, что вы уложились в окно. Сервер и тестовый контур — те же ежемесячные платежи, возможно с небольшим ростом из-за увеличения объёма данных. Администрирование — регламентные обновления, теперь это плановые часы. Доработки — то, что не вошло в первый этап: дополнительные отчёты, автоматизация, доработка по итогам первого года эксплуатации. Обучение новых сотрудников.

Год третий. Лицензия — снова льготное продление. Инфраструктура — возможен апгрейд сервера, если выросло число пользователей или объём файлов. Администрирование — те же плановые часы плюс, вероятно, разовый проект по переезду на новую версию PHP или обновлению операционной системы: за три года требования к окружению успевают измениться. Сопровождение доработок — ревизия кастомных модулей.

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

Когда коробка оправдана экономически, а когда нет

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

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

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

И последнее, что стоит держать в голове при защите бюджета перед собственником. Стоимость коробочного Битрикс24 определяется не ценой лицензии, а качеством эксплуатации. Компания с регламентом обновлений, тестовым контуром и внутренним владельцем системы платит за коробку предсказуемо и получает ровно тот инструмент, за который заплатила. Компания без этих трёх вещей платит столько же за лицензию, а потом ещё раз — за разбор последствий. Разница между двумя сценариями измеряется не в проценте скидки, а в том, есть ли у системы хозяин.

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

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

Сколько стоит продление лицензии?
С 1 ноября 2025 года действуют два варианта. Льготное продление — 30% от полной стоимости лицензии, оформляется не раньше чем за 90 дней до окончания срока и в течение 15 дней после его истечения включительно. Стандартное продление — 100% стоимости лицензии, если с момента окончания прошло больше 15 дней.

Портал перестанет работать, если не продлить лицензию?
Нет, портал продолжит работать, но с ограничениями. Станут недоступны обновления продукта и техподдержка вендора, а также Маркетплейс, облачные модули, REST-методы и события, облачная телефония с SIP-коннектором, открытые линии, облачные резервное копирование и мониторинг, интеграции с внешними сервисами и функции ИИ в CRM.

Какой сервер нужен для коробочного Битрикс24?
Минимальные требования — 2 ГБ оперативной памяти и 10 ГБ дискового пространства без учёта операционной системы, PHP версии 8.2 и выше, MySQL 8.x, веб-сервер Apache 2.4.x (либо nginx 1.16+ с самостоятельной настройкой). Рекомендованные конфигурации зависят от числа пользователей: например, для портала на 50 — 100 человек ориентир — 8 ядер и 24 ГБ оперативной памяти.

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

Прокрутить вверх