Почему коробочный Битрикс24 стареет незаметно
Коробочная версия отличается от облака одним принципиальным свойством: она стоит на вашем сервере и живёт по вашим правилам. Никто извне не выкатит вам обновление ночью, не перестроит интерфейс и не сломает привычный сценарий работы. Ровно это и создаёт ложное ощущение стабильности — система работает, сотрудники в ней сидят, сделки заводятся, значит всё в порядке.
На практике деградация идёт другим путём. Компания меняется быстрее, чем CRM: появляются новые направления, меняется структура отдела продаж, добавляются юрлица, склады, каналы обращений. Каждое такое изменение решается «на скорую руку» — новым полем, новой стадией, ещё одним роботом, ещё одним самописным скриптом. Через два-три года получается система, в которой формально есть всё, но пользоваться ей неудобно, а любая новая задача упирается в фразу «у нас так исторически сложилось».
Аудит коробочного Битрикс24 — это способ вернуть систему в управляемое состояние. Не переписать всё заново, а увидеть реальную картину: на какой версии вы работаете, что именно доработано и где, что тормозит, какие процессы фактически не используются, а какие держатся на честном слове одного разработчика, который уже не работает в компании.
Пять сигналов, что коробке пора пройти проверку
Есть набор довольно надёжных признаков. Если вы узнаёте в них свою ситуацию хотя бы по двум-трём пунктам, аудит нужен не «когда-нибудь», а в ближайший квартал.
Обновления не ставились больше года. Это главный маркер. Вендор выпускает два больших релиза в год, а между ними — регулярные исправления, в том числе связанные с безопасностью. Отдельная история — мобильное приложение: оно обновляется несколько раз в месяц, и когда серверная часть отстаёт от него на год и больше, начинаются проблемы с синхронизацией. Сотрудники жалуются, что «в телефоне не то же самое, что в компьютере», а это уже прямой удар по дисциплине работы в CRM.
Интеграции начали «тихо» отваливаться. Почта, банки, мессенджеры, сервисы доставки постоянно меняют свои API. Если авторизация в каком-то из внешних сервисов перестала проходить или вебхук раз в неделю молча теряет данные — это редко проблема самого сервиса. Чаще устаревший коннектор на вашей стороне.
Никто не может внятно ответить, что доработано. Нет описания кастомизаций, нет разработчика, который вёл проект, нет тестового контура. Любое изменение делается сразу на «боевом» портале и сопровождается фразой «только не в понедельник».
Портал стал ощутимо медленнее. Особенно заметно на списках сделок с фильтрами, на карточках с большим количеством пользовательских полей и на отчётах. Часто дело не в железе, а в накопившихся данных и в неоптимальных доработках, которые с ростом базы начали тянуть систему вниз.
Сотрудники ведут параллельный учёт. Самый честный индикатор. Если рядом с CRM живёт таблица, в которой «на самом деле всё», значит система не закрывает реальный процесс — и никакие роботы этого не исправят, пока не разобраться в логике.
Что именно проверяют при аудите коробочного Битрикс24
Хороший аудит — это не «посмотрели портал и сказали, что всё плохо». Это структурированная проверка по нескольким слоям, от инфраструктуры до бизнес-логики. Ниже — та последовательность, по которой имеет смысл идти.
Версия продукта и статус подписки
Первое, что смотрят — какая версия установлена и в каком состоянии система обновлений. Проверка выполняется в административной части: раздел Marketplace > Обновление платформы. Там же видно, доступны ли обновления вообще и что предлагается установить — либо целиком через «Установить рекомендуемые обновления», либо выборочно на вкладке «Список обновлений».
Отдельно проверяется срок действия лицензии. С 2022 года новые лицензии коробочного Битрикс24 распространяются по подписке, и её окончание — не формальность. После истечения срока даётся пятнадцатидневный запас, а дальше система переходит в ограниченный режим: обновления продукта и техническая поддержка становятся недоступны. Работать портал продолжает, но развиваться перестаёт — и вместе с этим замораживаются все накопленные проблемы безопасности и совместимости.
Практический вывод: если подписка близка к окончанию, продление нужно планировать заранее. Вендор предусматривает более выгодные условия продления в определённом окне вокруг даты окончания — за 90 дней до и в течение 15 дней после, — а после этого срок начинает отсчитываться уже от момента активации, а не от исходной даты окончания.
Где живут доработки
Это самый важный пункт всего аудита, и именно здесь чаще всего вскрывается основная боль. Вопрос звучит просто: изменялись ли файлы ядра.
Платформа даёт корректный механизм для кастомизации — каталог /local/. Он поддерживается начиная с четырнадцатой версии главного модуля и обрабатывает те же типы содержимого, что и системная папка: activities, components, gadgets, modules, php_interface (в том числе init.php) и templates. При этом приоритет всегда у /local/ перед /bitrix/: если файл с одинаковым именем лежит в обеих папках, отработает файл из /local/. Смысл в том, чтобы изолировать проектный код от продуктового и спокойно обновляться.
Если же предыдущий подрядчик правил файлы внутри /bitrix/, картина другая: любое обновление либо затрёт доработки, либо не установится вовсе. На таких проектах бизнес годами не обновляется не из принципа, а из страха — и это чинится в первую очередь. Аудит фиксирует полный список правок ядра, оценивает, что из этого можно перенести в /local/, а что переписать на штатных механизмах.
Производительность и инфраструктура
Здесь помогает встроенный инструмент платформы — монитор производительности. Он позволяет оценить конфигурацию проекта, сравнить её с эталонной системой, измерить скорость генерации страниц и способность выдерживать нагрузку, а также подсветить проблемные участки. Это объективная база для разговора: вместо «нам кажется, что тормозит» появляются цифры, которые можно сравнивать до и после работ.
Параллельно проверяется всё, что вокруг: версии PHP и СУБД, объём и структура базы данных, настройки кэширования, дисковое пространство, расписание заданий, а главное — резервное копирование. Отдельный вопрос, который стоит задавать честно: когда в последний раз пробовали не сделать бэкап, а восстановиться из него. Разница между этими двумя действиями обычно и определяет, есть ли у компании реальная защита данных.
Бизнес-логика: воронки, поля, роботы
Технический слой без содержательного бесполезен. На этом этапе разбирают, как устроена работа в CRM на самом деле: сколько воронок и все ли живые, сколько стадий и понимают ли их менеджеры одинаково, сколько пользовательских полей заведено и какие из них реально заполняются.
Типичная находка — тридцать-сорок полей в карточке сделки, из которых регулярно используются восемь. Остальные создавались под задачи, которых давно нет, но продолжают занимать экран и время сотрудника. То же с автоматизацией: роботы и бизнес-процессы накапливаются слоями, часть дублирует друг друга, часть срабатывает вхолостую, а часть была отключена «на время» три года назад.
Отдельно смотрят на дисциплину данных: дубли контактов и компаний, сделки без ответственного, задачи с просроченными сроками, которые никто не закрывает. Это не про эстетику — на грязных данных не работает ни один отчёт, а значит руководитель принимает решения вслепую.
Интеграции и обмен данными
Проверяется каждая точка связи с внешним миром: телефония, мессенджеры, сайт и формы, почта, учётная система, склад, платёжные сервисы. По каждой интеграции нужно понимать три вещи — кто её делал, как она устроена технически и что произойдёт, если она перестанет работать.
Здесь же есть системный аргумент в пользу регулярных обновлений: часть современных возможностей платформы опирается на облачную инфраструктуру вендора, а внешние сервисы меняют свои интерфейсы независимо от вас. Коробка, которая не обновляется, постепенно теряет способность разговаривать с окружающим миром — и делает это тихо, без явных ошибок на экране.
Права доступа и безопасность
Последний слой — кто и что видит. Аудит показывает, у скольких сотрудников фактически права администратора, остались ли активными учётные записи уволенных, разграничен ли доступ к клиентской базе между отделами, кто может выгружать данные списком. В коробочной версии этот вопрос острее, чем в облаке, потому что вместе с порталом вы владеете и сервером, и всей базой целиком.
Мини-проверка своими силами за один вечер
Полноценный аудит требует подрядчика или сильного внутреннего специалиста, но первичную диагностику руководитель может провести сам — и часто этого достаточно, чтобы понять масштаб. Пройдитесь по шести вопросам и запишите ответы.
Какая у нас версия и когда её последний раз обновляли? Ответ ищется в административной части, в разделе обновления платформы. Если никто в компании не знает, где это смотреть, — это уже ответ.
Когда заканчивается подписка? Дата должна быть известна заранее, а не всплывать за неделю до окончания.
Есть ли у нас тестовая копия портала? Если все изменения делаются сразу на рабочей системе, любая доработка — это риск остановки отдела продаж.
Кто последний раз восстанавливался из резервной копии и когда? Не «делаем ли мы бэкапы», а именно восстанавливались ли. Формулировка принципиальна.
Сколько людей имеют полные права администратора? Считать нужно поимённо. Цифра больше двух-трёх на компанию до сотни человек почти всегда означает, что права раздавались ситуативно.
Сколько полей в карточке сделки и сколько из них заполнено хотя бы в половине сделок? Разрыв между этими двумя числами — прямая мера того, насколько система оторвалась от реального процесса.
Шесть ответов дают достаточно честную картину, чтобы решить, звать ли подрядчика и с каким запросом. Если хотя бы три из них звучат как «не знаю» — вопрос не в том, нужен ли аудит, а в том, насколько срочно.
Как это выглядит на практике
Приведём иллюстративный пример — собирательный, но узнаваемый для большинства проектов, с которыми мы работаем.
Производственная компания, около семидесяти пользователей, коробочный портал развёрнут пять лет назад. Обращение звучало предсказуемо: «CRM тормозит, менеджеры жалуются, хотим переехать в облако».
Проверка показала, что переезд не был нужен. Портал отставал от актуальной версии более чем на два года — обновления не ставили, потому что предыдущий подрядчик правил файлы ядра, и любая попытка обновления ломала карточку сделки. Сама «медлительность» складывалась из трёх факторов: устаревшая версия PHP на сервере, отключённое кэширование после какого-то давнего инцидента и самописный обработчик, который при каждом открытии списка сделок делал запрос во внешнюю систему по каждой строке.
План работ вышел на три этапа. Сначала — развернули копию портала на тестовом контуре и перенесли доработки из ядра в /local/. Затем последовательно установили обновления и проверили на копии, что ничего не отвалилось. И только потом занялись инфраструктурой и переписали проблемный обработчик так, чтобы он не дёргал внешнюю систему в цикле.
Отдельным блоком шла чистка: из тридцати восьми пользовательских полей в сделке оставили четырнадцать, из одиннадцати воронок — четыре, отключили девять роботов, которые никак не влияли на процесс. Сотрудникам это дало больше, чем любая оптимизация сервера: карточка перестала быть анкетой на две страницы.
Важный нюанс: ни один из этих шагов не был «доработкой ради доработки». Каждый закрывал конкретную причину, найденную на этапе проверки. Именно поэтому аудит должен предшествовать работам, а не идти параллельно с ними.
Что делать с результатами
По итогам проверки решения обычно распадаются на четыре категории, и полезно раскладывать их именно так — это сразу превращает отчёт в план.
Срочно. Всё, что связано с потерей данных и безопасностью: неработающие бэкапы, доступы уволенных сотрудников, критическое отставание по обновлениям, истекающая подписка. Здесь не обсуждают целесообразность — просто делают.
Обязательно, но по плану. Перенос доработок из ядра, приведение сервера к актуальным версиям окружения, переписывание проблемных мест. Это основная часть бюджета и основной источник эффекта.
Чистка. Поля, воронки, роботы, права, дубли. Самая недооценённая категория: стоит недорого, а на удовлетворённость пользователей влияет сильнее всего. Здесь есть одно правило, которое экономит много нервов: ничего не удалять безвозвратно на первом шаге. Лишние поля сначала скрываются из карточки, лишние воронки — закрываются от создания новых сделок, роботы — отключаются. Если через месяц никто не хватился, изменение фиксируется окончательно. Такой порядок снимает главное возражение сотрудников — «а вдруг это было нужно».
Развитие. Новые сценарии, автоматизация, отчётность для руководителя. К этому переходят, когда фундамент приведён в порядок — иначе новая функциональность строится на песке.
Отдельный вопрос, который почти всегда всплывает: не проще ли перейти в облако. Иногда действительно проще — если доработок мало, инфраструктура обходится дорого, а поддерживать сервер внутри некому. Но если у вас сложная бизнес-логика, требования к размещению данных или глубокая интеграция с учётной системой, коробка остаётся оправданным выбором, и правильный ответ — привести её в порядок. Мы обсуждаем оба сценария честно, без попытки продать более дорогой: если нужен взгляд со стороны, посмотрите наши услуги по Битрикс24 — аудит существующего портала мы делаем как отдельную работу, не привязывая её к обязательному внедрению.
Сколько это занимает и что остаётся у вас на руках
Полноценная проверка коробочного портала среднего размера — это работа порядка одной-двух недель, из которых основное время уходит не на технический осмотр, а на разговоры с людьми. Администратор рассказывает про сервер, руководитель отдела продаж — про то, как процесс устроен на самом деле, менеджеры — про то, что бесит в ежедневной работе. Расхождение между этими тремя картинами обычно и есть главная находка.
На выходе заказчик должен получить не презентацию, а рабочие документы: описание текущего состояния системы с версиями и конфигурацией, полный перечень доработок с указанием, где именно лежит код, список рисков с приоритетами, план работ с оценкой трудозатрат и — что часто забывают — регламент дальнейшего сопровождения. Последний пункт важнее, чем кажется: аудит без регламента через год приводит ровно к той же ситуации.
Регламент при этом простой. Плановое обновление с проверкой на тестовой копии — минимум раз в квартал, а лучше по мере выхода значимых релизов. Проверка резервных копий с пробным восстановлением. Ревизия прав доступа при каждом изменении в штате. Фиксация любой новой доработки в едином описании — где лежит, что делает, кто автор. Это дисциплина, а не технология, и держится она на назначенном ответственном, а не на добрых намерениях.
И ещё одно наблюдение, которое стоит проговорить прямо. Доработка CRM-системы почти никогда не начинается с кода. Она начинается с решения о том, какой процесс вы хотите получить — и только потом превращается в поля, стадии и роботов. Коробочный Битрикс24 даёт для этого больше свободы, чем облако, но ровно поэтому требует больше осознанности: система будет ровно такой, какой вы её спроектировали, включая все компромиссы, принятые впопыхах пять лет назад.
Частые вопросы
Как понять, что коробочный портал сильно устарел, не привлекая подрядчика?
Посмотрите в административной части раздел Marketplace > Обновление платформы — там видно текущую версию и доступные обновления. Если обновления не ставились больше года, этого уже достаточно, чтобы считать ситуацию требующей внимания: за такой срок выходит несколько крупных релизов и множество исправлений, включая связанные с безопасностью.
Что будет, если не продлевать подписку на коробочный Битрикс24?
Портал не выключится сразу. После окончания срока действует пятнадцатидневный период, а затем система переходит в ограниченный режим: перестают быть доступны обновления продукта и техническая поддержка. Работать сотрудники продолжат, но система фактически замирает в текущем состоянии со всеми накопленными уязвимостями и проблемами совместимости.
Можно ли обновиться, если предыдущий подрядчик правил файлы ядра?
Можно, но не «в лоб». Сначала правки нужно инвентаризировать и перенести в каталог /local/ или переписать на штатных механизмах платформы, затем проверить всё на копии портала и только после этого обновлять рабочую систему. Порядок здесь принципиален — попытка обновиться первой обычно и приводит к тому, что проект надолго остаётся без обновлений.
Аудит обязательно заканчивается большой доработкой?
Нет. Довольно часто основной эффект дают дешёвые действия: обновление, приведение окружения в порядок, чистка неиспользуемых полей и воронок, наведение порядка в правах доступа. Крупная разработка нужна тогда, когда бизнес-процесс изменился настолько, что текущая конфигурация его физически не описывает.
Чем аудит коробки отличается от аудита облачного Битрикс24?
Содержательная часть — воронки, поля, автоматизация, дисциплина данных — совпадает. Разница в техническом слое: в коробке добавляются сервер, версии окружения, резервное копирование, состояние системы обновлений и, главное, кастомный код, которого в облаке в таком виде просто нет.