Когда облака Битрикс24 уже мало: коробка не «круче», а про контур и доработки

Коробка Битрикс24 нужна не ради статуса. Она про контур данных, тяжёлые доработки и учёт, который не хочет жить только в чужом облаке. «Давайте сразу коробку» часто значит переплатить за админов, которых нет. Облака мало — когда упираетесь в лимиты и контур, не в самолюбие IT. Пока не упёрлись, облако честнее: вендор патчит, вы продаёте.

Три схемы: облако хватает / коробка по делу / ещё рано

Облако хватает

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

Коробка по делу

Контур: юридически или по ИБ данные не могут лежать у вендора в облаке. Тяжёлый кастом: свои модули, которые облако не переживёт. Свой контур 1С и обмен, который IT уже держит на серверах и не хочет тащить в чужой SaaS. Офлайн-сценарии, которые облако не закрывает. Это не «коробка круче». Это другая эксплуатация. Бюджет админки — часть решения, не мелочь после КП.

Ещё рано

Фразы-маркеры. «Как у крупных». «Чтобы никто не лез». «Нам точно понадобится через год». «IT хочет потрогать сервер». Если живой боли нет, коробка — аванс за сложность. Год облака дешевле урока «мы не готовы патчить». Переезд облако → коробка существует. Обратный тоже, но его затевают реже и злее. Не стартуйте с редкого манёвра без причины.

Лимиты облака реальны: пользователи, место, некоторые автоматизации — по тарифу вендора. Статья не таблица тарифов: тарифы меняет вендор. Правило другое. Сначала измерьте, упёрлись ли вы. «Нам мало», пока в портале сидят 12 человек и два робота, — обычно не лимит, а нежелание вычистить поля. Коробка это не лечит.

На проекте: коробка «как у больших»

Производственная компания, IT из одного совместителя. Настояли на коробке до запуска продаж: «данные наши». Сервер купили. Обновления откладывали «когда будет окно». Окно не наступило. Через месяцы встал вопрос безопасности уже не контура, а непропатченного коробочного портала. Продажи при этом жили в тех же стадиях, что спокойно живут в облаке.

Контур хотели. Эксплуатацию — нет. Получили сервер как символ. Символ не открывал карточки на звонке. Когда честно спросили, какая боль кроме «наши данные», осталась одна: привычка IT держать железо. Это не достаточная причина, пока нет политики ИБ, которая это требует.

Не уговаривали «облако всегда лучше». Зафиксировали: либо появляется человек на обновления и бэкапы, либо контур остаётся требованием на бумаге. Для воронки хватило облака. Коробку отложили до внятного ИБ, не до обиды IT. С чего начинать контур продаж — снова узкий запуск, он не зависит от шкафа в серверной.

Сравнение «какая CRM лучше» здесь ни при чём: выбор Битрикс24 уже сделан, спор про поставку. Чужой текст сравнения CRM про другой вопрос. Здесь — облако или коробка внутри уже выбранной платформы. Деньги работ — на странице стоимости и услугах, не как аргумент «коробка престижнее».

Контур, кастом, админ — три разных вопроса

Контур. Юрист или служба ИБ говорят: карточки клиентов не могут лежать у вендора. Тогда разговор про коробку честный. Пока этого письма нет, «наши данные» — ощущение, не требование. Ощущение дорогое, если за ним нет регламента бэкапов и доступа к серверу.

Кастом. Своё приложение, которое лезет глубоко в портал и падает после обновления облака. Иногда коробка даёт контроль над окном обновлений. Иногда она даёт иллюзию контроля: обновления всё равно нужны, просто теперь вы их боитесь сами. Если кастом можно сделать внешним сервисом по REST — чаще так и надо, без смены поставки.

Админ. Человек, который любит железо, сертификаты, ночные окна, мониторинг. Без него коробка — не контур, а отложенный инцидент. Совместитель «когда будет время» — не админ. Время не появится в сезон продаж. Облако в этом месте честнее: патчит вендор, вы занимаетесь воронкой.

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

Что проверить, прежде чем купить шкаф

Есть ли письменное требование ИБ или договор, который запрещает облако. Есть ли человек на обновления, не «потом наймём». Есть ли доработка, которую облако уже отказалось переваривать — не гипотеза. Упёрлись ли в тариф так, что это видно в кабинете вендора, а не в разговоре «нам мало души».

Если ни одного да — коробка подождёт. Вы не обязаны быть «несерьёзными» из-за облака. Серьёзность — карточка на звонке, нить письма, права после увольнения. Шкаф к этому не прилагается. Иногда мешает: внедрение продаж стоит в очереди за сервером.

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

Ещё маркер «рано»: внедрение продаж ещё не начинали, а уже выбирают гипервизор. Сначала карточка на звонке в облаке. Железо подождёт. Если ИБ запрещает облако до старта — это честный контур, и тогда коробка идёт первым этапом инфраструктуры, но продажи всё равно запускают узко, не «раз уж сервер есть, включим всё».

Кастом «напишем себе как SAP». Облако это переживает плохо, коробка — тоже, если нет команды на сопровождение модуля. Честный путь: внешний сервис и REST, пока можно. Шкаф ради одного скрипта — дорогая обида на тариф вендора.

Что не делать

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

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

Коротко по вопросам

Нужна ли коробка, чтобы были бизнес-процессы?

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

1С на своём сервере — уже повод для коробки CRM?

Повод поговорить. Не автоматический да. Обмен облачной CRM и своей 1С делают часто. Коробка нужна, когда контур требует оба контура у себя, не когда 1С просто «своя» и IT привыкло к шкафу. Привычка — слабый ИБ-регламент.

Можно ли начать в облаке и переехать?

Да. Это нормальный путь, если боль контура появилась позже. Хуже — купить коробку «впрок» без админки. Переезд — проект, не кнопка. Не обещайте выходные. Не пугайте им первый месяц без боли.

Коробка спасёт, если менеджеры не работают в CRM?

Нет. Это люди и правила, не поставка. Сервер не заставит заполнять карточку и не отменит Excel. Сначала доска в облаке, которая живёт. Потом, если надо, шкаф. Иначе вы перенесёте саботаж ближе к железу.

Нужна ли коробка ради «чтобы данные не украли из облака»?

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

Кто это внедряет?

Иван Остривной, NAVIPOINT, партнёр Битрикс24. Выбор облако / коробка делают на консультации по контуру, доработкам и наличию админки. Не по фразе «хотим как крупные».

Читайте по теме

• Битрикс24 по подписке или проект под ключ: считать TCO, не «человеко-часы подрядчика»
• Аудит уже живого Битрикс24: чеклист «что сломалось за год», не предпроект
• Кастомизация Битрикс24 под специфику вашего бизнеса