В нише внедрения CRM принято публиковать только истории успеха. У всех на сайте «выручка выросла на 47%», «время цикла сделки сократилось в 2,3 раза», «менеджеры довольны, дашборды красивые». Это создаёт у рынка ложное впечатление, что внедрение CRM — почти всегда удачное.

Это не так. По нашим внутренним наблюдениям, 15–20% проектов заканчиваются провалом разной степени: от тихого саботажа со стороны команды до полного отказа клиента от системы через 3–6 месяцев после запуска. Системные причины этих провалов одинаковые, и о них почти никто не пишет.

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

Все детали обезличены, цифры реальные.

Если вы разрабатываете на Битрикс24 и поддерживаете несколько окружений — тест, стейдж, прод — вы знаете эту боль. Настроил воронку, добавил пользовательские поля, написал робота с десятком условий, всё это поправил в карточке, назначил права. А потом нужно повторить то же самое на проде. Руками. Забыв половину.

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

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

Мы прошли этот путь и в итоге написали набор Version Builder'ов для модуля sprint.migration, покрывающих основные сущности CRM Битрикс24. В этой статье — о самой задаче, подходе и подводных камнях.

Пишите в личку по вопросам.

Если вы веб‑разработчик и хоть раз подключали шрифт «потому что он красивее, чем системный Arial» — есть ненулевая вероятность, что у вас на сайте лежит коммерческий гарнитур без лицензии. Российский бизнес три‑пять лет назад массово открыл для себя, что это не безобидно: за период 2021–2025 годов через арбитражные суды по шрифтовым искам взыскано 15,3 млн ₽ (данные Коммерсанта), число исков выросло в 2,5 раза за пять лет, и тренд продолжается.

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