Вопрос про облако и коробку возникает почти в каждом проекте, и почти всегда его задают слишком рано — до того, как понятно, какие процессы нужно автоматизировать. Разбираем, чем версии отличаются на практике и в каких случаях выбора действительно нет.
Коротко о разнице
Облачный Битрикс24 работает на серверах вендора: вы платите за подписку и получаете готовый портал, который обновляется сам. Коробочная версия ставится на ваш сервер: вы получаете доступ к коду, полный контроль над данными и возможность дорабатывать систему на PHP — но и отвечаете за инфраструктуру.
Всё остальное — следствия этих двух пунктов.
Деньги
Облако — регулярный платёж, который зависит от числа сотрудников. Коробка — разовая покупка лицензии плюс ежегодное продление техподдержки, плюс сервер, плюс администрирование. На старте коробка заметно дороже, но на большой команде разница в подписке начинает играть в другую сторону.
Считать нужно на горизонте трёх лет и обязательно с инфраструктурой: сервер, резервные копии, обновления, время системного администратора. Забыть про эти расходы — типичная ошибка при переходе на коробку.
Сроки запуска
Облако разворачивается за день, и настройка процессов начинается сразу. Коробка требует подготовки: сервер, окружение, установка, проверка. Плюс время на согласование доступов, если в компании есть служба информационной безопасности. На практике разница в старте — от недели до месяца.
Доработки
В облаке доступны приложения, вебхуки и REST API — этого хватает для подавляющего большинства задач: интеграции, автоматизация, свои интерфейсы поверх портала. Чего нельзя — менять само ядро системы.
В коробке доступен код, и это решает задачи, которые в облаке не решаются в принципе: нестандартная логика внутри CRM, тяжёлые отчёты по большим массивам, интеграции с системами, которые не выпускают данные наружу.
Когда коробка обязательна
- Данные не должны покидать контур организации — требование безопасности или отраслевого регулятора
- Работа с персональными данными по 152-ФЗ в конфигурации, где хранение на стороне вендора не согласовано
- Интеграция с внутренней системой, доступной только внутри локальной сети
- Отраслевые требования к аттестации инфраструктуры
Чаще всего это клиники, государственные и муниципальные учреждения, компании с гостайной или с жёсткой политикой безопасности. Для них мы разворачиваем коробочный портал на своём сервере — подробнее в услуге внедрения. Если вы не в этом списке — вероятнее всего, облако закроет ваши задачи.
Частое заблуждение про 152-ФЗ
Считается, что закон о персональных данных автоматически запрещает облако. Это не так: облачный Битрикс24 размещается на серверах в России, и работать с персональными данными в нём можно. Вопрос в том, какие именно данные вы обрабатываете, какой у вас класс защищённости и что записано во внутренних документах.
Поэтому решение принимается не по названию закона, а по конкретным требованиям к вашей системе. Нередко после разбора выясняется, что облака достаточно, а коробку хотели «на всякий случай».
Что мы советуем в большинстве случаев
Начинать с облака, если нет жёстких требований к хранению данных. Причина простая: на старте главная задача — заставить процессы работать, а не выбрать инфраструктуру. Переехать в коробку позже можно, и это делается штатно; а вот полгода настраивать сервер вместо настройки продаж — потерянное время.
Если требования есть — сразу коробка, и тогда в проект закладывается подготовка инфраструктуры и сопровождение. Промежуточный вариант «начнём в облаке, а потом решим» тут не работает: переносить настроенную систему дороже, чем сразу поставить её там, где она должна жить.
Что происходит при переезде
Переход из облака в коробку — штатная процедура: данные переносятся, структура сохраняется. Но это отдельный проект со своим бюджетом и сроком, а не бесплатная операция в один клик. Нужно подготовить сервер, перенести данные, перепроверить интеграции и права, обучить администратора.
Обратный переезд, из коробки в облако, сложнее: доработки, написанные под коробочную версию, в облаке работать не будут, их придётся переносить на API. Поэтому если вероятность жёстких требований к данным высока, лучше обсудить это до старта, а не после года работы.
Кто будет администрировать коробку
Коробочная версия — это сервер, который кто-то должен обслуживать: обновления платформы, резервные копии, мониторинг доступности, сертификаты, разбор инцидентов. У крупной компании для этого есть системный администратор. У небольшой чаще всего нет, и тогда эти работы идут в сопровождение к подрядчику.
Это не аргумент против коробки, но это статья расходов, которую забывают посчитать. Портал, который не обновляют полтора года, однажды перестаёт работать в самый неподходящий момент, и восстановление обойдётся дороже, чем регулярное обслуживание.
Коробка — это не только лицензия, но и сервер, обновления и бэкапы. Посчитайте эти расходы до решения, а не после.
Короткий алгоритм выбора
- Есть ли требование хранить данные внутри своего контура? Если да — коробка, вопрос закрыт
- Нужны ли доработки внутри ядра системы, которые не решаются через API? Если да — коробка
- Есть ли кому обслуживать сервер или бюджет на сопровождение? Если нет — облако
- Нужно ли запуститься в ближайшие недели? Если да — облако
- Во всех остальных случаях начинайте с облака и возвращайтесь к вопросу через год
Разберём требования к данным и процессам на бесплатном аудите и скажем, где именно стоит разворачивать систему.
